Rubric Is All You Need

从论文《Rubric Is All You Need》出发，依次拆解了三种基于 Rubric 的 LLM 评估 Agent的设计思路，厘清了 Rubric 与传统 Test Harness 的互补关系，并进一步延伸至 Vibe Coding 时代的三种落地玩法——Rubric 驱动提示词、双 Agent 自我修复循环、以及以 RDD 取代 TDD。在 AI 大规模生成代码的今天，定义好 Rubric，比写好代码本身更重要。

unted_pooh

• 8 min read
Share

Rubric Is All You Need：用定制化评估准则重构代码质量体系

当AI开始写代码，谁来审查AI？

一、一个老问题，一个新时代

在日常工程研发或技术筛选中，有一个长期存在的痛点：如何高效、准确地评估一段代码的质量？

传统自动化测试平台的答案是"跑测试用例"——编译通过、输出匹配，就算合格。这套逻辑看似严谨，却极其刻板：少一个分号、边界条件触发异常，一段业务逻辑完全正确的代码就会被打上零分。

这种"非黑即白"的评判方式，显然不符合人类工程师做 Code Review 的习惯。我们真正在乎的，是逻辑是否通顺、架构思路是否正确、边界场景有没有覆盖到——而不是语法有没有拼错。

大模型时代到来后，自然有人想到：让 LLM 来做代码评估。但早期尝试往往让人失望——给 LLM 一个通用标准（"请评估这段代码的复杂度、可读性和整体正确性"），得到的结果不仅颗粒度极粗，还频繁出现幻觉。

问题出在哪？出在通用标准本身。

二、核心洞察：从"通用标准"到"定制化 Rubric"

论文《Rubric Is All You Need: Improving LLM-based Code Evaluation With Question-Specific Rubrics》给出了一个极具工程落地价值的答案：抛弃通用标准，拥抱特定问题评估准则（Question-Specific Rubric）。

什么是 Rubric？

Rubric 源自教育评估领域，是一种详细的"计分量表"或"评估准则"。

在代码评估的语境下，我们可以这样类比：

类型 类比 特点
通用 Rubric 公司通用代码规范 命名清晰、复杂度低……泛而不精
特定问题 Rubric 针对当前需求的逻辑拆解清单 逐步拆分、有权重、可量化

举个例子，针对一道"两数之和"的算法题，特定问题 Rubric 会明确规定：

  • 第一步：初始化哈希表 → 得 1 分
  • 第二步：双指针遍历 → 得 2 分
  • 第三步：正确处理边界条件（空数组、无解情况）→ 得 1 分

研究团队发现，当给 LLM 提供这种极其具体、按步骤拆解的定制化 Rubric 时，其评估准确度和反馈有效性将发生质的飞跃。

三、架构拆解：三种工程化评估 Agent

为了将 Rubric 落地，研究团队设计了三种不同策略的评估 Agent，分别适配不同场景。

Agent 1：CRE（Complete Rubric Evaluation）—— 全量评估流

工作方式：将"需求描述 + 完整 Rubric + 待测代码"一次性喂给 LLM，输出结构化 JSON 评分结果。

核心特性：

  • 单次 API 调用，Token 消耗低，速度快
  • LLM 以全局视角理解代码，能像人类一样给予"步骤分"或"部分正确分"
  • 宽容度高，最贴近资深工程师做 Code Review 的直觉

适用场景：日常合并请求（PR）的初筛，快速判断代码逻辑方向是否正确。

Agent 2：PRE（Pointwise Rubric Evaluation）—— 逐点精准阻击

工作方式：将完整 Rubric 拆碎，每次只将单一条目连同整段代码发给 LLM，只做 Yes/No 的二元判断。

核心特性：

  • 多次 API 调用，资源消耗大
  • LLM 注意力被强行收束在单一指标上，评判极其严苛，几乎不给同情分
  • 零容忍，适合对逻辑严谨性要求极高的场景

适用场景：核心交易链路的合规检查、安全敏感逻辑的审查。

Agent 3：EME（Ensembling Method Evaluation）—— 多模型集成共识

工作方式：引入多个异构模型（如 GPT-4o、Claude 等）同时进行 Rubric 评估，最终通过多数投票得出结论。

评估前，会先让 LLM 识别目标代码采用的是 Rubric 中的哪一种解法（暴力解？动态规划？），再让各模型独立打分——有效消除单一模型的幻觉和偏见。

适用场景：逻辑极复杂的算法或业务场景，单一模型容易产生误判时。

三种 Agent 的核心差异一览：

Agent 调用次数 宽容度 核心优势 典型场景
CRE 1 次 高 速度快，全局视角 PR 初筛
PRE N 次 低 精准严苛，逐条核对 合规检查
EME N×M 次 中 多模型共识，抗幻觉 复杂算法评估

四、概念辨析：Rubric 与 Test Harness 是什么关系？

在理解了 Rubric 的价值之后，有一个关键问题需要厘清：Rubric 是要取代传统测试台（Test Harness）吗？

答案是否定的。它们是正交的互补关系，各自守护代码质量的不同维度。

Test Harness（测试台）

  • 本质：可执行的动态运行环境，包含启动脚本、Mock 数据、预设输入输出用例
  • 关注点：程序的状态与结果——代码必须能编译、能跑通，且输出必须与预期字节级一致
  • 局限：无法评估代码是怎么写的。一段全是硬编码的屎山代码，只要输出了正确结果，Harness 就会判定 Pass

Rubric（评分准则）

  • 本质：基于语义和逻辑的静态审查标准，是一组结构化的自然语言约束
  • 关注点：程序的意图、逻辑结构与业务完整性
  • 优势：能看懂代码的"灵魂"。一段逻辑精妙但因拼写错误导致编译失败的代码，Harness 给 0 分，但 Rubric 体系下的 LLM 会识别出其正确意图并给予高分反馈

两者的协同方式

CI/CD 流水线
├── Test Harness  →  物理正确性兜底（能不能跑）
└── Rubric Agent  →  逻辑与设计质量把控（好不好、有没有漏）

Harness 保底线，Rubric 保上限。 两者结合，才是完整的代码质量防线。

五、范式迁移：Rubric 在 Vibe Coding 时代的高阶玩法

如今，越来越多的开发者开始实践 Vibe Coding——用自然语言描述意图，依靠 AI 编程助手（Cursor、GitHub Copilot 等）生成具体代码。

Vibe Coding 极大提升了编写速度，但带来了一个致命问题：代码失控。

当你通过几轮对话生成了包含上千行逻辑的复杂组件时，你怎么知道 AI 没有遗漏关键的边缘逻辑？仅凭肉眼 Review 已经变得不切实际。

这正是"特定问题 Rubric"大展身手的地方。

玩法一：Rubric 驱动的提示词工程（RDP）

不要对 AI 说：

❌ "帮我写一个购物车结算逻辑。"

而是对 AI 说：

✅ "请按照以下 Rubric 编写购物车结算逻辑：

  1. 必须处理库存并发扣减问题（权重高）
  2. 必须计算会员等级折扣（权重中）
  3. 异常状态必须抛出自定义的 CartException（权重高）"

先定义 Rubric，再让 AI 写代码——这能极大收敛 AI 的发散性，提高一次性生成可用代码的成功率。

玩法二：闭环的自我修复（Self-Healing Loops）

在 Vibe Coding 工作流中引入 PRE（逐点评估）机制，构建双 Agent 的对抗与协作循环：

生成阶段  →  Agent A 根据需求生成代码
    ↓
评估阶段  →  Agent B 拿着 Rubric 逐条核对，输出精准 Feedback
    ↓
修复阶段  →  Feedback 回传给 Agent A 针对性迭代
    ↓
重新评估  →  直到所有 Rubric 条目达标

这种机制能让纯自然语言驱动的开发变得可靠和可预测。

玩法三：从 TDD 到 RDD（Rubric 驱动开发）

在写 Harness 测试用例成本极高的场景（复杂 UI 交互、依赖众多第三方系统的聚合接口），我们可以换一种思路：

不写传统 Unit Test，而是写一份结构化的 JSON Rubric。

将验证逻辑的责任从"机器执行层"上移到"LLM 语义理解层"。这是 AI 辅助开发时代下，敏捷开发的一种新形态——Rubric-Driven Development（RDD）。

六、结语

《Rubric Is All You Need》虽然是一篇面向教育场景的代码评估论文，但其背后的系统设计思想可以直接复用到工程实践中。

面对日益普及的 AI 生成代码，我们需要两道防线：

  • Test Harness：确保代码能跑，守住物理正确性的底线
  • Rubric 评估机制：提供具备高级工程师视角的语义审查，守住逻辑与设计质量的上限

将两者结合，或许正是我们在走向 Vibe Coding 和全托管 AI 开发时代时，保持代码质量不降级的关键密码。

当 AI 开始大规模生成代码，能驾驭 AI 的工程师，将是那些懂得如何定义好 Rubric 的人。