不寫、不看、不審查：這家安全公司決定不再讓人類碰代碼，還把這套模式開源了

編譯 | Tina

沒人寫代碼，也沒人看代碼，軟件照樣交付？

2026 年 2 月，一家專注于基礎設施安全的公司 StrongDM 公開了一套“軟件黑燈工廠”式的生產線成果。

在這個生產線里，人類不再直接寫代碼、也不承擔代碼審查；開發從交互式協作變成“把 spec 和場景喂給系統”。隨后由 Agent 自動生成代碼、運行測試 / 評測 harness，并在反饋回路里反復迭代，直到結果收斂、可以交付為止。團隊把這套玩法寫進章程，最重要的只有一句話——No hand-coded software。

StrongDM AI 還不尋常的開源了它們：

其中一個倉庫是：

https://github.com/strongdm/attractor

這是他們“軟件工廠”體系中最核心的非交互式編碼 Agent。不過，這個倉庫本身一行代碼都沒有：里面只有三份 Markdown 文件，極其細致地描述了軟件的完整規格說明（spec），以及 README 里的一句提示——把這些規格說明交給你選擇的編碼 Agent 去執行即可。

另一個倉庫

https://github.com/strongdm/cxdb

這個則更接近傳統意義上的軟件發布：包含 1.6 萬行 Rust、9500 行 Go，以及 6700 行 TypeScript。這是他們的 “AI Context Store”——一個用于存儲對話歷史和工具輸出的系統，數據以不可變 DAG 的形式組織。

在 Hacker News 的討論中，很快就有開發者按圖索驥，實際跑了一遍這套流程。他表示，自己仔細閱讀了 Attractor 倉庫中的文檔，并嚴格按照 StrongDM 提供的規范，讓 Claude 基于 spec 構建了一個完整應用。最終生成的是一個可以直接使用 Claude API Key 的 AI 代理，其整體質量“明顯好于讓模型自由發揮時生成的結果”。

讓他印象最深的，是這套規格說明的體量和細節程度：整套 spec 大約6000–7000 行，覆蓋了行為約束、接口語義以及系統邊界。“我以前給代理布置項目時，規格說明最多也就一頁紙，這次的細節密度讓我非常震驚。”

當然，這次開源并不是一個“打磨完畢”的展示版本。代碼一經放出，Hacker News 上就有開發者迅速上手檢查，指出其中存在疑似 bug、Rust 反模式，以及相對寬松的錯誤處理方式。對此，StrongDM AI 團隊成員 Jay Taylor 在評論區回應稱，這批項目“是最近幾天才決定開源的”，尚未經過充分的技術優化，目前已經安排代理繼續對 CXDB 進行清理和改進。

這套實踐也很快得到了學界的點名。沃頓商學院研究 AI 與組織變革的教授 Ethan Mollick 在轉發 StrongDM 的公開內容時直言，這是一次“真正激進的軟件開發方式”：“幾乎沒有任何人類介入。即便這種方式未必適用于大多數場景，我們也需要更多這樣的跳級式設想，去重新設計流程，而不是只把 AI 塞進舊流程里。”

在他看來，真正有價值的進步，不是在原有流程上“多加一點 AI”，而是圍繞 AI，把流程本身重做一遍。

一條“禁止手寫代碼”的內部實驗線

StrongDM 是一家專注于基礎設施訪問與身份安全的公司，核心工作是管理人類與非人類身份如何安全地連接到數據庫、云資源和各類內部系統。

而他們的 AI 團隊成立于半年前， 2025 年 7 月 14 日這天，Jay Taylor、Navan Chauhan 與 StrongDM 的聯合創始人兼首席技術官 Justin McCarthy 一起，正式把一條原本分散在內部的探索工作，獨立成一個專門的團隊。

新團隊成立后，第一天的工作并不是寫代碼，而是寫一份章程。Justin McCarthy 在回顧中提到，在團隊成立的第一個小時，他們就先明確了一組接下來必須遵守的約束條件。

代碼不得由人類編寫。 代碼不得由人類審查。 如果你今天在每位人類工程師身上花費的 token 成本還不到 1000 美元，那么你的軟件工廠還有很大的改進空間。

在 StrongDM 自己的回顧里，這個決定并不是一時沖動。其背景要追溯到 2024 年末。隨著 Claude 3.5 在 2024 年 10 月的第二次修訂發布，團隊開始觀察到一個此前并不常見的變化：在長時序的 Agentic 編程任務中，結果開始疊加正確性，而不再只是不斷疊加錯誤。

到了 2024 年 12 月，這一變化已經可以通過 Cursor 的 YOLO 模式清晰地觀察到。

StrongDM 在博客中寫道，在此之前，將 LLM 反復用于編碼任務，往往會累積誤解、幻覺、語法錯誤、依賴不兼容等問題，最終讓系統“慢慢壞掉”；而結合 YOLO 模式，Anthropic 的更新模型第一次展現出他們后來在內部稱之為“非交互式開發”或“成長型軟件”的雛形。

在這樣的背景下，新成立的團隊從一開始就確立了一條極端的實驗前提：不允許任何手寫代碼。在 2025 年 7 月，這聽起來依然相當激進。

其中最耐人尋味的，是第二條規則：代碼不得由人類審查。畢竟大家都很清楚，大語言模型極其容易犯下一些“非人類式”的錯誤；在這樣的前提下，徹底放棄人工 code review，本身就顯得反直覺。

更何況，安全軟件向來是最不愿意交給“未經人工審查的 LLM 代碼”去支撐的一類系統。

規則落地后，問題也隨之出現：如果什么都不手寫，怎么確保代碼真的能跑？讓 Agent 自己寫測試，只在一個前提下有用——它們不會“作弊”，比如直接寫個 assert true。

這也迅速被他們提煉成一個更根本的問題：當實現和測試都由編碼 Agent 生成時，你要如何證明自己交付的軟件是可工作的？StrongDM 的答案，受到了場景測試（Scenario Testing，Cem Kaner，2003） 的啟發。他們是這樣描述的：

我們重新定義了“場景（scenario）”這個詞，用它來表示一個端到端的“用戶故事”。這些場景通常存放在代碼庫之外（類似模型訓練中的“留出集”），既能被 LLM 直觀理解，又可以靈活地進行驗證。

由于他們構建的軟件本身往往就包含 Agentic 組件，StrongDM 也隨之放棄了“測試全綠”這種布爾式成功定義，轉而采用一種更接近真實體驗的度量方式。他們引入了“滿意度（satisfaction）”這個概念，用來量化驗證結果：在所有場景中觀察到的執行軌跡里，有多大比例可能令用戶滿意？

他們把這些場景當作“隔離集”，不存放在編碼 Agent 能直接訪問的地方，用來評估系統整體行為。這個設計本身就很有意思，它在某種程度上，模擬的是傳統軟件工程中一種極其昂貴、但也極其有效的做法——由外部 QA 團隊執行的強力端到端測試。

合成場景策劃與塑造界面

從軟件工廠的整體原則來看，StrongDM 把這一切總結為一條清晰的流程：“種子 → 驗證 → 反饋回路”。系統先接收一個最小起點——幾句話、截圖，或一個已有代碼庫；然后在盡量貼近真實世界的驗證環境中跑場景，把輸出持續反饋回輸入，讓系統在閉環中自我糾錯、不斷疊加正確性；循環會一直運行，直到所有被隔離出來的場景不僅通過，而且能持續通過。token 被他們形容為這條生產線的燃料。

將“驗收”交給 spec？

在 StrongDM 的軟件工廠里，spec 并不是用來給人看的設計說明書，而是整個系統能夠啟動、糾偏和收斂的核心輸入。

在傳統開發流程中，spec 更多是一種“對齊工具”：它幫助工程師理解要做什么，但真正的實現細節、權衡和妥協，往往發生在代碼和 code review 過程中。而在 StrongDM 的設定下，當“人不寫代碼、人不看代碼”成為前提，spec 的角色被徹底前移——它不再是參考材料，而是事實上的控制面。

團隊要求系統能夠“從層層遞進的自然語言規范中生長”，并且必須能夠在“不對源代碼做語義層面檢查的情況下完成驗證”。在這種設定下，“驗收”本身也被重寫了。spec 與場景（scenario）一起，構成一個不斷運行的評測基準：模型生成的行為是否符合規范，不是靠人去讀代碼判斷，而是靠它在這些場景中跑出來的結果是否持續滿足預期。

換句話說，StrongDM 的方法把覆蓋率從“人為寫了多少測試”這一維度轉向了“規范 / 場景是否足夠多與足夠準確”＋“驗證生態能否在閉環中捕獲異常”這一維度。

基于這一理念，StrongDM 還進一步提出了他們的另一個關鍵概念：數字孿生宇宙（Digital Twin Universe, DTU）。

StrongDM 的定義是：數字孿生宇宙是一組對第三方服務的行為級克隆體。他們構建了 Okta、Jira、Slack、Google Docs、Google Drive 和 Google Sheets 的孿生系統，復刻這些服務的 API、邊界情況以及可觀察到的行為。

有了 DTU，他們就能在遠超生產環境限制的規模和速率下做驗證：既能測試那些在真實服務上危險、甚至根本不可能嘗試的失敗模式，也能每小時運行成千上萬個場景，而不必擔心觸及限流、觸發濫用檢測，或累積 API 成本。

那這些 Okta、Jira、Slack 的關鍵行為是怎么“克隆”出來的？答案是：用編碼 Agent。

有人將這套做法概括為一條可復用流水線：把某個服務的完整公開 API 文檔直接喂進 Agent harness，讓它生成一個自包含的 Go 二進制程序去模擬這些 API；然后在此基礎上再快速搭一個簡化 UI，方便把整套仿真跑通、跑順。

隨后，DTU 的創建者 Jay Taylor 在 Hacker News 上補充了一些背景，分享了一條關鍵的提示策略：

我最初有一個關鍵洞察，最終形成了一套可重復的方法，用來確保 DTU 與官方 SaaS 服務之間具有高度一致性：以最流行、公開可用的官方 SDK 客戶端庫作為兼容性目標，始終追求 100% 兼容。

當這些不受限流和配額約束的服務克隆體跑起來后，一整支“模擬測試 Agent”隊伍也就能徹底放開手腳。場景測試不再是一錘子買賣的驗收環節，而是變成了 Agent 會反復、持續執行的腳本：系統一邊搭建，一邊就被不停拉出來跑場景、做驗證。

他們的 Slack 孿生系統截圖也直觀展示了這種測試方式：一批模擬的 Okta 用戶不斷出現，并分別去申請訪問不同的模擬系統。

問題依然是：太燒錢了？

在驚艷之外，這次實驗也迅速暴露出一個無法回避的現實問題：成本。

在 Hacker News 的實操反饋中，有開發者提到，按照 StrongDM 提供的 spec，讓 Claude 構建完整應用時，TypeScript 路線的 token 消耗極高，不得不中途給賬戶充值，才能在一個晚上把流程跑完。他甚至計劃改用 Rust 或 Go 再試一次，只是為了看看是否能把成本壓下來。

這個反饋并非個例，也不是枝節問題。StrongDM 團隊在內部曾提出過一個頗具沖擊力的衡量標準：如果你今天在每位人類工程師身上花費的 token 成本還不到 1000 美元，那么你的軟件工廠還有很大的改進空間。

這句話一旦落到現實，就更像是一個商業模式的探討：你能否打造出一條足夠盈利的產品線，從而負擔得起以這種方式開發軟件所帶來的巨大成本？當任何競爭對手只需幾個小時的編碼代理工作就能克隆你的最新功能時，構建可持續的軟件業務也變得截然不同。

另外，正如 StrongDM 團隊在回顧中所說，其實這一切技術上是可行的，只是以前從經濟上來說不劃算：

“構建一個高保真 SaaS 應用的克隆在技術上一直可行，但在經濟上從未現實過。幾代工程師都可能想過，做一個完整、內存級的 CRM 副本來測試，但最終往往會在心里把這個提案按下去——‘算了，太不劃算了’。

即使對于那些不打算在 token 成本上一次性投入數千美元的團隊和個人來說，StrongDM 這種做法依然有很多值得思考的地方，尤其是在人力成本和個人投入回報這一層面。對程序員個人而言，真正的問題或許不只是“現在貴不貴”，而是：當算力成本持續下降幾乎成為共識時，你是否已經開始為新的角色和分工做技能投資——還是仍然把全部價值押在“寫代碼本身”上。

這是個很有意思的觀點，不過我想從另一個角度補充一下：如果按每個月 20 個工作日來算，那就是 2 萬 × 12 = 24 萬美元一年，差不多等于一個 FANG 新畢業生的總包（TC）。我和不少初級到中初級的軟件工程師（SDE）共事過，說實話，其中 80% 的表現并不比 Claude 好。（我也見過一些 staff 級別的工程師寫出的代碼比 AI 還差，但他們通常會用領域知識和技術負責人職責把短板補回來。） 我確實看到，AI 正在把軟件工程進一步推向一種 金字塔結構：頂層只有極少數人類，其余大量工作由 AI 承擔。

雖然從按現在的成本算，AI“還沒便宜到值得完全替代人”，但有網友認為成本下降也許能夠預期：“我在想，這會不會只是軟件工廠還處在非常早期、效率極低階段的副產品。Yegge 和 Huntley 都承認，他們在做的自治工廠實驗既昂貴又浪費。從制造業的歷史經驗來看，我反而會預期：隨著方法逐漸成熟、流程被不斷優化，成本會慢慢降下來。”

而在博客中的最后，他們給出的結論，也為這條實驗線畫上了一個頗具警示意義的注腳：“我們這些構建軟件工廠的人，必須刻意保持一種天真：主動識別并移除軟件 1.0 時代留下的習慣、慣例和限制。數字孿生宇宙（DTU）就是最好的證明——六個月前還不可想象的事情，如今已經成了日常。”

https://factory.strongdm.ai/

https://simonwillison.net/2026/Feb/7/software-factory/

https://news.ycombinator.com/item?id=46924426

會議推薦

InfoQ 2026 全年會議規劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產業落地，從技術前沿到行業應用，全面覆蓋 AI 與軟件開發核心賽道！集結全球技術先鋒，拆解真實生產案例、深挖技術與產業落地痛點，探索前沿領域、聚焦產業賦能，獲取實戰落地方案與前瞻產業洞察，高效實現技術價值轉化。把握行業變革關鍵節點，搶占 2026 智能升級發展先機！