今天去面試時，面試官拋出了一個問題：「如果是設備監控系統，當同時有 1000 台以上的設備回傳狀態時，你會怎麼寫入資料庫？」
當時的我根本沒遇過高頻跟高併發的情境，當下只是滿頭問號看著他，心想：「阿不就把資料寫進資料庫嗎？寫個 INSERT INTO 語法不就好了，這有什麼好問的？」
想當然爾，面試結束後我還是一臉懵，直到回來的路上跟學姊討論才發現原來資料量大到一個程度時會產生「高頻海量數據寫入」的致命效能瓶頸，這瞬間激起了我的好奇心於是在回程的車上我直接開了 Gemini 一路追問到底，這才終於推開了後端架構的另一扇大門也深刻體會到自己原本的想法有多麼井底之蛙，這篇筆記就是這趟探索之旅的總結。
最近網路上有許多關於哪家 AI 比較聰明的討論，大家常把焦點放在 AI 的「通靈能力」、也就是猜測隱性需求的能力上，但經過這陣子的實戰摸索，我發現除了模型本身的聰明程度之外，我們如何去「使用」它，反而才是決定開發體驗的關鍵。
最近找工作連續遇到幾次讓我大開眼界的「奇葩面試」，實在不吐不快。
決定寫下來抒發一下順便當作紀錄，找工作大家多少都會急，但千萬不要因為想趕快拿到 Offer，就無視了這些公司在面試流程中狂刷的「紅旗」（Red Flags）。
最近在使用 AI Agent 輔助開發時，發生了一件讓我冷汗直流的小慘案。
我請 AI 幫忙整理專案的 Markdown 文件，改了一大堆檔名。整理完後，我很順口地對它說：「給我部署指令。」
沒想到，它就像個聽到關鍵字的機器人，毫不猶豫地吐出了標準的 git push 指令。我一貼上終端機，過了不到一分鐘，GitHub Actions 就亮起了大紅燈——因為一堆舊連結沒更新，觸發了 Docusaurus 的 Broken Links 死結檢查，部署直接中斷。
當下我滿腦子問號：「等等，我明明就在專案的 .agent 檔案裡規定過，部署前絕對要先跑 npm run build 測試啊！你為什麼沒有照做？」
深入挖掘後，我發現了 AI Agent 在系統協作上一個非常致命的弱點：隧道視覺 (Tunnel Vision)。
在日常的開發與生活中，我們總會遇到需要一些小工具來輔助的時候。網路上雖然有很多免費的線上工具，但它們往往充斥著滿滿的廣告，或是剛好「缺了那麼一點點」我們需要的功能。
為了不再將就，我決定自己動手，打造一個乾淨、快速，且完全符合自己需求的專屬工具箱 —— LiTool (https://litool.liwen.studio)。
現在是 AI 橫行的時代，我認為這對軟體工程師的職涯發展產生了深遠的影響。
過去，只要具備專業的程式開發能力——不管是前端、後端或是其他軟體工程技能，要找到一份不錯的工作並非難事。然而，隨著 AI 發展日益迅速，市場上「純粹寫扣」的初階工程師職缺反而變少了。
做前端開發或靜態網站管理（例如這個 Docusaurus 數位花園）時，我們常常會把 git push 和自動部署串在一起。但這衍生出一個惱人的日常痛點：每次 push 完，你總是要打開瀏覽器、點開 Actions 標籤、然後傻傻地按 F5 重新整理，直到進度條跑完為止。
這不僅中斷開發心流，還非常破壞開發者體驗 (DevEx)。
為了解決這個問題，我開發並開源了一個超輕量級的 CLI 工具：ghaction-lis！
身為一名後端工程師，我們經常需要實作一些自動化的小工具，例如：
在過去，要做到這些事，大部分人的直覺反應都是：npm install discord.js。
但問題來了：如果你只是想「單向」地發送一則通知，或者只是想寫一個架設在 AWS Lambda 或 Vercel 等 Serverless 平台上的輕量腳本，殺雞真的需要用牛刀嗎？
在與 AI 協作的過程中，你是否曾產生過一種不適感？
這是一種微妙的「程式開發恐怖谷效應」。當 AI 在程式碼撰寫、邏輯推演上都展現出超越人類的能力時，我們不禁會產生懷疑：我們真的比 AI 厲害嗎？如果我硬要介入技術細節，反而成為了 AI 發揮能力的絆腳石？
這是我近期深刻的迷惘。
身為工程師，我們最怕的不是複雜的演算法，而是那種「邏輯斷層」的溝通。最近在思考職場定位時，有感而發想聊聊一個現象：為什麼有些優化專案，最後會變成技術人員的災難？
當「技術優化」的口號響起，如果缺乏清晰的業務定義，工程師往往會從「解決問題的人」變成「幫人通靈的人」。這不僅是效率的浪費，更是對專業價值的消耗。