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

AI 時代開發者的工作不是逐行審查代碼，而是寫清楚架構指令，讓 AI 在明確的約束下生成代碼。

舊的審查方式已經過時了

Fowler 和 Steinberger 的分歧點其實很清楚：當 AI 能夠穩定生成可用代碼時，傳統的「逐行審查」這個工作就失效了。不是說審查不重要，而是審查的對象變了。

過去十年，我們花了大量精力在代碼質量檢查上——風格、邊界條件、命名規範。這些工作對人類編寫的代碼很有意義。但當 AI 生成的代碼已經通過了單元測試、靜態分析、類型檢查，你再去逐行看它的 if-else 邏輯，其實是在做機器已經做過的事。

真正的問題不在代碼行數，在於：你有沒有給 AI 足夠清晰的指令。

Steinberger 強調的 agentic engineering 核心就是這個。當開發者的主要工作從「寫代碼」轉向「寫指令」時，指令的質量就成了瓶頸。

這不是簡單的 prompt engineering。我說的是：

我在 91APP 做 AI PoC 時遇到過這個問題。一開始團隊以為只要把需求丟給 AI 就行，結果生成的代碼在形式上沒問題，但架構決策和實際業務邏輯的適配度很差。後來我們改變方式，先把架構意圖寫成文檔，然後用那份文檔作為 AI 的上下文，效果好了一個量級。

這不是說不用審查了。而是審查的焦點從「代碼對不對」變成「指令清不清楚，架構決策對不對」。

換句話說，你需要審查的是：

這需要不同的眼光。你不能再只看代碼，你要看代碼背後的「決策邏輯」——而這個邏輯應該在你的指令裡已經清楚了。如果不清楚，問題不在 AI，在你的指令。

坦白說，這對很多開發者是痛苦的。因為「寫清楚指令」比「寫代碼」更難。寫代碼時，你可以邊寫邊改，靠直覺和試錯。但寫指令需要你先把思路整理清楚——架構是什麼，為什麼這樣設計，邊界在哪。

這意味著你需要更強的系統思維能力。不只是懂技術，還要能把技術決策的脈絡表達出來。

Fowler 的保守態度可能源於這一點。他知道，不是所有開發者都準備好做這個轉變。但準備不準備，轉變都在發生。

我傾向於 Steinberger 的方向。不是因為 AI 多麼厲害，而是因為這個轉變解決了一個根本問題：人類最擅長的不是逐行寫代碼，而是做架構決策和定義約束。

如果 AI 能接管代碼生成，我們就可以把更多精力放在真正需要人類判斷的地方。當然，前提是你能把指令寫清楚。這不是一個技術問題，是一個思維問題。

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