為什麼AI編程智能體仍然需要明確的規格説明

本文原載於Markus Eisele的新聞通訊《The Main Thread》，經授權轉載。

開發者社區中正流行一種心智模型：智能體足夠聰明，能自己搞清楚事情，因此繁重的前期規格化是不必要的官僚開銷。只需寬鬆描述目標，讓智能體探索，然後邊走邊修正。快速、靈活、現代。

這種觀點是錯誤的。不是因為智能體能力不足——它們往往很出色——而是因為賬算錯了。你並沒有消除成本，而是將其推遲、碎片化，並使其更難發現。

讓我們看看實際的分類賬。

兩個極端，兩種隱藏成本

一個極端是最小化規格：你寬鬆描述意圖，智能體自由解釋，工作立即開始。前期人力成本接近零。但你不會立即看到的是下游累積的成本：修正循環，每次攜帶代幣成本和人類重新投入時間。審查週期中，人類成為每個輸出的神諭——決定智能體產生的是否正是原本意圖。當不符合時則返工。

另一個極端是全面正式規格：測試驅動開發（TDD）、行為驅動開發（BDD）、Gherkin場景、驗收標準在代碼運行前鎖定。前期人力成本真實可見。但下游驗證成本完全不同，因為測試就是神諭。通過或失敗。人類無需親自評估每個輸出——規格自動、重複、不疲勞地做這件事。

你實際上是在交換支付時間和貨幣。最小化規格前置代幣成本，後置人類判斷。全面規格前置人類努力，後置幾乎為零——自動驗證不隨運行次數擴展。

當將總成本對規格完整性作圖時，兩條曲線呈現U形。曲線的最低點——即最佳點——位於結構良好的驗收標準或BDD場景附近。不在零規格，也不在40頁的正式需求文檔。

一旦繪製完整的分類賬，陷阱便顯現。最小化規格看起來很便宜，只有在下游返工未計入時。多智能體工作將最低點進一步右移，因為漂移在交接中累積。

老問題始終是規格

軟件工程中真正的挑戰始終是規格。

不是類型、語法，甚至不是抽象架構。困難在於達成一致：應該存在什麼？絕不應發生什麼？哪些權衡重要？系統允許忘記什麼？當世界比工單更混亂時，“完成”意味着什麼？

智能體並未消除那個問題。它們使其更加可見。

幾十年來，我們將規格問題隱藏在會議、積壓工作、代碼審查、QA週期、事故覆盤和高級工程師的私人心智模型中。大量軟件工程從來不是“寫代碼”。而是將未充分指定的想法通過足夠多的摩擦，迫使缺失部分暴露出來。

智能體減少了生成代碼的摩擦。這很棒。但這也意味着缺失部分在更晚的階段浮出水面，因為系統現在可以在任何人真正決定實現應意味着什麼之前，產生一個看似合理的實現。

在舊世界中，模糊的需求撞上人類的緩慢。在智能體世界中，模糊的需求撞上機器的速度。

當實現變得更便宜時，瓶頸並未消失。它轉移到規格和驗證。

但編寫規格只是問題的一半

幾乎每種對此權衡的框架都遺漏了：在你將規格交給智能體之前，必須對其進行驗證。

這聽起來顯而易見，但實際上被系統性地忽視。

編寫規格時——即使非常小心——它可能以在智能體執行前不可見的方式失敗。可能內部不一致：兩個相互矛盾的需求，孤立看都不明顯錯誤。可能不完整：充分覆蓋快樂路徑，但對第三方API返回429時隻字不提。可能技術上正確但不可測試：描述的行為無法機械驗證。最陰險的是，可能正是你寫的，但不是你本意的。

智能體忠實地執行有缺陷的規格，產生難以調試的東西。它通過了所有給定的檢查。問題不在實現——而在上游，規格本身。現在修正循環更昂貴，因為你必須撤銷的不僅是代碼，還有推理。

因此，規格驗證是一個獨立的成本類別，位於“寫規格”和“運行智能體”之間。它詢問：此規格內部一致嗎？是否足夠完整以有用約束智能體，但不過度約束有效解決方案？它是否實際描述了我們打算構建的東西？

該驗證工作是人力時間，或是智能體時間，或理想情況下兩者皆是——但它不為零。一旦你誠實地將其記入分類賬，圖像就會改變。

智能體如何編寫規格

還有第三種策略被這兩極框架系統性地忽略：使用智能體來編寫和驗證規格，然後使用實現智能體來執行它。

這改變了規格側成本結構。不是繁重的人力來產生驗收標準或BDD場景，而是規格起草智能體從粗略意圖產生第一版。規格驗證智能體——具有不同角色和系統提示，可能帶有搜索或領域知識——壓力測試該草稿的一致性、完整性和可測試性。測試編寫智能體將存活的聲明轉換為可執行檢查。你審查結果，這比從頭編寫更快。

重要的是，智能體不應僅僅“編寫需求”。那會產生精美的迷霧。

一個有用的規格編寫智能體更像一個懷疑的產品工程師，而不是速記員。它應命名假設。應分離目標與非目標。應產生示例和反例。應説明哪些需求可機械測試，哪些仍依賴人類判斷。應識別懶惰實現可能遺漏的失敗模式。應詢問什麼是有效解決方案必須不變的。

最好的提示不是“給我寫一份規格”。更接近於此：

起草能讓另一個智能體安全實現的最小規格。包括假設、非目標、驗收標準、邊界情況、可觀察結果和開放問題。然後標記哪些部分可成為自動測試，哪些需要人工審查。

然後你運行不同的智能體針對輸出：

攻擊此規格。找出矛盾、歧義術語、隱藏依賴、不可測試的聲明、缺失的失敗模式，以及實現能通過書面標準但仍違反意圖的地方。

最佳點不是智能體撰寫的散文。而是經過人類批准、智能體起草、對抗性審查的規格，並儘可能讓神諭可執行。

智能體並未消除對規格的需求。它們可以降低向曲線有用部分移動的成本，其中規格足夠完整以指導實現，但仍由人類審查。

這並未使規格驗證消失。它改變了誰做以及成本如何。結構性要求——實現智能體運行前必須驗證規格——仍然存在。變化是智能體現在承擔了部分工作。

BDD如何部分解決此問題

行為驅動開發（如果做得好）將規格編寫和規格驗證摺疊到同一工件中。Gherkin場景同時是意圖描述和可執行測試。你可以針對骨架實現立即運行規格，並觀察描述是否產生一致行為。使規格可執行的行為強制了散文驗收標準所沒有的一種驗證——某些歧義必須在場景運行前解決。

這就是為什麼總成本曲線的最低點不僅僅反映減少的返工。它反映了驗證內置於格式中的結構優勢。

當BDD將判斷從重複人工審查轉移到可執行神諭時，它就發揮了作用。這就是為什麼其最佳點出現在足夠穩定可測試的行為附近。

問題是仍然有人必須寫好場景。Gherkin可能寫得差。業務語言規格可能以BDD框架無法捕捉的方式模糊，因為歧義存在於語義而非語法。格式有幫助，但不能替代紀律。

多智能體管道破壞一切

如果你在良好邊界任務上運行單個智能體，未充分指定是可以恢復的。反饋環路緊密，修正是局部的，成本有界。

多智能體管道完全是另一類問題。

當智能體A的產出成為智能體B的輸入時，A的任何解釋性漂移都會加劇到B的執行中。B不知道A稍微偏離軌道。B努力工作且自信地建立在錯誤基礎上。當產出到達人類時，錯誤已通過多層看似一致的工作被放大並掩蓋。

這使盈虧平衡點決定性地移向規格。在多智能體系統中，規格不僅是單個執行的指導——它是智能體間的協調契約。該契約越不精確，每個智能體的解釋自由度引入的方差就越大。你希望智能體之間有強類型接口，而不是鬆散的對話式交接。

對於多智能體工作，x軸不再只是“我們指定了多少？”而是“交接契約有多強？”最低點移向類型化契約和可執行驗證器。

該契約的驗證相應地更重要。如果協調智能體的規格有缺陷，你不會只有一個智能體做錯事——而是所有智能體同時做着不同錯誤的事。

方法論中倖存的內容

那麼，這是否使我們關於協調軟件團隊所學的一切都過時了？

不。但它確實改變了哪些部分是承重的。

作為儀式的敏捷很麻煩。人們向空中背誦狀態的站會、產生虛構精度的估算儀式、主要功能是安撫管理層認為不確定性已被馴服的工單儀式——智能體不需要這些。老實説，人類也不需要。

作為反饋哲學的敏捷倖存。短週期倖存。工作軟件勝過抽象進展倖存。客户協作倖存。當現實説話時計劃應彎曲的堅持倖存。如果有變化，智能體使之更重要，因為它們能快速產生大量令人信服的錯誤。反饋環路必須更緊，而不是更松。

極限編程（XP）甚至更好地倖存。測試優先思維倖存，因為在實現更便宜時，可執行神諭更有價值。結對編程演變為人類-智能體配對，但基本思想保持不變：保持設計判斷接近代碼生產。持續集成倖存，因為每個智能體變更都需要快速、公正的門禁。重構倖存，因為智能體能產生工作代碼，但局部正確而結構平庸。小型發佈倖存，因為大的不可見增量是人類和智能體都迷失的地方。

可能消失的是作為大型羣體協調戲劇的方法論。

[原文為控制成本而截斷]