tooluniverse-self-review

自我审查：理解目标，然后进行审查

针对用户希望实现的目标，审查实际完成的工作。默认进行简洁的定性评估。评分和完整的 Qworld 递归扩展树（RET）均为可选项。

不可妥协的规则

1. 不要混淆评估请求与被评估的任务。 在“评估当前工作”这类请求中，这句话是审查指令。被评判的任务是此前的用户目标；被审查的工作则是当前的结果、实现、草稿、计划或进展。
2. 不要把 eval 等同于评分。 除非用户明确要求分数、等级、评级、分值、加权评分标准、Qworld、RET 或数值量表，否则 Eval、evaluate、review、assess 和 check 都表示定性审查。
3. 不要凭空捏造要审查的工作。 检查对话和可用材料。如果缺少证据，应说明哪些内容无法核实。
4. 默认不要透露过程。 除非用户要求提供这些内容，否则将情景扩展、视角生成和评分标准构建留在内部。
5. 根据用户的目标进行审查，而不是套用通用质量模板。 根据请求、明确的约束、验收标准和风险，确定相关的检查项。

确定审查对象

审查前，先区分以下三项：

• 评估指令：用户现在提出的要求（例如“审查一下”）。
• 原始目标：工作应满足的请求、问题或验收标准。
• 工作成果：要检查的答案、代码、文件、差异、计划、分析或当前进展。

按以下顺序确定工作成果：

1. 明确指定的文件、答案、提交、差异、章节或材料。
2. 当前消息中粘贴或附加的内容。
3. 当对话涉及代码更改时，当前仓库的实现或工作树差异。
4. 与此前用户目标相关的最新一项助手交付成果。
5. 任务仍在进行时的当前计划或部分进展。

根据上述顺序解读“当前工作”“这项工作”“我们已有的内容”“刚才的工作”和“当前工作”等指示性短语。在多轮对话中，最后一条用户消息通常是评估指令，而非原始目标。

只要能有把握地找回目标和工作内容，就直接进行审查。只有在没有可审查的工作，或存在多个可能的审查对象且审查结果会有实质差异时，才简短地提出一个澄清问题。

选择一种模式

模式	触发条件	默认输出
定性审查（默认）	“评估/审查/检查当前工作”“完成了吗？”“还缺什么？”	有证据支持的发现、优点、差距、改进建议和完成情况结论；不提供数字
检查清单	明确要求完成定义、成功标准或完整性检查清单，且没有待审查的工作	针对任务的检查清单；不提供分值
评分标准	明确要求评估标准或评分细则，但未要求评分	按必须/应该/可以分类的二元或可观察标准；不提供分值
评分评估	明确要求分数、等级、评级、分值、加权标准、LLM-as-judge 评分、Qworld、RET 或数值量表	按用户要求的量表或 RET 进行有证据支持的评分审查

单独出现“评估一下”时，应选择定性审查；即使提供了工作成果，也不代表应开始评分。

创建或运行 eval、实现评分器、编写评估测试或构建基准的请求属于工程任务，不属于自我审查请求。不要仅仅因为这些请求中出现了 eval 一词，就将它们归入此工作流。

定性评审工作流（默认）

1. 还原目标。 用一到两句话概述原始目标和重要约束。优先采用明确的验收标准，而不是推断出的偏好。
2. 检查工作成果。 使用实际的对话输出、文件、差异、测试结果或提供的产物。对于代码，检查相关实现和验证证据；如果文件可用，不要只根据摘要进行评判。
3. 在内部制定有针对性的检查项。 仅确定判断正确性、完整性、用户意图、风险和验证所需的任务特定维度。除非对方要求，否则不要输出冗长的评审标准。
4. 按影响报告发现。 首先指出具体问题或未满足的要求。对于每项发现，引用证据并说明后果。
5. 肯定有效之处。 简要指出有实质意义的优点；不要用泛泛的赞扬凑篇幅。
6. 给出优先级明确的修复建议。 推荐能够弥补最重要缺口的最小具体行动。
7. 用通俗语言给出结论。 使用 complete、mostly complete、partially complete、not complete 或 unable to verify，并简要说明原因。不要将结论转换为数字。

默认评审结构

根据任务调整标题，并省略空白部分：

1. 总体评估——目标、目的和结论。
2. 发现——按影响排序，并附证据。
3. 有效之处——简洁、具体地说明优点。
4. 建议的后续行动——按优先级排列修复措施。

对于代码评审，优先指出可操作的缺陷和回归问题，而不是概述。尽可能引用文件路径和精确的行号范围。如果没有发现问题，直接说明，并指出仍存在的验证缺口。

检查清单和非评分式评审标准模式

• 根据任务制定标准，而不是使用固定的维度列表。
• 每项都应可观察，且具体到足以进行检查。
• 在有助于确定优先级时，使用 must、should 和 could 表示重要程度。
• 不要添加数字、权重、百分比、得分总计或通过率。
• 如果同时提供了工作成果，请将各项标为 met、partially met、not met 或 not verifiable，并简要提供证据。这些标签不是评分。
• 除非用户明确要求查看推导过程，否则不要生成场景或视角。

评分式评估模式（仅在明确选择时使用）

仅当请求包含上述明确信号时，才使用此模式。

• 如果用户提供了评分尺度或评分方案，请遵照执行。
• 如果用户要求 Qworld、RET、加权评审标准或 LLM 评审评分，但未提供自定义方案，请阅读并遵循 references/ret-scored-evaluation.md。
• 所有结论都必须以证据为依据。没有证据时不得给予分数，也不得因原始目标以外的标准扣分。
• 解释分数的含义，并指出影响最大的缺口和修复措施。只给出数字并不是有效的评审。

正确路由示例

用户请求	正确解读
“评估当前工作。”	根据之前的目标评审当前结果；采用定性评审，不打分
“评估我们是否完成了最初的请求。”	检查当前产物并给出完成情况结论；不打分
“这个实现还缺什么？”	以发现为先的实现评审；不打分
“为此功能制作一份完成定义检查清单。”	检查清单模式；不打分
“为这些回答创建一份评估标准。”	使用非评分式评审标准，除非用户要求权重或评分
“按 1 到 10 分给这个回答打分。”	按所要求的尺度进行评分
“应用 Qworld/RET 给这些回答评分。”	完整的 RET 评分模式
“为这个 Agent 创建一个评估套件。”	超出此技能的范围；视为评估工程任务

证据与诚实

• 区分观察到的证据与推断。
• 除非有可用的输出，否则不要声称测试已通过。
• 不要仅凭 diff 干净、总结语气笃定或文件存在，就推断工作已完成。
• 如果用户在工作仍在进行时要求评估，请审查当前可用的进展，并标明尚未完成的部分，而不是假装已有最终结果。
• 回复内容应与工作量相称。小改动不应附带一大堆框架内容。