AI 會寫程式之後，軟體工程真正變貴的是什麼

很多人會把這一輪 AI 寫程式的進展，直接講成「語言模型正在取代軟體工程師」，甚至進一步講成「語言模型正在取代軟體工程」。

這樣講不算全錯，但沒有對準焦點。軟體工程沒有消失，變的是成本最高的地方不一樣了。過去 SDLC 昂貴的部分，常常落在寫程式、處理低階細節、人工重構。現在語言模型可以很快產生候選實作，原本集中在實作端的成本，就開始往別的地方移。用高德拉特的 Theory of Constraints 來看，這其實就是瓶頸轉移。

接下來比較值得看的，不是軟體工程還在不在，而是瓶頸轉去哪裡了。那些新的瓶頸，比以前好處理，還是更難處理？

軟體工程的典範確實在變，但工程紀律沒有因此結束。比較貼近現況的說法是：抽象層往上拉了，驗證負擔在重分配，治理形式也得跟著調整。

一、LLM 不是編譯器

軟體工程史上反覆出現的一個主題，是抽象層持續上升。

早期程式設計高度依賴機器碼與組合語言，人類必須直接處理硬體細節、暫存器配置與控制流程。高階語言與編譯器出現後，很多低階安排不再需要手動處理，工程師的注意力才逐步從「指令怎麼排」轉向「邏輯怎麼表達」。寫法變方便，人機分工也跟著重組。

從這個角度看，今天的 LLM 編程確實像新一輪抽象層提升。人類不再只寫語法層級的指令，而是更常用自然語言、規格、測試與約束來描述意圖，再由語言模型生成候選實作。意圖導向、規格導向的開發方式，現在又開始變得可行，不是因為理念突然變新，而是因為工具終於比較撐得住了。

但這個歷史類比只能拿來說明方向，還不能直接往下推論。很多人講到這裡，很快就會接一句：既然高階語言取代了低階語言，今天 LLM 也會像編譯器一樣，成為新的工程基礎設施。

這個推論太快了。

編譯器之所以能成為工程基底，關鍵不只是它很強，而是它可預期：同樣的合法輸入，在同樣條件下，應該得到語意一致的輸出。

所以這個類比真正有用的地方，只是在提醒你：抽象層又往上升了一層。把它再往前推成「LLM 已經等同於編譯器」，就走過頭了。這裡最重要的差異其實很簡單：編譯器可以默認信任，LLM 不行。

二、語意層的不確定性

有一種常見說法是，現代系統本來就充滿不確定性：快取未命中、垃圾回收時機、JIT 最佳化、多執行緒交錯，哪一個不是非決定性的？既然工程師早就習慣跟這些東西共處，那麼 LLM 的不穩定，看起來也只是另一種可管理的系統特性。

這種說法最大的問題，是沒有分清楚不確定性發生在哪一層。

傳統系統的非決定性，大多發生在執行路徑、資源調度與效能表現層面；在設計得當的前提下，系統的語意正確性仍可透過型別系統、同步模型、測試與形式方法加以分析與約束。LLM 的不穩定，則更常直接出現在語意建構本身：同樣一個提示，可能對應不同的實作策略、不同的邊界條件假設、不同的錯誤處理方式，甚至引入安全弱點、違反隱含限制，或偏離原始需求。¹²

這不是單純「跑法有點抖」，而是你拿到的東西本身就可能已經換了意思。

但也不能因為這樣，就滑到另一個極端，好像 LLM 完全不可工程化。那也不對。在任務範圍受限、提示結構清楚、工具介面穩定、測試充分的條件下，的確可以明顯收斂語言模型的輸出。Anthropic 對 workflow 與 agent 的區分，本身就在提醒一件事：工程上真正重要的，是你授予了多少自主性，又用什麼外部機制把這種自主性框住。³

比較準確的理解方式，是把 LLM 當成候選實作產生器，再用規格、測試、權限與審計把它包起來。它可以很強，但不能裸奔。⁴⁵

三、AI 擅長封閉問題

要理解 AI 為什麼能在某些問題上表現驚人，最好的科普材料其實不一定是寫程式，而是下棋。

2016 年，AlphaGo 贏了頂尖棋士李世乭，固然很了不起；更重要的是，它讓很多人第一次很具體地看到：只要規則固定、目標清楚、勝負可判定，而且系統可以大量自我對弈，AI 就能在封閉問題裡快速逼近甚至超過人類。圍棋雖然複雜，但它仍然是一個封閉世界：棋盤有限，合法動作明確，輸贏標準預先給定。這種問題的難，主要是搜尋空間巨大，不是目標函數模糊。AlphaGo 與後續 AlphaGo Zero 的關鍵，就是把策略學習、價值評估與搜尋結合起來，再透過大量自我對弈持續優化。⁶⁷

幾年後，AlphaDev 把相近的邏輯帶進程式世界。它把「尋找更好的小型排序程式」表述成一個可搜尋的問題：每一步都是組合更好的指令序列，目標函數也相對明確，例如正確性與效能。也因為目標清楚、評估穩定、搜尋空間可封裝，AlphaDev 才能在某些小型排序問題上找到優於既有人類基準的方案。⁸

這裡真正值得抓住的，不是「AI 很強」這個空話，而是它在規則封閉、回饋明確、可大量試錯的任務裡，確實特別能發揮搜尋能力。

也正因如此，這條路線不能直接外推到一般企業軟體工程。企業工程面對的，通常不是單一而乾淨的目標函數，而是一組彼此牴觸的要求：可維護性、模組邊界、法規遵循、事故可追溯性、部署風險、團隊交接成本、長期總持有成本。這些維度很難壓成一個簡單分數。局部效能最優，也不等於系統治理最優。

不同層級的問題，適合不同程度的自動化。 AI 未必能接管所有工程決策。

四、審查重心轉移

代理式工作流真正帶來的衝擊，在於它把一個原本就存在的問題放大了：當語言模型生成候選實作的速度，遠快於人工閱讀速度，傳統以逐行 diff 為核心的審查方式，開始很難擴展。

近年來，部分開發者與團隊開始嘗試更激進的工作流：人類主要提供需求、規格與目標，語言模型或代理則負責撰寫程式碼、執行測試、修復錯誤，甚至在一定範圍內自動迭代。

這類工作流裡，OpenClaw 作者 Peter Steinberger 算是很有代表性的一個例子。他讓語言模型在帶有工具、上下文與回合控制的環境裡，自己跑完一段工作流。這時候，人類審查的焦點就可能從逐行閱讀程式碼，轉向評估需求表述是否清楚、系統意圖是否被正確理解、代理執行路徑是否合理、測試結果是否可信，以及最終行為是否真的滿足目標。⁹

這裡最容易出現的誤解，是把「不 review code」聽成「不再審查」。比較準確的說法是：審查沒有消失，只是審查的對象在改變。 當 AI 可以在短時間內產生大量候選實作時，人類很難再用原本的方式逐行追蹤每一段程式；比較務實的方向，是把更多信任建立在規格、測試、靜態分析、語意差異辨識與執行證據上，而不是只建立在肉眼閱讀程式文字上。

不過，OpenClaw 或 Steinberger 都不能直接拿來當成普遍結論。它們更像壓力測試：不代表所有團隊明天都要照這樣工作，但它們會提前把未來工程可能遇到的結構性問題推到檯面上。這些案例真正有價值的地方，不在於證明「所有團隊都會變成這樣」，而在於它們先把一些原本還不夠明顯的成本，暴露出來。

更值得注意的是，不同團隊在實作代理式流程時，最後常會收斂到一個很務實的原則：先把能確定、能驗證、能回退的部分做好，再去談更高程度的自治。 Anthropic 在與多個團隊合作建置 agent 的經驗中，也反覆看到這個傾向。比較穩的系統，往往不是一開始就追求「讓語言模型自己決定一切」，而是先把任務切清楚、把工具介面縮小、把失敗後的回收方式設計好，再視情況逐步放寬模型可自行決定的範圍。³

這不只是「先從簡單開始」這種老話，而是在提醒你代理式工程的成本函數：自主性不是免費的。 每多給語言模型一層循環控制、多一個外部工具、多一次可自行決策的機會，就同步抬高觀測、驗證、審計與回溯的要求。成熟不是把 agent 權限一次拉滿，而是知道哪些判斷可以交給語言模型，哪些邊界必須牢牢握在人類手上。

工程師沒有突然失業。但未來高價值的審查能力，未必還是看得出每一行 code 怎麼寫；更可能是看得出這套系統的規格是否清楚、證據是否充分、風險是否被控制、責任是否能被追溯。

五、規格開始卡住

如果開發越來越依賴對話、提示與逐步澄清，那麼上下文管理就不再只是使用技巧，而會變成真正的工程問題。

原因不複雜。多輪代理式互動，不是把同一句話反覆重講，而是不斷增加限制、修正假設、引用先前輸出、放棄失敗路徑。系統不只要記住內容，還要知道哪些前提已經失效，哪些推論應該撤回，哪些局部探索不應污染全局。¹⁰

語言模型不是因為「對話變長」才突然變笨，而是它在多輪互動裡，常常不擅長處理自己先前留下來的推論痕跡。一旦早期對問題的理解有偏差，後面的回合就很容易不是重新定義問題，而是在錯的前提上繼續修修補補。Laban 等人的研究，可以把它看成對這個現象的系統化描述：對話越長，真正危險的往往不是記不住資訊，而是放不掉先前已經形成的錯誤解釋。¹⁰

也因如此，後來像 Context Branching 這類做法才開始變得有意思。它重點不在把 prompt 包裝得更花，而是把「探索不同解法」這件事，從一條連續對話，改成可分支、可切換、可捨棄的工作流。¹¹ 這其實是在把版本控制的觀念搬進規格管理：不是所有嘗試都值得留在主線，也不是每一次失敗都應該污染後續推理。

所以這裡的限制，不只出現在單次生成的正確率，也出現在規格如何隨著回合演化、修正與隔離。未來更重要的能力，可能不是把 prompt 問得更長，而是把探索過程切得更乾淨。

六、測試開始立法

如果 LLM 與代理式系統開始承擔更多實作、重構與局部迭代工作，那麼測試策略就不能只是沿用舊習慣，而得重新回答一個問題：測試的作用，到底只是查錯，還是同時在規定 AI 可以怎麼改、不能怎麼改。

要談這個問題，得先把經典的兩個測試流派講清楚。

所謂 Detroit school，也常被稱為 Chicago school 或 classicist TDD，核心想法是：測試應盡量從系統的外部行為與狀態變化來驗證，而不是過度關注物件之間的互動細節。這一派通常偏好經過真實組合的物件，較少使用 mock；只要功能完成後，系統狀態正確、輸出正確、公開介面行為正確，那麼內部到底怎麼協作，不一定需要在測試裡寫死。它的好處，是測試通常比較耐重構；只要外部契約沒變，內部實作可以持續調整。¹²

相對地，London school，也就是常說的 mockist TDD，更強調從物件協作與互動設計出發。這一派常採取 outside-in 的開發方式：先從外部需求開始，逐層往內設計物件之間如何分工，並在過程中大量使用 mock 驗證「誰應該呼叫誰、何時呼叫、帶什麼參數」。這種做法的優點，是它會提早暴露設計問題。當你在寫測試時，就得先把各個元件如何互動講清楚，很多模糊的責任分配也會被迫提前釐清。因此，London school 的支持者常認為，測試不只是驗證工具，也是設計工具。¹³

壓縮成一句話，Detroit / Chicago school 關心的是：最後系統有沒有做對事。 London school 關心的是：系統是不是用預期的協作方式做對事。

這裡沒有誰天然比較高級。它們對應的是兩種不同的風險感知。

如果你最擔心的是重構成本、測試脆弱性、內部設計被過早綁死，那你通常會更偏向 Detroit。因為它保留了較大的內部實作自由，只要外部結果沒變，系統就能繼續演化。

如果你最擔心的是依賴邊界不清、責任分工混亂、元件互動失控，那你通常會更偏向 London。因為它要求你把協作契約提前講清楚，藉由 mock 讓設計更早成形。

問題在於，到了 AI 參與開發的場景，這兩派的權重會變。

在代理式重構或生成場景中，語言模型很可能會調整控制流程、替換內部實作、重新切分模組，甚至用一種人類原本沒想到的方式達成同樣的外部行為。如果這時候測試過度綁定方法呼叫次序、參數傳遞路徑與物件互動細節，那麼很多本來有效、甚至更好的重構，都可能被測試判定為失敗。換句話說，過度 London 化的測試，在 AI 場景裡特別容易把設計選擇誤寫成功能規格。

這也是為什麼 AI 時代值得重看這場舊爭論。問題已經不只是「哪一派比較優雅」，而是「哪一種測試更能分清楚：什麼是系統真正不能變的東西，什麼只是暫時的實作路徑。」

我會把它拆成三層來看。

第一層，對於 AI 需要自由探索、自由重構的區域，測試應更接近 Detroit school 的精神。盡量用公開 API、可觀察狀態、整體行為與高階不變量來定義正確性，不要太早把內部協作方式寫死。這一層的目的，是替語言模型保留足夠的搜尋空間，讓它能在不破壞外部契約的前提下，自主改進實作。

第二層，對於那些真的不能亂動的區域，例如對外協定、錯誤處理流程、安全檢查、高成本依賴呼叫、金流與審計事件，London school 的精神仍然有價值。此時我們在意的本來就不只是結果對不對，也在意它是否以正確、可追溯、可受控的方式發生。這時互動測試不是多餘，而是在保護關鍵邊界。

第三層，是傳統 TDD 爭論比較少正面處理、但在 AI 場景中特別重要的一件事：測試不只要檢查答案，還要提供足夠抽象的驗證標準。 只靠單一輸入對單一輸出的例子，對人類手寫程式有時還勉強夠用；但對於生成式系統來說，這種驗證往往太窄，容易讓語言模型學會的是「迎合測試」，不是「滿足規格」。也因此，property-based testing 這類方法會變得更重要，因為它驗證的不是個別樣本，而是程式在一整類情境下是否維持某些不變條件。¹⁴

所以，比起問 Detroit 還是 London 哪個對，更值得問的是：哪些測試在保護真正的外部契約？哪些測試其實只是把歷史實作的偶然性誤寫成規格？哪些互動細節真的是安全或合規要求？哪些地方其實應該交給語言模型自由重構？

AI 時代比較合理的方向，不是在 Detroit 和 London 之間二選一，而是把不同測試放回各自最適合的層級。對可自由重構的內部邏輯，優先保護外部結果與高階不變量；對不能出錯的依賴互動、權限流向與副作用，再用更嚴格的互動驗證去守邊界；至於生成式系統特有的風險，則再往上補一層，用 property-based 或 differential testing 去檢查「不同實作是否其實破壞了同一個規格」。¹⁵

測試不再只是查錯工具，也越來越像一套治理語言：一方面給模型留出探索空間，另一方面清楚告訴它，哪裡可以動，哪裡不能動。

七、Clean Code 變了

關於 clean code，過去最常見的說法是：它能降低人類工程師的理解成本，讓維護、交接與重構變得比較容易。到了 LLM 參與開發的時代，這套論述還得再往前推一步。問題已經不只是「人看不看得懂」，而是：語言模型能不能穩定理解你給它的程式。

對人類來說，命名差一點、函式大一點，也許還能硬讀；對語言模型來說，這些東西會直接改變它如何切分問題、辨認模式、推測哪裡是主幹、哪裡只是雜訊。

這裡很容易被低估的一點是，對語言模型來說，程式碼不只是執行對象，同時也是上下文材料。模型得根據這些材料去推斷命名意圖、模組邊界、控制流程與可重用模式。程式越雜亂，語言模型越難分辨什麼是核心結構，什麼只是歷史殘留；越容易把偶然寫法誤判成必要約束，把局部噪音誤當成系統規律。到了這個階段，clean code 的意義就變了：它不只是讓人比較好維護，也是在替語言模型降低語意負擔。

這件事真的可能有差嗎？

Jain 等人的研究把它變成一個可以測量的假設：如果不急著增加資料量，而是先改善程式碼本身的可讀性與結構性，語言模型會不會學得更穩？¹⁶ 他們不是先去改演算法，而是改善語言模型接觸這段程式時看到的認知表面：命名更有語意、結構更容易分段理解、高階步驟更容易被看見。

結果也很直接：在程式生成任務上，資料整理得更好，確實能帶來可觀提升；甚至在某些設定下，少量但較乾淨的資料，會比大量但混亂的資料更有價值。這對工程實務很重要，因為它提醒了一件常被忽略的事：在 AI 時代，很多時候真正拉開差距的，不是你餵了模型多少東西，而是你餵進去的材料到底有多容易被正確理解。

這個發現替 clean code 補上了一個新的經驗支持，也改變了我們對工程價值的理解。過去談工程紀律，常常像是在談一種道德要求：今天命名清楚、模組分明，未來團隊比較好維護。這當然成立。但在 AI 時代，這些做法不只服務未來的人，也立刻服務當下的語言模型。你把程式整理得越清楚，模型越容易在比較小的語意空間裡工作；上下文噪音越少，生成越穩；結構越清楚，幻覺風險和誤解成本就越低。也就是說，傳統工程紀律沒有因 AI 而過時，反而第一次在「機器可理解性」上得到很直接的操作性理由。

在 LLM 時代，乾淨程式碼正在從人類維護性的美德，變成語言模型可生成性的基礎設施。

下一次再談 clean code，不只問「這樣別人看不看得懂」，也要多問一句：這樣的結構，語言模型能不能穩定理解、穩定延續、穩定驗證。

這不是審美問題。這是生成條件問題。

八、可治理的程式碼

一旦接受前面的判斷，工程問題就會改寫成另一句話：不是能不能生成 code，而是能不能生成可被安全吸收、可被驗證、可被審計的 code。

這至少有三層要求。

第一層是執行隔離。未經驗證的 AI 輸出，不應直接跑在高權限、真實資料或可對外互動的環境中。候選實作的執行，本身就是安全決策，不只是開發便利功能。¹⁷

第二層是語意審查與變更理解。當產出速度遠超過人工閱讀速度，人類不可能只靠文字 diff 理解變更影響。未來的審查機制勢必更依賴語意差異分析、結構化重構辨識、靜態檢查與契約違反提示，讓人類把注意力放在真正改變業務邏輯、權限流向與風險邊界的地方。¹⁸

第三層是高保證驗證。對多數一般系統來說，單元測試、整合測試與模擬環境，已足夠吸收大部分風險；但在安全關鍵、金流、基礎設施與高合規場景，這些往往不夠。這時更形式化的狀態建模、語言模型檢查與規格驗證方法，就可能變成必備品。¹⁹

這些要求最後都指向同一件事：生成加速了，但驗證不會因此自動變簡單。很多時候，它只會變得更重要。

九、樂觀主義的邊界

坊間流傳很多樂觀派說法。像「AI 明天就會取代工程師」這種口號，其實不必太認真。真正需要認真回應的，是它比較強的版本：真實軟體工程 benchmark 確實在快速進步，代理式 coding 也正在逼近大規模可用門檻。

的確，以 Copilot 的實驗來看，生成式工具已經能在受控任務中帶來明顯的速度提升。²⁰ 從 SWE-bench 這類更貼近真實 issue resolution 的 benchmark 來看，代理式 coding 也確實跨過了早期那種只能做玩具題的階段。²¹

但也正因為能力上升得夠快，benchmark 本身開始暴露另一層問題。OpenAI 在 2026 年不再把 SWE-bench Verified 視為前沿能力的好指標，不是因為它不重要了，而是因為語言模型越接近高分，測試設計缺陷、資料污染與任務定義模糊，就越會主導最後的評估結果。²²

所以，這不只是捷報，也是一份壓力測試報告。當語言模型還不夠強，大家關心的是它會不會做；一旦語言模型開始會做，真正決定結果能不能信任的，反而是測試有沒有設計好、規格有沒有寫清楚、驗證有沒有跟上。

與其說「工程快要不重要了」，不如說：當語言模型更強時，規格、測試與 benchmark 設計反而變得更重要。 能力上來之後，先暴露出來的不是工程退場，而是驗證與治理的缺口被照得更亮。

你的治理能力，有跟著一起升上來嗎？這才是更值得擔心的事。

結論

從組合語言走到 C 語言，人類並沒有完全放手，而是把約束搬到更高的抽象層級：結構化程式設計、模組化、型別系統。這些約束不是拿來限制編譯器，而是確保人類在必要時仍然能理解和控制系統。

LLM 時代的轉折其實很像。把邊界限縮到可掌握的顆粒度 這個原則沒有消失，只是往上移了：從「人類要看懂每一行程式碼」，移到「人類要看懂每一個模組的意圖與契約」，再移到「人類要看懂系統的架構決策與約束框架」。

所以現在真正該問的，不是「AI 會不會取代程式設計」。比較重要的是：規格由誰定義，結果由誰驗證，權限由誰控制，後果由誰承擔。

這幾件事沒有設計好，語言模型越強，風險只會越大。 這幾件事設計好了，語言模型越強，工程收益才可能真的放大。

至於將來是否會出現像 AlphaGo 那樣徹底超越人類認知的時刻？也許會。但在那之前，我們需要以歷史為師，在新的抽象層級上，重新建立一套人類能夠理解和掌控的約束體系。那套約束體系的名字，可能叫做 harness、validation loop、architectural guardrails，而不是 structured programming 和 SOLID。