这次我们不聊某个具体模型而是聊一个很容易被忽略的工程现象当你要在两个代码实现之间分胜负时用 LLM 生成的测试作为评判标准结论可能会因为测试集不同而反转。A 实现和 B 实现都能跑通需求看代码也都合理但 LLM 生成的一组测试可能让 A 胜出换一组提示词重新生成赢的又变成 B。这不是偶然误差而是测试集本身自带生成偏差。本文要讲清楚三件事为什么 LLM 生成的测试能改变实现选择怎么量化这种偏移以及如何在项目里设计一套更公平的评测协议。如果你平时在多个实现之间做选型或者正在用 LLM 写单元测试这篇文章可以收藏。1. 核心信息速览先把全文的关键信息压缩成一张表方便你不看细节也能快速判断这篇文章对你的价值。维度说明问题本质LLM 生成的测试集带有生成偏好会掩盖或夸大不同实现之间的差异影响路径覆盖盲区、断言强度、测试重复、实现信息泄漏主要场景代码实现选型、LLM 生成代码的评测、回归测试、代码评审判断标准变化换一组 LLM 测试后胜者可能从 A 变成 B应对策略黑盒测试生成、多模型交叉生成、独立测试集、人工复核落地方式pytest / JUnit CI 流水线 LLM 接口调用脚本适合读者用 LLM 写单测的开发者、做代码模型评测的研究者、做选型决策的架构师一句话概括如果你想公平比较两个实现不要把 LLM 生成的测试当作“中立尺子”要先验证测试集本身有没有偏袒某一方。2. 为什么测试集能决定实现胜负很多人默认测试是客观的但测试从来不是中立尺度。测试定义了一个假设空间它只检验实现的一部分行为。两个实现差异最大的地方往往不是正常路径而是边界条件、异常处理、资源清理和极端输入。测试集覆盖到哪个角落哪个角落的优势才会被看见。2.1 测试与实现的“双向适应”传统测试往往由人根据需求和接口文档编写测试与实现之间保持一定距离。LLM 生成测试改变了这个距离。当 LLM 在读实现代码的基础上生成测试时测试点会不自觉地向实现已有的行为模式靠拢这会让某些实现更容易“过测”。而在比较多个实现时这种适应是不均匀的。实现 A 的代码结构更贴近 LLM 训练时的常见模式生成出来的测试就会更容易命中它的行为实现 B 用了另类写法测试反而暴露它在边界处理上的真实问题。于是“谁赢了”很可能变成了“谁的写法更接近 LLM 的训练分布”。2.2 Goodhart 定律在评测中的表现经济学里有一条 Goodhart 定律当某个指标变成目标它就不再是好指标。套用到这里就是当某个测试集成为实现之间的竞争标准时这个测试集本身就开始失真。LLM 生成测试把这条定律放大了因为生成过程会受到提示词、采样温度、上下文长度、目标代码风格等多重影响。同一份需求文档你用不同的 LLM 生成测试得到的是不同概率分布的测试用例用同一模型但温度从 0 调到 1也会得到行为差异明显的测试套件。实现还是那两个实现代码一行没改胜负却可能翻转。这个现象说明的核心问题是你拿来做决策的测试集本身就是一个需要被评估的变量。2.3 生成测试改变了评审重心人工评审实现时大家习惯讨论时间复杂度、可读性、扩展性LLM 生成测试则把注意力集中到“哪些用例能跑通”。这种重心转移本身没有对错问题是如果测试生成偏重某种模式评审结论就会被带偏。比如 LLM 倾向于生成大量异常输入测试那么异常处理更健壮的实现会占优如果 LLM 倾向生成极端性能数据那么快速路径更优的实现会占优。理解了这一层再去看“LLM-generated tests can change which implementation wins”这个标题它就不是一句结论而是一个需要被控制的变量。3. LLM 生成测试的生成机制在讨论如何规避偏差之前先看 LLM 生成测试的完整链路。通常有三种输入模式。3.1 三种生成输入模式模式输入偏差风险黑盒生成需求文档、接口规格覆盖正常路径容易遗漏隐式约束白盒生成具体实现源码测试会被实现带偏对同实现更友好规范驱动生成形式化规范、旧测试集较稳定但依赖规范质量黑盒生成的优势是测试和实现解耦适合做多实现比较。白盒生成适合做针对性回归但如果用它来分胜负天然的偏向性会比较强。在实际项目里常见做法是先用黑盒生成测试再用白盒补覆盖。3.2 提示词设计示例下面给一个黑盒测试生成的提示词模板核心是要求模型只看需求文档不接触实现源码。GENERATE_TEST_PROMPT 你是资深测试工程师。请根据下面的需求文档编写单元测试。 需求文档 {requirement} 约束 1. 不能查看或假设任何具体实现代码。 2. 测试必须覆盖正常路径、边界值、异常输入三类场景。 3. 使用 pytest 风格断言必须明确具体。 4. 每个测试用例都要标注覆盖意图。 5. 只输出测试代码不要解释。 要求格式 注意这里的关键约束是“不能查看实现代码”。如果测试生成阶段读到了实现源码后续用它来判断实现胜负就会产生信息泄漏结论不可信。3.3 生成-运行-修复循环LLM 并不是一次就能生成可运行的测试代码完整链路通常是根据需求文档生成测试代码。在目标实现上运行测试收集语法错误和执行失败。把失败信息反馈给 LLM要求修复。迭代到测试套件可执行为止。这个循环同样会影响最终测试集。模型在修复过程中会看到越来越多的失败信息这些信息来自某个特定实现于是测试集会进一步偏向该实现的行为路径。因此比较实现时最好先和实现无关地修复测试的语法错误再用测试去跑各实现。4. 影响胜负判定偏移的关键因素即使走完生成链路测试集偏差依然藏在几个细节里。我看过不少出现“测试集翻转结论”的案例最终都能归到下面四类因素。4.1 覆盖盲区LLM 生成的测试覆盖路径并不均匀。它可能对条件表达式、空值输入、网络异常覆盖得很充分但遗漏了并发、时间戳、状态顺序这类行为。如果实现 A 的优势恰好落在盲区里测试集就会系统性低估它实现 B 的弱点也落在盲区里它就被系统性高估。判断测试集是否公平不能只看总通过率要按模块、按行为域拆开看覆盖分布。谁在哪个域占优、谁在哪个域吃亏要比一个简单总分有价值得多。4.2 断言强度与断言偏向LLM 生成的断言经常出现两类问题断言过弱和断言过强。过弱断言只检查返回值不为空实现就算算错也能通过过强断言则绑定了实现内部的中间过程比如检查某个私有函数被调用次数这种测试天然偏向某种实现风格。公平的比较应该是测试断言只验证需求层面的可观察结果不绑定内部实现细节。生成之后需要人工扫一遍把绑定内部实现的断言改掉。4.3 实现信息泄漏这是最隐蔽的一个因素。当测试生成过程接触到具体实现代码LLM 会根据该实现的行为调整测试预期。比如实现里注释写着“输入为负数时返回 -1”LLM 就会把这个行为写成断言但需求文档里可能根本没规定负数场景该返回什么。于是测试实际上是在“复述实现的行为”而不是“检验需求是否符合”。避免信息泄漏的办法很简单比较实现时测试只能从需求文档和接口定义生成不能让生成器看到任何候选实现。理想的评测是“盲测”。4.4 测试重复与状态污染LLM 生成多轮测试时很容易生成重复覆盖同一个正常路径的用例却遗漏真正有区分度的边界场景。此外如果测试用例之间存在共享状态比如同一份临时文件、同一个全局缓存执行顺序会改变结果。这种状态下测试失败并不是实现的错而是测试自身不稳定。批量生成测试后要先去重、隔离状态再拿去跑实现比较。测试执行必须是可重复的否则结论没有任何参考价值。5. 设计中立化评测协议要把“测试决定胜负”这个变量控制住不能只靠运气而是需要一套协议。核心思路是把测试生成和实现评估拆成两个独立环节。5.1 建立独立测试池第一步先建立一个与所有候选实现无关联的测试池。测试池来源有三类需求文档派生的黑盒测试。历史回归测试。人工编写的关键场景测试。这三类测试混在一起按需求覆盖面切分。这样做的好处是任何单一模型的生成偏好都不会直接决定结果。5.2 多模型交叉生成用多个模型生成测试时不要把多个模型的测试合并成一个大套件就完事而是要让每个模型生成的测试单独作为一套测试集分别去看候选实现的表现。这样你能看到“哪个实现最稳定地赢”和“哪个实现只在特定测试集下赢”。如果 A 在三个模型生成的测试集上都赢你的信心会强很多如果 A 只在其中一个模型下赢那很可能是测试偏差在起作用。5.3 人工审核清单人工审核不需要逐行检查每条测试而是按清单抽查。审核重点包括断言是否绑定内部实现、是否覆盖了需求中的异常边界、是否存在重复用例、共享状态是否清理、超时设置是否合理。一份可直接套用的审核清单检查项通过标准断言验证结果只验证需求可观察行为不验证内部函数调用边界值覆盖正常、边界、异常三类用例都覆盖用例去重同一路径至少保留一条代表性用例状态隔离每个用例可独立重复执行执行超时无明显死循环风险超时时间已设置5.4 胜率与稳定性指标不要只打印一个“A 通过 80%B 通过 75%”就下结论。更合理的指标是胜率矩阵每个测试集上A 和 B 的通过率差异是什么差异有多大多轮生成下差异是否稳定。用差异分布而非单一平均值来下判断。6. 验证实验判断测试集是否偏袒某方协议说再多不如一个可以复现的实验。下面给一个通用的验证实验设计用来检验“当前这个 LLM 测试集是否偏袒某一实现”。6.1 实验流程选取两个候选实现功能等价但实现路径不同。使用同一份需求文档通过黑盒方式生成三套测试集分别来自三个不同模型或三种不同提示词。每套测试集分别跑两个实现。计算每套测试集下两个实现的通过率差异记录差异是否统一。如果采用多轮生成同一模型可以生成多套温度分别取 0.2、0.7、1.0观察结果稳定性。6.2 评判伪代码以下代码是通用模板你需要把它适配到自己的测试框架上。核心思路是分离“测试生成”和“结果评估”两个阶段避免互相污染。import json import subprocess from pathlib import Path def run_tests(implementation_path, test_path): result subprocess.run( [pytest, test_path, --tbno, --json-report], capture_outputTrue, textTrue, cwdstr(implementation_path), timeout120, ) return result.stdout def evaluate(impl_a, impl_b, test_path): result_a run_tests(impl_a, test_path) result_b run_tests(impl_b, test_path) stats_a parse_pytest_report(result_a) stats_b parse_pytest_report(result_b) return { test_suite: Path(test_path).name, pass_rate_a: stats_a[passed] / stats_a[total], pass_rate_b: stats_b[passed] / stats_b[total], delta: (stats_a[passed] / stats_a[total]) - (stats_b[passed] / stats_b[total]), } # 每个模型生成的测试都单独跑一次不要合并 test_suites [suite_model_a, suite_model_b, suite_model_c] for suite in test_suites: print(evaluate(./impl_a, ./impl_b, suite))6.3 异常结果判读如果所有套件都指向同一个胜者结论相对可靠。如果套件之间出现了以下差异就要警惕测试偏差A 在套件 1 胜出B 在套件 2 胜出。A 在某个套件下做到接近 100% 通过在另一个套件下只有不到 50% 通过。某一套测试把所有实现都甩到极低通过率说明测试生成本身有问题。这三种情况都说明测试生成过程引入了实现之外的变量用单个测试集合下结论是不安全的。7. 在项目中落地 LLM 生成测试验证完协议真正落地到项目里还需要流程和配置支持。下面给出一个比较通用的落地路径。7.1 从生成到回填的完整流程建议按照下面这个顺序操作准备需求文档把它整理成接口定义级别的规格。用多模型生成测试每个模型独立输出测试套件。执行初步静态校验检查语法和命名冲突。人工审核断言强度与覆盖缺失。将所有测试套件放入独立目录不放在实现仓库里。对每个候选实现运行全部测试套件输出差异报告。根据差异报告人工决策而不是让测试通过率自动决策。流程记录和日志很重要。每个测试套件要记录模型名、提示词版本、生成时间和最终执行结果。这样出现结论争议时可以回溯是哪一层生成了偏差。7.2 接入 CI 流水线当测试生成和评估流程稳定后可以接入 CI。下面是一个通用 Jenkins 流水线片段你按实际环境调整pipeline { agent any stages { stage(Generate Tests) { steps { sh python scripts/generate_tests.py --config config/eval.json } } stage(Run Evaluation) { steps { sh python scripts/evaluate.py --config config/eval.json } } stage(Publish Report) { steps { sh python scripts/report.py --output-dir ./eval_reports } } } }核心点是测试生成和评估是流水线中的不同阶段。若测试生成失败但评估还在跑结果不可用。7.3 评测配置文件示例{ requirement_path: ./docs/requirement.md, models: [ gpt-4o, claude-3.5, deepseek-v3 ], implementations: { impl_a: ./src/impl_a, impl_b: ./src/impl_b }, test_framework: pytest, output_dir: ./eval_results, timeout_seconds: 120 }这里的模型列表需要替换为你实际可用的模型服务。配置单独存放方便以后扩展更多的候选实现或测试模型。7.4 在评测中加入性能观察LLM 生成测试本身也会带来耗时成本。评测时除了看通过率还要记录三类资源指标每个测试集生成耗时。每个测试集在两套实现上的执行耗时。失败用例的重试次数。如果某个模型生成的测试频繁卡在超时或死循环说明生成质量不稳定要降低它的结果权重。性能和稳定性本身就是评测协议的一部分不能只看最终通过率。8. 常见问题与排查LLM 生成测试在对比实现时容易遇到下面这些问题。问题现象可能原因排查方式解决方案同一实现换提示词后通过率大幅波动测试生成对提示词敏感对比各提示词生成的用例覆盖差异固定提示词模板并做多轮交叉验证LLM 生成的测试大量语法错误输出格式不稳定检查生成模型能力与上下文长度增加修复循环或换成代码生成能力更强的模型所有实现都几乎 100% 通过断言过弱或生成测试偏向正常路径人工抽检断言质量统计边界覆盖加强提示词对异常输入的约束补充人工用例A 在套件 1 胜B 在套件 2 胜测试生成覆盖偏向不同观察两个套件覆盖分布按行为域拆分测试不再看总分测试运行顺序影响结果共享状态污染检查日志中的执行顺序测试隔离加入 fixture 清理生成测试时触发了 LLM 幻觉接口模型编造不存在的函数将运行报错反馈给模型增加编译/运行校验重新生成某个模型生成的测试总是偏袒实现 A模型训练数据中 A 风格代码更多检查测试是否绑定内部实现改用黑盒生成删除内部实现相关断言这类问题和普通单元测试调试很不一样问题往往不在实现而在测试生成链路本身。一旦开始怀疑“测试是不是有问题”优先检查测试生成时的提示词和输入范围而不是先怀疑实现代码。9. 最佳实践与下一步最后给几条可以直接抄走的经验。第一第一次做这类比较时先不要大规模生成测试。选两个实现用同一个需求文档分别用三个模型生成测试跑一遍交叉验证先看是否存在“胜负反转”。如果没有反转再扩大规模如果有说明当前评测协议不可靠。第二把测试生成和实现评估的代码分目录管理不要混在同一个仓库里。测试生成脚本、测试套件、评估报告各放一个目录方便复现和回溯。第三人工审核的重点不是所有测试而是断言强度和关键边界值。用抽查的方式找到绑定内部实现的断言把它改成需求层面的约束。第四做实现选型时结论不要只依赖 LLM 生成的测试要把历史回归测试、人工补充场景和需求建模测试都纳入比较。最终结论依据交叉验证的稳定性而不是某一个测试集下的分数。第五凡是涉及生成代码、测试脚本、比较结果的工具和配置都要记录版本。以后出现结论争议时可以快速定位是模型版本、提示词版本还是配置版本发生了变化。下一步可以做的事情也很明确把这里的中立化评测协议做成一个自动化工具接入 CI每次有新实现候选时自动跑多模型交叉验证。这比手动挑选测试集要稳定得多也更容易防止选型被生成偏差带偏。建议把这篇的方法整理成团队内部测试规范第一次跑通后后续的成本就很低了。