代码生成比拼：函数正确率 vs 测试通过率

52JinY 助手

过去一年里，我在内部做了几轮代码生成评测，最直观的结论是：函数级“正确率”和项目级“单元测试通过率”这两套指标，经常给出相互矛盾的信号。很多人爱用某平台的“函数是否与参考实现一致”来打分，但一落到真实仓库、跑起测试套件，分数就会打回原形。这不是指标谁更“高级”的问题，而是它们关注的切面不同。

先说函数

级正确率。很多评测把它等同于“和参考实现逐行一致”或者“样例输入输出一致”。这类指标的好处是便宜、可重复、可横向比较；坏处也明显：它忽略了上下文依赖、隐藏约束和边界协议。比如一个 JSON 解析函数，在独立评测里喂几组常见样例就稳稳过线；可一接到真实项目里，上下游约定了严格的错误码语义、时区处理、甚至日志格式，哪怕主体逻辑八九不离十，也会因为一个异常类型不匹配而让集成测试全红。

再看单元测试通过率。它更接近“工程真实度”，能把依赖管理、接口契约、并发时序、I/O 抖动统统纳入考量。但它同样有噪声：测试是否覆盖关键路径？断言有没有误报？测试夹具是不是在消耗者视角写的？我见过“100% 通过”的仓库，点开一看是把易碎的断言全部放宽成了“返回非空即可”；也见过函数级正确率平平，但在严苛测试下依旧稳过的模型，因为它在不确定处倾向于显式失败而非静默容错，反而契合了团队的失败策略。

更微妙的是，两者在优化目标上会形成张力。函数正确率鼓励“贴近参考”的最短路径，倾向于复刻已有实现；测试通过率鼓励“契合环境”的鲁棒性，可能促使模型引入额外检查、重试与超时，代码风格更冗余。前者利于榜单成绩，后者利于生产落地。把二者揉成一个分数，常见的结果是既失去区分度，也失去可解释性。

我的做法是把评测拆解成三层：函数层、契约层、场景层。

函数层只看纯逻辑正确与边界处理：给出最小上下文、明确输入输出、覆盖等价类与典型异常。这里我更喜欢“多元参考”的打分：不设唯一金标，实现只要满足性质测试（property-based）和约束即可过；同时统计风格警告与复杂度，避免把“会跑的意大利面”当成高分。函数层的目标是判断“这段逻辑在抽真空条件下是否站得住”。

契约层关注模块间约定是否被忠实履行：类型与协议（包括错误码、幂等、超时、

重试语义）、资源清理与可观测性（日志、指标、追踪）。这里不关心具体算法实现，而是看“接口是否可被安全使用”。评测办法上，可以通过契约测试+故障注入来逼出边角：比如模拟下游超时、半成功响应、幂等键冲突，观察调用方是否退避、是否重复提交安全。契约层的目标是回答“把它接进系统，会不会把别人坑死”。

场景层

场景层则把评测搬到贴近生产的端到端流程：真实依赖、真实数据规模、真实部署拓扑下跑关键用例。这里不追求覆盖所有路径，而是挑选“最贵的失败”和“最常见的成功”两类路径，例如：高并发下的批量导入、跨服务的资金记账、数据落地与回滚、跨时区调度。这一层的度量不再是单一通过率，而是多维SLA