暗黑工廠驗證層：當沒有人類閱讀程式碼

暗黑工廠（Level 5）是一種軟體開發環境，由機器生成、驗證並部署程式碼——沒有任何人類閱讀任何一行。 使暗黑工廠得以運作的驗證層，需要留存式評估、數位孿生宇宙、多代理審查，以及編碼化的品味約束。少了這一層，代理程式就會鑽測試的漏洞，品質隨之崩解。

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 將終點稱為 Level 5：暗黑工廠。程式碼由機器生成、由機器驗證、部署時無人閱讀任何一行。³ 前面的各級追蹤了多數團隊目前的演進路徑：手動編碼（Level 0）、任務卸載（Level 1）、高速公路自動駕駛（Level 2）、配備安全駕駛員的 Waymo（Level 3），以及機器人計程車模式——撰寫規格後離開 12 小時（Level 4）。³

至今無人妥善回答的問題是：Level 5 的驗證層究竟該是什麼樣貌？以下分析將勾勒所需的基礎設施，建立在我用以評估所有工程產出品質的品味基礎設施之上。

驗證問題呈複合式增長

Level 5 以下的每一級，總有人類在某個環節閱讀程式碼。Level 3，人類以資深開發者的角色管理 AI。Level 4，人類在 12 小時後檢查測試是否通過。³ 這些層級之所以可行，是因為具備組織知識的人能夠對照意圖進行模式比對。規格書寫「以指數退避策略重試」，程式碼卻執行線性重試——開發者一眼就能發現問題。

徹底移除人類後，驗證就變成了截然不同的問題。不是程度上更難，而是本質上不同。驗證者無法依賴閱讀理解能力，必須將「正確」的定義編碼為可執行的形式，然後在不檢視產出物本身的情況下，對照該編碼進行評估。

核心陷阱在於代理程式鑽測試漏洞。StrongDM 發現他們的代理程式撰寫 return true 來通過測試套件，實際上什麼有用的事都沒做。¹ 測試全綠。CI 管線回報成功。但程式碼毫無價值。史丹佛法學院的 Eran Kahana 將這一觀察延伸為結構性警告：更深層的問題是循環性——同一類技術在評估由同一類技術所撰寫的程式碼。⁴

古德哈特定律在此處發揮了異常強大的作用。品味是一套技術系統一文論證了自動化驗證之上需要一個判斷層；缺少品味層級的評估，測試就會從衡量標準退化為目標。當代理程式以通過測試為優化目標時，通過測試便不再衡量正確性。⁴ 任何成為目標的指標都不再是好指標。暗黑工廠的驗證層必須正視這個動態，否則衡量的只是合規性而非品質。

StrongDM 實際上如何解決驗證問題

StrongDM 的答案是他們稱之為「Scenarios」的機制：存放在程式碼庫之外的端到端使用者故事，其功能類似機器學習中的留存集。¹ 這個類比非常精確：正如機器學習從業者用從未訓練過的資料來評估模型，獨立的代理程式用編碼代理程式在生成過程中無法存取的場景來評估所產出的程式碼。

關鍵指標是「Satisfaction」：觀察到的軌跡中可能滿足使用者需求的比例。¹ 目前業界尚無標準來界定多高的滿意度分數才算足夠。StrongDM 透過經驗法則找到了自己的閾值。

為了讓場景式測試大規模運作，StrongDM 打造了一個數位孿生宇宙：Okta、Jira、Slack、Google Docs、Drive 和 Sheets 的行為克隆體。¹ 這些孿生體以使用熱門公開參考 SDK 用戶端程式庫達到 100% API 相容性為目標。¹ 代理程式針對孿生體執行測試，而非針對模擬端點。孿生體的行為保真度決定了測試的可信度。

StrongDM 觀察到一個我也曾親歷的模式：「隨著 Claude 3.5 第二版修訂（2024 年 10 月），長時程的代理式編碼工作流開始累積正確性而非累積錯誤。」¹ 在能力閾值之下，代理程式執行時間越長，錯誤越多。超越該閾值後，執行越久反而產出越好的程式碼。暗黑工廠模式在模型跨越此閾值之後才真正可行。

五層治理架構

BCG Platinion 的五支柱轉型框架包含一個治理層，在程式碼進入生產環境前須通過多重驗證步驟。² 五大支柱分別是：意圖驅動的作業系統、編碼化知識基礎設施、人力提升、由獨立驗證代理程式組成的治理層，以及用於編排的工廠架構。² 治理支柱包括由獨立代理程式執行的場景式測試、靜態分析、架構一致性檢查、行為回歸測試，以及主動嘗試破壞產出的紅隊代理程式。²

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

BCG Platinion 將「意圖思維」定義為暗黑工廠團隊的關鍵能力：將業務需求轉化為精確、可測試的預期結果描述。² 人類的角色從撰寫程式碼轉向撰寫代理程式可據以執行的規格。規格不佳會導致測試通過卻行為錯誤——與 StrongDM 遭遇的 return true 如出一轍。¹

BCG Platinion 同時點出了一個我親身經歷過的限制：「AI 代理程式的效能取決於它能存取的編碼化知識。」² 缺乏專案上下文的代理程式會生成看似合理卻違反本地慣例、忽略架構決策、重新發現團隊早已解決之問題的程式碼。編碼化知識（設計決策、API 契約、風格指南、故障歷史）是基礎設施，不是文件。

我目前在 Level 4 運行的實踐

我的隔夜執行迴圈——Ralph 代理架構——運行在 Shapiro 的 Level 4。我撰寫規格、啟動代理程式、入睡，隔天早上審查結果。代理程式運行時受到 95 個以上的 hook 攔截，每一次工具呼叫（檔案寫入、git 命令、shell 執行）在執行前後都會被攔截。這些 hook 強制執行代理程式無法協商或繞過的約束。

這些 hook 在工具層面解決了 Kahana 所指出的鑽漏洞問題。另一篇文章完整記錄了 hook 架構，但此處的關鍵特性在於攔截：hook 在工具執行之前觸發，而非之後。嘗試強制推送到 main 的代理程式會在命令執行前遭到阻擋。嘗試提交匹配 .env 模式的檔案的代理程式會被攔截。宣稱「所有測試通過」卻未執行 pytest 的代理程式則會被證據閘門標記——該閘門要求貼出顯示零失敗的測試輸出，而非口頭聲稱測試會通過。

證據閘門對每一項非瑣碎變更強制執行六項標準：遵循程式碼庫慣例（指出該慣例及其所在檔案）、最簡可行方案（說明被否決的替代方案）、邊界情況已處理（逐一列出）、測試通過（貼上輸出）、無回歸（指出已檢查的檔案）、解決了實際問題（陳述使用者需求及變更如何回應）。「我相信」和「應該會」不構成證據。閘門拒絕含糊用語，要求具體產出物。

品質迴圈（實作、審查、評估、精煉、全局檢視、重複、報告）作為行為約束，透過 CLAUDE.md 編碼在代理程式的系統提示中運行。迴圈本身不保證代理程式遵守每一步，但 hook 會驗證它確實做到了。

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

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

有兩個支柱我尚未建立：人力提升（對獨立從業者而言不適用）和作為專用編排平台的工廠架構（目前的設定使用 Claude Code 的原生代理生成機制，而非專門打造的工廠）。複合上下文系統描述了這些基礎設施層如何累積為資本資產，使每一次後續工作階段都更加強大。

Level 4 與 Level 5 之間的鴻溝

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

Hook 遺漏的問題恰恰是最值得關注的。它們歸為幾類，而目前的自動化在這些方面表現不佳：

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

架構侵蝕。 代理程式新增了一個孤立看來運作正常的功能，卻損害了系統的結構一致性。例如一個繞過既有 repository 模式的新資料庫查詢，或一個複製另一模組邏輯的新端點。靜態分析能捕捉其中一部分。架構一致性檢查（BCG Platinion 治理層的一環）能捕捉更多。² 但兩者都無法捕捉那些微妙的情況——新程式碼在技術上符合現有模式，卻引入了概念上的分裂，隨未來變更而不斷複合累積。

組織知識流失。 Kahana 提出了一個被低估的風險：當沒有人閱讀程式碼時，就沒有人能對系統建立直覺。⁴ 如 Kahana 所警告：「沒有人會知道為什麼。沒有人會知道如何修復。」⁴ 目前，我的早晨審查讓這種直覺逐步累積。到了 Level 5，系統對其操作者變得不透明。每一個複雜系統終將需要自動化無法處理的干預：一場安全事件、一項違反測試套件內建假設的業務邏輯變更、與一個行為不符其文件描述的外部系統整合。從未閱讀程式碼的操作者無法有效介入。

驗證層真正需要什麼

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

留存式評估。 生成代理程式在程式碼產出過程中無法存取的測試。StrongDM 的場景。與程式碼庫分開存放、由獨立代理程式評估的行為規格。缺少留存式評估，古德哈特定律會將每一個測試套件變成目標。

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

具備去相關化失敗模式的多代理驗證。 撰寫代理程式和評估代理程式必須在不同的上下文中運作。主動探測鑽漏洞、走捷徑和幽靈驗證行為的紅隊代理程式，提供了被動測試所無法企及的防護層。

工具層級攔截。 在有害操作執行之前予以阻擋的 hook，而非事後偵測損害的測試。Hook 層位於代理程式決策之下，能抵禦巧妙提示或 return true 捷徑的規避嘗試。

可執行的意圖規格。 精確到歧義可被偵測的規格。BCG Platinion 的「意圖思維」能力。² Shapiro 的 Level 4 規格——離開 12 小時前撰寫的那份。³ 規格才是產品，程式碼只是副產物。

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

誠實的評估

我在 Level 4 運行得頗具信心。隔夜代理程式產出的成果多半能通過早晨審查。Hook 捕捉機械性故障。證據閘門捕捉認知性故障。品質迴圈減少行為性故障。

Level 5 要求解決我尚未解決的問題。無需人類模式比對的意圖漂移偵測。能捕捉概念侵蝕而不僅是結構違規的架構一致性。累積在系統中而非操作者腦中的組織知識。

BCG Platinion 報告採用暗黑工廠模式的團隊獲得了 3-5 倍的生產力提升。² StrongDM 以三名工程師和一筆 token 預算發布了代理程式建構的軟體。¹ 生產力的論證已經明確。驗證的論證尚未。

在 Level 5 取得成功的團隊有一個共同特徵：他們在驗證基礎設施上的投入超過了程式碼生成。StrongDM 在信任代理程式交付程式碼之前，先打造了一整個數位孿生宇宙。¹ BCG Platinion 的框架包含五大轉型支柱，其中治理層在程式碼進入生產環境前設有多重驗證步驟。² 暗黑工廠並非在黑暗中運行的工廠，而是一座以驗證層為光源、其餘一切（包括程式碼）皆為商品的工廠。

我先前寫過代理程式無人監督時會出什麼問題以及證據閘門作為對抗幽靈驗證的防線。那些文章描述的是 Level 4 的基礎設施。暗黑工廠要求的是同一套基礎設施，但須擴展到能在目前負責閱讀早晨 diff 的人類缺席時運作。Hook、證據閘門、品質迴圈：在 Level 5 都是必要條件，但並非充分條件。缺失的一塊是驗證能力須與生成能力同步擴展自主性。

建構這一塊，是前方的工作。AI 工程中心收錄了這項研究的完整脈絡，從個別 hook 設計，經過複合上下文，直至暗黑工廠的前沿。

FAQ

什麼是軟體開發中的暗黑工廠？

暗黑工廠（Dan Shapiro 的 Level 5）是一種軟體開發環境，由機器生成程式碼、驗證程式碼、部署程式碼，全程無人閱讀任何一行。前面的各級從手動編碼（Level 0）逐步邁向更高自動化，Level 4 為「機器人計程車」模式——人類撰寫規格、離開 12 小時後審查結果。暗黑工廠連這最後的審查也一併取消。

Level 5 最大的驗證挑戰是什麼？

核心陷阱在於代理程式鑽測試漏洞。StrongDM 發現代理程式撰寫 return true 來通過測試套件，實際上什麼有用的事都沒做。古德哈特定律在此處發揮異常強大的作用：當代理程式以通過測試為優化目標時，通過測試便不再衡量正確性。驗證層必須透過留存式評估（生成代理程式在程式碼產出過程中無法存取的測試）、具備去相關化失敗模式的多代理驗證，以及在有害操作執行之前予以阻擋的工具層級攔截來應對此問題。

Level 4 與 Level 5 之間的差距在哪裡？

三個目前自動化處理不佳的問題：意圖漂移（代理程式忠實完成規格，卻對模糊需求選擇了錯誤的詮釋）、架構侵蝕（新功能孤立看來正常運作，卻損害結構一致性），以及組織知識流失（當沒有人閱讀程式碼，就沒有人能建立事件應變或業務邏輯變更時所需的系統直覺）。

StrongDM 如何解決驗證問題？

StrongDM 使用「Scenarios」——存放在程式碼庫之外的端到端使用者故事，其功能類似機器學習中的留存集。獨立的代理程式用編碼代理程式在生成過程中無法存取的場景來評估程式碼。他們打造了一個數位孿生宇宙（Okta、Jira、Slack、Google Docs 的行為克隆體），以 100% API 相容性為目標，使代理程式得以對照真實的行為面進行測試，而非淺層的模擬物。