事實驅動開發：簡化代理工作流

軟體開發的格局正在不斷演變，AI 代理在從程式碼生成到維護的各個階段中扮演著日益重要的角色。然而，將這些代理有效地整合到傳統的開發範式中，特別是規格驅動（spec-driven）的方法，帶來了獨特的挑戰。facts 專案引入了一個新穎的概念：事實驅動開發，旨在透過剝離規格的複雜性並純粹專注於可驗證的事實，來簡化代理工作流。

這種轉變是由於觀察到 AI 代理在與冗長或複雜的規格互動時會出現效率低下的問題。代理容易產生不必要的「廢話」（fluff），且大型專案中規格的龐大數量與相互關聯性往往導致「一致性稅」（consistency tax），使得代理難以在整個文件中保持連貫性。facts 的核心前提是，每一份規格，其核心本質上僅僅是一組事實的集合；透過直接隔離並呈現這些事實，開發過程對於 AI 代理而言可以變得更加高效且不易出錯。

代理使用傳統規格驅動開發的問題

傳統的規格文件雖然對人類的理解與協作至關重要，但往往包含敘事性元素、程序性指令以及隱含的上下文，這些對於 AI 代理而言，高效處理起來可能具有挑戰性。facts 的創作者 everlier 強調了幾個關鍵問題：

• 廢話生成：當給予廣泛的規格時，代理可能會生成與核心意圖偏離的贅餘細節或解釋，增加了噪音而非訊號。
• 一致性稅：在大型專案中，規格可能會變得非常龐大且相互關聯。在這些文件中保持一致性，特別是在發生變更時，會成為沉重的負擔，導致代理出錯並需要人類不斷監督。
• 維護開銷：為了讓詳細的規格與不斷演進的程式碼庫保持同步並一致，所需的努力可能非常巨大，消耗了寶貴的開發資源。

這些問題表明，原本旨在澄清人類理解的結構，可能會在無意中使代理的操作變得複雜。

什麼是「事實」？它們與「規格」有何不同？

facts 方法的核心主張是，一份規格最終是原子化、可驗證陳述的集合。兩者的區別在於其結構與意圖：

• 規格 (Specs)：通常冗長、具敘事性，且可能包含程序性步驟、設計選擇與上下文資訊。它們是為全面的人類理解而設計的，可能包含冗餘或隱含的依賴關係。
• 事實 (Facts)：簡潔、宣告式、原子化的真理陳述。它們剝離了敘事性，純粹專注於可驗證的資訊。例如，與其用一段文字描述使用者流程，一個「事實」可能會陳述：「使用者驗證需要有效的電子郵件與密碼。」或「API 端點 /users 回傳一個包含使用者物件的 JSON 陣列。」

正如一位評論者 @bgsesr42 所詢問的，「規格與事實列表有何不同？」兩者的區別主要在於粒度與焦點。規格包含事實，但它也包含更多內容。facts 旨在提取僅有的核心、可驗證的真理，使代理更容易吸收並據此採取行動，而無需解析贅餘資訊或推論意圖。

使開發對代理更友善

透過將規格精煉為一組離散的事實，facts 專案旨在建立一個本質上更適合 AI 代理的環境。這種方法提供了幾種潛在的好處：

• 減少歧義：原子化的事實為代理留下的誤解空間較小，從而產生更精確的輸出。
• 更容易進行一致性檢查：驗證一組離散事實之間的一致性，比交叉引用複雜且具敘事性的規格要簡單得多。
• 專注的代理行動：可以引導代理直接針對這些事實進行操作，執行如程式碼生成、測試或文件更新等任務，並具有對所需結果更清晰的理解。
• 較低的維護成本：更新特定的事實通常比修改傳統規格的大型章節要簡單得多，從而降低了代理的「一致性稅」。

為了促進這一點，facts 專案提供了一套專為代理設計的技能與命令列介面 (CLI)，以便代理與這些事實進行互動與管理。這些工具讓代理能夠以實際且整合的方式利用事實驅動開發。

未來的路徑：證明概念

雖然從規格轉向事實的概念性轉變呈現了一個引人注目的願景，但這種方法的實際效能將是其能否被採用的關鍵。正如 @sminchev 正確指出的，需要具體的證據：

我很樂意看到一些證明這行得通的證據。一個開始並運作中的專案。一個更友善的規格看起來是什麼樣子，以及為什麼代理能更好地理解它。

透過真實世界的專案來展示這種範式，展示「更友善」的規格（即事實的集合）是如何構建的，並展示代理如何處理並從中受益，將是至關重要的。這種驗證將有助於說明事實驅動開發所承諾的，在代理效能、一致性與整體開發效率方面的實質性改進。

結論

facts 專案代表了我們如何建構開發流程的一種有趣的演進，特別是當 AI 代理日益深入地整合到我們的開發工作流中時。透過挑戰傳統對冗長規格的依賴，並轉而倡導一種精簡、事實驅動的方法，它試圖解決常見的痛點，例如代理生成的廢話以及高昂的一致性稅。隨著專案成熟並出現真實世界的實作，我們將會看到這種範式轉變如何重新定義代理輔助開發的效率。