上一篇我们探讨了 Generator + Critic 双模式，许多读者看完后第一个问题就是：Critic 究竟依据什么来做评测？
答案其实很简单：评分标准（Rubric）。注意，它并非一句笼统的质量要求，而是一份你提前编写好的、可逐条核查的验收清单。Agent 天生不具备判断“什么是好结果”的能力，它只能依据你设定的规则进行生成、检查和修正。Rubric 写得越清晰，Generator 与 Critic 之间的协作成本就越低；Rubric 写得越含糊，后续的自动修复就越像在碰运气。
模糊期望是 Agent 最大的敌人
给 Agent 一个模糊的任务，它就会返回一个模糊的结果。这并不新鲜。但许多人在引入 Critic 之后，仍然犯同样的错误：用模糊的标准来做评审。
比如这样的 Rubric：
检查测试用例是否完整、质量是否足够高。
这句话连人类都很难判断，更不用说 Agent。“完整”是什么意思？“足够高”的边界在哪里？Critic 拿到这个标准，只能凭感觉打分，等于没有标准。
问题不在于 Critic 不够聪明，而在于它缺乏可核查的判断依据。它看不到你脑海中的预期，只能根据文本中的规则做出判断。如果规则本身没有边界，Critic 就会把许多看起来差不多的结果都放过去，Generator 也不知道下一轮应该改进哪里。
好的 Rubric 长什么样
好的 Rubric 有一条硬标准：每一条都能被独立地回答“是”或“否”，不依赖主观感受。
仍以测试用例为例，把上面那句模糊的话拆开并重写：
- 是否包含正向用例？（至少 1 条）
- 是否包含逆向用例？（至少 1 条）
- 是否包含边界值用例？（至少 1 条）
- 每条用例是否有明确的预期结果？
- 用例之间是否存在重复的测试逻辑？
每一条都有明确的判断依据。Critic 对照这张清单逐条核查，无需发挥、无需猜测你的意图。
这里的关键是把抽象词汇拆解成可验证的条件。例如，“完整”可以拆分成正向、逆向、边界、异常、重复校验；“质量高”可以拆分成预期结果明确、步骤可执行、数据可复用、断言可观察。只要条目能被逐项检查，Critic 的反馈就会从主观评价转变为结构化验收。
Rubric 的三个层次
实际使用中，Rubric 可以按三个层次来设计：
- 必须项（Must）：不满足直接打回，不进入下一轮。
- 应该项（Should）：不满足则扣分，但不一定触发重试。
- 加分项（Nice to have）：满足则更好，不满足不影响通过。
必须项控制底线，应该项引导质量，加分项为优秀输出留有空间。三层分开定义，Critic 才能给出有意义的反馈，而不是简单地“通过”或“打回”。
这套分层非常适合融入 Agent 工作流。比如在测试用例生成中，必须项可以是覆盖关键业务路径、包含明确断言、不遗漏边界值；应该项可以是数据命名清晰、用例之间没有明显重复、步骤便于维护；加分项可以是补充风险说明、标记优先级、给出可自动化建议。这样一来，系统不会因为一个小表达问题反复重跑，也不会放过真正影响结果质量的缺口。
反馈要指向问题，不要只给结论
Rubric 决定了 Critic 的评分依据，但 Critic 反馈给 Generator 的内容，决定了下一轮能否改对。
只给结论没有用，比如：“测试用例不合格，请重新生成。” Generator 不知道哪里不合格，只能重跑一遍，大概率出同样的问题。
有效的反馈应该指向具体条目：
第 3 条未满足：缺少边界值用例。第 5 条未满足：用例 2 和用例 4 的测试逻辑重复。
Generator 拿到这个反馈，才知道下一轮该改什么。
更进一步，反馈里最好同时包含三类信息：失败条目、失败证据、修复范围。失败条目告诉它哪条规则没过，失败证据告诉它为什么没过，修复范围告诉它只修改相关部分，不要把已经合格的内容推倒重来。否则 Generator 很容易为了修一个点，顺手改坏其他已经通过的内容。
Rubric 也需要迭代
很多人以为 Rubric 写一次就足够了。实际上，第一版 Rubric 几乎一定是不完整的。
常见的问题有两种：一是漏掉了重要的判断维度，导致 Critic 放行了本不该通过的输出；二是某些条目定义过于宽松，形同虚设。
比较好的做法是，在 Agent 运行一段时间后，把那些 Critic 通过但人工审核觉得不对的案例收集起来，逐条对应到 Rubric，看哪条没有拦住，然后补充。Rubric 越跑越准，和写自动化测试的思路是一样的。
这里最有价值的不是把 Rubric 写得越来越长，而是把它写得越来越准。每次迭代都应该回答一个问题：这条规则能否拦住真实的失败案例？如果不能，就需要补充边界、示例或失败条件；如果能，但经常误伤正常结果，就要放宽触发条件，或把它从必须项降为应该项。
小结
Rubric 不是一句描述期望的话，而是一张可以逐条核查的清单。它的质量直接决定了整个 Generator + Critic 模式能否真正发挥作用。
当你想让 Agent 稳定产出时，不要只告诉它目标，还要告诉它验收标准；不要只让 Critic 打分，还要让它指出具体失败项；不要指望第一版 Rubric 一步到位，而要把人工复核中发现的问题持续沉淀回规则中。这样，Agent 才会从一次性生成，慢慢变成可检查、可修正、可迭代的工作流。
