上週在 @HelloUntangle，我們完成了公司史上規模最大、風險最高的工程專案。
- 834 個檔案
- 生產資料變更
- 資料庫結構更新
- 31 個 Pull Request
- 從週五開始 -> 週一完成
- 零生產事故
全部由一個 Fable 主編排器 (orchestrator) 工作階段完成。
一個 @DevinAI 主工作階段規劃了所有工作，產生了四十個子工作階段來執行，在各階段之間強制執行回歸檢查與備份驗證，並且只將真正需要負責人決策的事項提出來：範圍裁定，以及不可逆步驟的執行與否。
這次能成功的關鍵，是一套能改善任何大型遷移專案的專案管理模式。
以下是我們的執行方式……
架構：一個編排器，多個工作者
- 一個主工作階段 全權負責整個專案。它的唯一任務是規劃、產生子工作階段、審查它們的輸出、安排各階段的順序，以及在需要人類決策時向上呈報給我。它沒有撰寫任何程式碼。
- 約 40 個子工作階段 負責執行所有實際工作：第 0 階段的 11 個平行稽核工作階段、每個波次的執行工作階段，以及專門負責執行回歸測試套件的關卡執行工作階段。
這種分工之所以重要，是因為長期專案（無論是 AI 或人類主導）的失敗模式通常是脈絡崩潰：執行工作的主體會逐漸失去對整體專案目標的掌握。
讓主工作階段保持純粹的編排角色，能讓它的脈絡保持清晰；它掌握著計畫、範圍決策，以及每個波次的狀態。每個子工作階段則獲得一個全新且專注的脈絡，只需處理單一任務。
七個成功的關鍵模式
1. 先稽核，並將結果凍結在單一清單中
第 0 階段是 11 個平行稽核工作階段，每個負責程式碼庫的一個區塊：應用程式路由、API 路由與 Cron 任務、資料庫結構、共享函式庫與工作流程、腳本與文件。它們的發現被整合成一個檔案，並提交到儲存庫中。
這份清單為每個程式碼單元指定了處理方式與波次編號。兩個規則讓它變得強大：
- 沒有工作者可以重新爭論範圍。 每個執行提示實際上都在說：這份清單是唯一的事實來源。沒有這個規則，四十個工作階段各自都會對範圍產生自己的看法——而且它們的看法會不一致。
- 「未知」意味著停下來詢問。 任何稽核未提及的項目都被明確標記為未知，並附上一條指示：不要猜測；去取得裁定。 負責人的裁定會直接記錄到清單中，以便後續的工作階段繼承。
2. 按風險排序工作，而非按便利性
波次的排序是從最安全到最不可逆。
波次
內容
風險
0
稽核 + 清單 + 還原點 git 標籤
無
1
已驗證無即時依賴項目的變更
接近零
2
共享基礎設施的糾纏手術
中
3–4
大部分的程式碼變更
中
5
生產資料變更（含預演庫存 + 快照）
高
6
資料庫結構遷移
高
7
依賴項目清理、agents.md 重寫、Agent 知識庫稽核
低
生產資料變更（波次 5）在資料庫結構變更（波次 6）之前 執行，而這兩者都只有在所有涉及受影響表格的程式碼路徑都經過可驗證的更新後才會執行。等到遷移執行時，已經沒有任何東西會依賴舊狀態了。
3. 檔案不重疊的邊界讓平行處理變得安全
在一個波次內，子工作階段會平行執行——其中一個波次有四個工作階段同時處理樹狀結構的不同部分。紀律是：每個提示都包含一個明確的檔案邊界，而且這些邊界彼此不重疊。沒有合併衝突，沒有兩個 Agent 編輯同一個檔案，子工作階段之間完全不需要協調。
這是經典的任務分解——跟你把工作分配給不同工程師時的做法一樣——但 Agent 需要在提示中明確地被告知這一點，每次都要。
4. 波次之間的安全關卡
在下一個波次開始之前，前一個波次必須先通過一個關卡。這些關卡本身就是子工作階段：
- 一個基於瀏覽器、端到端的回歸測試套件，涵蓋平台的核心客戶工作流程，在波次 2 之後以及波次 3–4 之後再次執行，使用一個全新的隔離資料庫分支。
- 在任何生產資料變更之前：一個專門的工作階段稽核了我們的資料庫備份庫存（數量、日期範圍、保留期限），並且我們建立了一個新的時間點快照。
- 生產步驟本身先執行預演，產生行數供負責人批准，並在執行後重新驗證行數。
- 每個被變更的行都有一個 git 標籤標記還原點。
當一個關卡失敗時，它會產生一個範圍限定的修復工作階段。例如，回歸測試套件抓到了一個因過度積極的變更而損壞的客戶面向流程；一個修復工作階段在幾小時內就將其恢復。這就是系統在運作——關卡將原本會是客戶回報的錯誤，變成了一個當天修復的問題。
5. 人類批准；Agent 提案
在這個專案中，我從未撰寫程式碼、執行遷移或執行生產腳本。但是，每一個不可逆的步驟都需要我明確同意：每次合併到 main 分支、生產資料變更、資料庫結構遷移，以及對每個「未知」範圍項目的裁定。
對於破壞性工作的模式是：Agent 提出一個庫存清單，人類批准這個庫存清單，然後 Agent 就只執行那個庫存清單中的內容。 生產工作階段在觸碰任何東西之前，會先產生它將要觸及的行的精確清單。我批准的是特定的清單，而不是一個模糊的意圖。
6. 針對突發狀況的升級協議
子工作階段被告知，當實際情況與清單不符時該怎麼做：停下來，向主工作階段報告，不要即興發揮。真實案例：
- 一個稽核認為安全的模組，結果在其他地方有即時的依賴項 → 子工作階段標記了它，該單元被降級到後面的波次，並記錄了糾纏情況。
- 第二輪稽核推翻了第一輪對五個完整區域的判定 → 這些推翻被明確地作為覆寫記錄到清單中，而不是由碰到它們的任何工作階段臨時解決。
主工作階段將這些突發狀況吸收到計畫中。個別工作者從不做範圍決策。
7. 讓營地更乾淨：教導系統什麼改變了
波次 7 可能是最被低估的階段。在變更上線後，工作階段重寫了我們的 AGENTS.md、儲存庫技能和 Agent 知識庫，以描述新的架構——這樣每個未來的 Agent 工作階段都能從真實情況開始，而不是從過時的指示開始。如果你的工程是由 Agent 驅動的，那麼你的文件就是承載基礎設施。
成本是多少
專案中的每個工作階段都做了標記，所以帳目是完整的：一個主工作階段和三十九個子工作階段，全部使用 Devin 的 Ultra Agent，從週五下午到週一早上。以下是我們使用儀表板中的實際計量成本。
階段
工作階段數
成本
主編排器（跨多日）
1
$115.26
第 0 階段稽核（兩輪）+ 清單整合
12
$85.56
波次 1
4
$37.55
波次 2（糾纏手術）
4
$299.34
波次 2–4 回歸關卡 + 修復
4
$244.69
波次 3–4
5
$130.84
波次 5（生產）+ 備份稽核
2
$15.20
波次 6（資料庫結構遷移）
3
$118.83
波次 7（依賴項目、文件、知識）+ 最終關卡
4
$96.64
基礎設施修復
1
$11.47
總計
40
$1,155.38
在細項中有三點特別突出。
- 整個包含 12 個工作階段的稽核階段，產生了清單，成本不到 90 美元——這是我們買過最便宜的保險。
- 成本最高的項目正好落在需要進行困難思考的地方：糾纏手術（299 美元）和確保一切正確無誤的回歸關卡（245 美元）。
- 風險最高的步驟——生產資料變更——只花了 15 美元，因為在它執行時，所有風險都已經被工程手段排除了。
注意：如果 Devin 允許我為子 Agent 選擇不同的模型，整個專案的成本可以更低。大部分的程式碼撰寫工作使用 gpt 5.5 或 opus 4.8 就能成功完成。指示 Fable 選擇適合子 Agent 任務的模型會很簡單。
即使沒有這個功能：1,000 美元對於我們完成的工作來說已經便宜得難以置信——而且完成的速度和驗證速度——哇。
https://x.com/ryancarson/status/2072694425365426344
重點總結
重點不在於 AI 寫了很多程式碼——Agent 執行明確指定的變更現在已經是基本要求了。
重點在於專案管理本身也被委派了：分解、排序、平行化、關卡設定和升級通報，全部都在編排器內部運行，而人類的角色被壓縮到只剩下需要負責人決策的事項。
如果你想嘗試這個方法，請複製這些模式，而不是工具：
- 先稽核；將發現結果凍結在一個任何工作者都不能重新爭論的清單中。
- 按風險排序波次；不可逆的步驟最後做。
- 為平行工作者提供明確不重疊的檔案邊界。
- 用真正的回歸測試套件和真正的備份來為每個波次設立關卡。
- 在破壞性變更之前要求提出庫存清單；批准的是清單，而不是想法。
- 在突發狀況到來之前就定義好升級路徑。
- 將更新文件和 Agent 知識作為專案的一部分，而不是事後才做。
祝大家編排愉快！ :)
