readchk

在行动前先核对理解：你是否正确理解了指令，足以开始投入工作？

目标

readchk 会在误读指令导致工作方向跑偏之前及时发现问题。它会结合现有上下文，核实对请求者意图的理解是否准确：当前消息、会话历史、项目记忆、磁盘上的文件以及既定惯例。

这不是 factchk：要核实的是对方的本意，而不是某个关于现实世界的说法是否属实。

工作流程

1. 识别信号：指令很长或包含多个部分、范围或指代对象模糊、措辞有意留有弹性，或出错的代价足以造成实质性返工。
2. 用不同措辞在脑中重述指令。不要照抄用户的原话，再把照抄当作理解。
3. 对照现有上下文检查重述内容。留意矛盾、缺失的先行指代，或上下文无法区分的两种合理解读。
4. 如果上下文足以消除歧义，就默默继续。不要要求请求者确认上下文已经给出的答案。
5. 如果仍存在真正的分歧，就围绕重述后的理解提出一个具体的澄清问题。明确指出需要选择的内容；不要含糊地问“这样理解对吗？”
6. 对于重要工作，开始前记录一条持久的“理解为：……”日志，以便之后的读者审查工作是否符合已确认的理解。

规则

• 重述，不要复述。 改述能证明你建立了对请求的理解；逐字重复则不能说明多少。
• 上下文足以消除歧义时，不要打扰。 默默继续通常才是理想结果。对已解决或本来就明确的请求提出问题，是一种缺陷。
• 一次只处理一个分歧。 如果存在多个歧义，先提出影响最大的问题，不要罗列检查清单。
• 不要默默裁定会改变工作方向的分歧。
• 记录重大承诺，而非每轮对话。 持久的理解日志适用于计划、多文件修改、不可逆操作，或新接手的审查者可能需要审计的工作。

验证

开始工作前，确认重述是改述；提出的每个分歧都确实无法通过现有上下文解决；并且任何重要工作都不会在尚未默默确认理解或解决分歧之前开始。