AI 是放大鏡：好的越好、爛的越爛
我以為 AI 會幫我加速，結果它也順手把我的壞習慣加速了。
我以為 AI 會幫我加速，結果它也順手把我的壞習慣加速了。
幸運地能處在 AI 爆發的時代，真的有點爽。
很多事情以前要花幾天，現在幾個小時就能長出來。
畫面有了（雖然我還是在摸索網頁設計、UI/UX），功能有了，流程看起來也跑得動。
那種感覺很容易讓人產生一種錯覺：
好像只要把目的和方向講清楚，後面就沒我的事了 😆
一開始我只是拿 AI 做一些小工具。
個人用嘛，能跑就好，長得差一點也沒關係。
但做了幾個之後，我開始有點膨脹。
覺得 AI 真的很強。
好像什麼東西都可以丟給它。
然後我就開始把它用在一些比較正式的專案上。
這時候問題就開始了。
我開始把很多細節交給 AI。
或者更準確地說，是把一部分「思考」外包出去：
- 技術選型
- 架構安排
- 資料流
- 模組邊界
- 一些我其實沒有完全理解的 term
- 一些我心裡想說「反正 AI 應該懂」的地方
短期看起來真的很有效率。
什麼？你要一個 XXX 功能？
好啊，1 小時後給你 😆
但那時候我還沒意識到：
AI 不只會加速我想做的事。
它也會加速我沒想清楚的地方。
我突然發現：我失去對系統的掌握了
該來的還是來了。
有一天我突然意識到：
怎麼會這樣？
我竟然失去對系統的掌握了。
於是我終於開始回顧這段時間跟 AI 的協作。
失控不是突然發生的。
系統也不是一天壞掉的。
它是一點一點變得難維護。
一開始只是：
這段 code 好像有點怪，但先能跑就好。
後來變成：
這個設計為什麼是這樣？算了，叫 AI 幫我改。
再後來變成：
我不太確定這個 term 是什麼意思，但整個系統好像都在用它。
最後變成：
我現在到底是在維護系統，還是在維護 AI 上次幫我製造的混亂？
這時候我才意識到，真正失控的不是 AI。
是我把本來應該由人類負責的控制面放掉了。
AI 不是單純的加速器，它更像放大鏡
這是我這段時間最大的反思：
AI 不是單純的加速器。
它更像放大鏡。
它會放大好的東西：
- 清楚的需求
- 小而明確的任務
- 穩定的技術棧
- 好的測試
- 明確的驗收標準
- 良好的文件
- 清楚的 ownership
但它也會放大爛的東西：
- 模糊需求
- 沒想清楚的架構
- 隨手試試看的技術選型
- 沒有測試
- 沒有驗收
- 沒有人真正理解的 code
- 「先讓 AI 寫看看」的僥倖心態
所以它不是讓好的越好而已。
它也會讓爛的越爛。
而且速度很快，快到人類有時候追不上。
模糊需求，對 AI 來說是創作授權
對人類來說，模糊需求是溝通成本。
對 AI 來說，模糊需求是創作授權。
你需求沒說清楚，人類工程師可能會問你：
這裡你是什麼意思？
但 AI 很常不問。
它會根據自己的理解補完，而且補得很有自信。
這在小工具階段很迷人。
靠，太懂我了吧！
連我沒想到的都想到了 XD
但在系統維護階段就很可怕。
因為你會發現：
慘，它連我沒想清楚的也幫我實作了。
這就是最危險的地方之一：
AI 可能在你還沒真正理解問題前，就幫你產生大量看似完整的答案。
而那些答案一旦進到系統裡，後面就會變成你要維護的東西。
要快，任務還是要切小
我以前有時會丟很大的任務給 AI。
例如：
幫我做一個 ____ 系統。
或是：
幫我把這整個流程重構一下。
現在回頭看，這很容易出事。
因為大任務裡通常藏著很多還沒決定的東西：
- scope 到底到哪？
- 哪些是 MVP？
- 哪些不能碰？
- 哪些要相容舊流程？
- 哪些需要人工驗收？
- 哪些地方只是暫時做法？
- 哪些 tradeoff 是我還沒想清楚？
如果這些沒拆出來，AI 就會自己補。
所以我現在比較相信：
速度不是來自更大的 prompt，而是來自更小的迴圈。
小任務有幾個好處：
- 比較容易說清楚
- 比較容易驗收
- 比較容易 rollback
- 比較容易 review
- 比較容易知道 AI 哪裡做錯
- 比較不會一次產生一大坨看似完整、但其實方向錯的東西
AI 可以讓執行變快。
但前提是，人類要把任務切到它可以穩定執行。
要穩，該抓住的不能放
有些東西可以交給 AI。
有些東西不能。
我現在覺得，這些控制點不能隨便放：
- 技術棧
- 架構邊界
- data model
- testing strategy
- acceptance criteria
- security / permission
- release gate
- observability
- definition of done
AI 可以幫我寫 code。
但它不應該在我沒意識到的情況下，替我決定整個系統的骨架。
因為一旦骨架長錯，後面每一次修改都會更難。
這也是為什麼工程基本功在 AI 時代不是變得不重要，而是變得更重要。
以前基本功差，最多是人慢慢踩坑。
現在基本功差，AI 會幫你高速踩坑，還順便幫坑鋪水泥，然後讓你在做的道路上高速前進。
聽起來很有效率。
但其實只是更快把自己送進坑裡。
要好，人類還是要先想清楚
這點可能最不討喜，但也是最重要的：
AI 沒有讓「想清楚」這件事消失。
它只是讓你更容易假裝自己已經想清楚。
因為只要你丟一句話，它就會回你一大段。
只要你說「繼續」，它就會繼續產出。
只要你說「幫我改好」，它就會真的開始改。
但問題是：
如果人類沒有定義好「好」是什麼，AI 的「做好」就只是它自己的猜測。
所以規格不是官僚。
驗收標準不是拖慢。
測試不是麻煩。
任務拆分不是多此一舉。
這些東西其實是在幫 AI 建立邊界。
清楚不是慢。
清楚是 AI 時代的加速器。
我重新理解了 Harness Engineering
也因為這段經驗，我後來重新理解了自己以前做過的一些東西。
2025 年，我做過一個類似 Harness Engineering 的實驗：
smart-dev-plugin
https://github.com/coolwuu/smart-dev-plugin
裡面有：
- skills
- agents
- hooks
- commands
- safety checks
- handover
- verification
- workflow
當時我想解決的是：
怎麼讓 AI 更順地參與開發流程？
但現在回頭看，我覺得這個問題還不夠深。
真正要問的應該是：
- 這個 hook 到底約束了什麼？
- 這個 agent 到底驗證了什麼？
- 這個 workflow 保留了哪一種人類判斷？
- 這個 skill 避免了哪一種重複犯錯？
- 這套東西是在提高品質，還是在增加活動量？
這是我現在重新理解 Harness Engineering 的地方。
Harness 不是 agents 越多越好。
不是 hooks 越多越好。
也不是流程越完整越好。
如果一套 Harness 只是讓 AI 做更多事，但沒有讓人類更清楚地掌握系統，那它可能只是在幫混亂加速。
真正重要的是：
它有沒有幫人類拿回控制權？
它有沒有避免我們把思想和決策外包出去？
Harness Engineering 到底在做什麼？
如果用很白話的方式說：
Harness Engineering 是在設計 AI agent 外面的工作系統。
AI agent 本身很強。
但它需要被放在一個有邊界、有驗證、有回饋的系統裡。
這個工作系統要回答幾個問題：
- 它到底要做什麼？
- 它需要知道哪些上下文？
- 它可以用哪些工具？
- 它不能碰哪些東西？
- 做完後怎麼驗證？
- 做錯後怎麼修正？
- 哪些決策一定要留在人類手上？
所以 Harness Engineering 不是另一種 prompt 技巧。
它更像是 AI 時代的工程管理、平台工程、品質工程和安全邊界的交集。
更白話一點：
Harness Engineering 不是讓 AI 變成天才。
而是讓普通團隊不容易把 AI 用到失控。
它真正提高的，不只是上限。
更重要的是下限。
因為大部分團隊的問題，不是 AI 不夠聰明。
而是人類自己的需求、架構、驗收、ownership 本來就不夠清楚。
AI 只是把這些問題放大了。
AI 很像一個能力很強、速度很快的新成員
我有時候覺得 AI agent 很像一個能力很強、速度很快，但缺乏組織脈絡的新成員。
你不會丟給新人一句：
幫我把產品做好。
然後就期待他完全理解公司脈絡、系統歷史、技術債、商業目標和風險邊界。
你會給他 onboarding。
你會拆任務。
你會給 coding standard。
你會要求測試。
你會安排 reviewer。
你會定義什麼叫做 done。
在人類團隊裡，這些叫 training、process、management。
在 AI 團隊裡，這些很大一部分就是 Harness Engineering。
AI 不會自動修好模糊需求、缺失測試、混亂架構和不清楚的責任。
它只會讓這些問題跑得更快。
AI 沒有省掉基本功
所以我現在對 AI 的看法比較冷靜了。
AI 很強。
AI 真的可以讓很多事情變快。
但它沒有省掉工程基本功。
它只是讓基本功的影響變得更明顯。
需求清楚，AI 會放大清楚。
架構混亂，AI 也會放大混亂。
有測試，它會跑得更安全。
沒驗收，它就會更快把錯誤包裝成完成。
所以我現在比較相信：
要快，任務還是要切小。
要穩，該抓住的控制面不能放。
要好，人類還是要先想清楚。
AI 是放大鏡。
好的越好，爛的越爛。
而 Harness Engineering 的價值，就是提醒我們：
不要只忙著給 AI 更大的油門。
也要記得裝方向盤、煞車和儀表板。