軟體工廠在過去幾週蔚為風潮，所以我也打造了一個。
以下是我學到的東西、它的運作方式，以及你如何用一個下午就建構一個。
我的目標
它必須非常簡單，能夠直接運作，不需要太多監管。理想情況下，它可以完全依賴我既有的 Claude 訂閱來運行。
聽起來很天真，但基本上，除非它能輕鬆整合到我現有的工作流程中，否則它不會是一個能持久使用的東西。我不想為了使用這個新系統而改變我所有的既有習慣。根據經驗，如果發生這種情況，它長期下來就無法順利運作，最終會被遺忘。
所以我沒有將它當作一個大工程來處理，而是拆分成兩個明確的階段：
- 預先分類（Pre-triage）——找出「待辦」事項
- 執行（Implementation）——實際「完成」事項
核心是 Linear，它是工作事項的真相來源。
每個軟體工廠都需要有這樣一個集中式的工作事項儲存庫，無論是 GitHub issues、Linear 或其他工具。它應該是你已經在使用的東西，以便任何系統都能輕鬆擴展，讓 Agent 或人類可以後續接手完成工作。
透過系統健康檢查迴圈自動產生議題的 Linear
這個管線有刻意定義的縫隙，讓建構軟體工廠的過程真正易於管理：
- 建立工作（使用 MCP 的迴圈）
- 儲存工作（Linear）
- 完成工作（SDLC Agent）
透過拆分，你不需要同時建構預先分類和執行兩端（我實際上建議不要這樣做，以避免過度設計）。Linear 讓「待辦」事項與我們目前正在「進行」的事項之間的介面定義清晰且易於擴展。
預先分類步驟
在上圖中，工作從左到右進行。左側是建立工作的地方，包含任意數量的系統（人類、Agent 或 API），這些系統會新增待辦事項。在此預先分類步驟中產生的所有輸出都會放入我們的 Linear。
一些在 Claude 雲端環境中運行的迴圈
在此步驟中，我們有三個主要迴圈：
- 系統健康檢查迴圈（即錯誤尋找器）——此迴圈每天凌晨 5 點運行，連接到幾個 MCP 伺服器：Posthog 用於錯誤追蹤；Vercel 用於系統診斷；Linear 用於建立議題。
- UX 改善與客戶回饋迴圈——此迴圈每週一早上 9 點運行，掃描每一則新回饋、來自 Intercom/Fin 的每則客戶支援對話，以及所有 Posthog 工作階段重播。工作階段重播是金礦。你可以看到憤怒點擊發生的位置，或者使用者感到困惑與掙扎的地方。
- 流失分析迴圈——此迴圈每天上午 6 點運行，調查在過去 24 小時內點擊取消的每位客戶。它從 Stripe 拉取付款和使用者資料（包括他們的電子郵件/位置），然後查看該客戶在 Posthog 中的工作階段重播，了解他們在取消前做了什麼。我們從 Supabase 拉取他們的使用量，以判斷是否是錯誤的 ICP、從未體驗過「哇」的時刻，或者遇到錯誤。報告會發送到 Slack，如果這些問題與客戶流失相關，Agent 會建立（或評論）議題以提高優先順序。
為了實際持續運行這些 Agent，我保持簡單，使用了 Claude Code Cloud Routines。
不需要過度設計，像是 Hetzner VPS、灌滿咖啡因的 Mac Mini 等等。這是我目前找到最簡單的方式，可以善用你既有的 Claude Code 訂閱，建立始終在線的 Agent，並能透過排程或 webhook 事件觸發。對於那些說「但供應商鎖定怎麼辦！！」的人——這真的只是一些文字。你可以隨意將提示複製到任何地方，我只是想要一個最簡單、最便宜且能可靠運作的設定。
另一個使用 Claude Code Cloud Routines 的原因是，Anthropic 的雲端環境與本機運行的 Claude 具有高度一致性。
Cloud Claude Routines
顯然，它們沒有你的環境變數（如果需要，可以新增到雲端環境設定中），但如果你透過桌面應用程式的連接器設定 MCP 連線，你的本機 Claude cli 和遠端 Claude 都可以使用它們，這點與 Codex 不同。這對我來說是殺手級功能，也是讓這些預先分類 Agent 迴圈運作得這麼好的原因。它也讓同時運行多個會話變得容易，不用擔心筆電的記憶體。
如果你只實作這個預先分類步驟，即使不建立下一個完成工作的步驟，你仍然能獲得很大的效益。
從小處著手，從一個迴圈開始，試試看，改進它，然後再加入更多。想辦法找出你今天可以建立哪些常規，將新的高品質工作放入你現有的議題追蹤器中，然後繼續你目前每天在做的執行工作。
執行步驟
第二步最基礎的版本是給你的 Agent 一個議題 ID，然後叫它去完成。這已經是大多數人與 Agent 協作時的做法，但如果你是正在讀這篇文章的人，這可能不是你要的，因為你現在成了迴圈中的瓶頸——直接在會話中啟動 Agent。
相反地，我建立了一種直接從 Linear 觸發遠端 Claude Code 會話的方式。
從 Linear 議題到 Claude
它的運作方式如下：
- 首先，決定你要如何觸發新的 Claude 會話。我們的做法是，在 Linear 議題上加入一個 'auto' 標籤，用來啟動這個新任務。
- 然後，Linear 會發送一個 webhook 事件到我們的內部 webhook API 服務（一個新建立的內部 Hono 應用程式），該服務會解析事件，然後將正確的資訊轉發給 Claude Routine。
- 最後，這個輕量級的 API 服務會向 Anthropic 發送 POST 請求，用初始提示觸發 Claude routine。
使用 'auto' 標籤作為觸發器，讓我們可以控制新 Claude 會話的自動執行。
預設情況下，我們不會在預先分類步驟中包含這些 'auto' 標籤，而是需要人類來加入觸發 Agent 開始工作的標籤（維持人機協作）。這就是為什麼我們稱步驟 1 為預先分類步驟，因為仍然需要某種方式來確定實際要處理的工作，無論是透過人類參與，還是某個 Agent 迴圈監控新議題的加入並啟動新的執行會話。
然而，因為加入標籤也可以由 Agent 輕鬆完成，所以我們可以讓預先分類迴圈預設建立帶有 'auto' 標籤的新議題，從而啟動新的 Claude 會話。使用標籤成為一種非常靈活的方式，可以讓 Agent 或我們人類自動開始新的執行工作。
一個輕量級路由服務，用來啟動 Claude 會話
因為 Linear 支援 webhooks，所以整個「加入標籤時推送」的機制可以運作。唯一的缺點是我們需要一個公開的 API 來接收這些 webhook，並格式化事件和 payload 資料來觸發 Claude Code。這個新服務還會加入正確的認證標頭，這就是為什麼你不能讓 Linear 直接觸發 routine。
或者，你可以設定一個定時啟動的 routine，每隔一段時間檢查並嘗試實作任何帶有 auto 標籤且尚未進行中的新議題。
對於實際的 routine 提示，我建議建立一個可重複使用的技能，涵蓋整個 SDLC，命名為類似 /implement 或 /do 的名稱，讓你只需說「/do ISSUE-NNN」即可，它會記錄如何正確執行獲取議題背景、實作工作、在瀏覽器中驗證、建立 PR 以及追蹤評論等步驟。
然後由 Linear 事件觸發的 Claude routine 提示可以非常簡單。以下是我的版本：
取得提供的議題，並使用 /do 技能來實作請求的變更並建立拉取請求。只獲取確切提供的議題。如果已完成或正在進行，則停止。
議題參考不會出現在此訊息中——它會以單獨的後續訊息形式出現，包在 \
<routine-fire-payload>\標籤中，並在同一會話中緊接在此訊息之後發送。在收到該訊息之前，不要判斷是否提供了議題。只有在檢查過 \<routine-fire-payload>\訊息並確認所參考的議題確實不存在之後，才能斷定議題不存在或沒有提供任何議題。當你開始工作時，對議題發表評論，將其設為「進行中」，並在進展過程中更新任何有意義的內容。始終在 Linear 議題評論前加上 [Claude]。
所以到目前為止，你已經有透過 API 觸發的平行 Claude Remotion 會話，負責實作議題、開啟 PR（希望也能透過 Playwright 或 Agent Browser 驗證工作）。
這基本上是一個完整的軟體工廠，完全可觀察、在你睡覺時運行，而且完全依賴你的 Claude Code 訂閱運作。
