Brief a Subagent

一份委派指示（brief）如果只寫「現況是什麼」而不附證據，執行者會帶著自信把一個沒查證的假設付諸行動。以下規則讓 brief 本身可被查核。

規則

1. 只陳述目標與證據，不陳述「現況」的斷言。 brief 裡每一句關於程式碼現況的事實陳述，都要附 file:line。沒有出處的斷言，執行者沒有能力分辨它是查證過的還是猜的，於是會照單全收去執行。

2. 給明確的路徑許可清單，以及明確的禁止動作清單。 不要讓執行者自己判斷「這個檔案算不算我的範圍」；也不要讓它自己判斷「這個動作算不算太危險」——兩者都要寫死。

3. 明確指定要用哪個 model，不要讓它繼承預設，也不要反射性地選最強的。 按「這件事需要多少推論」選，從能做完的最低一級起，只在有具名理由時升級。用特性判斷，不用名字：

   • 機械執行（推論極少，正因如此會像機械操作一樣照目標做完）：規格完全明確、有現成測試可判對錯——改一行、跑一條測試、抄一張表、查一個值、突變稽核。
   • 快速執行（執行快、推論不多）：規格與邊界都清楚的多檔實作、照現成模式做、驗證與回報、文件整理。
   • 深度推論（會停下來判斷）：只有在跨模組推理、規格含糊要判斷、安全或資料遺失路徑、要對抗性審查時。brief 裡寫下升級的理由；寫不出理由就不升級。
   • 旗艦（派工者自己用的那一級）：子代理不用。哪個名字對到哪一級，在角色定義與專案指示裡，不在這裡。

   模型之外也寫明 effort（推論深度）；沒寫，子代理就沿用派工者的 effort。想要少一點推論，先調低 effort，不要先換小一號的模型，也不要在 brief 裡叫它「少想一點」——調 effort 比這兩種做法都可靠。最高的兩級只給實測過確有收穫的工作。

4. 每份 brief 都要逐字包含這句話：如果 brief 與程式碼不一致，以程式碼為準——停下來回報，不要自行推進。

5. 要求回報時說明「哪些是查證過的、哪些是假設的」。 一份只回報「完成了」的報告無法區分執行者是驗證了假設還是延續了假設。

6. 多個 agent 平行跑時，告訴每一個 agent 忽略自己範圍以外的失敗。 否則每個 agent 都會想去「順手修好」別人範圍內看起來壞掉的東西，製造衝突。

對照範例

• 差的 brief 一句話："同一句話在頁面裡出現四次，刪掉其中三個。"——沒有出處，執行者得自己去猜是哪四個、憑什麼判斷該刪哪三個。
• 好的 brief 一句話："目標：這句話每頁應該只出現一次。證據：已在 a.tsx:42 與 b.tsx:88 各看到一次。刪除前自己查證完整清單。"——目標和已知證據分開陳述，且明白提醒證據不完整、執行者要自己補完查證，而不是假設這兩處就是全部。

快速檢查（動手前）

• brief 裡每一句「現況」陳述都有 file:line 了嗎？
• 路徑許可清單與禁止動作清單都寫了嗎？
• model 與 effort 都指定了嗎？
• 那句「以程式碼為準」逐字放進去了嗎？
• 回報格式要求區分查證與假設了嗎？