小編精選 - 技術文章翻譯 · 11月05日

AI 驅動開發的下一階段：軟體工廠

前言

最近，我讀了 Claude Code 開發者 Felix Rieseberg 的文章〈給與 AI 模型共事的人類的「志存高遠」教學〉。受到他的想法啟發，所以想稍微引用並介紹一下。

文章提到，Claude 最近甚至還幫忙發現了新的行星。
但即便如此，我們大多數人仍然還停留在像「日本最高的山是哪一座？」這種很單純的用法。

文章指出，原因其實在於我們使用者本身。
「把自己的極限誤認為是 LLM 的極限，對自己不擅長的事就不去碰」 ！:helmet_with_cross:

也因此，在開始做任何事情時，不要先武斷地認為做不到，而是試著和 LLM 一起挑戰看看，我覺得這樣會比較好。

把文章的訊息濃縮成一句話，就是：「對軟體開發要有野心」。

於是我決定，不再自己一個個做應用程式，
而是轉向去做「能夠產生應用程式的機制」。
這篇文章會介紹我目前正在打造的軟體工廠。

什麼是軟體工廠

簡單來說，就是把想法變成工單丟進去，系統就會幫你推進應用程式開發的機制。

這不是什麼新的概念！:point_up_tone1:
幾年前就已經有像 Devin 這樣的 SaaS，現在也能在 Codex cloud、Claude Code 的雲端工作階段（舊稱 Web）、GitHub Copilot coding agent 中做類似的事情。也有很多公司是自己實作後在內部部署使用。

不過因為各家都是各自實作，所以術語還沒有統一。
因此，正在嘗試建立共通語言的人是 Matt Pocock。
Matt 是以「Total TypeScript」聞名的 TypeScript 教育者，最近也以「AI Hero」教人如何運用 AI 開發。他同時也是超過 30 萬星的代理技能集「mattpocock/skills」作者。

在 2026 年 10 月 21 日，他把用來設計軟體工廠的術語集整理成技能，並以下一個 PR 的形式提出（以下稱為「術語集」）。

術語集把軟體工廠定義為：

以工單、PR 與排程作為輸入，產出已合併程式碼的代理系統。它運作在使用者選定的遠端基礎架構上。

只聽這樣，可能會覺得「那直接用 Claude Code 不就好了嗎？」
其實工廠裡面也可以用 Claude Code。差別在於運作方式！:point_up_tone1:

在術語集的定義中，一次執行會在不等待人工介入的情況下結束。
當人更新工單或 PR 時，就會觸發下一次執行。執行用的機器是一次性的，上一次執行的記憶只會留在工單追蹤系統、Git 主機、協調器裡。
像 Codex cloud 或 Claude Code 的雲端工作階段這類產品，在術語集裡也只是「執行器」的選項之一，前提是你要自己挑選並組合各個零件。

人主要負責的工作，就是寫工單和審查。
不需要在自己的電腦前一直對話，工單會在你自己選定的遠端基礎架構上被實作出來。

忙しさと自動化の対比.png

這個 PR 已在 10 月 31 日合併，成為 software-factory 技能，但它還放在 in-progress 資料夾裡，代表仍屬於未完成狀態。接下來先整理術語，再看看自己打造軟體工廠時應該注意什麼！:relaxed:

軟體工廠的構成零件

術語集把構成零件分成兩組：「任務與執行」以及「服務」。

「任務與執行」 是用來描述工廠裡有哪些東西、它們怎麼運作的群組。
「服務」 則是工廠連接的外部零件群組，會為每個部分選擇產品並套用。

各零件的詳細定義如下。

任務與執行

用語含意任務工廠要處理的工作種類。定義一次，可反覆執行。像是審查、調查、實作、棘輪（逐步提高檢查標準的作業）等。對象可以是工單、PR 或整個程式碼庫觸發啟動執行的契機。工單追蹤器或 Git 主機上的變更、協調器的時鐘、另一個執行執行單一任務在一台執行器上跑一次的結果。內部視為黑箱，不等待人工介入就結束執行執行時所使用的一次性機器。執行結束後不會留下任何東西### 服務

用語角色工單追蹤器工單存放處，也是人與工廠的接點。人會寫工單請求工作，並透過留言與代理互動。當人變更工單時，會觸發執行工單來源工廠外部用來產生工單的東西。像是回饋按鈕、監控、錯誤追蹤器、收件匣等Git 主機分支、PR、審查的存放處協調器接收觸發條件，在執行器上啟動執行，並記錄各次執行是待命中、執行中還是已結束可觀測性基礎設施執行器送出日誌、追蹤與狀態的地方，供人查看執行內容。很多時候只靠執行器或協調器的產品就夠了，不一定需要

零件之間的連接

當人把工單寫到工單追蹤器裡，它就會成為觸發條件，協調器會在執行器上執行實作任務。

執行完成後會在 Git 主機上建立草稿 PR，該 PR 又會觸發自動審查任務的執行。若審查發現問題，就會再啟動修正任務的執行。

執行的串接方式有兩種。
一種是由協調器直接啟動下一次執行；另一種是執行去改寫工單或 PR，再以那些變更作為觸發條件。

組合範例

術語集中列出了 Matt 舉出的三種組合。

欄位全部 GitHub Linear 用來管理工單自製追蹤器工單追蹤器 GitHub Issues Linear 自製應用程式工單來源回饋按鈕回饋按鈕、監控回饋按鈕、監控 Git 主機 GitHub GitHub GitHub 協調器 GitHub Actions 自有伺服器與資料庫自製應用程式執行器 Actions 的執行器 Actions、E2B、Daytona、VPS 其一自製應用程式，或沙箱可觀測性基礎設施無（Actions 的執行頁面就夠了）LLM 追蹤基礎設施自製應用程式全都 GitHub 的配置中，GitHub Actions 同時扮演了協調器、執行器與可觀測性基礎設施三種角色。

服務買現成，任務自己做

Matt 的方針是「服務買現成，任務自己做」。
因為服務是通用零件，而工廠各自的設計則體現在任務上。

工單追蹤器也建議直接使用現成產品。
原因是它們穩定、大家也比較熟悉，而且容易邀請外部使用者加入。

自製工廠介紹

我根據術語集實際打造了一個工廠，這裡來介紹一下。
只要在聊天中提出困擾，經過設計確認之後，就會收到一個可以直接操作的 mock 應用程式。

構成要素

零件自製工廠中的分工工單追蹤器 GitHub Issues。標籤 foundry 的工單會成為自動化對象工單來源入口網站的聊天。由 Bedrock 上的 Claude 負責訪談。也可以透過 Amazon Transcribe 用語音諮詢Git 主機GitHub協調器GitHub Actions（agent-design、agent-build、ci、preview 等）執行器運行在 Actions 的一次性 Ubuntu 上的 Claude Code（claude-code-action，Bedrock 東京區域）可觀測性基礎設施入口網站只負責顯示進度這是把前面「全部 GitHub」的配置，再加上聊天式工單來源後的版本。

狀態只保留在 GitHub 裡，所以沒有資料庫；入口網站上的進度顯示，也都是每次根據 Issue、PR、檢查與工作流程執行的狀態即時計算出來的。

儲存庫是一個單一 monorepo。apps/ 放入口網站和生成出來的應用程式，packages/ 放可在各應用程式之間共用的元件。工作流程放在 .github/workflows/，要給 Claude Code 的技能則放在 .claude/skills/。

基礎設施建在 AWS 上，入口網站和應用程式透過 S3 與 CloudFront 發佈，入口網站的 API 則是 Lambda。Actions 裡不放長期存取金鑰，而是透過 GitHub OIDC 來承擔角色，Bedrock 的 Claude 也用同一個角色呼叫。

任務流程

在使用者提出需求時，基本上會全自動進行，但在設計確認與公開確認這兩個步驟上，會有人介入判斷。

在入口網站的聊天中，Claude 會先進行訪談。按下「用這個內容提出需求」後，GitHub App 會建立一個帶有標籤 foundry 的 Issue。
以該標籤作為觸發條件，agent-design 會啟動，Claude Code 會製作規格書與各畫面的 HTML，並建立設計 PR。PR 會自動留言預覽網址。
人員確認預覽後，按下「用這個設計繼續」就會合併設計 PR（人工判斷 1）。如果想修改，也可以先在 PR 留言，再重新執行 agent-design，即可重做。
以設計 PR 的合併作為觸發條件，agent-build 會啟動，根據已核准的設計製作 Next.js mock，並建立實作 PR。
CI 通過後，就可以按下「公開」。按下後實作 PR 會被合併（人工判斷 2），Issue 會被關閉，應用程式也會正式公開。預覽與工作分支都會自動刪除。