從逐行審查到架構指令：AI時代開發者角色的真正轉變

AI 時代的開發工作不是在優化「審查代碼」，而是在根本上改變審查的對象——從代碼本身轉向架構與指令的清晰度。

15 3月 2026 • 4 min read

問題不在工具，在工作的定義

Martin Fowler 和 Peter Steinberger 的觀點對比，其實反映的不是「該不該用 AI」，而是一個更根本的問題：當 AI 能夠可靠地生成程式碼時，開發者的核心職責是什麼？

Fowler 的立場大概是：代碼質量的守門人角色不會消失，只是形式改變。Steinberger 則更激進——他認為開發者會逐漸演變成「架構與指令的設計者」，而不是「代碼的生產者」。這不是修辭上的差異，是工作內容的質變。

傳統的 code review 建立在一個假設：人類讀代碼比寫代碼快。所以 review 是個高效的品質檢查點。

但當 AI 生成的代碼量變成 10 倍、100 倍時，這個假設崩潰了。你不可能逐行審查 AI 生成的每一行代碼——不是因為時間不夠，而是因為這樣做本身就是錯的工作方式。

更深層的問題是：AI 生成的代碼往往「看起來沒問題」。它的 bug 不在單行的邏輯錯誤，而在系統級的假設錯誤——比如對邊界條件的誤解、對業務流程的偏差理解、對性能約束的忽視。這些東西看不出來，除非你知道要看什麼。

Steinberger 說的 agentic engineering，核心是把開發過程拆成兩層：

轉變的關鍵是：你不再問「這段代碼對不對」，而是問「我的指令清楚嗎」。

比如，與其讓 AI 生成一個複雜的查詢函數然後逐行審查，不如：

這不是偷懶，這是把精力從「找 bug」轉向「定義問題」。

Fowler 會質疑的地方是：定義清楚架構和指令本身就很難。如果你定義得不夠精確，AI 生成的代碼再完美也解決不了問題。

這是對的。但這不是 AI 時代的新問題，這是軟體開發的永恆問題。只是以前我們用「逐行審查」來補救定義不清的缺陷，現在這個補救方式失效了，所以問題暴露出來。

換句話說，AI 沒有創造新的難度，只是把我們一直在逃避的難度強制浮出水面。

如果 Steinberger 的預測是對的，那麼開發者需要重新訓練的不是「怎麼用 AI」，而是：

這些技能不是新的，但權重完全改變了。曾經是 20% 的工作，現在變成 80%。

Fowler 和 Steinberger 都有道理，但他們可能在同一個維度上辯論。Fowler 在說「品質保證的責任不會消失」，Steinberger 在說「保證品質的方法會改變」。兩個都對。

真正的問題是：大多數團隊現在還在用傳統的 code review 流程去處理 AI 生成的代碼。這就像用手動變速箱的駕駛方式去開自動檔車——不是不行，就是效率低得可笑。

轉變不是一年兩年的事。但如果你現在還在逐行審查 AI 生成的代碼，值得問問自己：我是在做品質保證，還是在做無用功？

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。