軟體工廠 (Software Factory) 是什麼?

在 2025 年時，我們曾在 1-2 AI 程式助手 (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 團隊公開他們打造的軟體工廠，以全自動化的方式，過程中不由人類寫程式碼，甚至也不由人類審查程式碼，來完成軟體的開發實作。

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 專案中看到以下的核心執行迴圈

FUNCTION run(graph, config):
    context = new Context()
    mirror_graph_attributes(graph, context)
    checkpoint = new Checkpoint()
    completed_nodes = []
    node_outcomes = {}

    current_node = find_start_node(graph)
        -- Resolves by: (1) shape=Mdiamond, (2) id="start" or "Start"
        -- Raises error if not found

    WHILE true:
        node = graph.nodes[current_node.id]

        -- Step 1: Check for terminal node
        IF is_terminal(node):
            gate_ok, failed_gate = check_goal_gates(graph, node_outcomes)
            IF NOT gate_ok AND failed_gate exists:
                retry_target = get_retry_target(failed_gate, graph)
                IF retry_target exists:
                    current_node = graph.nodes[retry_target]
                    CONTINUE
                ELSE:
                    RETURN Outcome(
                        status=FAIL,
                        failure_reason="Goal gate unsatisfied and no retry target"
                    )
            RETURN Outcome(status=SUCCESS, notes="Pipeline completed")

        -- Step 2: Execute node handler with retry policy
        retry_policy = build_retry_policy(node, graph)
        outcome = execute_with_retry(node, context, graph, retry_policy)

        -- Step 3: Record completion
        completed_nodes.append(node.id)
        node_outcomes[node.id] = outcome

        -- Step 4: Apply context updates from outcome
        FOR EACH (key, value) IN outcome.context_updates:
            context.set(key, value)
        context.set("outcome", outcome.status)
        IF outcome.preferred_label is not empty:
            context.set("preferred_label", outcome.preferred_label)

        -- Step 5: Save checkpoint
        checkpoint = create_checkpoint(context, current_node.id, completed_nodes)
        save_checkpoint(checkpoint, logs_root)

        -- Step 6: Select next edge
        next_edge = select_edge(node, outcome, context, graph)
        IF next_edge is NONE:
            IF outcome.status == FAIL:
                RETURN outcome
            RETURN Outcome(status=SUCCESS, notes="Pipeline completed")

        -- Step 7: Handle loop_restart
        IF next_edge has loop_restart=true:
            restart_run(graph, config, start_at=next_edge.target)
            RETURN

        -- Step 8: Advance to next node
        current_node = graph.nodes[next_edge.to_node]

    RETURN Outcome(status=SUCCESS, notes="Pipeline completed")

如果以視覺化的方式來看，簡化來說會是這樣。在完成任務時，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 代理時，可以降低人為介入的需要。感興趣的讀者，歡迎加入 E+ 會員方案閱讀完整版本。

加入 E+ 會員方案

如果你覺得這篇分享有幫助，想閱讀更深入的內容，歡迎加入 E+ 會員。除了有會員專屬的深度文與影片，探討前後端開發、AI 工程、職涯發展，同時有 Discord 社群一同交流與成長。

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