跟 AI Agent 一起寫程式(四):怎麼收尾——驗證、review、何時自己接手

📚 《跟 AI Agent 一起寫程式》　這是一個 7 篇的系列,記錄我跟 AI coding agent 真實協作、一起蓋出這個站的工作法。

1. 心態與分工:它是協作者,不是神諭
2. 怎麼開場:脈絡、計劃、拆任務
3. 引導,而不是餵答案
4. 怎麼收尾:驗證、review、何時自己接手(本篇)
5. 信任的光譜:什麼時候盯緊、什麼時候放手
6. 工具與長期記憶:把協作規模化
7. 完整復盤:我們怎麼蓋出 8 軌道 64 課

前面三篇講的是「怎麼開好頭、怎麼引導」。這一篇翻到任務的尾巴——東西做出來了,接下來呢?

很多人到這一步就鬆懈了:agent 回一句「搞定了!」,你看一眼,覺得好像對,就收下。這是整個協作裡最危險的一刻。

因為第一篇講過那條鐵律:agent 的自信,跟它的正確率,是兩條獨立的曲線。 它說「搞定了」時的篤定語氣,跟「這東西到底對不對」之間,沒有必然關係。收尾這一篇,講的就是怎麼在這一刻保持清醒。

收尾的核心心態:不盲信

我對 agent 產出的預設態度,跟我前陣子幫課程加的一批「教學提醒框」其實是同一個——那些框框在提醒學生:訓練曲線崩了、準確率掉了、生成是糊的,「先別急著以為自己壞了,也先別急著以為一切正常」。

對 agent 的輸出,我抱的是一模一樣的懷疑:先別急著相信它說的「對了」。 這不是不信任它這個夥伴,而是一種職業習慣——就像 code review 時你不會因為「作者是資深同事」就跳過審查。

具體來說,我的不盲信落在三個層次:

1. 它說的,我去查。 它聲稱「這個 API 是這樣用」「這樣訓練是對的」,我不會照單全收,尤其是我自己不熟的領域。
2. 它做的,我去跑。 Code 能編譯 ≠ 邏輯正確;notebook 寫得出來 ≠ 跑得起來。
3. 它沒說的,我去想。 它報喜不報憂時——「完成了!」卻沒提邊界情況、沒提它跳過了什麼——那個「沒說」往往才是地雷。

把驗證做成關卡,而不是靠肉眼

光靠「我多看兩眼」是不可靠的,人會累、會漏。更穩的做法,是把驗證設計成自動的關卡,讓錯誤自己跳出來。

在這個站上,我設了幾道這種關卡:

• 建置驗證:任何內容或程式改動,跑一次 build。連結斷了、語法錯了、引用炸了,build 會直接喊。這比我一頁一頁翻可靠太多——像那批跨課的交叉連結,我加完二十幾組之後,是靠 build 跟一段檢查腳本確認「零斷鏈」,而不是靠眼睛掃。
• 改完馬上跑:手刻那個迷你擴散模型(DDPM)時,我沒有直接相信「程式碼看起來對」就 commit。我先在本機跑一次,確認張量形狀對、參數量合理,跑通了才收。因為那些 notebook 是讓學生在 Colab 上跑的,我若連自己都沒驗過,等於把沒拆過的炸彈交出去。
• 守住一條不可破的線:課程的 notebook 一律「不含執行結果」地存進版本庫(output-free)——這是我立的規矩,agent 每次都得遵守。這條線本身就是一道品質關:它逼著「結果由乾淨的環境重跑產生」,而不是把某次可能有問題的輸出醃在檔案裡。

自動關卡的價值,不只是抓錯,還在於它不會累、不會給面子。build 不會因為「這次改得很趕」就放水,測試不會因為「作者很有自信」就跳過。把人會鬆懈的地方交給機器把關,你才有餘力去看真正需要判斷的部分。

Review:看它「怎麼想」,不只看它「寫了什麼」

過了自動關卡,還有一層人工的 review。但 review agent 的產出,跟 review 人的 code 有個微妙的差別:

人寫錯,通常是『想對了、手滑了』;agent 寫錯,常常是『一開始就理解錯了』。

所以我 review 的時候,除了看「這段 code 對不對」,更會去感覺「它是不是誤會了我的意圖」。一段邏輯自洽、跑得起來、但解錯題的程式,比一個會 crash 的 bug 危險得多——後者 build 會幫你抓,前者只有靠人看出「方向歪了」。

幾個我會特別盯的點:

• 它有沒有偷偷縮小範圍? 我要它處理 A、B、C 三種情況,它只做了 A,然後信心滿滿地說「完成了」。這種「靜默地把任務做小」最容易漏看。
• 它有沒有為了讓測試過、把測試改鬆? 該修的是實作,不是把驗證標準降低。
• 它有沒有引進我沒同意的東西? 多裝一個套件、多開一個全域狀態、改了某個約定——這些都該先問。

何時自己接手:辨認最後那一哩

收尾還有一個判斷:有些事,與其反覆叫 agent 改,不如自己上手更快。

我接手的時機,大概是這幾種:

• 品味的微調。「這裡的留白不對」「這句文案不夠有力」——這種只可意會的審美,我來回描述三次,不如自己動手改一次。這正是第一篇說的「人類守住品味」。
• 又細又難講清楚的 edge case。有些邊界情況,我腦子裡很清楚,但要轉成文字講給 agent 聽,比我自己改掉還累。
• 環境/組態的鬼坑。像我之前踩過一個 git worktree 加 symlink 害 dev server 擋掉 React runtime 的坑——這種高度依賴具體環境、要反覆試錯的問題,人在現場親手調,常常比遠端指揮 agent 快。
• 它已經卡在原地打轉。如果 agent 改了兩三輪還在同一個地方鬼打牆,那是個訊號:該換我下場,而不是再給它一次機會。

知道什麼時候停止指揮、自己接手,跟知道什麼時候放手讓它做,是同一種能力的一體兩面。前者是這一篇,後者是下一篇。

小結:收尾決定了品質的下限

開場決定上限,收尾決定下限。

你前面的脈絡給得再好、引導得再巧,只要收尾時鬆懈——agent 說「好了」你就信——那一刻就可能把整個任務的品質拉到地板上。反過來,一套穩的收尾(不盲信、自動關卡、看意圖的 review、該接手就接手),等於替每一次協作鋪了一張安全網。

下一篇我們把這件事推到極致來談:既然要驗證、要盯,那到底什麼時候該死盯著它、什麼時候又可以完全放手、給它全部權限讓它一路幹到底? 信任,是有光譜的。