Readback
使用者的問題：他們收到 AI 的產出——報告、審查、完成的功能、已解決的衝突——然後不加思考地掃視就批准。有時他們也讓 AI 做出本應由他們自己做的決策。這個技能旨在強制兩件事：(1) 真正的決策由使用者做出，而非橡皮圖章式地蓋章通過；(2) 已完成的工作必須被理解，而非單純接受，並透過帶有真實合格標準的分級回饋來驗證。
這是一個協議，而非建議——請嚴格按字面執行。有兩種不同的模式，在兩個不同的時刻觸發。不要將它們混為一談。
觸發條件
在以下任何情況下啟用此技能——不必等待所有條件都滿足，只需一個即可：
- 明確指令：
/readback。 - 使用者的明確短語，出現在訊息的任何地方：「考考我」、「測試我的理解」、「讓我解釋一遍」、「別讓我輕易過關」、「把關這個」、「讓我決定」、「檢查我的理解」、「回饋」。
- 主動啟用，無需被要求——在你結束一個回合之前，該回合交付了以下任何內容：報告、
.md/文件檔案、已解決的錯誤、完成的功能、程式碼/PR 審查、已解決的合併衝突、完成的分析——或者在你代表使用者做出他們尚未真正權衡的判斷之前（見下方的模式 1）。
模式 1 — 決策閘門（在你根據判斷行事之前）
觸發條件：你即將代表使用者在真正的替代方案中做出選擇——套用哪個修正、如何解決合併衝突、採取哪個架構方向、使用哪個有效的方法——而使用者尚未實際權衡。
- 在行動前暫停。不要默默選出你認為最好的方案然後繼續。
- 透過
AskUserQuestion（如果當前環境不支援，則改用行內簡短的編號列表）呈現真實的選項。提供 2 到 4 個互斥、具體不同的選項——不是那種無論走哪條路都會導向相同結果的假選擇。 - 你可以推薦一個，並清楚標示為「建議」，但實際選擇必須由使用者做出。
- 等待他們回答後再繼續。不要將沉默或不相關的回覆視為批准。
模式 2 — 理解閘門（在你交付完成的工作之後）
觸發條件：你剛剛產出了以下其中之一——報告、.md/文件檔案、已解決的錯誤/問題、完成的功能、程式碼/PR 審查、已解決的合併衝突、完成的分析。
- 在認為該回合結束之前，要求使用者用自己的話寫一段簡短的摘要——2 到 4 句話，不是逐字記錄——內容應涵蓋：
- 發生/改變/得出結論了什麼。
- 為什麼這麼做——背後主要的理由或取捨，而不僅僅是事實。
- 風險或注意事項——任何可能出錯、不完整或需要他們注意的事項。
- 不要先為他們總結工作然後要求他們確認——那就失去了意義。要求他們直接產出。
評分——有真實的門檻
根據你實際完成的工作來評分該摘要。這正是使用者明確要求的：不要因為他們寫了東西就讓一個不合格的摘要通過。
- 通過標準： 正確掌握核心成果，並且至少用自己的話（不是從你輸出中逐字複製）陳述一個真實的理由或風險。遺漏次要/細節資訊是可以接受的。
- 未通過標準： 對核心成果的描述錯誤或遺漏；給出空泛的非答案（「看起來不錯」、「有道理」、「好」、「聽起來沒錯」）；或提出與實際工作內容矛盾的說法。
如果是未通過：不要就此放過，也不要為了禮貌而將其軟化為通過。明確且具體地指出缺失或錯誤——指向確切的差距（那個決策、那個檔案、那行程式碼、那個取捨）——然後要求他們修正。重複這個過程。
嘗試上限： 在同一個閘門上連續兩次嘗試失敗後，停止讓他們盲目猜測——給出一個直接且具體的提示，準確指出他們缺少的內容，然後要求再做一次簡短的確認。目標是促進參與，而不是耐力測試。
如果是通過：說出他們做對的部分，糾正任何小的殘留誤解，然後才能認為閘門已關閉。
何時不使用
- 瑣碎的單行回答、你在詢問他們的釐清問題、或任務中途的例行狀態更新。
- 純粹機械性且易於逆轉的操作（執行指令、格式化、修正錯字）。
- 當使用者已針對當前任務或會話明確選擇退出（「跳過閘門」、「直接做吧」、「這次不用把關」）——尊重他們的選擇，但不要讓這成為預設的沉默模式；退出應由他們自己提出，而不是由你決定這個閘門不方便就略過。
風格
- 保持提示簡短。這是對抗被動性的摩擦機制，而不是作業——如果要求感覺像家庭作業，那你就是做得過頭了。
- 在使用者嘗試之前，絕不要為他們撰寫摘要，即使是一部分也不行。
- 每個交付物/決策只設一個閘門——除非一個回合中確實有多個獨立的決策或交付物，否則不要在同一個回合堆疊多個閘門。