上一篇聊了 Generator + Critic 双模式，很多读者看完之后的第一个问题是：Critic 怎么知道该怎么评测？
答案是 Rubric。它不是一句泛泛的质量要求，而是你提前写好的评分标准。Agent 不是天生知道什么叫写好了，它只能根据你给出的 验收口径 去生成、检查和返工。Rubric 写得越清楚，Generator 和 Critic 之间的协作成本越低；Rubric 写得越含糊，后面的自动修复就越像碰运气。
模糊期望是 Agent 最大的敌人
给 Agent 一个模糊的任务，它会给你一个模糊的结果。这不是新鲜事。但很多人在引入 Critic 之后，还是犯同样的错误：用模糊的标准来评审。
比如这样的 Rubric：
检查测试用例是否完整、质量是否足够高。
这句话对人来说都很难判断，更别说 Agent。完整是什么意思？足够高的边界在哪里？Critic 拿到这个标准，只能凭感觉打分，等于没有标准。
问题不在于 Critic 不够聪明，而在于它没有 可核查的判断依据。它看不到你脑子里的预期，只能根据文本里的规则做判断。如果规则本身没有边界，Critic 就会把很多看起来差不多的结果都放过去，Generator 也不知道下一轮应该改哪里。
好的 Rubric 长什么样
好的 Rubric 有一个判断标准：每一条都能被独立地回答是或否，不依赖主观感受。
还是以测试用例为例，把上面那句话拆开重写：
评分标准：
1. 是否包含正向用例？（至少 1 条）
2. 是否包含逆向用例？（至少 1 条）
3. 是否包含边界值用例？（至少 1 条）
4. 每条用例是否有明确的预期结果？
5. 用例之间是否存在重复的测试逻辑？
每一条都有明确的判断依据。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 才会从一次性生成，慢慢变成可检查、可修正、可迭代的工作流。