Back to Details

readchk

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Check the read before acting: did you understand the instruction correctly enough to spend the work?
行动前先确认理解：你是否足够准确地理解了指令，值得投入工作？

Goal

目标

readchk
catches misread instructions before they become coherent work against the wrong target. It verifies a claim about the requester's intent against available context: the current message, session history, project memory, files on disk, and established conventions.
This is not 
factchk
: the question is what was meant, not whether a world claim is true.
readchk
用于在错误理解指令导致针对错误目标开展有效工作之前，及时发现误读情况。它会对照可用上下文（当前消息、会话历史、项目记忆、磁盘文件以及既定惯例）验证关于请求者意图的判断。
这不是
factchk
：核心问题是请求者的意图是什么，而非某个事实陈述是否真实。

Workflow

工作流程

  1. Recognize the signal: a long or multi-part instruction, ambiguous scope or referents, deliberately flexible wording, or stakes high enough that a wrong guess would cost real work.
  2. Restate the instruction internally in different words. Do not copy the user's wording back to yourself and treat that as understanding.
  3. Cross-check the restatement against available context. Look for contradictions, missing antecedents, or two plausible readings that context cannot choose between.
  4. If context resolves the read, proceed silently. Do not ask the requester to confirm what the available context already answered.
  5. If a real fork survives, surface one specific clarifying question anchored to the restated understanding. Name the choice; do not ask a vague "does this look right?"
  6. For substantial work, log one durable "understood as: ..." line before beginning so a later reader can audit whether the work matched the confirmed read.
  1. 识别信号：当指令篇幅较长或包含多个部分、范围或指代模糊、表述刻意灵活，或错误猜测会导致大量返工的高风险场景时。
  2. 在内部用不同的语言重新表述指令。不要直接照搬用户的表述来自我欺骗，认为自己已经理解了。
  3. 将重新表述的内容与可用上下文进行交叉核对。查找矛盾点、缺失的指代对象，或上下文无法区分的两种合理解读。
  4. 若上下文解决了理解问题，则直接执行。不要要求请求者确认已有上下文已经明确的内容。
  5. 若确实存在无法解决的歧义，基于重新表述的理解提出一个具体的澄清问题。明确指出需要选择的选项，不要问模糊的“这样看起来对吗？”
  6. 对于重要工作，开始前记录一条明确的“理解为：……”内容，以便后续审阅者可以核查工作是否符合已确认的理解。

Rules

规则

  • Restate, don't echo. A paraphrase proves you built a model of the request; a verbatim repeat proves little.
  • Silent when context resolves it. The default good outcome is invisible. Surfacing a question for a resolved or unambiguous request is a defect.
  • One fork at a time. If several ambiguities exist, surface the highest-stakes one first instead of dumping a checklist.
  • Never silently resolve a fork that changes the shape of the work.
  • Log large commitments, not every turn. Durable read logs are for plans, multi-file changes, irreversible actions, or work a fresh reviewer may need to audit.
  • 重新表述，而非重复。 意译能证明你对请求建立了正确的认知模型；逐字重复则几乎无法证明理解。
  • 上下文能解决时保持静默。 默认的理想结果是无需额外沟通。对已明确或无歧义的请求提出问题是一种缺陷。
  • 一次处理一个歧义。 若存在多个模糊点，先处理风险最高的那个，而非一次性列出所有待澄清项。
  • 绝不能悄悄解决会改变工作性质的歧义。
  • 记录重大承诺，而非每次互动。 明确的理解记录适用于计划、多文件修改、不可逆操作，或需要新审阅者核查的工作。

Verification

验证

Before proceeding with the work: the restatement is a paraphrase, every surfaced fork is genuinely unresolved by available context, and no substantial work starts without either a silent pass or a resolved fork.
在开展工作前：重新表述的内容必须是意译，所有提出的歧义确实是上下文无法解决的，且重要工作必须在静默确认或歧义解决后才能开始。