軟體工廠是一個圍繞軟體工作的可重複循環。如果你正在建立一個軟體工廠，那麼「夠好到可以出貨的程式碼」仍然需要人類的品味與所有權。我們將討論這個議題，包含你是否真的「需要」一個工廠。
如果是的話：
- 你可能需要在前期就讓人工介入，來決定產品意圖、系統設計（如果你在意的話）以及你的品質標準。
- 要進行程式碼審查（燈亮著的工廠），但要有意識地將審查資源集中在最需要的地方。我發現你需要留意自動化回壓機制何時會失效，或者何時需要做出可維護性上的取捨。
- 目標是讓品質檢查盡可能早且持續地發生。並非所有檢查都必須如此，但這包括型別系統、自動化測試、突變測試、安全掃描器以及針對架構規則的 linting。
- 檢查的數量不等於品質。你可能需要實驗，找出哪些檢查能給你最佳的訊噪比。準備好有意識地收緊或放寬你的限制條件。
你希望建立你的工廠，讓人類品味的某些面向能被編碼到環境中，讓 Agent 提供其工作正確的證據，並且讓一個人仍然「擁有」最終出貨到生產環境的內容。
你真的需要一個軟體工廠嗎？
根據我的經驗，使用你現成的程式碼開發工具就能達到驚人的成果！ 也就是說，使用 Claude Code 或 Codex、多個工作階段、包含驗證機制的良好規格書以及限制條件。你甚至可以將一批 GitHub Issue 丟給它們，並附上實作標準和人工介入的條件。Claude Code 的 routines 以及 Copilot/Codex 的雲端 Agent 已經能提供你排程或事件驅動的循環，而無需自訂基礎設施。
當你需要可重複且一致的執行、在 Agent 之間交接工作、避免兩個工作階段處理同一個 Issue、保留證據以及在審查進度落後時暫停生產時，工廠就值得投資。
所以我一開始就說軟體工廠是一個圍繞軟體工作的可重複循環。我們實際上可以看一個提示詞，它展示了一個非常小的工廠循環：
在修改程式碼之前，請先閱讀 GitHub Issue #123 和儲存庫的說明文件。
僅實作陳述的驗收標準。請勿修改驗證、帳務、資料庫遷移或現有的測試斷言。在一個分支中工作，並保持 diff 易於審查。
執行 npm run lint、npm test 和 npm run build。如果某個必要的檢查無法執行，請停止並解釋原因。開啟一個草稿 Pull Request，附上你已執行的檢查、剩餘的風險，以及任何仍需人類做出的決定。請勿合併。
一個目標可以讓這個循環持續運作，直到檢查通過，我們可以每天早上輪詢 GitHub Issue 來尋找特定標籤，或審查開啟的 Pull Request。分支保護可以強制執行合併邊界，而人類可以透過選擇哪些內容準備就緒、進行審查以及做出最終的合併決定等方式，來保持在循環中。
當你需要一個事件驅動的工作佇列（例如 Slack 觸發、GitHub Issue、Linear、待辦事項清單）在隔離的雲端環境中執行，以處理分類、實作和測試，並伴隨一些明確的人工監控時，就加入一個軟體工廠。有些工廠的循環終點是一個監控 Agent，它會監控生產環境並建立 Issue，然後再次進行分類。
根據我的經驗，當困難的部分在於讓你的不同執行保持一致、在 Agent 之間交接工作、避免不同工作階段認領同一個 Issue、保留證據，以及當人工審查進度落後時停止生產時，工廠就變得有用。
解決這個問題的方法聽起來可能有點無聊。例如，Warp 提到將每個進來的 Issue 分類到四個狀態之一——準備實作、準備規格、需要資訊、等待實作——而這個標籤就是觸發下一個 Agent 的訊號。
這個標籤一次完成了好幾項工作：它是佇列、是鎖定，而且由於一個工作階段只會挑選標記為「準備好」的任務，它也是一個讓人類可以擱置任務而不必永久拒絕的地方。
在工作流程方面，與單純使用 Claude/Codex 相比，有一些相似之處和差異：
- 引導：Agent 需要方向修正，你可以提供輸入並重新導向它
- 通知：工廠如何表示它被卡住了。這可能是因為需求不明確、它開始了某項有風險的操作，或者它需要人類輸入（引導）
- 交接：在雲端工廠、另一個 Agent 或人類審查者之間移動任務、其狀態和上下文。良好的交接會追蹤發生過什麼、還有什麼待辦，以及為什麼需要交接。
在一個好的工廠中，人類不僅僅局限於在最後審查和批准最終的 diff。他們可以在早期塑造工作，在實作過程中引導它，讓它通過交接，或者阻止它出貨到生產環境。
驗證是一個負責任的工廠花費大量時間的地方。我們稍後會更詳細地討論這個。
如果你決定確實需要一個軟體工廠，建立它並不是唯一的選擇。建立擴展工廠所需的基礎設施可能是一項龐大的工作，你可能需要考慮購買 vs. 自建。Factory.ai、Devin、Warp 和 HumanLayer 都在銷售這個循環的某些部分。
我實際上把注意力花在哪裡
在過去一年裡，我日常的軟體開發體驗改變了很多。我一直在談論越來越多地使用 Agent 進行平行工作，並逐步邁向一個燈亮著的軟體工廠。而很多人一直在問我，這些東西到底是什麼意思？你在建立什麼？你使用這些東西的專案類型是什麼？大部分是這樣：
所以在一個非常普通的日子裡，我有一個比較簡單的燈亮著軟體工廠。我可以有在雲端執行的任務。這些任務中有一半可能是在為我合作的小公司處理生產環境的客戶端應用程式。它們會有真實的使用者。它們會有真實的驗證、付款、訂閱，以及你需要小心的真正重大風險。你不能只是說，「哦，Agent，去做這個」，而沒有測試、限制條件和品質檢查。
我可以處理我的開源專案。我可以為我的書籍建立配套網站。我可以開發工具。我可以建立我自己的應用程式。這些都是我正在處理的、非常非常不同類型的應用程式。有時候，它們唯一的共同點就是我用來處理它們的工具，對吧？也許我正在處理一個遷移任務。其他時候，我可能正在進行真正的重大功能開發。而工作的影響範圍也可能非常非常不同。
所以，當你開始思考如何達到一個我們越來越多地進行平行工作的狀態時，我們試圖提高速度、提高生產力，並提高自主性，這意味著讓系統達到一個我們更信任它的狀態，你確實必須思考哪些地方絕對需要人類的程式碼審查、人類的輸入。
而其中很多需求會發生在前期，對吧？當你定義你的規格、需求時，產品的設計會是什麼樣子？產品的意圖會是什麼樣子？然後你要如何驗證 Agent 確實正確地完成了工作？你要如何驗證它們沒有破壞既有的系統？你要如何確保它達到你的品質標準？
所以，產生程式碼不一定是你需要最擔心的部分。只要有足夠的上下文，Agent 可以為我們撰寫實作、執行測試、檢查失敗並修改程式碼。我們需要達到一個狀態，讓我們覺得環境中已經編碼了足夠的人類品味，足以信任正在建立的東西，這樣我們人類的注意力就可以集中在最需要的地方。
現在，有些人會反駁說，「嘿，我不認為你可以就這樣自動化掉這麼多東西。」這並不是說我們要自動化掉所有東西，對吧？但是考慮到產生的程式碼量，我認為要求人類閱讀所有程式碼是不現實的，特別是在很多時候我們並不是在建造火箭，對吧？我們在建立 UI，我們在建立全端應用程式。
我們的判斷力、我們的品味最好集中在最需要的地方。例如，系統中最有風險的部分是什麼？我們需要在哪裡應用人類的品味？這可能在前端。這可能在系統的運作方式上。它不必是 100% 的程式碼。
我的認知頻寬無法與 Agent 一起擴展
現實是，是的，我們現在可以同時啟動數十、數百、數千個 Agent，但你自己的認知頻寬並不能以同樣的方式擴展。這可能會導致我之前談過的認知或理解債務。
如果你回想一下僅僅五到十年前，工程社群中有很多關於情境轉換及其成本的討論。我們會談論人們多麼討厭當他們正在處理一個任務時，同事或某人走到你的辦公桌前。然後你需要很長時間才能重新進入心流狀態，因為你必須重新跟上進度，像是：我做到哪了？我在做什麼？即使你腦中還殘留一點印象，仍然需要時間。
我們現在的情境轉換比過去更多。在任何一天，如果我在軟體工廠之外工作，我可能同時在處理五到十個不同的專案，每個專案都有 Agent，或者同時在處理一個專案中的五到十個不同功能。可以說，我可能同時有五到十個不同的工作階段。
這意味著我必須能夠掌握至少其中一部分。如果我有信心我已經足夠好地定義了任務、定義了結果、定義了如何驗證它是否完成，那麼我有可能增加我賦予某些任務的自主權。但也會有一些任務，我可能不一定有這種感覺，並且涉及更多風險或更多細微差別。我將不得不密切關注。
考慮為你的審查者最佳化軟體工廠。考慮到這些方法中的每一個最終都將其輸出導向一個人的注意力，你應該問問，工廠在多大程度上降低了你仍然需要做出的決策的成本。
一個搞錯專案的錯誤
我記得當我同時使用我的 Agent 處理多個平行專案時，有幾次我意外地做了這樣的事情：也許我正在開發一個我想加入深色模式的網頁應用程式，所以我腦中想著，「好吧，這就是這個功能需要的樣子。」但我卻不小心進入了另一個專案的工作階段，並開始輸入相同的提示詞。
所以我開始為一個完全不需要深色模式的東西實作深色模式。所以我會犯這種錯誤。我不希望我的軟體工廠犯這種錯誤。
你需要從系統的角度來思考這個問題。你實際上是在嘗試將一種軟體工程文化、一種團隊文化編碼到一個系統中，讓它擁有相同的行為模式，讓所有權歸屬於某處，讓仍然有人為發生的事情負責，並且你非常明確地思考這些事情。
當綠色具有誤導性時
即使在這些系統中，你也需要非常小心，對吧？我們很多人都見過，當你要求 AI 幫助你通過測試時，比如我們在談論一個程式設計測試、一個單元測試，它可以修改單元測試來滿足那個條件，或者它可以修改程式碼的邏輯來通過那個條件。這並不代表它真的遵循了你的意圖，以使功能行為和測試應該測試的內容保持一致，對吧？
僅僅因為一個軟體工廠顯示一切都是綠燈，並不代表它實際上就是綠燈，特別是在你剛開始設定這些東西的時候。你需要投入大量注意力，以確保你的檢查、你的驗證等等，都是以正確的方式塑造的。它們正在做你期望它們做的事情。你不希望它們具有誤導性。
你不希望出現這樣的情況：你的測試說，「嘿，實際上，我已經去更改了支援哪些驗證提供者。你要求我加入 GitHub 作為一個驗證提供者，但是，嘿，我的 UI 只有三個空間，所以我已經去掉了其中一個。而且，順便說一句，那恰好是你的客戶想要的一個。」所以你只需要非常明確地說明你希望這些系統如何運作。
順便說一句，安全性也非常重要，如果你的工廠讀取了不受信任的輸入（例如 GitHub Issue / Slack 訊息），它可能具有對抗性，並包含供應鏈攻擊等問題。一些圍繞軟體工廠的產品，例如 Vercel Sandbox / AI ADK Factory，會在隔離的沙盒中執行它們的 Agent，只持有任務所需的機密。這樣，一個被入侵的執行就無法觸及任務不需要的東西。你的防禦最終是分層的。
哪些舊專案值得重獲新生？
我也認為，我們現在工作方式的一個重要部分是決定什麼應該存在。如果你回想多年前，在 AI 出現之前，有那麼多被遺棄的軟體工程專案，那麼多被遺棄的週末專案、個人專案，它們就是無法上線，因為我們沒有時間完成它們。我們沒有頻寬優先把它們推出門，因為它們對我們來說沒那麼重要，或者我們找不到時間。
現在，完成這些專案對我們來說相當簡單，但同樣的人類判斷問題出現了。這些專案值得存在嗎？它們應該被推出嗎？因為你把它們放到世界上，即使只有五個使用者，也許你必須維護它。也許你現在有一個想要維持的品質標準。
我知道多年來我有過這麼多 GitHub 專案，現在我有了 Agent，我做的第一件事就是讓東西能夠建置。因為，當然，你克隆它，現在它因為所有依賴項都變了而無法建置。一半的東西都過時了，或者到處都有安全漏洞，所以你必須更新它們。
然後你必須添加測試（如果你沒有測試的話），這樣你才能知道，如果你以某種方式升級專案，或者將它遷移到更現代的語言或框架之類的東西，至少行為會在那裡。
然後你開始問自己，嗯，也許，一個愚蠢的例子，但也許我以前為這個用了 Twitter Bootstrap，但現在每個人都用 Tailwind 和 shadcn，所以我必須重新實作 UI。你會注意到，突然間這花費了你更多時間，對吧？是的，Agent 可以更快地完成很多這樣的工作，但你現在必須考慮產品感、品味和所有這些東西。
你仍然會質疑，嗯，這是為誰做的？它有市場嗎？是為了我自己嗎？是為了其他人嗎？如果我把它放到世界上，考慮到現在任何人都可以這麼快地建立這些東西，它還會那麼有趣嗎？
所以我認為，這些東西是否值得存在這個人類問題？我們如何融入我們的品味和判斷力？我覺得這些東西仍然極其重要。這就是人類注意力這個稀缺資源真正發揮作用的地方。過去，我們一天只有有限的時數。我們有會議。我們必須為設計、編碼等預算時間。
現在我們有 Agent 來幫助我們，我認為你真的必須非常明確地說明你把時間花在哪裡以及為什麼。
當我建立一個範例工廠時發生的事
所以我將談論 82 分鐘的工廠執行。人們問我已經有一段時間了，「我該如何建立一個軟體工廠？」或者，「我習慣使用 Claude Code 或 Codex。我該如何將我的設定演進到使用軟體工廠？」
所以我一直在說的第一件事是，「你可能沒問題。你的工作實際上可能完全不需要工廠。」但我確實想給人們一個可以參考的設定。所以我整理了一個名為 Factory 的儲存庫，你可以去看看。我還整理了一個示範應用程式和工作坊。
現在，在過去幾年裡，我很多事情的預設示範應用程式都是一個電影應用程式。我是個大影迷。我喜歡看電影。我一直在看電影，所以我有一個示範應用程式，它最初只是一個非常簡單的電影應用程式。我希望工廠能夠去實作一些功能。有幾個不同的功能。我想要一個收藏功能。我希望它能夠進行搜尋，也許還想要一個深色主題，諸如此類。
所以我讓我的工廠開始處理這些事情。你可以查看實作。其中一個好處是它實際上捕捉到了真實的問題。這些問題可能不是如果我要求它一次性實作就能捕捉到的。
也許在大約 60 分鐘的時候，我感覺，「哇，這進行得異常緩慢。」我使用工廠問我的開發工具，「為什麼事情變慢了？」它說，「這實際上完全正常。所有的驗證器仍在執行。」
你可能預期單個任務需要 10 分鐘、15 分鐘、20 分鐘，但一旦你開始加入驗證、重試、瀏覽器檢查、人工審查，任何這些額外的延遲，它們可能需要兩到四倍的時間。
我確實認為這些可以累積成更好的品質和對系統更好的信任。從衡量角度來看，你可能會關注每個合併 PR 的成本和程式碼保存期限等指標，作為理解債務的指標。
你還需要思考什麼是有用的延遲，什麼是工廠開銷。在我的案例中，驗證器捕捉到了一些真實的問題。有一點時間可能花在了產生我想要的證據上。其中一些是工廠運行的開銷。我並沒有花任何時間去最佳化它，但是一個只是運行大量你覺得沒有價值的檢查的工廠，並不代表它是一個高品質的工廠。
你想研究，對於任何重複的檢查，它們是否不相關？它們是否嘈雜？它們是否真的讓系統更安全？
驗證需要一個預算
我思考驗證預算的方式，基本上就是我們在談論的。我們在談論一個驗證預算。我以與過去思考效能預算相同的方式來思考它。
有些類型的檢查你可以在軟體開發生命週期的早期運行，而有些東西非常沉重，但它們提供了巨大的價值，你會希望稍後再運行它們。有些類型的快速檢查，例如 linting、型別檢查。這些是你可以早期運行的相對快速的檢查。
我們完整的測試套件可以在接近準備草稿 PR 的時候或之後運行。這可以包括突變測試、瀏覽器測試、安全檢查等等。
我認為你不一定想用摘要來取代這些。你想要真實的測試，但你只需要確保你在正確的地方為它們預算，因為你不想減慢你的開發循環。我當然從不想減慢我的開發循環。擁有快速的迭代循環對我來說很重要，但我仍然希望有那些制衡機制。
當一次執行沒有出貨時
我上面寫的很多內容都與檢查有關。
在他們的軟體工廠中，Vercel 將每個 Agent 執行標記為「成功」、「有缺陷」、「受阻」或「手動」，並且只有「成功」會出貨到生產環境。其餘的會重新進入系統。我一直在用類似的術語思考執行。
這裡的「有缺陷」意味著實作了錯誤的東西，或者可能沒有完整的上下文，所以必須修復。「受阻」意味著環境可能缺少某個憑證，所以你必須提供它。「手動」是一個工廠可能還不被允許跨越的邊界。
這裡三件事中有兩件可能有機械式的修復，最後一件是關於信任。
雖然這很好，但分類並未向你顯示成本。回到我使用 TMDB 應用程式的工廠實作，沒有拒絕的快速查找功能花了 7 分鐘。收藏功能，經歷了兩次拒絕和一次中間的人工決定，花了 56 分鐘。同一個工廠。所以我會將分類與每個階段的計時配對，否則你只知道一次執行回來時有缺陷，卻不知道發現這個缺陷花費了什麼代價。我要修復的另一件事是邊界處的交接：我的範例工廠停止了第一個 Issue 並將其移動到 factory:needs-info，這是對的，但我不知道該把我的答案放在哪裡。一次手動執行不是在工廠停止時完成，而是在人類知道下一步該做什麼時完成。
自主性不是一個單一設定
幾週前我寫了一篇關於 Agent 自主性的文章，以及如何思考自主性，因為自主性不會是每個專案的單一設定。
驗證為你買來了信任，也買來了賦予你的 Agent 更多自主權的能力。所以，舉例來說，如果我在處理一個非平凡的變更，但我有許多檢查到位，所有東西都正確驗證，而且可能我自己也手動檢查過。下次我在同一個專案中要做類似的任務時，也許我會覺得給 Agent 多一點自主權是舒服的。
這就是你在建立這些軟體工廠時要思考的事情。你的驗證會隨著風險而改變。你的目標是最佳的訊噪比。你不只是想有一個正在運行的大型檢查清單。
我必須重新學習的功能
有一個功能我一直拖延，那天我同時使用多個 Claude 工作階段，同時處理幾個不同的專案，每個專案同時處理幾個不同的功能。所以 Claude 實作了我正在處理的功能。測試看起來通過了。我沒有在驗證上花很多心思，但測試通過了，所以我認為它有效。我合併了它。
這是一個收藏功能。我認為這實際上相當不錯。我試著在瀏覽器中檢查它。看起來還可以，但幾天後，我實際上回到了那段程式碼，因為我認為我可能對它做一些調整。
我不想只是要求我的 Agent 來修改，因為那只是它運作方式中一個很微妙的環節。你點擊圖示，但它卻沒有顯示出正確的點擊效果，所以我只想微調一下。我想了解它的運作原理，這樣才能正確地引導我的 Agent。
我回到程式碼中，卻無法向你解釋這個功能是如何運作的。這個儲存庫是我的，對吧？我核准了這項變更。我了解這個儲存庫中很多部分的運作方式，但我的理解已經跟不上累積起來的所有程式碼了。
我未能吸收的是，這個後來加入的功能實際上如何運作、UI 如何運作、以及它的效果如何運作。我必須重新實作這個功能，並逐步釐清：「這是怎麼運作的？我要如何才能理解它？」
平行工作對理解造成的影響
當你進行平行工作時，這個整體問題會被放大，而在軟體工廠中進行時，情況會更加嚴重。當你同時進行五到十個工作階段時，它們創造的不僅僅是審查量的問題。它們會產生好幾種心智模型，而當你在其他地方工作時，這些模型很可能會變得相當冷卻。
我們過去常討論情境轉換的挑戰，而一旦對話被壓縮，你拒絕某些方法、嘗試不同做法、與 Agent 配對協作時，你將很難記住工作階段中發生的所有事情。
你可以向上捲動，但隨著壓縮的發生，你無法看到所有內容，也無法將所有資訊都記在腦中。程式碼通常會保留所做的決定，但不會保留做出該決定的原因。
我認為這對你來說可能是一個有用的學習經驗，重要的是，考慮要求你的 Agent 實際儲存關於其軌跡的資訊，或是它處理問題時的有趣經驗，以便你之後可以回顧。
這可以是你可以決定是否提交到儲存庫的內容。你可以選擇保留在本機，也可以選擇與團隊分享，但這可以成為日後可供查閱的資料。而不是依賴它可能還留在某個工作階段中，或是你之後可能還記得。
它實際上產出了什麼？
@threepointone 和 @bentlegen 發表了一些關於軟體工廠的 看法 與，我深表贊同：
人們很容易著迷於「執行」的機制，優化這個機制，然後忘記它原本應該產出什麼。如果你的工廠主要產出的是一個更好的工廠，那麼你打造的就是一個產品即自身的軟體。
我認為投資於這個循環是沒問題的，而且它會產生複利效應。失敗在於當這個循環封閉起來的時候，當工廠生產的一切都被工廠自身消耗掉，而外面沒有人會注意到你是否關閉了它。我會應用的測試是「拉動」。必須有外部的某個東西在要求這項改進。如果你說不出是誰在拉動，那你只是在打磨。
所有權並不會消失
這一切背後有一個更廣泛的原則。
由人類實際鍵入的程式碼比例可能會急劇下降。但我認為人類的所有權不需要隨之下降。
- 仍然需要有人選擇問題。
- 仍然需要有人選擇架構。
- 仍然需要有人設定品質標準。
- 仍然需要有人決定哪些驗證訊號值得信賴。
- 仍然需要有人決定何時有足夠的證據可以發布。
而當最終的系統出現故障時，「是 Agent 寫的」這句話並不能解決問題。這就是為什麼我認為軟體工程的未來最好不被描述為人類離開循環。相反地，人類的判斷力正在被重新定位。
我們應該將人們從那些機器能夠產生更強、更快、更確定訊號的循環部分中移除。同時，我們應該將人們集中在那些背景脈絡、品味、風險和長期所有權最重要的地方。
最好的軟體工廠，其定義不會是它們多麼徹底地消除了人類的參與。
它們的定義將是它們多麼聰明地 安置 人類。
將人類的判斷力保留在關於意圖、系統架構和品質標準的上游。在自動化回饋壓力變弱或後果變得主觀的地方審查程式碼。將每個確定性訊號盡可能早且持續地推入循環中。隨著系統贏得或失去信任，有意識地收緊或放寬限制條件。
最終發布的程式碼，仍然必須有人為其負責。足以發布的程式碼，仍然始於一個關心它是否應該存在的人。
