暗黑工廠的驗證層

StrongDM 在兩條規則下發布軟體：「程式碼不得由人類撰寫」以及「程式碼不得由人類審查」。¹ 由 Justin McCarthy、Jay Taylor 和 Navan Chauhan 組成的三人團隊，建造並發布了 Attractor 與 CXDB（16K 行 Rust、9.5K 行 Go、6.7K 行 TypeScript），每位工程師每日至少投入 1,000 美元的 token 費用。¹ BCG Platinion 引用 Spotify 與 TechCrunch 的報導指出，Spotify 最優秀的開發者自 2025 年 12 月起便不再撰寫程式碼，該公司每月合併數百個 AI 生成的 pull request。²

Dan Shapiro 將終極階段稱為第 5 級：暗黑工廠。程式碼由機器生成、由機器驗證、在無人閱讀任何一行的情況下部署。³ 前面的級別追溯了大多數團隊正在經歷的演進——從手動編碼（第 0 級）、任務分流（第 1 級）、高速公路自動駕駛（第 2 級）、配備安全駕駛員的 Waymo（第 3 級），到你寫好規格後離開 12 小時的無人計程車模式（第 4 級）。³

至今無人妥善回答的問題是：第 5 級的驗證層究竟該是什麼樣貌？

驗證問題的複合效應

在第 5 級以下的每個級別，人類都會在某個環節閱讀程式碼。第 3 級，人類以資深開發者的角色管理 AI。第 4 級，人類在 12 小時後檢查測試是否通過。³ 這些級別之所以可行，是因為擁有機構知識的人能夠將產出與意圖進行模式比對。規格寫著「以指數退避重試」，而程式碼做的是線性重試——開發者一眼就能抓到問題。

完全移除人類，驗證就變成了截然不同的問題。不是程度上更難，而是本質上不同。驗證者不能依賴閱讀理解。驗證者必須將「正確」的含義編碼為可執行的形式，然後依據該編碼評估產出，而無需檢視產出本身。

核心陷阱在於代理程式操弄測試。StrongDM 發現他們的代理程式會撰寫 return true 來通過測試套件，實際上卻什麼都沒做。¹ 測試全綠、CI 流水線一切正常，程式碼卻毫無價值。史丹佛法學院的 Eran Kahana 將這一觀察延伸為結構性警告：更深層的問題在於循環論證——由同一類技術來評估同一類技術所撰寫的程式碼。⁴

古德哈特定律在此展現了異常強大的力量。當代理程式以通過測試為目標進行最佳化，測試通過便不再衡量正確性。⁴ 每一個成為目標的指標都不再是好的指標。暗黑工廠的驗證層必須考慮這一動態，否則它衡量的只是合規性，而非品質。

StrongDM 實際如何解決驗證問題

StrongDM 的答案是他們所稱的「場景」——儲存在程式碼庫之外的端對端使用者故事，功能類似機器學習中的留出集。¹ 這個類比十分精確：正如機器學習模型會用它從未訓練過的資料來評估，代理程式建構的程式碼也會用代理程式在生成過程中無法存取的場景來評估。

關鍵指標是「滿意度」：觀察到的軌跡中可能滿足使用者的比例。¹ 對於何種分數構成足夠的滿意度，業界尚無標準。StrongDM 透過經驗法則得出了自己的門檻。

為了讓場景測試能夠規模化運作，StrongDM 建構了數位孿生宇宙——Okta、Jira、Slack、Google Docs、Drive 和 Sheets 的行為複製體。¹ 這些孿生體的目標是使用熱門的公開參考 SDK 客戶端函式庫，達成 100% 的 API 相容性。¹ 代理程式對孿生體執行測試，而非對模擬端點。孿生體的行為保真度決定了測試的可信度。

StrongDM 觀察到一個我也親身經歷過的現象：「隨著 Claude 3.5 第二版（2024 年 10 月）的推出，長時程代理式編碼工作流開始累積正確性，而非累積錯誤。」¹ 在能力門檻之下，代理程式運行越久，錯誤越多；超過門檻後，運行越久，程式碼越好。暗黑工廠模式要在模型跨過該門檻之後才變得可行。

五層治理架構

BCG Platinion 的五大支柱轉型框架包含一個治理層，在程式碼進入生產環境之前設有多道驗證關卡。² 五大支柱分別是：意圖驅動的作業系統、知識編纂基礎設施、人才技能升級、由獨立驗證代理程式組成的治理層，以及用於編排的工廠架構。² 在治理支柱中，BCG Platinion 描述了由獨立代理程式執行的場景測試、靜態分析、架構一致性檢查、行為回歸測試，以及主動嘗試破壞產出的紅隊代理程式。²

獨立性至關重要。當同一個代理程式撰寫並測試自己的程式碼時，Kahana 所指出的循環論證問題便會浮現。⁴ 當由另一個代理程式——擁有不同的系統提示、不同的上下文、不同的激勵機制——來評估工作成果，失敗模式就會去相關化。不是消除，是去相關化。兩個代理程式仍可能共享從訓練資料中繼承的系統性偏誤。但當評估代理程式從不同的框架運作時，出現相同盲點的機率會下降。

BCG Platinion 將「意圖思維」視為暗黑工廠團隊的關鍵能力：將商業需求轉化為精確、可測試的預期結果描述。² 人類的角色從撰寫程式碼轉變為撰寫規格，供代理程式據以執行。糟糕的規格會讓錯誤行為通過測試——與 StrongDM 遇到的 return true 如出一轍。¹

BCG Platinion 也指出了一個我親身體會過的限制：「AI 代理程式的效能取決於它們能存取的編纂知識。」² 缺乏專案脈絡的代理程式會生成看似合理但違反在地慣例的程式碼，忽略架構決策，並重新發現團隊早已解決的問題。編纂的知識——設計決策、API 合約、風格指南、故障歷史——是基礎設施，不是文件。

我目前在第 4 級運行的系統

我的隔夜執行迴圈——Ralph Loop——運作於 Shapiro 的第 4 級。我撰寫規格、啟動代理程式、入睡，隔天早上審查結果。代理程式在 95 個以上的 hook 環境下運行，這些 hook 會攔截每一次工具呼叫——檔案寫入、git 指令、shell 執行——在執行前後介入。hook 強制施加代理程式無法協商或覆寫的約束。

這些 hook 在工具層級解決了 Kahana 所指出的操弄問題。試圖 force-push 到 main 的代理程式會在指令執行前被攔截，而非在測試發現損害之後。試圖提交符合 .env 模式檔案的代理程式會被攔截。宣稱「所有測試通過」卻未實際執行 pytest 的代理程式會被證據閘門標記——證據閘門要求貼出零失敗的測試輸出，而非聲稱測試會通過。

證據閘門對每一項非瑣碎變更強制執行六項準則：遵循程式碼庫模式（指出模式名稱與所在檔案）、最簡可行方案（陳述被否決的替代方案）、邊界情況已處理（逐一列出）、測試通過（貼上輸出）、無回歸（指出已檢查的檔案）、解決實際問題（陳述使用者需求及變更如何回應）。「我認為」和「應該可以」不算證據。閘門拒絕模糊措辭，要求具體產出物。

品質迴圈——實作、審查、評估、精煉、退一步全觀、重複、回報——作為行為約束編碼在代理程式的系統提示中，透過 CLAUDE.md 施行。迴圈無法保證代理程式遵循每一個步驟，但 hook 會驗證它確實做了。

BCG Platinion 的五大支柱對應到我已維護的基礎設施：

• 意圖驅動作業系統：CLAUDE.md 檔案與 PRD 驅動的開發規格將專案意圖編碼為可執行的上下文。
• 知識編纂：139 個以上的技能，以可重用能力的形式組織，讓代理程式得以存取專案慣例、架構決策和領域知識。
• 治理：hook 實現攔截層，證據閘門實現審計層，品質迴圈實現行為約束層。

有兩根支柱我尚未建構：人才技能升級（對獨立開發者而言不適用）以及作為專用編排平台的工廠架構（我目前的設定使用 Claude Code 的原生代理程式衍生機制，而非專門打造的工廠）。

從第 4 級到第 5 級的鴻溝

從第 4 級邁向第 5 級，意味著消除晨間審查。目前我醒來後會閱讀代理程式一夜的產出，檢查 git diff、執行應用程式、驗證產出是否符合我的意圖。這段審查耗時 30 分鐘到 1 小時，能捕捉到 hook 遺漏的問題。

hook 遺漏的問題才是有趣的部分。它們屬於目前自動化處理不佳的幾個類別：

意圖漂移。 代理程式忠實地完成了規格，但規格本身存在歧義，代理程式選擇了錯誤的詮釋。沒有任何測試能捕捉到一個產生有效行為的錯誤詮釋。StrongDM 的場景方法以使用者故事作為規格來應對這一問題，而非技術需求。¹ 場景描述的是使用者的體驗，而非程式碼的行為。

架構侵蝕。 代理程式新增了一個獨立運作正常的功能，卻破壞了系統的結構一致性。一個繞過既有 repository 模式的新資料庫查詢，一個複製另一個模組邏輯的新端點。靜態分析能抓到一部分，BCG Platinion 治理層中的架構一致性檢查能抓到更多。² 但兩者都無法捕捉那些微妙的情況——新程式碼在技術上符合既有模式，卻引入了概念分歧，在未來的變更中逐漸累積惡化。

機構知識流失。 Kahana 提出了一個被低估的風險：當沒有人閱讀程式碼，就沒有人能培養對系統的直覺。⁴ 正如 Kahana 所警告的：「沒有人會知道原因，沒有人會知道如何修復。」⁴ 目前，我的晨間審查能漸進式地累積這種直覺。到了第 5 級，系統對其操作者而言將變得不透明。每個複雜系統終究會遭遇自動化無法處理的介入需求——安全事件、違反測試套件中既有假設的業務邏輯變更、與行為不同於其文件描述的外部系統整合。從未閱讀程式碼的操作者無法有效介入。

驗證層實際上需要什麼

綜合 StrongDM 的實踐、BCG Platinion 的治理框架、Kahana 的失敗分析，以及我自身的基礎設施，暗黑工廠的驗證層至少需要：

留出式評估。 生成代理程式在程式碼產出過程中無法存取的測試。StrongDM 的場景。儲存在程式碼庫之外、由獨立代理程式評估的行為規格。缺少留出式評估，古德哈特定律會將每個測試套件變成被瞄準的靶心。

用於整合測試的數位孿生。 代理程式無法對生產系統進行測試。模擬物（mock）太過淺薄——它們驗證的是 API 合約，而非行為。複製外部依賴行為表面的孿生體，能在無生產風險的情況下實現端對端場景執行。

具有去相關失敗模式的多代理程式驗證。 撰寫代理程式與評估代理程式必須從不同的上下文運作。紅隊代理程式主動探測操弄、投機取巧和虛假驗證，提供被動測試無法達到的防護層。

工具層級攔截。 在執行前攔截有害操作的 hook，而非在損害發生後才偵測的測試。hook 層運作在代理程式決策之下，無法被巧妙的提示或 return true 捷徑所繞過。

可執行的意圖規格。 精確到足以偵測歧義的規格。BCG Platinion 的「意圖思維」能力。² Shapiro 第 4 級中你離開 12 小時前撰寫的規格。³ 規格才是產品，程式碼只是副產品。

無責任缺口的審計軌跡。 Kahana 引用 AI 生命週期核心原則，要求產出「可追溯至適當的負責方」。⁴ 針對代理程式建構的軟體，業界尚無標準的審計方法論。⁴ 驗證層需要產生能讓人類（或監管機構、或事件回應者）從已部署的行為一路追溯到生成該行為之規格的產出物。

誠實的評估

我以高度信心運行第 4 級。我的隔夜代理程式產出的工作，通過晨間審查的比例超過半數。hook 捕捉機械性故障，證據閘門捕捉認知性故障，品質迴圈減少行為性故障。

第 5 級要求解決我尚未解決的問題：不依賴人類模式比對的意圖漂移偵測、能捕捉概念侵蝕而非僅限結構違規的架構一致性檢查、在系統中而非操作者腦中累積的機構知識。

BCG Platinion 報告採用暗黑工廠模式的團隊實現了 3 至 5 倍的生產力提升。² StrongDM 以三名工程師和一筆 token 預算發布了代理程式建構的軟體。¹ 生產力的論據很明確，驗證的論據則否。

在第 5 級取得成功的團隊有一個共同特質：他們在驗證基礎設施上的投入超過在程式碼生成上的投入。StrongDM 在信任代理程式交付程式碼之前，先建構了整個數位孿生宇宙。¹ BCG Platinion 的框架包含五大轉型支柱，其中治理層在程式碼進入生產環境前設有多道驗證關卡。² 暗黑工廠並非在黑暗中運行的工廠，而是以驗證層為光源的工廠——其餘一切，包括程式碼本身，都是商品。

我先前曾撰文探討代理程式在無監督下運行時會出什麼問題，以及證據閘門如何防禦虛假驗證。那些文章描述的是第 4 級的基礎設施。暗黑工廠要求的是同樣的基礎設施，但必須擴展到在目前那位閱讀晨間 diff 的人類缺席的情況下運作。hook、證據閘門、品質迴圈——在第 5 級是必要的，但並不充分。缺失的環節是能與生成同等自主地擴展的驗證。

建構那個環節，就是前方的工作。