指令长、多部分、高风险或指代含糊（这个、那个…

在投入实质性工作前，验证自己对用户指令的理解是否与请求者意图一致。

适用场景

解决思路

1. 识别信号：指令很长或包含多个部分、范围或指代含糊、措辞刻意留有灵活性，或风险高到猜错就要付出真实工作代价时，先做理解核对。
2. 用不同的话在心里把指令复述一遍；不要照抄用户原话再把它当作“已经理解”。
3. 把复述结果与可得上下文交叉核对（当前消息、会话历史、项目记忆、磁盘上的文件、既有约定），寻找矛盾、缺失的先行词，或上下文无法在两种合理解读之间做出选择的点。
4. 如果上下文已经解决了理解问题，就静默继续；不要拿上下文已经回答的问题去让请求者确认。
5. 如果仍存在真实的分叉，只提出一个具体的澄清问题，并锚定在复述出的理解上；点明选项，不要问含糊的“这样对吗？”。
6. 对实质性工作，在开始前记录一行可留存的“理解为：……”日志，让后续读者能审计工作是否与确认过的理解一致。
7. 复述而非回音：改写证明你建立了对请求的模型；逐字重复证明不了什么。
8. 上下文能解决时就保持安静：默认的好结果是不可见的；对已解决或无歧义的请求还冒泡提问，属于缺陷。
9. 一次只抛一个分叉：存在多处歧义时，先抛出风险最高的那一个，而不是一次倒出一整张清单。
10. 绝不静默解决会改变工作形态的分叉。
11. 只记录重大承诺，不是每一轮：可留存的理解日志用于计划、多文件改动、不可逆操作，或新接手审查者可能需要审计的工作。
12. 开始工作前做验证：复述必须是改写；每个抛出的分叉确实是现有上下文未解决的；任何实质性工作都必须在静默通过与分叉解决两者之一发生之后才能开始。

适用边界 · 注意事项

• 不适用于核对世界性事实断言的真假（那是 factchk 的职责）——这里问的是“想表达什么”，而不是某个事实是否为真。
• 上下文已经明确解决、或不涉及重大投入的请求不要走提问流程，默认应静默通过，冒泡确认反而是缺陷。
• 不要每一轮都写“理解为：……”日志，该做法只用于计划、多文件改动、不可逆操作等重大承诺。