Instant 軟體工廠

新增一個自動化軟體工廠，持續提升您的專案。您需要兩項要素：

GitHub 倉庫必須具備 Actions 能力並可強制分支保護。公共倉庫可使用免費方案；私有倉庫則需要個人帳號的 Pro 或組織的 Team/Enterprise。
排程器：此啟動指令碼使用Claude Code routines，可於 Claude Pro、Max、Team 與 Enterprise 計畫中使用。

此倉庫包含使用 Claude Code 透過雲端例程設定的提示。BOOTSTRAP.md 定義了代理的職責與操作限制。設定代理會選擇符合您專案的流程、模型與排程。

開始使用

在您想要讓工廠運作的倉庫中開啟 Claude Code，並貼上：

Set up an Instant Software Factory on this repo: clone https://github.com/mikolalysenko/instant-factory into a temp folder and follow its BOOTSTRAP.md

若在隔離環境中進行本機設定會話，您可選擇啟動 claude --dangerously-skip-permissions 以跳過許可權提示。此旗標並非此啟動指令碼所需，亦不會設定雲端例程的許可權。參見 Claude 的許可權指引.

啟動程式會先檢查您的倉庫、CI、分支保護、歷史中的憑證以及 GitHub 存取許可權，然後再提出問題。若需要，它會安裝 gh，若本機驗證缺失則會請您執行 ! gh auth login；雲端存取則另行檢查。若缺少 CI，則會使用專案實際驗證指令建立最小工作流程。已存在的失敗會被記錄，現有工作與安全措施亦會被保留。

它會詢問缺失的預算或吞吐量目標、審批人、常規身份，以及 QA 應覆蓋的產品領域。它還會解決任何缺失的分支保護並說明審批流程。常規作業使用已連結的 GitHub 身份，因此其 PR 需要獨立的人類審批人；角色標記或手動合併不能替代該審批。

在未監督工作啟動前，預設分支必須強制執行必要檢查、獨立審查，以及對最新提交的人類審批。設定會產生一個已測試的 PR，等待人類審批，並將說明保留在您的倉庫中。受控執行會驗證 GitHub 存取權、審查目前提交、合併條件，以及管理者的排程與關機控制。生產排程在設定 PR 合併前保持停用，常規作業使用已合併的說明，並由您授權恢復。設定報告記錄證據、剩餘缺口、關機延遲以及任何剩餘步驟。

代理使用與 GitHub Actions 時間的預算。 先以適度吞吐量開始，檢查管理者的成本與結果摘要，並僅在 CI 與人類審查能跟上時才提升活動量。

為什麼軟體工廠

Vibe coding 擅長快速實現功能。給一個代理明確目標，一個下午就能得到可運作的原型。

但原型並非產品。程式碼的前 90% 需要前 90% 的時間，而最後 10% 則佔剩餘 90%。從「它在我的機器上能跑」到生產品質，意味著大量後續工作：邊緣案例、錯誤回報、效能回歸、相容性、測試、CI、發布、使用者使用後提出的功能需求，以及清理原型為達成目標所採取的捷徑。

這項工作沒有一個終點。它包含數百個小任務，分佈在許多關注點上，每次程式碼變更時都會出現新的任務。你可以逐個任務提示代理，但這樣你就需要每次啟動新會話、等待並檢查結果，讓你的注意力成為瓶頸。

軟體工廠會不斷回到那些關注點，而不需要為每一次變更都提供新的提示。你設定目標與限制；代理會在背景中調查、實作並審查工作。在此設定中，人類仍需批准最終成果。

工作原理

每個代理都是一個具有固定目標的排程會話。每一次執行都會讀取倉庫的目前狀態，挑選有用的工作，執行、記錄結果後結束。若任務需要，它可以使用子代理或更複雜的工作流程。若執行時發現沒有值得做的事，也可直接結束而不產生工作。

GitHub 儲存共享狀態。Issue 傳遞證據與建議變更，PR 傳遞實作與審查，討論或其他倉庫紀錄儲存進度與決策。所有權與交接亦可在此顯示。後續執行可直接取用已記錄的工作，而不依賴前一次會話的記憶。

啟動程式建立八個角色，若不同產品區域需要分別關注，則再加入額外的 QA 代理：

代理	固定目標
QA	與你一起測試所選產品區域與使用者工作流程，並開啟可重現、去重的錯誤 Issue。
Performance	以基準測試速度、資源使用與 CI 時間；並以證據開啟 Issue。
CI	修復失敗與偶發錯誤，並保持檢查可靠、快速且成本低廉，同時不降低品質。
Architecture	整合重複的業務邏輯，移除不必要的抽象與層級，簡化結構並保持行為不變。減少元件數量。
Implementation	修復問題並開啟已測試的 PR。
PR review	獨立審查最新提交，且不編輯程式碼。
Merge	僅在完成必要檢查、獨立審查與人類批准最新提交後進行合併。
Manager	優先排序並指派工作；追蹤舊 PR、被阻塞的 Issue 與失敗修復至完成。追蹤每位代理的成本與成果，於預算與容量內調整模型與排程，並報告每次合併 PR 的成本。

這些角色涵蓋三類工作：調查機會、實作與整合變更，以及維護工廠本身。它們使用相同的倉庫進行協調。經理確保工作持續推進並分配容量；每個代理在共通規則內決定如何執行其目標。

經理必須使用 create_trigger 建立其管理的流程，然後透過本地 RemoteTrigger 更新設定每個流程的倉庫、模型與工具，依照 BOOTSTRAP.md 的說明。此建立路徑很重要，因為經理無法更改以其他方式建立的流程。每個角色僅取得所需的工具與聯結器。啟動程式的平臺筆記會記錄測試結果，以便對照已安裝版本與實際執行。

為什麼不只用一個優秀的代理？

一個能幹的代理能規劃、拆解任務，並完成明確目標。規格與長時間會話能很好處理單一目標。

軟體專案一次可能有多專案標。新增功能可能會消耗效能預算。修正 bug 可能會加入測試，導致 CI 變慢。清理工作可能會簡化一個子系統，同時使另一個子系統變複雜。隨著程式碼變更，這些權衡會不斷改變。

持續的目標使代理回到那些權衡點。效能在功能合併時持續被測量。架構持續減少重複與不必要的元件。CI 讓回饋迴路對其他人足夠快速。QA 持續以使用者的方式測試產品。

這些目標也相互強化。程式碼越簡潔，修正越容易實作與審查；更快的 CI 讓每個代理能更早檢查自己的工作。當目標衝突時，代理會記錄證據，經理則根據專案目標與可用容量進行優先排序。必要的檢查、獨立審查與人工核准仍然是最終變更的治理方式。

你可以透過管理本機會話來近似這個流程，但那樣就必須不斷啟動它們並保持機器可用。排程的例程可讓工作在互動式會話之間持續進行，且進度會記錄在版本庫中。

排程與會話結合

我仍然進行互動式工作。對於新功能或重大變更，我會在本機分支上啟動一個會話，工廠則繼續處理 bug、效能、架構與 CI。

那個功能會經過與代理 PR 相同的檢查、獨立審查與核准流程。合併後，持續目標亦涵蓋它。人工指導提供新目標，定期代理則在專案演變時繼續處理其後果。

缺點與限制

我的設定中主要瓶頸是 CI 容量與 GitHub 的可靠性。頻繁執行代理僅在驗證與整合能吸收其輸出時有幫助；否則會產生大量問題與 PR 的佇列。調查者可能超前於實作者，實作者又可能超前於審查者，多個修正可能在同一程式碼中衝突。

經理需要根據這些限制調整活動。這意味著追蹤被阻塞的工作，當佇列擴大時減少排程，並在預算與可用 CI、API、審查容量內選擇模型與排程。CI 代理透過修復不穩定測試並減少浪費工作來提升吞吐量，同時保留確保變更可信度的檢查。

代理使用量與行動分鐘數皆被計算。每合併 PR 的成本是衡量運營的有用指標，與變更內容、失敗修正與後續工作並列。若實際使用資料不可得，經理會標註估算值及其假設，並報告測量缺口。單靠高 PR 數量無法說明專案是否在進步。

這也讓維護者保留真正的工作：選擇優先順序、提供預算、核准變更，以及解決需要產品判斷的決策。排程代理使重複工作更易維持，但並未消除這些責任。

安全與運營控制

工廠擁有更改軟體的許可權，因此其存取與停止規則必須明確：

使用專用身份與有限工具。驗證連線至例程的 GitHub 身份，限定其許可權，並移除未使用的聯結器。將人工核准者的憑證、管理存取權與無關機密從執行代理中隔離。代理角色標記有助於追蹤工作…
保護預設分支，避免無人值守的工作。要求進行檢查、獨立審查以及對最新提交的人為批准。作者無法審查自己的更改。每一次新的提交都需要新的審查與批准。將規則套用於常規身份，且不允許繞過存取，並防止代理人編輯這些規則。
控制外部輸入。限制誰可以將工作送入工廠；使用私有工作倉庫可以更方便。Issue、PR、討論、下載的程式碼及其他檢索內容不能改變代理人的指示或許可權。
限制依賴與程式碼執行。審查或掃描第三方程式碼與依賴，並使用隔離的執行環境與適當的網路限制。
每次寫入前先檢查共享停止控制。它一開始是停止的。如果停止或無法讀取，代理人會停止正常工作；只有用於停用自動化的寫入才可繼續。它們只有在獲得授權後才會恢復。
在啟用排程前證明控制有效。設定必須測試存取、審查與合併需求、排程管理以及實際執行中的關機，並報告缺口與關機延遲。未經證實的自動化將保持停用。

若要暫停工廠，請使用在設定時檔案化的共享停止控制。確認待處理的自動化已停用，並考慮報告的關機延遲，包括已在執行的工作階段。如果管理員無法執行，請使用檔案化的直接常規控制。無法讀取停止控制的代理人必須停止正常工作。僅在您確認停止原因並取得明確授權後才能恢復。

嘗試

在您想持續改進的專案中執行上方提示。閱讀 BOOTSTRAP.md，設定預算與吞吐量目標，並確定誰能批准變更。先以已測試的 PR 與設定報告開始，讓您在排程執行前檢視工作與控制。

接著觀察管理者的摘要：有用變更、停滯工作、代理人成本以及每個合併 PR 的成本。隨著瞭解瓶頸所在，調整目標與容量。分享成功與失敗的經驗。