错题本 × LLM：人机协作如何炼成“最严代码考官”

大家好，我是肆〇柒。在 vibe coding 活跃的当下，有时，我们不得不思考一个问题：在软件开发流程中，我们能否完全依赖、使用 LLM 生成的代码？大型语言模型（LLM）在代码生成基准测试中的卓越表现备受瞩目，从 HumanEval 到 LiveCodeBench，众多基准测试平台见证了 LLM 在代码生成任务上的飞速进步。然而，随着 LLM 日趋融入软件开发，其生成代码的质量和可靠性评估变得更加关键，因为这影响着生产落地应用的品质和服务价值。

那么，代码验证作为衡量 LLM 生成代码质量的核心环节，其评估方法的可靠性，直接影响着我们对模型性能的认知，以及强化学习从可验证奖励（RLVR）框架的有效性。但遗憾的是，当前主流代码生成评估基准存在显著局限性，这不仅高估了 LLM 的性能，还使得 RLVR 框架中的奖励估计存在偏差。为此，上海人工智能实验室联合西安交通大学等机构的研究者，系统地研究了测试用例生成（TCG）任务，提出了多维度量化测试套件全面性的指标体系，并引入“人 - LLM 协作”方法 SAGA（Strategic Adversarial & Constraint-differential GenerAtive workflow），显著提升生成测试用例的覆盖率和质量。并且还开发了 TCGBench，助力 TCG 任务研究。

实验表明，SAGA 在 TCGBench 上将验证器准确度（Verifier Accuracy，VAcc，衡量测试套件能否一次性拒绝所有已知错误解的指标）提升了 15.86%，基于 SAGA 的 CodeCompass 基准测试使模型 Pass@1 相对下降 9.56%，重塑了模型性能排行榜。这项研究已开源 TCGBench 和 TCGCoder-7B，期望推动 RLVR 研究发展。

这个研究非常有意思，我欣赏到的是一场 AI 原生的“定义任务”-“制定评估”-“人机交互”的一次研究实战。这抛开研究课题内容本身，对于自己落地 AI，很有借鉴意义。下面我们一起来看看研究历程。

现有代码验证方法的缺陷

主流代码生成评估基准存在诸多不足，这些缺陷可能导致我们对 LLM 性能的评估过于乐观，许多潜在错误未被发现。以下是现有代码验证方法的主要缺陷：

测试用例覆盖不足

主流代码生成评估基准的测试用例数量有限且同质化严重。HumanEval 平均每个问题仅提供 7.7 个测试用例，MBPP 每个问题仅提供 3 个，EvalPlus 尽管增加了测试数量，却导致通过率骤降 15%，暴露出测试用例覆盖面不足、同质化严重的问题。

LLM 生成测试用例的偏差

LiveCodeBench 利用 LLM 生成大量测试用例，在提升测试效率方面具有显著优势。然而，其生成的测试用例存在明显偏差，倾向于反映 LLM 自身的典型、同质化错误模式，而人类编程错误则更加多样化，涵盖逻辑错误、整数溢出等多种复杂情况。这种偏差导致 LLM 生成的测试用例难以有效检测人类编写的错误代码。

下图（a）显示，LLM 验证器对人类代码的漏检率显著高于 LLM 代码。下图（b）则揭示，LLM 诱导错误高度聚集，而人类错误分散。横纵坐标为前两主成分，LLM 错误呈 “致密团簇”（红色），人类错误呈 “星云状”（蓝色）。距离越近代表错误模式越相似，可见 LLM 测试用例对 “团簇外” 的人类错误几乎无感知。这进一步凸显了现有验证器在应对多样化错误模式时的不足，强调了改进测试用例生成方法的必要性。

(a) LLM 验证器对人类代码漏检率高；(b) LLM 错误模式分布与人类错误模式分布对比

既然“测得越多≠测得越好”，我们就需要一套更精细的尺子，来衡量“怎样才算测得足够好”。下面，我们先给出这套尺子的刻度——TCG 任务的正式定义与多维指标。

测试用例生成任务的形式化定义与多维度评估指标

带着“尺子”的诉求，我们先把 TCG 任务放在放大镜下：它到底要解决什么问题，又该用什么刻度来评价？

TCG 任务定义

多维度评估指标

为更精准衡量测试套件质量，提出以下多维度评估指标：

至此，我们有了刻度，下一步自然要问：现有方法到底离“刻度满分”还有多远？下面我们来了解一下三大主流范式。

现有 TCG 范式

在探讨三种范式之前，我们先通过一张图直观对比它们的流程差异。

代码评估流程与多种 TCG 范式

图中清晰展示了：

• 直接生成（Direct Generation）
• 输入解释器（Input-Interpreter）
• 人类先验（Human Priors，即本文中的 SAGA 方法）

三者在输入来源、输出验证方式上的关键区别。

直接生成范式

直接生成范式通过直接提示 LLM 生成完整测试用例，包括输入和输出。然而，这种方法对 LLM 的深度理解能力要求极高，尤其是对边缘情况的把握。实验结果显示，LLM 生成的测试用例保留率低，整体 DR 通常低于 60%，VAcc 低于 10%，且 LLM 生成的解决方案容易通过自身生成的测试用例，表明这些测试用例难以挑战模型的认知偏差。例如，在生成复杂算法（如图算法、动态规划算法）的测试用例时，直接生成范式往往难以覆盖所有关键路径和边界条件，导致生成的测试用例质量较低。

下图（a）展示了 LLM 直接生成的测试用例质量低，下图（b）显示了其高自通过率，这表明 LLM 生成的测试用例存在明显不足，难以有效检测代码中的错误。

 (a) LLM 直接生成测试用例质量低；(b) LLM 生成测试用例高自通过率

输入解释器范式

输入解释器范式由 LLM 生成随机输入，再由真实解释器计算对应输出。虽然这种方法可以生成大量测试用例，但单纯增加数量无法根本提升检测率，因为测试用例之间存在相关性。通过理论推导和实验验证，我们发现，随着生成的测试用例数量 n 趋近于无穷大，在平均检测概率 p 和平均正相关 p eff 稳定的情况下，检测率的上限收敛于 。这表明，测试用例的相关性限制了检测率的提升。例如，在测试一个数学计算函数时，输入解释器范式生成的测试用例可能集中在某些特定的数值范围或计算模式内，导致无法有效检测出在其他数值范围或计算模式下的错误。

下图（a）显示，随着测试用例数量增加，检测率逐渐饱和，无法达到 100%。下图（b）进一步表明，检测率与测试用例数量的对数呈半对数关系，验证了相关性对检测率提升的限制。

(a) 检测率随测试用例数量增加而饱和；(b) 检测率与测试用例数量的对数关系

Human Priors 范式（人类先验）

Human Priors 范式利用人类的正确解决方案和错误解决方案来指导 LLM 生成测试用例。与前两种范式相比，该方法能够更好地结合人类的编程经验和 LLM 的语义理解能力，通过人机交互，从而生成更高质量的测试用例。

三大范式对比

经验告诉我们：单靠 LLM 或单靠人类直觉都不足以突破天花板。在 LLM 性能日趋强大的今天，我们可以尝试“人机协作”，把二者拧成一股绳——这就是 SAGA（Strategic Adversarial & Constraint-differential GenerAtive workflow）。

SAGA：人 - LLM 协作的 TCG 框架

研究者提出 SAGA，正是为了回答“如何利用人类知识，却不被人类知识的速度和规模所限”这一关键问题。

SAGA（Strategic Adversarial & Constraint-differential GenerAtive workflow）是一种创新的人 - LLM 协作框架，致力于生成高质量、多样化且具有区分性的测试套件。该框架通过结合人类编程见解与 LLM 推理，充分利用正确解决方案和错误提交中的信息，以指导 LLM 构建挑战性测试输入。

工作流程

SAGA 的工作流程如下：

1. 输入阶段 ：SAGA 接收编程问题描述、正确解决方案以及错误提交。

2. 分析阶段 ：SAGA 对正确解决方案进行多维度分析，提取约束处理差异和防御模式解构等关键信息；同时对错误提交进行差异分析，找出约束处理差异、防御完整性缺失和失败模式。

3. 生成阶段 ：SAGA 利用提取的信息指导 LLM 构建挑战性测试输入，并生成相应的测试用例。

4. 验证阶段 ：通过自验证脚本验证生成的测试用例是否符合问题约束和测试策略，确保测试用例的有效性和准确性。

下图展示了 SAGA 框架的整体架构，包括输入、分析、生成和验证等阶段，体现了其人 - LLM 协作的特点。

SAGA 框架架构

多维度分析与差异分析

多维度分析从正确解决方案中提取深刻见解以设计挑战性测试，主要涵盖约束处理差异和防御模式解构两个方面：

• 约束处理差异 ：比较错误解决方案 Swrong 和正确解决方案 S′ 在处理问题特定约束上的差异，发现测试用例中约束条件的薄弱环节，从而设计出更能暴露错误的测试用例。例如，在一个资源分配问题中，正确解决方案可能严格遵循资源限制条件，而错误解决方案可能在某些情况下超出资源限制。通过分析这种差异，可以生成专门测试资源限制条件的测试用例。
• 防御模式解构 ：将正确解决方案中的防御逻辑和问题解决策略分解为正式的数学或逻辑约束，如 “等价类：玩家配对”，“边界值：[(1,2), (N,N−1)]”，使 SAGA 能针对奇点、极端值或特定结构属性生成边缘和对抗性测试用例，提升测试用例的多样性和针对性。例如，在一个网络请求处理函数中，正确解决方案可能对各种异常请求（如超大请求、非法格式请求）进行了完善的防御处理。通过解构这些防御模式，可以生成相应的异常请求测试用例，验证代码在面对恶意攻击或异常输入时的鲁棒性。

差异分析通过对比错误提交 Swrong 与其修正版本 S′ correct，发现常见错误模式。主要关注以下几点：

• 约束处理差异 ：找出 Swrong 和 S′ correct 在处理问题特定约束上的差异。例如，在一个数据处理任务中，错误提交可能未正确处理数据的完整性约束，而修正版本则修复了这一问题。通过分析这种差异，可以生成专门测试数据完整性约束的测试用例。
• 防御完整性缺失 ：揭示 Swrong 在处理边缘情况或边界输入方面的不足。例如，错误提交可能未对极端输入值（如非常大或非常小的数值）进行有效的处理，导致程序崩溃或产生错误结果。通过差异分析，可以发现这些缺失的防御措施，并生成相应的边缘输入测试用例。
• 失败模式分析 ：生成能触发 Swrong 失败但被 S′ correct 正确处理的特定输入，将这些输入纳入测试套件 T，增强验证器的区分能力。例如，错误提交可能在处理并发访问时存在死锁问题，而修正版本通过优化锁机制解决了这一问题。通过失败模式分析，可以生成特定的并发测试用例，验证代码在高并发场景下的正确性。

自验证脚本

自验证脚本在确保生成测试输入符合问题约束和测试策略方面发挥着重要作用。它在执行前验证测试输入是否满足问题要求，如检查输入是否符合指定范围、格式等，从而提升生成测试用例的准确性和有效性，避免生成无效或不符合要求的测试用例。例如，在一个文件解析函数的测试中，自验证脚本可以检查生成的测试文件是否符合特定的文件格式规范（如 JSON 格式、XML 格式），确保测试用例的有效性。

SAGA 的优势

与传统 TCG 范式相比，SAGA 具备以下优势：

1. 高质量测试用例生成 ：通过结合人类编程见解与 LLM 推理，SAGA 能够生成更高质量的测试用例，有效提升测试套件的检测率和验证器准确度。

2. 多样化测试用例 ：SAGA 的多维度分析和差异分析能够生成多样化的测试用例，覆盖更广泛的错误模式，降低测试用例之间的相关性。

3. 适应性强 ：SAGA 对不同的 LLM backbone 具有良好的适应性，即使使用较小的模型也能取得优异的性能。

SAGA 的实验验证

通过实验验证 SAGA 框架在提升测试用例生成质量方面的有效性，并与现有方法进行对比，分析其优势和局限性，提出实验。

实验设置

在 TCGBench 上对 SAGA 进行了全面验证。TCGBench 汇集了来自 Atcoder、Codeforces 和 Nowcoder 的 1840 个近期编程问题，每个问题平均包含 36.66 个错误用户提交。我们采用了 DeepSeek-V3-0324、Qwen2.5-72B-Instruct 和 Qwen2.5-Coder-32B-Instruct 等开源 LLM 模型，并运用检测率（DR）、验证器准确度（VAcc）、不同错误模式覆盖率（DEPC）和多样性比率（Diversity Ratio）等指标进行评价。

关键发现与图表引用

实验结果显示，SAGA 在检测率、验证器准确度等关键指标上显著优于随机输入解释器基线及其单独分析组件。例如，在 270 道 TCGBench-Lite 难题上，SAGA 将 VAcc@50 从随机基线的 16.72% 提升到 32.58%，提升 15.86 个百分点，相当于让每三个原本蒙混过关的错误解中多抓出一个。其 AUC@50（0.5445）是基线的 2 倍。这表明 SAGA 能更有效地检测错误，生成更具区分性的测试用例。

下图（a）展示了 SAGA 在检测率上的表现远超基线和单独分析组件，下图（b）显示了 SAGA 在验证器准确度上的显著优势，下图（c）和下图（d）分别呈现了 SAGA 在不同错误模式覆盖率和多样性比率方面的优秀表现。

(a) SAGA 检测率表现；(b) SAGA 验证器准确度表现；(c) SAGA 不同错误模式覆盖率；(d) SAGA 多样性比率表现

进一步分析发现，SAGA 生成的测试用例在不同错误模式覆盖率和多样性比率方面也表现出色，能够更广泛地覆盖错误模式，降低测试用例之间的相关性，从而提高测试套件的整体质量。例如，在一个字符串处理函数的测试中，SAGA 生成的测试用例涵盖了各种字符串边界情况（如空字符串、超长字符串、包含特殊字符的字符串），而基线方法生成的测试用例则主要集中在普通字符串情况，未能有效覆盖边界情况。

消融实验

通过对 SAGA 进行消融实验，研究者深入分析了其各个组件对性能的影响。结果表明，多维度分析和差异分析组件的协同作用是实现 SAGA 优越性能的关键。以下是消融实验结果：

从表中可以看出，SAGA 对 LLM backbone 变化表现出良好的鲁棒性，即使使用较小的 Qwen2.5-Coder-7B 模型，也能取得与基线方法相媲美甚至更优的性能。这充分证明了 SAGA 框架的有效性和适应性。

下图展示了 SAGA 在不同 LLM backbone 下的性能表现，表明其在不同模型和问题来源下均能显著提升检测率和验证器准确度。

SAGA 在不同 LLM backbone 下的检测率和验证器准确度表现

基于 SAGA 的高级应用

带着实验验证的信心，研究者让 SAGA 直接“接管”了 270 道最新竞赛题，由此诞生了更严苛、更公平的全新基准——CodeComPass。

CodeComPass 基准测试

研究者基于 SAGA 开发了 CodeComPass，这是一个高质量的代码生成评估基准测试。与 LiveCodeBench-v6 相比，CodeComPass 在验证器质量、对代码生成模型评估的区分能力等方面实现了显著提升。例如，在共享子集上，CodeComPass 的 DR@40 比 LiveCodeBench-v6 高出 14.59 个百分点，VAcc@40 高出 10.78 个百分点，多样性比率高出 43.13%，AUC@40 高出 43.4%。这些提升表明，CodeComPass 能更准确地评估代码生成模型的性能。

CodeComPass 在不同难度问题上的平均 Pass@1 表现

上图显示了 CodeComPass 在不同难度问题上的平均 Pass@1 表现，表明其对模型性能的区分能力更强。下图则展示了模型在 CodeComPass 和 LiveCodeBench-v6 上的排名变化，凸显了 CodeComPass 能更细致地揭示模型之间的性能差异。

模型在 CodeComPass 和 LiveCodeBench-v6 上的排名变化

对 RLVR 的影响

SAGA 生成的高质量验证器显著提高了 RLVR 框架的准确性。通过提供更准确的奖励信号，SAGA 减少了奖励欺骗现象，使模型在训练过程中能更真实地反映其性能。例如，在使用 SAGA 生成的测试套件进行训练时，模型在复杂编程问题（如图算法问题、动态规划问题）上的性能提升更为显著，代码生成的正确性和鲁棒性得到增强。这为开发更强大、更可靠的代码生成模型奠定了基础。

至此，从“发现问题”到“定义刻度”再到“交付工具”，我们已经跑完一个完整闭环。这就是一个关于“评估”的研究案例。

总结

本文重新审视了基于 LLM 的 TCG 方法，通过构建 TCGBench、提出 SAGA 框架以及开发 CodeComPass 和 TCGCoder-7B 等实际举措，为提升 LLM 代码评估的可靠性提供了切实可行的方案，提升了 RLVR 的性能，也为自动化对抗测试合成和自适应基准整合奠定了基础。这些成果在优化代码生成评估方法、提高模型训练效率和增强代码生成质量方面具有重要意义。

如同我在文章开头所说的那样，这份研究真正吸引我的是研究者对“方法论”的演示。这对于我们在 AI 应用中的“评估”设计以及落地，具有较高的参考价值。以下是我的一点学习后的观感，分享给大家：

把“评估”做成产品：一次 AI 原生的方法论演练

如果把这篇论文只看成一个“更高明的测试用例生成器”，就低估了它的示范价值。它真正精彩的，是把“评估”本身当成一个可迭代、可度量、可规模化的 AI 产品——从任务定义、指标设计、数据构造、算法框架到最终交付，形成了一条AI-native 的闭环。下面我用五个关键词，把这条闭环抽出来，供任何想在垂直场景落地 AI 的同学做一点参考，如果你觉得我说的不对，我希望能与你成为“觉察流”的社区伙伴，我们一起探讨、进化。

1. 痛点溯源：把“感觉不对”翻译成“指标不对”

• 现象 HumanEval 看似 80+ 分，实则在 LeetCode 真·评测机上 20 %～40 % 的题被打出 WA（Wrong Answer）。
• 翻译 不是模型菜，而是“测试用例的检测率 / 验证器准确度”这两个维度被严重高估。

启发：先别急着改模型，先改“尺子”。把“我觉得测试不够”翻译成可计算的 DR（Detection Rate） 与 VAcc（Verifier Accuracy），问题立刻有了抓手。

2. 任务定义：把“测试生成”升格为 TCG 任务

• 输入：问题描述 + 题解空间 + 历史 WA/TLE（Time Limit Exceeded） 代码
• 输出：用例集 T
• 目标：最大化 DR（检测率） & VAcc（验证器准确度），同时最小化测试冗余， 也就是≈ 最小化 （平均有效相关系数，可以理解为“测试之间不要互相抄答案”）。

启发：用一句话把任务写成“带约束的优化问题”，后面就能用算法和数据来解。

3.据工厂：把公开平台变成“错误市集”

• 从 AtCoder / Codeforces / Nowcoder 抓 1840 道最新题 + 36.66 条真实错误提交 / 题
• 人工去噪，但不人为写用例——让数据保持“野生”分布

启发：高质量数据不必从零标注；把公开资源“切一刀”就能变成科研级数据集（TCGBench）。这一招可复制到任何带评测记录的开源社区。

4. 人机协作：让 LLM 做“放大器”，人类做“瞄准镜”

SAGA 人机协作中，有个很妙的点，就在于双向蒸馏：

• 正向蒸馏：从 AC（Accepted） 代码里提炼“等价类 + 边界值 + 防御模式” → 告诉 LLM “该往哪打”。
• 反向蒸馏：从 WA（Wrong Answer） 代码里提炼“错误触发路径” → 告诉 LLM “别人在哪儿跌倒”。最后让 LLM 写脚本、写解释、写自检，完成大规模、低人力的对抗用例仓库。

启发：与其让 LLM 瞎猜，不如用“人类错题本”给它装一个导航系统（指导作用）；既解决规模，又保留人类经验。

5. 产品化交付：把“论文指标”变成“行业基准”

• CodeComPass：270 道最新题 + 50.54 个 SAGA 用例 / 题 —> 直接替换 LiveCodeBench 子集，立刻让排行榜重排座次。
• TCGCoder-7B：用 15 k 题蒸馏出 7 B 小模型，推理成本降一个量级，效果却吊打 70B 通用模型。

启发：评估基础设施一旦做成“即插即用”的组件，就能反过来喂养训练、评测、产品迭代的全链路。

把“测得更准”升级为“做得更对”

当你把评估工具做成产品，它就不仅是“扣分器”，而成了持续改进的飞轮：

• 对研究者而言：TCGBench + CodeComPass 提供了可复现、可对抗的科研沙盒；
• 对工程师而言：SAGA 用例脚本可以直接嵌入 CI（持续集成），让每一次 PR 都跑在更严苛的测试上；
• 对 RL 训练者而言：更准确的奖励信号让模型不再“钻测试空子”，而是真正学会“写对代码”。

这正是 AI 时代的方法论：把“主观经验”转成“可计算指标”，把“人力痛点”转成“数据红利”，把“一次性实验”转成“可持续迭代的系统”。

所以，我的理解，SAGA 是一套可迁移的模板。那么，，下一次，无论你是做表格理解、药物发现还是硬件验证，都可以复现这条“定义任务 - 设计指标 - 人机协作 - 数据闭环 - 产品化交付”的步骤。

一句话：评估不是成本，而是杠杆；把它做到极致，剩下的就只是时间问题了。