ExplainThis 全端開發雙週報 #87 軟體工廠 (Software Factory) 是什麼? 有什麼限制?

在 2025 年時，我們曾在 1-2AI 程式助手 (Coding Assistant)與 AI 代理 (Coding Agent) 有什麼不同?談過 AI 從 2021 年的自動補全到 2025 年的 AI 代理發展簡史。而進到了 2026 年，AI 代理發展得更加成熟，我們進而在 [線上課程] AI Coding 201 — 從實戰到最佳實踐談了關於使用 AI 代理的最佳實踐。

進到 2026 的下半年，AI 代理仍是社群討論的主軸；而這個主軸發展出駕馭工程 (Harness Engineering)、迴圈工程 (Loop Engineering)，以及軟體工廠 (Software Factory) 這些不同的新名詞。

在這期雙週報，我們會來一探軟體工廠的相關概念，討論為什麼這個不算新的名詞會在今年再次被提出、進到 AI 時代後的軟體工廠與過去的軟體工廠有什麼區別，同時也會談目前在使用建置軟體工廠時，會遇到哪些限制，以及該如何突破這些限制。

什麼是軟體工廠?

軟體工廠其實不是一個新的概念，早在 1968 年就曾被提出。早期的軟體工廠概念，著重於建立標準化的開發環境、工具、流程與可重用元件，希望提高軟體生產的規模與效率。

然而，過去軟體工廠遇到的根本限制在於，透過傳統軟體的方法，當遇到有變動的部分，模組與框架就會不足應付，仍依賴人類工程師處理需求差異、設計判斷與例外情況，因此能做到的是「工業化軟體生產」，而不是今天所談的自主軟體生成。

不過進到 AI 時代後，AI 代理不再只是按照固定模板產生程式碼，而是能夠讀懂需求、探索既有程式碼庫，並根據不同的變化來生成對應的程式碼。只要由人類輸入目標、規格、限制與驗收情境，AI 代理便有機會在較少人為介入的情況下持續實作、測試與修正。如果在寫的過程中有出錯，AI 代理也能自行完成除錯，直到成果通過驗證為止。

在 2026 年，StrongDM 團隊公開他們打造的軟體工廠 (詳見 https://factory.strongdm.ai/)，以全自動化的方式，過程中不由人類寫程式碼，甚至也不由人類審查程式碼，來完成軟體的開發實作。

StrongDM 團隊把這種方式稱為「非互動式開發 Non-interactive Development」，因為對比起人類工程師需要持續跟 AI 互動、要求 AI 調整，採用軟體工廠的做法，則是讓 AI 從頭到尾自行完成，過程中沒有與人類互動，直到完成為止。

在社群中，有人進一步用「關燈工廠 Dark Factory」來形容這種流程。關燈工廠的概念放在工業界，是指一間工廠中完全沒有人類，由機器全自動化操作；因為沒有人類，所以也不需要開燈，因此被稱為關燈工廠。

規模化的迴圈

在了解了軟體工廠的概念，相信讀者們會問「要如何做到自動化的軟體工廠?」。

這就不能不提在現行社群中討論度最高的迴圈工程 (loop engineering)。所謂的迴圈工程，是指為 AI 代理設計迴圈。目前業界有許多團隊採行這種開發方式，其中最著名的是 Claude Code 團隊。Claude Code 的負責人 Boris Cherny 曾在 WorkOS 舉辦的 Acquired Unplugged 訪談中提到「我已經不再直接下提示詞給 Claude，我現在做的事是寫迴圈。 I don’t prompt Claude anymore… My job is to write loops.」。

具體來說，可以把 AI 代理的運作當成一個 while 迴圈，直到某個終止條件達成之前，這個迴圈會一直跑下去。如果最終的目標是完成功能，AI 代理在完成之前，就會不間斷地持續運行。

而所謂的寫迴圈，則代表設計一個迴圈中的條件。舉例來說，「迴圈的終止條件是完成功能」這其實是個很粗略的描述。「完成功能」要如何被定義，就必須仰賴迴圈的設計者。舉例來說，要通過所有新測試、既有回歸測試也都必須通過、程式碼風格必須跟既有程式碼庫一致，這些都可以被視為「完成」的要件。如果這些要件設計得越明確且精細，最終迴圈完成後的成果也會越貼近開發者的預期。

回到 StrongDM 的方法來談，可以在他們開源的 attractor 專案中看到核心執行迴圈。如果以視覺化的方式來看，簡化來說會是這樣。在完成任務時，AI 代理會檢查是否已達終點，如果沒有的話，會確認有沒有需要重試的，如果有就繼續。在執行任務的過程，如果有發生任何錯誤 (例如測試沒通過)，就會把結果記錄下來，透過下一個迴圈來修正：

由於近年的前沿模型普遍強化了工具使用與長時間代理工作的能力，所以當在系統提示詞中設置相關的流程，AI 代理會依照這樣的迴圈來完成任務。先前 Cursor 的團隊在《Expanding our long-running agents research preview》一文談到，現代的前沿模型可以持續執行任務達到超過 30 小時。

軟體工廠真的如想像中美好嗎?

看完上面的描述，相信許多讀者可能會有所質疑，畢竟多數人在工作上使用 AI 代理，都仍需要適時介入，避免 AI 代理越走越歪。在實務上，關燈工廠真的可行嗎? 在社群中也有人質疑，如果採用關燈工廠的方式，前期做出可用的產品，但內部程式碼混亂，很可能導致長期的維護成本大幅提升。

在實務上要用這種形式，必然會遇到一些問題。舉例來說，「假如人類完全不經手任何東西，要怎麼確保程式碼真的能運作？」有人可能會說透過軟體測試來達成，這時下個問題就會是「如果實作與測試都是由 AI 代理撰寫，要如何證明自己產出的軟體真的可以如期運作，而不是 AI 寫了一段滿足測試但與預期不符的實作內容？」。

在社群中知名的工程師，同時也是 HumanLayer 的創辦人 Dex，就曾發長文《Why Software Factories Fail》談他們團隊實際嘗試後，即使到了今天，關燈工廠仍是不可行的概念；原因在於當遇到某個代理無法解決的問題時，團隊回過頭看程式碼，發現是一團難以理解的混亂，第一次遇到這類問題時，他花了將近兩週梳理 AI 產生的程式碼；到了第三次左右，團隊甚至認為從頭重整更容易，最後再花兩週手動整理程式碼結構。

在他的質疑中提到，當時仍找不到足夠完整、能評估長期成效的 StrongDM 後續資料，這讓人懷疑 StrongDM 的關燈工廠，從長期維護的角度來看是否真的可行。

除了可行性外，社群中也有人質疑軟體工廠的成本與效益比；在 StrongDM 的發表文中提到「假如今天平均每位人類工程師還沒有花掉至少 1,000 美元的 tokens 費用，那麼你的軟體工廠仍有改善空間」。假如每位人類工程師每天花 1,000 美元，以每個月 22 個工作天來說，一年的成本超過 25 萬美元；假如這放到亞洲公司的脈絡中，以台灣來說，幾乎是四到五名資深工程師的年薪。如此高昂的花費，讓許多人認為採用軟體工廠的形式，未必是效益比較高的。

儘管有這些不同的批評、儘管我們也不認為真的能做到 100% 的全關燈自動化，但我們認為往這個目標邁進仍是有意義的。因此，在下個段落，我們會討論可以透過哪些方法，讓實務上使用 AI 代理時，可以降低人為介入的需要。

閱讀更多

如前面段落提到，社群中對於軟體工廠最主要的質疑，在於長期的可維護性與成本。先前我們在 [線上課程] AI Coding 201 — 從實戰到最佳實踐 有談過一些具體的方法，來提高使用 AI 代理時的可維護性，以及降低成本。

在 E+ 會員方案的主題文中，我們會多談一些社群近期分享，但我們先前沒有收錄的觀點，讓大家在使用 AI 代理時，能夠更接近全自動化的理想。歡迎感興趣的讀者加入閱讀 (E+ 連結看這邊)。

備註：許多 E+ 會員透過所任職公司的教育訓練補助 (E+ 會開立有統編的發票)，不用花自己的錢，也能每週透過深度主題文與社群交流，用穩扎穩打的方式拓展技術視野、在職涯持續成長。

本期推薦

• Cursor 團隊在《Git at any scale》中，從 Git 為什麼難以大規模託管講起，回顧 GitHub 過去的架構演進，再介紹 Cursor 為新一代 Git 打造的 Origin (連結)。如果你好奇 GitHub 這類服務背後怎麼處理大量儲存庫、維持資料一致性，這篇有很完整的脈絡
• 《How good engineers write bad code at big companies》一文解析，為什麼科技大廠明明有很多優秀工程師，程式碼裡仍然常出現一些看起來很糟的做法 (連結)，並點出問題往往不是出在工程師能力，而是整體系統與機制
• 《Potential Consequences of Using Postgres as a Job Queue》一文拆解把 PostgreSQL 當工作佇列時，高併發下可能遇到的鎖競爭、資料清理與效能問題 (連結)
• 《The MVC Mistake》一文挑戰一個很常見的 MVC 架構直覺，並談到這種做法不一定真的能做到關注點分離 (連結)。如果你正在思考大型專案該怎麼切模組，這篇提供很不一樣的思考角度
• Cloudflare 在《How we saved 100 terabytes of memory by optimizing 1.1.1.1’s DNS cache》中，分享他們如何重新整理 1.1.1.1 DNS 快取的資料結構，一口氣省下約 100 TB 記憶體 (連結)
• 《WebSockets vs. SSE should be about ordering and correctness》一文談到，WebSockets 和 SSE 的選擇不該只比較效能或實作難度，更重要的是事件順序與資料正確性 (連結)。文章用即時更新的例子示範 SSE 搭配 Fetch 時，不同資料流如何互相競速、讓畫面停在錯誤狀態
• Gábor Koós 在《Your Modules Are Lying to You》中，從幾段看似一模一樣的 JavaScript 開始，拆解 ESM 與 CommonJS 在匯入值、共享狀態、模組執行與循環依賴上的實際差異 (連結)。很多 import、require 的怪問題，其實不是工具壞掉，而是兩套模組系統本來就有不同規則