AI 寫完應用之後：你敢審查 diff 並點 Merge 嗎？

先給結論：當 AI 能寫出任何程式碼，“寫得快”就不再是優勢——人人都有。真正稀缺的，是你敢不敢點下那個 Merge 按鈕。而你敢不敢，取決於 AI 交給你的東西，是不是你能審、能治、能擔責的。

先看一個已經天天在發生的場景。

一位工程師讓編碼 agent “搭一個客服退款的小應用”。半小時後，一個能跑的應用出現了：前端、介面、資料庫遷移、測試，一應俱全，CI 全綠。她開啟 PR，看到一行字：+8,142 −0。

然後她卡住了。

這八千行不是她寫的，她一行都沒讀過。退款金額的上限校驗在哪個檔案？這個介面會不會把別人的退款記錄也返回？改了它會不會連帶影響對賬？她不知道——因為沒人知道。CI 綠，只證明”程式碼自洽地跑起來了”，不證明”它做的是對的事、且只做了被允許的事”。

她有兩個選擇，而且都很糟：要麼硬著頭皮假裝審過、點下 Merge——把一個沒人理解的黑箱放進生產；要麼真的去逐行讀這八千行——那她還不如自己寫。這就是 AI 時代真正的新瓶頸：不是寫程式碼，是點 Merge。

寫程式碼被商品化了，“信任”沒有

過去十年，工程師的稀缺能力是”能把它寫出來”。這個能力正在被 AI 迅速、徹底地抹平。當生成一個應用的邊際成本趨近於零，“快”就不再是任何人的護城河——你的競爭對手的 agent 也一樣快。

被推到前臺的，是另一件一直都在、但以前被寫程式碼的成本掩蓋的事：有人得為這段程式碼負責。 得有人能回答”它讀了哪些資料、能做哪些動作、出錯算誰的、審計查得到嗎”。在 AI 把”寫”的成本砍到零之後，“審與治”就成了整個流程裡最貴、也最關鍵的一段。可審查性，是 AI 寫程式碼時代的新護城河——不是誰生成得多，而是誰生成的東西敢上線。

這正是 Vibe Coding 技術債 和 AI Agent 試點失敗的四層原因 兩篇講過的同一件事的另一面：vibe coding 讓人人都能生成應用，但生成完沒人敢上線——因為沒人能審、沒人能擔保。區別只在於，那兩篇是從企業和決策者視角看，這篇是從你——那個手指懸在 Merge 按鈕上的人——的視角看。

“讓另一個 AI 去審”為什麼閉不了環

最自然的反駁是：既然 AI 能寫，那讓 AI 來 review 不就行了？程式碼評審 agent、自動安全掃描，現在都有。

這條路能擋住一部分，但閉不了那個真正要命的環。

回到那個 GET /api/refunds。它返回了所有人的退款記錄——可它能通過幾乎所有自動檢查：語法沒錯、沒有空指標、有測試（測試也是同一個 agent 寫的，自然只測了”能查到退款”，不會去測”該不該查到別人的退款”）。AI 評審擅長的是程式碼對不對它自己：有沒有 bug、符不符合已知漏洞模式、風格一不一致。它回答不了三個程式碼之外的問題：這段程式碼該不該讀這張表？這個動作該不該動這筆錢？這是不是我們想要的業務規則？

這些答案不在程式碼裡——它們在許可權模型、在審批策略、在業務意圖裡。兩個 AI 互相點頭，不等於治理。 審計員、法務、安全團隊要的那個”誰授權、誰擔責”的答案，一個再聰明的評審模型也籤不了字。所以”讓 AI 審 AI”省掉的是人讀程式碼的體力，省不掉那個必須由人來做的”該不該”判斷。問題繞回原點：人得能審。可八千行，人審不動。

出路：把 AI 要交給你的東西，縮小到你審得動

你審不動八千行，和這套系統半年後會爛掉，是同一個原因——沒人真正理解那一坨實現（這就是那篇講的”理解債”）。

那就換掉 AI 交付的形態：不讓它生成實現，讓它生成宣告。同一個退款應用，AI 該交給你的不是八千行程式碼，而是這樣一份後設資料 diff：

+ object: support_refund
+   amount: currency (min 0)
+ permission: support_agent
-   allowDelete: true        # agent 生成的初版給多了
+   allowDelete: false       # 審查時收回：客服不能刪退款
+ flow: refund_amount > 500 → 需財務審批

這十幾行，你能逐行讀懂、能在五分鐘內評審、能一鍵回滾。更關鍵的是最後那幾處：審查不再是”我讀得完嗎”，而變成了**“這條許可權對不對、這個審批閾值合不合理”**——一個你真正能判斷、也該由你判斷的業務問題。那個會洩露的 GET /api/refunds 在這裡壓根不會出現：support_refund 的讀取許可權被宣告為”按呼叫者許可權”，執行時據此強制，越權那條路從源頭就被關上了。

而實現去哪了？實現屬於一個被反覆審計、所有應用共用的執行時（ObjectOS），不是每個應用各生成一份。“該不該做”——能不能讀、能不能刪、要不要審批——由執行時在執行時強制，而不是埋在八千行裡靠運氣。

一個能真正閉合的迴圈

把這件事畫成流程，就是一個人始終在場、但不被程式碼量淹沒的閉環：

注意第④步：因為業務定義本身就聲明瞭物件與許可權，執行時會把它投影成一組受治理的工具——於是同一個 agent 不只”寫”了這個應用，之後還能在同樣的許可權邊界內去操作它（查退款、發起退款），每一步都帶身份、都留痕。寫和用，共用一套治理。

先潑一盆冷水

這套打法有邊界，得說清楚。

第一，不是所有東西都能變成後設資料。一個全新的即時演算法、一套獨特的渲染管線，仍然需要真正的程式碼，也仍然需要有人硬著頭皮 review 那部分——後設資料幫不了你，硬套反而誤事。它擅長的是企業裡那 90% 反覆重建的業務系統。

第二，信任被轉移了，不是被消滅了。你不再逐個 review 每個應用的實現，但你把信任押在了那個執行時上——它得被認真審一次、被持續維護。但算一下這筆賬：傳統做法下，AI 每生成一個應用，你就得重新信任一坨新程式碼；後設資料做法下，你審一次執行時，之後它派生出的每個應用都自動繼承同一套被驗證過的許可權與審計。審一次，勝過審一千次。 這是個划算得多的交易，但它是一筆交易，不是魔法。

結語

AI 會寫程式碼這件事，不會讓工程師失業，但會改變工程師最該把守的關口：從”我能不能寫出來”，變成”我敢不敢為 AI 寫出來的東西簽字”。

而你敢不敢簽字，幾乎完全取決於 AI 把什麼放到了你面前——是八千行你讀不完的實現，還是幾十行你能審、執行時能治的宣告。別讓你的 agent 去寫一堆程式碼，讓它去生成一個你審得動、執行時託得住的目標。

npm i -g @objectstack/cli && os start

給你的編碼 agent 指一個宣告式、可治理的目標，而不是一句”幫我寫個 CRUD”——然後看看下一個 PR 的 diff，是不是終於小到你敢點 Merge。