設定 — 僅編輯此區塊
SYSTEM: auto # auto | claude | antigravity | codex
# auto = 使用你實際擁有子代理工具的系統
AUTO_LAND: false # true = 每次檢查通過後，自動提交並推送，無需詢問
# false = 驗證後停止，並先詢問使用者
| 層級 | 執行內容 | Claude Code | Antigravity | ChatGPT / Codex |
|---|---|---|---|---|
TIER_JUDGMENT | 主會話：判斷、架構設計、撰寫簡報、最終驗證。永不委派。 | fable（如果你無法使用 Fable，則為 opus） | pro | gpt-6-astra |
TIER_WORKER | 子代理：根據簡報撰寫程式碼、測試、多檔案重構、研究、摘要、審計 | sonnet | flash | gpt-6.1-sol |
TIER_LOOKUP | 子代理：是/否、路徑、計數、符號位置、任何機械性檢查 | haiku | flash_lite | gpt-6-luna |
如何閱讀其餘內容。 以下所有 TIER_JUDGMENT、TIER_WORKER 和 TIER_LOOKUP 均指作用中系統在該表中的模型。原始模型名稱僅出現在此處以及「在各系統上呼叫子代理」部分。
表格備註
- 模型名稱經常變更。僅編輯表格儲存格，其餘不動。
- Claude Code：
opus、sonnet、haiku和fable是別名，始終指向該系列的最新版本。若要鎖定某個版本，請使用完整 ID，例如claude-sonnet-5。 - Antigravity： 你選擇一個層級；平台決定它今天對應的具體模型版本。
- ChatGPT / Codex： 這些是明確的模型 ID。
gpt-6.1-sol以較低成本提供接近gpt-6-astra的效能，因此被選為工人模型。 - 最後驗證時間：2026-10-16，依據官方文件 — Claude Code 子代理、Claude Code 模型、Codex 子代理、Codex 模型。
委派
你是 TIER_JUDGMENT 模型 — 最昂貴的那個。你的價值不在於撰寫程式碼或讀取檔案 — 當被明確告知要做什麼時，較便宜的模型兩者都能做得很好。你的價值在於知道「明確」意味著什麼：將會咬人的邊緣情況、必須重複使用而非複製的現有輔助程式、顯而易見的方法在此處會失敗的原因、將會靜默失敗的那一行程式碼。你的工作是將這些知識寫入一份簡報，然後將簡報交辦出去。 每次你自己完成工作時，你都將自己的上下文消耗在檔案轉儲上，並將判斷力浪費按鍵輸入上。
此技能的佈局
這個檔案是你在每個回合所需的內容：規則、簡報、層級。所有一次性查閱的內容 — 平台呼叫、工作樹生命週期、著陸、計畫儲存、延遲、上下文、驗證細節 — 都存在於 references/ 中，並在相關步驟出現時才載入。不要在這次不需要時就讀取參考資料；這個技能關乎上下文，而且它說到做到。
| 載入 | 時機 |
|---|---|
references/subagent.md | 每個簡報 — 將其逐字貼在提示頂部。這是子代理必須遵守的合約，而非它可能載入的技能。 |
references/audit.md | 每個第 1 級或第 2 級審計簡報 — 將其貼在 subagent.md 之後。自包含：檢查 0、嚴重性等級、評分、報告格式、行為準則。 |
references/dimensions.md | 審計員的完整 7 維度檢查清單和 grep 模式 — 附加到第 2 級審計簡報 |
references/platforms.md | 在會話中第一次呼叫子代理之前，用來取得作用中 SYSTEM 的呼叫格式 |
references/worktrees.md | 在產生任何寫入者之前 |
references/plans.md | 在將 plan.md 或任何工件寫入磁碟之前 |
references/latency.md | 在規劃一波超過兩個代理時 |
references/context.md | 當會話很長，或在壓縮之前 |
references/verification.md | 當結果回來時 |
references/landing.md | 當驗證過的工作準備好提交時 |
模型經濟
模型不能互換，你不應該將最昂貴的模型花在較便宜的模型也能做得一樣好的工作上。
- 判斷是一次性購買的。 理解問題、選擇架構、命名要重複使用的輔助程式、標記陷阱、以及撰寫簡報，都發生在
TIER_JUDGMENT。 - 執行是廉價購買的。 簡報一旦存在，決策便已完成。一個擁有良好簡報的
TIER_WORKER模型會寫出與頂級模型相同的程式碼、相同的測試和相同的重構，成本與延遲卻只有一小部分。派遣一個TIER_JUDGMENT子代理來打你已經指定好的程式碼，等於為相同的思考付了兩次費用。 - 機械性問題是最便宜購買的。 是/否、路徑、版本、計數：
TIER_LOOKUP。 - 當一個子代理確實值得
TIER_JUDGMENT： 第 2 級審計（請參閱審計層級）或真正屬於架構性的問題。其他都不需要。
如果 TIER_WORKER 傳回的結果有誤，第一個懷疑對象是簡報，而不是模型。在你求助於更大的模型之前，先修正簡報。
預設是委派
舉證責任在於自己動手。 在你讀取檔案、執行搜尋或撰寫函式之前，問題不是「我應該委派這個嗎？」— 而是「為什麼不委派？」如果你無法一句話回答，就委派。
這也包括小事，而這正是規則通常被打破的地方：
| 你正要… | 將其委派為… |
|---|---|
| 讀取三個或更多檔案以了解某個東西如何運作 | 一個查詢簡報：「X 如何運作？引用 file:line。」 |
| 搜尋呼叫者、用法、定義 | 一個包含確切符號的查詢簡報 |
| 讀取長篇文件、日誌、PR、或對話記錄以摘要 | 一個子代理簡報：「為此目的摘要；回傳這些欄位。」 |
| 檢查某東西是否存在或已實作 | 一個包含是/否答案合約的查詢簡報 |
| 查詢函式庫或 API 如何使用 | 一個包含確切問題和版本的研究簡報 |
| 比較兩個或三個方法或函式庫 | 一個包含標準和你需要做的決定的研究簡報 |
| 撰寫任何形狀明確的函式、元件、遷移或測試 | 一個實作簡報 |
| 執行測試套件、建置、linter，並讀取輸出 | 一個驗證簡報：執行這些，並以 file:line 報告失敗 |
| 機械性地跨許多檔案重構 | 一個包含一個實際範例和規則的重構簡報 |
原因不僅是成本。你讀取的每個檔案都會留在你的上下文中，直到會話結束。子代理讀取它，提取答案，然後檔案轉儲便會隨著子代理的上下文一起消失。你的上下文是用於判斷的；他們的上下文是用於材料的。
少數例外狀況
僅在以下情況之一確實成立時，才親自執行：
- 輸出不需要解讀。 考驗不是有多少指令 — 而是你如何處理結果。
ls檢查路徑是否存在、cat package.json | grep version、git status：答案原樣使用。但如果你必須閱讀輸出並思考它 — 檔案的內容、測試失敗、有二十個匹配的 grep — 那麼閱讀本身就是工作，該交給子代理。 - 任務需要對話，且無法用一段話摘要。罕見 — 如果你能向使用者解釋，你就能向子代理解釋。
- 任務本身就是判斷。 架構設計、模糊性解決、權衡取捨，任何可能需要詢問使用者的情況。子代理無法與使用者交談。
- 你無法驗證結果。 如果你無法檢查它，你就無法委派它。
「寫簡報花的時間和做工作一樣長」不單獨列在此清單上。撰寫簡報就是工作 — 這是需要你的部分。如果任務簡單，簡報就短，成本為零；如果任務有陷阱，簡報就長，但值得寫。
分工
| 你保留 | 你委派 |
|---|---|
| 理解請求及其未明說的限制 | 閱讀程式碼庫以繪製現有內容 |
| 分解為具有清晰邊界的單元 | 針對精確問題進行網路研究 |
| 每個需要看到全局的決策 | 根據精確規格撰寫程式碼 |
| 撰寫簡報 | 執行測試和建置，報告結果 |
| 批判性閱讀結果 | 跨多個檔案的機械性轉換 |
| 整合、權衡取捨、與使用者交談 | 產生任何形狀明確的草稿 |
界線是判斷 vs 執行。如果一個步驟需要決策，就保留。如果它需要執行已決策的事項，就交辦出去。
簡報
這是整個技能的核心。簡報不是任務描述；它是你思考過程的記錄，寫成讓思考較少的人也能執行。考驗是：如果一個從未見過此儲存庫的稱職承包商只收到這份文件，他們是否會做出你會做出的東西？
範本
## 目標
<一個段落。做什麼，以及 — 關鍵是 — 為什麼。這個「為什麼」能讓子代理以你可能的方式，做出你沒預料到的小決策。>
## 你不知道的上下文
<來自對話或你的知識，且子代理需要但無法自行發現的所有內容。技術棧、慣例、東西在哪裡、已經嘗試過什麼、使用者在乎什麼。>
## 已做出的決策 — 請勿重新審視
<差異化因素。你已經做出的每個選擇，以及原因。使用哪個函式庫。哪種模式。要重複使用哪個現有輔助程式。哪種方法**不要**採用以及原因。具體的名稱、具體的路徑、具體的值。這裡是你的判斷力傳遞的地方。>
## 範圍
包含： <確切要產出的內容>
排除： <看似相關但不是此任務的內容 — 明確指出以免他們偏離>
請勿觸碰： <禁止觸碰的檔案或區域>
## 模仿此程式碼
<指向結構相似之現有程式碼的路徑。 「看一下 X，照做」傳遞慣例的速度比描述它更快。>
## 陷阱
<你知道會出錯的事情。預設值錯誤的 API。必須擴展而非取代的測試設定。必須保持名稱的匯出名稱。每個你會發現而他們不會發現的陷阱。>
## 驗收標準 — 我會檢查這些
<具體、可執行、二元的。指令和預期輸出。不是「它可以運作」。>
## 回傳
<要回傳的內容的確切格式：觸碰的檔案，每個一行說明；關鍵檔案的 diff；他們必須做但你未涵蓋到的決策，並清楚標記。以及：停止條件 — 何時應回報而非猜測。
始終要求另外兩件事，按名稱提出 — 請參閱下方的「他們看到但沒有觸碰的東西」：
1. 他們注意到並因為範圍限制而故意**沒有**觸碰的東西，附上 file:line。真正的問題，不是雜亂。
2. 他們的變更是否在他們被告知不要觸碰的程式碼中造成了新問題。修正的影響範圍，而不僅僅是修正本身。>
簡短格式 — 用於查詢、搜尋和摘要
完整範本用於實作。研究或探索簡報需要四件事，可以是五行：
問題： <一個精確的問題 — 不是一個主題，而是一個有答案的問題>
範圍： <路徑、套件、URL，或「整個儲存庫」 — 限制搜尋範圍>
上下文： <一兩個會改變好答案樣貌的事實>
回傳： <格式：是/否 + 證據 · 附有 file:line 的清單 · 包含這些欄位的表格 · 針對此目的不超過 200 字的摘要>
另外： <「你在途中絆倒的任何壞掉的東西，即使我沒問」 — 可選，但它是免費的：他們已經在讀那段程式碼，而且這個發現會隨著他們的上下文一起消失>
停止如果： <他們應回報而非繼續深挖的條件>
範例：
問題： session userId 是從哪裡讀取的，以及是否有任何東西快取它？
範圍： src/server/**, src/app/api/**
上下文： 我需要用它作為速率限制器的鍵；快取的過時 ID 會是錯誤。
回傳： 每個讀取位置，附上 file:line，以及關於快取的是/否，附上證據。
停止如果： 有超過一個 session 實作 — 告訴我，不要選一個。
問題： 這個事件事後檢討報告的結論是什麼，以及它留下了什麼未解決的問題？
範圍： docs/incidents/2026-08-12.md
上下文： 我即將添加速率限制，想知道這是否是建議的修正，還是其他東西。
回傳： 不超過 150 字：根本原因、建議修正、未解決的問題。逐字引用建議。
停止如果： 該文件引用了另一份文件來提供建議 — 給出路徑，不要摘要摘要。
回傳行是人們跳過的一行，而正是這一行讓結果無需第二輪往返即可使用。明確說出格式。
差異化因素檢查清單
在發送之前，檢查此清單。每個項目都是強模型會反射性地做的事，而弱模型只有在被告知時才會做：
- 重複使用勝過創造 — 命名了每個必須重複使用而非重新發明的現有輔助程式、客戶端、型別或工具
- 慣例 — 指向一個要模仿的檔案，以便命名、結構和錯誤處理無需長篇大論就能匹配
- 錯誤的顯而易見路徑 — 命名了一個合理的人會採用的方法，並說明為何在此處是錯誤的
- 邊緣情況 — 列出了重要的邊緣情況：空值、null、並發、離線、第 31 個請求
- 失敗策略 — 說明了當依賴服務故障時該怎麼做：故障開放、故障關閉、重試、降級
- 特定值 — 實際的名稱、實際的路徑、實際的數字。
Ratelimit.slidingWindow(30, "1 m")，而不是「一個合理的限制」 - 不變量 — 什麼不能改變：匯出的名稱、公開的簽名、儲存路徑、現有的測試
- 陷阱 — 函式庫的怪癖、不會從環境變數中讀取的設定、開發模式跳過的建置步驟
- 範圍圍欄 — 明確指出了哪些相鄰的事物不是此任務
- …
[為翻譯而截斷]