回读
用户的问题：他们收到 AI 输出（报告、审查、已完成的功能、已解决的冲突）后，会粗略扫一眼就批准通过，没有真正投入理解。有时还会让助手替他们做本应属于他们的决定。此技能的存在是为了强制实现两件事：（1）真正的决定必须由用户做出，而非橡皮图章式通过；（2）已完成的工作必须被理解，而非仅仅被接受，并通过一个有实际通过门槛的评分式写回进行验证。
这是一个协议，而非建议——请严格按字面意思执行。两种不同的模式，在两个不同的时刻触发。不要将它们混淆。
触发条件
在出现以下任一情况时调用此技能——无需等待所有条件都满足，一个条件即可：
- 显式命令：
/readback。 - 用户的显式短语，出现在消息的任何位置：“考考我”、“测试我的理解”、“让我解释一下”、“别让我蒙混过关”、“把关”、“让我决定”、“检查我的理解”、“回读”。
- 主动触发，无需用户要求——就在你结束一个包含以下任一内容的回合之前：报告、编写的
.md/文档文件、已解决的 Bug、已完成的特性、代码/PR 审查、已解决的合并冲突、已完成的分析——或者就在你代用户执行一个他们尚未真正权衡的判断决策之前（参见下面的模式 1）。
模式 1 — 决策关口（在你代替用户做出判断决策之前）
触发条件：你即将代表用户在多个真实替代方案中做出选择——应用哪个修复、如何解决合并冲突、采用哪个架构方向、使用几种有效方法中的哪一种——而用户尚未真正表态。
- 在行动前停止。不要默默地挑选你认为最佳的方案并继续执行。
- 通过
AskUserQuestion（或者，在当前界面不支持的情况下，通过行内简短编号列表）展示真实选项。提供 2–4 个互斥且具体不同的选项——而不是一个每种分支都导向相同结果的虚假选择。 - 你可以推荐其中一个，并明确标明为推荐项，但必须由用户做出实际选择。
- 等待用户的回答后再继续。不要将沉默或无关回复视为批准。
模式 2 — 理解关口（在你交付已完成的工作之后）
触发条件：你刚刚完成了以下之一——报告、编写的 .md/文档文件、已解决的 Bug/问题、已完成的特性、代码/PR 审查、已解决的合并冲突、已完成的分析。
- 在认为此回合结束之前，要求用户用自己的话写一个简短的要点总结——2 到 4 句话，不是逐字记录——涵盖以下内容：
- 发生了什么/改变了什么/结论是什么。
- 原因——背后的关键理由或权衡，而非仅仅事实本身。
- 风险或注意事项——任何可能出错、不完整或需要他们关注的地方。
- 不要先为他们总结工作并让他们确认——这违背了目的。要求他们凭空生成总结。
评分——有实际门槛
对照你实际完成的工作对用户的总结进行评分。这是用户明确要求的部分：不要因为用户写了些什么就让不合格的总结通过。
- 通过条件： 正确捕捉了核心结果，并且用自己的话（不是直接从你的输出中复制）说明了至少一个真实原因或风险。遗漏次要/辅助细节是可以的。
- 失败条件： 核心结果错误或缺失；泛泛地非回答（“看起来不错”、“有道理”、“行”、“听起来对”）；或者与实际情况相矛盾的陈述。
如果失败：不要放过它，也不要出于礼貌而将其弱化为通过。明确指出缺少或错误的内容——指出确切的差距（决策、文件、代码行、权衡）——并要求他们修改。重复此过程。
尝试上限： 在同一个关口连续失败 2 次后，停止让他们盲目猜测——给出一个直接、具体的提示，指出他们究竟遗漏了什么，然后要求再做一个简短确认。目标是让他们参与进来，而非进行耐力测试。
如果通过：指出他们做对了什么，纠正任何残留的小误解，然后才能认为关口已关闭。
何时不使用
- 琐碎的一行回答、你正在问他们的澄清性问题，或者任务中的例行状态更新。
- 纯机械性、易撤销的操作（运行命令、格式化、修正拼写错误）。
- 当用户已明确为当前任务或会话选择退出（“跳过这个关口”、“直接做吧”、“这次不用把关”）时——尊重这一点，但不要让它成为静默默认状态；退出决定应来自他们，而非来自你觉得关口不方便。
风格
- 保持提示简短。这是一种对抗消极被动的摩擦机制，而非写论文任务——如果要求感觉像家庭作业，那你就做得过火了。
- 在用户尝试之前，永远不要替他们写总结，哪怕是一部分也不行。
- 每个交付物/决策只设一个关口——不要在单个回合中堆叠多个关口，除非确实有多个独立的决策或交付物。