工作回顧 (Debrief)

工作回顧 (Debrief) 是做什麼的？

工作回顧是一個持續存在的後設目標的工具：一個改善我們流程的流程。它關注人與代理如何協作，並附上證據，將其發現轉化為三種輸出：為代理準備的教訓（指令、技能、工作流程、掛鉤）、為人準備的教訓（如何更好地引導代理），以及專案設定的變更。它對雙方都誠實，並且不製造批評：一個順利的工作階段只會得到一份簡短的報告。

結構與規則改編自兩個 MIT 授權的技能，謹此致謝：Wavez 的 debrief（四個檢查群組、「每個發現都要引用一個時刻」、未經批准不套用任何東西）和 florianbuetow 的 retrospective（報告保留為歷史、檢查先前的建議並升級重複出現的問題、每個發現都需要根本原因和建議）。教練建議部分、五個為什麼的習慣和使用腳本是此技能的原創。

輸入

1. 對話記錄。 主要來源：工具呼叫、提問及其提出時間、使用者的修正與確認、子代理報告、錯誤與重試。如果工作階段已被壓縮，請在報告中說明，並將摘要視為低可信度的證據；不要為你無法看到的部分捏造時刻。

2. 使用數據。 為工作階段執行內建腳本，以獲取用量：回合數、按名稱分類的工具呼叫、子代理與工作流程及其使用的 token、使用的模型、每個模型的輸出 token、持續時間、壓縮次數。它會讀取 ~/.claude/projects/<專案別名>/ 下的工作階段記錄以及旁邊的 subagents/ 目錄。使用者可能會要求查詢另一個工作階段；屆時傳遞其 ID。

   python3 ${CLAUDE_PLUGIN_ROOT}/scripts/usage.py            # 當前工作階段（此專案的最新記錄）
   python3 ${CLAUDE_PLUGIN_ROOT}/scripts/usage.py <session-id>
   

3. 專案記錄。 指令檔案（CLAUDE.md、AGENTS.md）、若專案有維護則包含待辦事項與決策日誌，以及該專案的代理回饋記憶（~/.claude/projects/<專案別名>/memory/），這樣才能識別重複的錯誤。

4. 先前的回顧報告。 報告目錄中最近的三份報告（如下）。對於它們提出的每項建議，請註明是否已執行、是否重複出現或狀態未知；重複出現的問題需要提高嚴重性。

投入的努力要與工作階段規模匹配：一個簡短、乾淨的工作階段只需快速檢查；一個長達數週的工作階段則需要完整的處理，並對較大的模式問五次為什麼。

檢查重點

依序檢視以下四個群組。對於每個發現，請引用具體時刻（說了什麼或做了什麼、大約何時），說明其重要性，並對實例持續追問「為什麼」，直到找出流程原因或原則，或直到答案超出專案的控制範圍。將觀察與處方分開：觀察可能正確，而提出的修正方案可能是錯的。

1. 效率。 多餘或重複的工具呼叫、本應由腳本或技能處理的手動邏輯、額外的建置或測試循環、可以批次處理的工作、被遺漏或證明有價值的子代理、壓縮後的重工、隨工作階段結束而消失的背景工作。
2. 協作。 提問時機過早、過晚或根本沒問；未遵循常設指令；在需要規則指引時卻照搬範例；過於冗長；代理是否說明了它如何解讀模糊的請求；那些看似會阻礙的問題是否真的成為了阻礙。
3. 正確性與紀律。 未附證據的主張；後期才發現的限制；未經確認的破壞性或不可逆操作；忽略專案慣例；跳過「此功能是為了應對哪種情境？」和「什麼情況可以攔截此問題？」的提問。
4. 傳承。 值得保存為記憶或專案文件的偏好與決策；可轉化為技能、工作流程、掛鉤、常設規則或待辦事項的提案；能讓工作階段更順暢的工具；下次可以自動化的步驟。兩次重複的手動操作，表示缺少一個可重複使用的資產。

接著是讓此技能更具個人特色的兩個部分：

• 給使用者的教練建議。 寫提示的人如何能更有效率？他們的哪些做法最有幫助（指出來，以便重複執行），哪些又造成了損失（模糊的範圍、範例上缺少標籤、代理需要的決策被隱藏、跳過了審查）？直接寫給這個人，就像監督小組中的同儕那樣：具體、基於證據、不奉承、不軟化語氣。
• 模型與投入程度。 從數據來看：模型與投入程度是否與工作相稱？token 花在哪裡（主循環、子代理、工作流程），對於部分工作，使用更便宜的模型或較低的投入程度是否可行？高投入在哪些地方獲得了回報？

報告

將報告寫入報告目錄，並在回覆中顯示簡短摘要。目錄為目前儲存庫中的 docs/debriefs/（如果該儲存庫有 docs/ 目錄），否則為 ~/.claude/debriefs/<專案別名>/；使用者可以指定其他路徑。檔案名稱為 YYYY-MM-DD.md，如果已存在則加上 -2 後綴。

簡短而密集：讀者是親身經歷該工作階段的人，因此報告是提醒而非敘述。細微之處存在於證據和原因中，而非圍繞它們的修辭。使用以下範本：

# 工作回顧 <日期>: <工作階段的主要內容>

涵蓋範圍: <回顧能看到的內容；若有壓縮請註明>。先前的回顧: <日期或無>。

## 五點總結
- <工作階段達成了什麼>
- <什麼讓它成功>
- <什麼造成了損失>
- <一句話的教練建議>
- <有多少提案，以及最重要的那一個（非小型的）>

## 數據
<腳本產生的一段話：時間跨度、回合數、工具呼叫（列出前幾個）、每個模型的輸出 token、子代理、壓縮次數>

## 順利的部分
- **<兩個字的標籤>.** <具體時刻> → <帶來了什麼好處>。

## 造成損失的部分
- 🔴 / 🟡 / 🟢 **<標籤>.** <具體時刻，一行描述>。
  原因: <追問為什麼後得到的流程原因>。<已修正，或尚待處理>。

## 給 <使用者> 的教練建議
持續執行: <那些有所幫助的做法，一行列出>。
1. **<習慣>.** <證據> 以及 <替代做法>，一兩句話。

## 模型與投入程度
<一段話：是否相稱，以及佐證的數據>

## 提案
| # | 提案 | 目的地 | 投入程度 | 決策 |
|---|---|---|---|---|
目的地：AGENTS.md 或 CLAUDE.md 規則、記憶、技能、工作流程、掛鉤、待辦事項、共享指南、要採用的工具。

## 先前的建議
| 來源 | 建議 | 狀態 (已執行 / 重複出現 / 未知) |

嚴重性：🔴 造成了實際工作損失或有損壞風險；🟡 浪費了時間或注意力；🟢 一個小習慣。

規則

• 僅限報告。 在使用者批准某個提案之前，不會寫入任何指令檔案、記憶或待辦事項；批准後則僅套用該項。
• 每個發現都要引用一個時刻。 如果你無法指出一個具體時刻，就放棄這個發現。
• 不要誇大： 三個真實的發現勝過十個空洞的發現，而「這個工作階段進行得很順利」本身也是一個有效的結果。
• 教練建議是為了使用者的利益， 因此必須直言不諱；預設情況下也是私密的，所以不要將其放入使用者未要求分享的任何內容中。
• 平實、可執行的語言： 每個項目都要寫得讓未參與該工作階段的人或代理能夠據以行動。將某個做法描述為一種行為（某人做了什麼以及達成了什麼效果：「指定結果，而非解決方案」），永遠不要使用工作階段中創造的綽號（如「被隱藏的解決方案」、「懷疑論者」、「憑感覺」）；如果簡稱有助於識別，請在完整名稱後以括號附上。測試方法：同事能否將這句話複製到自己的指南中並遵循？
• 簡潔： 一個粗體標籤，接著一行證據，然後是原因。如果一個發現需要一整段才能說清楚，那它要不是兩個發現，就是還沒被理解透徹。目標是每個部分不超過一個螢幕的長度。
• 教訓與摩擦的區別： 教訓是你可以告訴另一個專案的另一個代理的內容；僅適用於此工作階段的內容則是摩擦，應歸入發現中，而不是納入常設規則的提案。