此為《軟體工廠為何失敗》的第二部分
本文的演講版本已上傳至 YouTube：https://www.youtube.com/watch?v=Ib5GBkD555M
重新點亮燈光
在第一部分中，我深入探討了為何模型無法長期維持程式碼庫的品質。為何無論多少的工程調校或 token 最大化，都無法解決模型訓練與基準測試的問題。為何「以模型作為評判」來評估程式碼品質，並不如某些人想告訴你的那麼有效。
目前，評判者就是你——所以我們要把程式碼審查重新放回流程中。
我們要擁抱我們在 AI 出現之前就在做的事情，也就是在前期進行一些規劃，以降低漫長且困難的審查機率。
我們要找到槓桿點，並利用 AI 來協助我們，涵蓋四個階段：
- 產品需求
- 系統架構
- 程式設計
- 垂直切片
產品審查
一切都從產品審查開始：一份簡短的文件，定義我們要建構什麼以及為什麼要建構。目標是能夠將兩句話或一段長長的語音備忘錄，轉換成結構化的內容。
首先，我們要對齊要解決的問題——使用者的真實痛點，用使用者的語言來描述。第二，成功的樣貌是什麼——我們在上線後能讀到什麼，來判斷這個東西是否值得建構。理想情況下，這是一個使用者成果，例如「能在更短時間內完成 XYZ 工作流程」或「更早達到入職里程碑 ABC」。有時它會是比較底層的指標，比如錯誤率或延遲數字，有時只是「關於 X 的客服工單停止增加了」。
我們會盡量讓這個階段保持貼近產品領域，而不是技術領域。作為一個同時涉足產品和技術領域的人，我常常發現自己會在這裡陷入技術細節。當這種情況發生時，我會試著先把想法記下來留給後續階段，然後回到使用者實際體驗的層面。如果技術決策阻礙了產品決策，那麼我們就先確定已有的內容，然後進入架構階段，或進行更多關於可行性的原型研究。
而且，由於這大部分關於使用者所見，我不會用文字描述——我會直接畫出原型。一個粗略的 HTML 頁面草稿，可以解決三個段落都說不清的爭論。
這是一個正在進行中的真實案例——這份文件透過 JSON 大綱定義了功能，然後是兩個實際頁面的粗略 HTML 草稿：
https://x.com/dexhorthy/status/2078592010852982977
當然，並非所有事情都需要產品審查。一個文案調整、一次性的腳本、一個有明確重現步驟的 bug——我們仍然會直接一股腦地丟給 Agent 處理。這個流程是針對那些 Agent 誤解我們意圖會付出高昂代價的變更。
對於這個系列文章中的所有文件，我們都採用「作者選擇加入」的審查方式。如果你想在審查時節省時間，你可以選擇那個會審查 PR 的人，然後與他們一起審閱產品/技術規格，可以透過文件的非同步評論（我們自己使用 HumanLayer 來做這件事，但你也可以輕鬆地在 GitHub、Notion、Plannotator 等工具中完成）。
系統架構
一旦產品審查確定了，我們就進行系統架構。這並非特別新穎，甚至是許多 vibe coder 也開始推崇的做法。
如果你想在審查時節省時間，請在進入編碼階段之前，選擇那個會審查 PR 的人，並與他們一起審閱產品/技術規格。
在這個階段，我們要對齊服務、端點、結構、佇列和儲存如何相互溝通，而不涉及程式設計的細節。為了最大化人機溝通頻寬，我們在這裡大量使用視覺化工具——例如序列圖：
合約 / 端點形狀：
資料模型與轉換：
Mermaid 在這裡還不錯，但有時可能小題大作，有時會讓你產生一種已經對齊的錯覺。架構的槓桿效應相當高，而且在這個階段你可以避免許多潛在的不良模型習慣。但是，僅靠架構並不足以產生高品質的程式碼。為此，我們需要程式設計。
程式設計
在架構之後，我們會做一件我認為在 Agent 編碼中被嚴重低估的事情：程式設計。
大多數人認為一旦架構正確，模型就可以直接「煮」出程式碼。你可以這麼做，但你可能不會喜歡得到的結果。
但我觀察到，一個有效的方法是，在任何人（人類或 Agent）開始撰寫實作之前，我們從架構往下再深入一層，進入程式碼的形狀：型別、方法簽章、程式佈局和呼叫堆疊。
我們最初版本的程式設計技能很糟糕。它很難讀，也很耗費心力。我們嘗試過 Mermaid，它有其適用之處，但我們真正喜愛的是用虛擬碼搭配輕量化的視覺化表示：
呼叫堆疊樹，適用於任何編排或控制流程的變更。當變更是重點時，使用 diff 語法來表示：
Dillon Mulroy 提到在規劃過程中使用呼叫圖，我認為這完全正確。
檔案樹差異 - 讓你能掌握程式碼庫的佈局以及檔案的位置
關鍵新函式的型別和方法簽章——那些對架構文件來說太內部，但 Agent 可能會搞錯的東西
這些都不會花很長時間產生（模型會先打草稿，你再與它爭論），而且每一個都是你原本會在程式碼審查時隱含做出的決定——而那是改變想法成本最高的時刻。
垂直切片
接下來，我們喜歡做我稱之為「垂直切片」的事情——Matt Pocock 和我在2026年1月的一場直播中討論過垂直切片或「追蹤子彈」——這也被稱為追蹤子彈。
模型喜歡我稱之為「水平計劃」的方式——按堆疊順序進行：
- 資料庫遷移
- 服務層
- API
- 前端
實際上，這意味著在開發過程中幾乎沒有辦法實際「觸碰」解決方案。你可以用程式碼來測試，但對於我建構過的幾乎所有功能來說，閱讀測試只是個開始，而在工作過程中，實際在瀏覽器中拉出畫面，或用 curl 打打 API，都是非常頻繁的步驟。
在 AI 出現之前，很少有人會在沒有沿途檢查的情況下，直接寫出 2000 行以上的程式碼，甚至 500 行。
我花了一段時間才注意到這與我習慣的方式之間的差異——在我使用 AI 之前寫程式時，我總是從中間開始，然後向外擴展。大致上是：
- 建立 API 合約並提供模擬資料，用 curl 測試
- 建立前端來消費模擬資料，在瀏覽器中迭代與打磨
- 將 API 連接到服務層（服務層提供模擬資料/行為）
- 加入資料庫遷移，將服務層連接到資料庫
- 加入大量商業邏輯
- 加入大量錯誤處理
而且我在每個步驟都會進行測試、迭代和打磨。
如果我非常在意程式碼品質，或者對模型在程式碼庫的這部分能否做好工作持懷疑態度，我也會在每個步驟審查程式碼。檢查 100-200 行程式碼並重新導向，成本要低得多。
在這裡，我會這麼做。大多數前沿模型在沒有人類引導的情況下，不會設計出這樣的計劃，而且很難針對每個程式碼庫甚至每個任務進行概括，所以我更傾向於在這裡保持參與。相信我。如果我能外包思考，那我早就做了。
30 分鐘的規劃可以節省數小時的審查時間
因此，我們有一些步驟，我認為如果你希望在維持接近人類水準的程式碼品質的同時，又不必在事後花費大量心力清理一堆垃圾程式碼（也就是說，你實際上想要快速前進），那麼人類必須參與其中。
- 產品設計
- 系統架構
- 程式設計
- 垂直切片
顯然，我們不會對我們推出的每件事都執行這整個流程（請參閱下方的支線任務）。我猜測分佈大致如下：
- 大約 40% 的任務會一次完成，或一次完成加上 1-2 輪的輕度回饋
- 對於中等任務，我們會將產品/系統設計全部放在一個規劃文件中，而不會費心將工作分解成階段
- 對於大型任務，我們會執行所有步驟。對於不適合的任務，例如大型重構，我們會跳過產品部分。
在大多數情況下，我會一次讓模型處理 1-3 個切片，並在過程中審查程式碼。無論是內部實作還是實際功能，及早重新導向，遠比等到 2000 多行程式碼寫完，卻完全不知道哪裡出了問題，要容易得多。
你可能覺得你的 Pull Request 太多了
你沒有太多 PR。你是有太多糟糕的 PR。
在 AI 出現之前很久，我們就都審查過許多需要重工的 PR。
但一個好的 PR 審查起來是一種享受。你瀏覽每個檔案，程式碼很乾淨，它遵循了你所有關於軟體應該如何構建所做的決定、討論和得來不易的意見。
另一方面，如果一個 Pull Request 需要 20% 的重工（這已經很寬容了，我認為大多數 AI 一次完成的 PR 傾向於接近 50%），這對提交者和審查者來說，既是智力的負擔，也是情緒的負擔。（即使提交者是 AI，很可能有人啟動了這項工作，或對 AI 的結果進行了 vibe 打磨，或者至少，他們關心最終的結果。）
為了節省你的時間（我們快結束了），我在一個支線任務中更詳細地討論了這個問題：
一個關於限制的理論（2026 年版）
這裡的核心論點可能會讓人有點沮喪：「目前我們還是得看程式碼」。
我曾經對一個世界感到非常興奮，在那裡我們可以只要求我們想要的東西，讓模型自己去「煮」，我們不用看程式碼，就能獲得美麗的、能隨著時間演進且不會變糟的生產級軟體。
但我在這裡盡力闡述的不過是各種限制。模型擅長某些事情，其他事情則不那麼擅長。在這些限制下，你如何優化你的流程？
模型擅長某些事情，其他事情則不那麼擅長。在這些限制下，你如何優化你的流程？
有可能你太忙於試圖以 10 到 100 倍的速度前進，並說服自己程式碼品質不再重要，而實際上你可以擁抱這些限制，以 2 到 3 倍的速度安全地前進。
我最後的總結建議大致是：
- 深入了解這些限制，透過大量與模型合作來培養直覺
- 在這些限制的範圍內優化系統
- 尋找槓桿點
- 讀那該死的程式碼
就這樣。如果你想繼續聽我的推銷，那就繼續往下滑吧。我希望這能幫助你避免災難，或者至少你看著那些可愛的小動畫覺得很有趣。
感謝閱讀
-dex
附註：我們對此非常著迷
我們正在開發 humanlayer.com，一個 Agentic IDE 和協作平台，幫助你在維持人類（或非常接近人類）水準的程式碼品質的同時，以 2 到 3 倍的速度前進。
我們正朝著兩個方向努力：「軟體工廠的建構模塊」和「軟體可維護性的更好驗證器」（或許甚至是更好的模型）。
HumanLayer 對最多 3 人的小型團隊免費，如果你想獲得入門幫助，可以加入我們的 Discord 或寄信至 founders@humanlayer.dev
快速感謝 @calvinfo 的啟發，感謝我的共同創辦人 @0xBlacklight，感謝 @swyx 和 @aiDotEngineer 團隊給我一個探索這些想法的舞台，以及感謝所有為我們加油的優秀客戶、投資者、朋友和家人。
如果你想了解更多，我基本上對此話題是停不下來的，所以你可以從這篇文章找到所有連結，以及將此內容轉化為 Podcast、長篇白板討論等其他形式，請見下方。
附註 2：其他資源
Podcast 與文章：
- Dex 和 Gergely 在《The Pragmatic Engineer》上討論上下文工程與軟體工廠 - 2026 年 7 月
- Dex 和 Matt Pocock 討論長青 AI 編碼建議（以及 Ralph Loops）- 2026 年 1 月
《AI That Works》系列集數：
本文連結：
- 《軟體工廠為何失敗》主題演講 — AI Engineer World's Fair 2026
- StrongDM 的關燈軟體工廠
- OpenAI：工程調校（2026 年 2 月）
- Ryan Lopopolo 談 Symphony（演講，2026 年 4 月）
- Mario 在 AI Engineer Europe 的演講：「在垃圾程式碼的世界中建構 π」
- 金融時報：亞馬遜因編碼 Agent 失誤導致服務中斷
- Matt Pocock：程式碼庫分崩離析
- Faros AI：AI 加速鞭打效應報告
- 編碼 Agent 的高級上下文工程（演講 25/8）
- 禁止 Vibe 編碼（演講 25/11）
- 我們對 RPI 的所有錯誤理解（演講 26/3）
- Awesome-RLVR - 強化學習資源
- 編碼 Agent 的高級上下文工程（文章）
- 十二因素 Agent
- Addy Osmani 談 Vibe 編碼 vs. 維護
- 北約軟體工程會議，1968 年
- 美國國防部 DevSecOps 參考設計（PDF）
- Ramp 的編碼 Agent 平台
- Stripe：Minions，一次性端到端編碼 Agent
- WorkOS：Project Horizon
- Brex (Latent Space)
- Dan Shapiro：軟體工廠的五個層級
- Simon Willison 談 StrongDM 的軟體工廠
- 「把大海煮沸」
- 散彈槍修改 (refactoring.guru)
- John Ousterhout — 軟體設計的哲學
- Robert C. Martin — 乾淨的程式碼
- Martin Fowler — 重構
- aider
- cline
- codebuff
- SWE-Agent 論文（2024）
- OpenAI Codex 演講（11 月）
- Calvin French-Owen — AI Council 演講
- SWE-bench 多語言（資料集）
- AIE Worlds Fair 2026 - 偉大的迴圈辯論（「炒作已經超越了紀律」）
- SWE-Marathon (Abundant AI)
- DeepSWE (Datacurve)
- Frontier Code (Cognition)
- 突變測試 (維基百科)
- Dillon Mulroy 談規劃中的呼叫圖
- Dex × Matt Pocock：垂直切片 / 追蹤子彈（直播，2026 年 1 月）
- 「思考的艱苦工作無法外包」(Jake Nations)
