OpenClaw 作者 Peter Steinberger 接受 36Kr Europe 訪談時說，多數程式碼其實很無聊，做的往往只是把一種資料形狀轉成另一種；那不是他真正關心的部分。¹

這句話聽起來有點刺耳，但它的確點出一個盲點：很多我們習以為常的工程安排，到底是在處理問題，還是在處理形式？

當 LLM 與 coding agent 開始直接參與 repo 級搜尋、修改與驗證，就很難迴避這個問題。要重新檢查的，不只是那些躺在架構文件裡的大原則，而是整套日常工程安排：哪些分層真的在隔離風險，哪些抽象真的在縮小修改半徑，哪些則只是因為大家早就這樣寫，所以很少再有人追問：它現在還有沒有必要？

以前，這類問題不回答，也不一定立刻出事。多幾層轉發、多幾個 mapper、多幾個永遠不會有第二個實作的 interface，頂多讓人覺得麻煩。資深工程師還是能靠經驗補完，靠默契繞過去，靠耐心把成本默默吞掉。

但現在不一樣了。

當搜尋、重構、局部修補與 repo 級修改，越來越多交由 agent 參與，很多原本還能被人類默默消化的成本，都會更早浮上來。原本人類可以靠背景知識硬撐過去的地方，對 agent 來說，往往就是直接失手的地方。

傳統架構會不會被淘汰？或者我們更該探討的是另一個更具體、也更尖銳的問題：

哪些結構仍然在管理複雜性，哪些其實只是在維持形式？

本文想處理的，就是這個問題。

很多人很容易把這一輪 AI 寫程式的進展，詮釋成「模型正在取代軟體工程師」，甚至「模型正在取代軟體工程」。

這個說法只碰到了表面，卻沒有碰到核心。軟體工程沒有消失，重心正在上移。過去 SDLC 昂貴的部分，多半落在撰寫程式碼、處理低階細節、人工重構；現在，既然模型能迅速產生候選實作，昂貴的環節也跟著換了位置。就像高德拉特的 Theory of Constraints 所說，瓶頸會轉移。

問題是，轉移到哪裡？相對於以前，新的瓶頸比較容易處理，還是比較困難？

軟體工程的典範確實在變。變化的重點，是抽象層的提升、驗證負擔的轉移，以及治理形式的重組；工程紀律本身並沒有因此終結。

幾個月前，我在社群媒體看到一張裁員通知書的截圖。底下有一行說明：「公司說是因為導入 AI 工具，現有的人力已經足夠應付產出需求。」

這類貼文底下很快就會吵成一團。有人說 AI 終於開始搶工作了；有人說這根本是景氣問題，不要什麼都怪 AI；也有人說，這只是管理層找的藉口。

如果把問題問得精確一點，真正值得分析的，其實不是口號式的「AI 會不會取代人類工作」，而是更窄、也更接近企業實際決策的問題：

如果公司導入 AI，並且希望用它減少一部分人力，那麼這個人力縮減比例，在理論上有沒有上限或下限？

這篇想做的，就是先用一個盡量簡單的模型，把這件事的骨架抽出來。

傳統上，複雜的軟體專案，除了程式設計師之外，還會搭配系統設計師，甚至系統分析師，確保領域知識及商業邏輯都有朝對的方向前進。

生成式 AI 既然會寫程式，下一個問題就是：它也會做系統分析嗎？

理論上來說，應該是的。畢竟我們在前一篇文章都親眼看過，AI 既然能理解規格、潤飾需求、撰寫程式碼，甚至生成測試案例，那麼系統分析 (SA) 和系統設計 (SD) 這類「中間產物」，確實也難不倒它。畢竟，系統分析本質上就是資訊的整理、建模與推理，而這些都是 AI 擅長的領域。

我認為，SA/SD 也應該納入 AI 協作。尤其是從 SA/SD 擅長的建模角度，能夠協助我們及早確認領域知識及商業邏輯，檢查需求規格是否有矛盾、遺漏或模稜兩可的地方，甚至提出改善建議，幫助系統分析師更快定位問題，減少後期開發的返工成本。譬如說，透過 AI 生成的狀態轉移圖，也有助於規劃黑箱測試，提高測試覆蓋率，進而提升系統的穩定性與可靠性。

接下來就是現實問題了：讓 AI 產生的狀態圖，真的比人工畫得更好嗎？能省多少時間？

這就要實測了！現在，就讓我們拿前一篇文章的規格作為引子，看看 AI 生成的狀態圖表現如何吧！

人類從事的領域，不斷被生成式 AI (GenAI) 入侵。

社群媒體上，早就充斥一大堆「AI 體」的文案圖案，現在就連程式設計領域也開始淪陷。像 Google 執行長就透露：「在 Google，超過 1/4 的新程式碼已經是先由 AI 生成，再讓程式設計師去複審與確認。」¹ 而 GitHub 執行長更大膽預言 80% 的程式碼都將會由 GenAI 生成。²

也就是說，以前，程式設計師得親手撰寫大部分的程式碼；現在則開始挪出一段時間去跟 GenAI 對話：調教提示詞 (prompt)、審核生成的程式碼、確認正確性，如此反覆進行好幾個回合。

GenAI 進展神速。如果某一天進展到，只要提示詞下得夠精準，第一次生出來的程式碼幾乎就合格過關了，是否也就意謂著，程式設計師的專業訓練及工作重點，將會更轉向 ⑴ 鑽研提示工程、⑵ 審核生成的程式碼這兩條路線發展？換句話說，將會更朝向 ⑴ 前段的需求規格、⑵ 後段的測試驗收這兩條路線？

如果頭尾兩端（需求規格與測試驗收）都由人來看守定義，中間步驟（撰寫程式碼）改由 GenAI 來操刀，是否也就意謂著，程式碼會變成像是可拋棄的東西，反正隨時都可以叫 GenAI 再生出一份出來？甚至當 GenAI 能力升級之後，又能夠生出比拋棄掉的還要更好的程式碼？

聽起來可能有點兒瘋狂。可是如果以上屬實，那麼，敏捷四大宣言之一「可用的軟體 重於 詳盡的文件」，在 GenAI 時代是否依然成立，可能都值得再重新評估檢討。

為此，我在 ChatGPT 4o 進行一系列小小的實驗。試試看當 GenAI 收到前段的需求規格之後，能夠生出什麼樣的程式碼以及測試驗收案例；緊接著會與 GenAI 協作調教頭尾兩端（需求規格與測試驗收），再看看 GenAI 重新生出來的程式碼，會有什麼不同。