為什麼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）甚至更好地倖存。測試優先思維倖存，因為在實現更便宜時，可執行神諭更有價值。結對程式設計演變為人類-智慧體配對，但基本思想保持不變：保持設計判斷接近程式碼生產。持續整合倖存，因為每個智慧體變更都需要快速、公正的門禁。重構倖存，因為智慧體能產生工作程式碼，但區域性正確而結構平庸。小型釋出倖存，因為大的不可見增量是人類和智慧體都迷失的地方。

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

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