問題所在
你加入了新團隊。你收購了一家公司。某個關鍵相依套件已無人維護，總得有人去評估它。程式碼庫龐大，時間又緊迫。
舊方法：開檔案、到處 grep，花好幾週在腦中建立心智地圖。單一代理的方法：把檔案貼給 Claude 問問題，一次一段對話，每次工作階段結束後脈絡就沒了。
兩種方法都無法擴展。一個 50 萬行的程式碼庫有數百個模組。一個代理在品質下降前，脈絡裡大概只放得下 20 個檔案。你得進行幾十次循序的工作階段，而且最後還是得自己彙整所有發現。
「我聰明、能幹，也有豐富的程式設計經驗，但光是要保持專注、好好審查單一 Claude 代理的輸出，就已經勉強應付得來而已。」—— petesergeant，HN
如果連一個代理的輸出都難以消化，想像一下，要在一個你從沒看過的程式碼庫上，彙整 40 個獨立工作階段的發現。
Chief 如何幫忙
平行閱讀整個程式碼庫
Chief 會把你的稽核目標拆解成平行的閱讀任務：每個模組、服務或層級各派一個代理。代理同時分散到程式碼庫各處，每個都只負責範圍明確的部分，讓脈絡保持清晰；你的代理訂閱額度允許多少個同時執行，就同時執行多少個。這正是驅動 Chief 重構工作流程的平行執行機制，只是改用在純分析上。
你設定稽核目標，代理負責閱讀
告訴 Chief 你需要知道什麼：「列出所有資料庫存取模式，並標記 N+1 查詢。」「找出每個驗證邊界，並記錄信任模型。」「找出所有外部 API 相依項目及其失效模式。」Chief 提出稽核計畫，由代理執行。開啟 Auto mode，各條稽核軌道就會在任務上限與供應商用量的每週上限內，在無需人工看管的情況下執行。你從頭到尾都不會打開任何一個原始碼檔案。
摘要統整所有發現
每個代理都會依你的稽核標準回報結構化的發現，Chief 再依里程碑的驗收標準審查每項結果。Chief 的摘要會彙整所有模組的發現：不是原始的代理對話紀錄，而是整理好、可直接據以行動的結果。需要你拍板的發現會放進你的待辦清單（搶先體驗）。
不同稽核面向使用不同代理
用 Claude Code 做架構分析，用 Codex 偵測機械性模式，用 Qwen Code 評估測試涵蓋率。Chief 的 BYOA 模式讓你為每個稽核里程碑挑選代理：安全審查、相依關係對應、無用程式碼偵測、API 介面盤點，全部平行執行。
跨稽核工作階段的持續脈絡
Chief 會在每個代理工作階段之間維持專案層級的脈絡，並把發現延續下去，讓後續任務建立在先前任務的成果上。當一個代理發現驗證模組委派給共用的中介層時，負責稽核該中介層的代理一開始就會知道這件事。不必從零開始，也不必重複探索。
為什麼程式碼庫稽核適合平行代理
1. 閱讀天生就高度可平行化
稽核程式碼庫完全是讀取端的工作。每個模組都能獨立分析。沒有合併衝突，沒有相依順序，只有數百個需要同時有人用心檢視的檔案。這正是 Chief 平行分派所適合的工作量。
2. 單一代理的脈絡崩潰會毀掉稽核品質
一個代理讀 500 個檔案，只會產出淺薄、籠統的觀察。十個代理各讀 50 個檔案，則會產出深入、具體的發現。Chief 讓每個代理都待在最佳狀態：範圍明確、脈絡清晰，同時統籌整個程式碼庫的全貌。
3. 彙整才是難處，而 Chief 會處理
價值不在任何單一代理的發現，而在於橫跨所有代理的彙整觀點。Chief 依各條軌道的標準逐一審查，並把每個代理的發現摘要成一份條理分明的稽核報告。你審閱的是彙整結果，而不是原始輸出。
4. 稽核會重複進行，而 Chief 記得
每季的安全審查。收購前的盡職調查。合規檢查。重大升級前的相依套件稽核。Chief 的持續專案脈絡讓每次稽核都建立在上一次的基礎上。第二次稽核會更快，因為 Chief 已經了解程式碼庫的結構。
範例：針對 40 萬行程式碼庫的收購前技術盡職調查
1. 設定稽核目標。 CTO 打開 Chief，設定一個專案層級的目標：「完成目標公司後端程式碼庫的技術盡職調查。評估架構品質、安全態勢、擴展瓶頸與技術債。」
2. Chief 提出稽核計畫。 Chief 分析儲存庫結構，提出 5 條平行的稽核軌道：
- 軌道 1：架構對應——服務邊界、資料流、相依關係圖（6 個代理，涵蓋 6 個服務）
- 軌道 2：安全稽核——驗證邊界、輸入驗證、機密管理、OWASP 攻擊面（3 個代理）
- 軌道 3：資料層分析——結構描述設計、查詢模式、遷移歷史、N+1 偵測（2 個代理）
- 軌道 4：基礎架構與部署——CI/CD、容器設定、擴展特性（1 個代理）
- 軌道 5：程式碼品質訊號——測試涵蓋率、無用程式碼、相依套件新舊程度、錯誤處理模式（3 個代理）
3. 代理分頭進行。 CTO 核准計畫，並開啟 Auto mode，設定任務上限與供應商用量的每週上限。Chief 平行分派各項閱讀任務，每項都有明確範圍；CTO 的代理訂閱額度允許多少個同時執行，就同時執行多少個。代理依結構化標準閱讀、分析並回報發現。不修改任何程式碼——這是純粹的分析。
4. 從任何地方監控。 CTO 在董事會會議中用手機查看進度。軌道 1 已完成 80%。軌道 2 標記了三項嚴重發現：兩個服務中有寫死的機密，以及一個管理端點缺少驗證檢查。這項驗證問題被放進 CTO 的待辦清單（搶先體驗），因為只有 CTO 能做這個決定。軌道 3 找出 14 個 N+1 查詢模式。
5. 彙整報告。 Chief 把五條軌道的發現摘要成一份結構化的盡職調查報告：3 個嚴重安全問題、14 個效能瓶頸、資料層有中等程度的技術債，整體架構穩健。CTO 在沒打開任何一個原始碼檔案的情況下，就取得了完整的技術評估。
6. 成果。 一般需要工程團隊 2-3 週的盡職調查流程，大約一天就完成了。每個代理都在各自明確的範圍內維持清晰的脈絡。每項發現都能追溯到具體的模組與檔案。CTO 根據資料而非直覺提出收購建議。
方案說明。 這種規模的稽核遠超過 Free 方案每天 30 個任務的額度，因此屬於 Pro 的使用情境。使用 Free 方案時，可以先從一兩條軌道開始。
何時使用 Chief
- 你需要理解一個從沒看過的程式碼庫——新工作、收購、接手的專案，或評估開源相依套件。
- 程式碼庫太大，一個代理處理不來——數十個模組、數百個檔案，超出任何單一脈絡視窗能容納的量。
- 你需要結構化的發現，而不是原始對話紀錄——安全態勢、架構品質、技術債評估或合規驗證。
- 稽核有時效壓力——盡職調查期限、事件應變，或遷移前的風險評估。
- 平行代理同時閱讀程式碼庫的不同部分——十個代理各自分析明確的範圍，比一個代理全部草草掃過，能產出更深入、更具體的發現。
常見問題
這和傳統的程式碼審查工具有什麼不同？
傳統的程式碼審查工具，例如 GitHub PR 審查、Reviewboard、Gerrit，評估的是程式碼的變更。Chief 的程式碼庫稽核評估的是程式碼本身。你不是在審查 diff，而是派代理去閱讀並分析整個既有的程式碼庫。這就像審查一個 pull request 和稽核一家公司的整個技術堆疊之間的差別。
Chief 能在不修改任何檔案的情況下稽核程式碼庫嗎？
可以。程式碼庫稽核完全是讀取端的作業。代理負責分析、回報發現並呈現結果，不會變更任何檔案，也不會建立任何分支。Chief 負責協調閱讀工作並彙整發現。
Chief 如何避免代理產出淺薄、籠統的觀察？
方法是讓每個代理的範圍保持明確。Chief 不會讓一個代理試圖理解 500 個檔案，而是派出 10 個代理，各自分析 50 個檔案。範圍明確代表脈絡清晰，也就能得到具體、可據以採取行動的發現。接著由彙整層串連各代理之間的洞見。
Chief 能統籌哪些類型的稽核？
任何針對既有程式碼庫的結構化分析：安全審查、架構對應、相依套件稽核、技術債評估、合規驗證、遷移前風險分析、測試涵蓋率評估、API 介面盤點、無用程式碼偵測，以及效能瓶頸辨識。
哪些代理最適合程式碼庫稽核？
不同代理擅長不同的稽核面向。Claude Code 在架構推理與安全分析方面很強。Codex 能妥善處理機械性的模式偵測。Chief 的 BYOA 模式讓你為每條稽核軌道挑選代理，全部透過同一個儀表板協調。
Chief 會記得先前稽核的發現嗎？
會。Chief 會維持持續的專案層級脈絡。當你執行每季安全稽核時，Chief 已從上次稽核中了解程式碼庫的結構。重複稽核會更快，也能專注於上次評估之後的變更。
我可以同時稽核多個程式碼庫嗎？
可以。每個儲存庫都是一個獨立的 Chief 專案，而你所有的專案都集中在同一處，所以你可以同時在多個儲存庫上執行稽核。這很適合多儲存庫收購案的盡職調查，或跨專案的全面安全檢查。Free 方案涵蓋 5 個專案；Pro 則取消此限制。
用 Chief 做程式碼庫稽核是免費的嗎？
是的。Free 方案包含 5 個專案，以及每天使用你自己的代理執行 30 個任務，而且不需要信用卡。Pro 會取消這些限制，並加入搶先體驗功能。大型稽核拆成許多閱讀任務後，通常每天需要超過 30 個任務，因此屬於 Pro 的使用情境。