说明本文讨论的是 AI 编程评测从单点补全转向仓库级任务的工程含义属于评测范式与工程实践话题不涉及具体模型版本与价格。AI 领域版本迭代极快凡涉及版本号、价格、可用性请以你阅读时的官方页面为准。文中代码为结构示意请按自己的技术栈调整后再上生产。一、单点补全类指标为什么在真实工程里失去区分度在 2023 年前后「AI 写代码行不行」有一个被广泛接受的答案口径看它能不能补全下一段代码。做法是给一个光标位置或者给一句注释让模型写出中间缺失的片段再拿生成结果和参考答案比对算完全匹配率、编辑距离或者文本相似度。这套口径在当时是有区分度的因为多数系统连「写出一段能编译的代码」都做不到谁离参考答案更近谁就更强。到 2026 年中这个区分度基本消失了。原因不是评测方法退步是任务本身太窄。单文件、单函数、几十行上下文几个主流工具都能做对分数挤在一个很窄的区间里榜单只剩小数点后一位的差别。工程师拿榜单去选型经常出现这种情况榜单前几名之间的差距放进自己仓库里根本感觉不出来。窄任务上有四个具体的失真点值得逐条看。第一上下文太短。一次真实的改动需要的信息有一半在光标之外这个函数被谁调用、参数类型定义在哪个文件、配置从哪读进来、返回值里那个错误码由谁处理。单点评测把上下文截到几十上百行等于把这些约束全删了。模型只需要「猜出题人想写什么」不需要「读懂这个仓库」。第二没有跨文件依赖。真实工程里改一个函数签名往往意味着同时改三处调用点、改一处测试、改一处序列化定义。单点评测只测一个文件测不出「知不知道该去改哪里」——而这恰恰是仓库级任务里最难的一步。找文件通常比写代码难。第三答案不唯一判定却按文本相似度。同一个行为用 for 循环和用推导式都对用早返回和用嵌套 if 都对。文本相似度会把这些正确解判成低分反过来它也会把「长得像但语义不同」的解判成高分。最典型的是边界条件参考答案写候选写字符串只差一个字符相似度很高行为在边界上却完全不同。第四没有行为判定。语法正确、能通过解析器和「这段代码跑起来结果对」是两件事。一个补全可能漏掉空输入、漏掉异常分支、漏掉并发下的顺序问题这些在文本层面都看不出来。用一个最小的例子说明第三点为什么致命。⚠️ 代码待验证importdifflibdefscore(reference:str,candidate:str)-float:按文本相似度打分越接近参考答案分越高。returndifflib.SequenceMatcher(None,reference,candidate).ratio()referenceif count threshold:# 参考答案same_meaningif threshold count:# 语义等价只是写法不同off_by_oneif count threshold:# 差一个字符行为差一个边界print(round(score(reference,same_meaning),3))# 偏低但它是对的print(round(score(reference,off_by_one),3))# 偏高但它是错的这不是在说相似度算法写得差而是在说指标问了一个错的问题。它问的是「你写得像不像参考答案」工程真正关心的是「你改对没改对」。任务足够窄时两个问题答案高度重合指标看着好用任务一宽两者就分道扬镳。这里要分清一件事指标失去区分度不等于这些系统变弱了而是这类任务的天花板本来就低。一个只能写对单函数的系统和一个能在仓库里完成一次改动的系统在单点指标上可能只差零点几分。指标没测出它们的差别不代表差别不存在。拿这个差值去做选型等于用一把量程不够的尺子去量东西。维度单点补全口径真实工程需要上下文范围光标前后几十到上百行跨文件调用方、类型定义、配置依赖范围单文件一次改动牵动多个文件与测试判定方式与参考答案的文本相似度测试是否由失败转为通过答案唯一性默认唯一同一行为多种写法都算对二、仓库级评测由哪几块构成仓库级评测换了一个评测单元不再评「一段代码」而是评「在一个真实仓库里完成一次改动」。判定也跟着从「像不像」换成「测试过不过」。这个转变不是把难度调高而是把问题问对了。它由四块构成缺任何一块结论都会失真。可复现的运行环境。任务必须能在任何一台干净机器上还原容器镜像按摘要固定、依赖用锁文件进版本库、安装与测试命令写死在任务描述里。没有这一块分数就不可比——同一套任务A 机器能跑、B 机器跑不出结果差的是环境不是被评对象的能力。真实仓库快照。任务绑定到一个具体的提交而不是「某个项目的主干」。改动前的状态是冻结的这样每个任务才有唯一且可回溯的起点。用主干当起点任务会随仓库演进而漂移昨天的题今天可能已经无解。用测试通过替代文本相似度。判定不看代码长什么样只看两件事原来失败的测试是否变绿fail to pass原来通过的测试是否仍然绿pass to pass。第二件事常被忽略但它是防回归的关键——没有它一个把老功能改坏、只让新测试通过的提交会被判为满分。任务描述来自真实 issue。描述是「用户报的问题」或「提出来的需求」不是把 diff 反过来写成题目。这点决定了任务里是否保留真实工程的噪声信息不全、表述有歧义、需要自己去翻代码定位。把 diff 翻写成题目等于顺手把答案的位置也交代了。四块里第三块是范式转换的核心。文本相似度问的是「你写得像不像标准答案」测试判定问的是「你改对没改对」。换成后者评测从比文本变成比结果而结果可以被独立验证。判断一份仓库级评测报告够不够格看三样东西就够了任务来自哪些仓库、环境怎么还原、判定命令是什么。三样都给全这个结果别人可以独立复现缺任何一样它就只是一个孤立的数字不能拿来做决定。构成块它解决什么缺了会怎样可复现环境让结果与机器无关环境差异被错算成能力差异真实仓库快照起点唯一、可回溯任务随主干漂移过期无法重跑测试判定判「改对没改对」并防回归退回文本相似度正确解被判错来自真实 issue 的描述保留真实噪声与歧义题目退化成提示词难度失真一个最小的仓库级任务声明大致是这样四个构成块各占一段。⚠️ 代码待验证task_id:repo-refund-issuesource:公开仓库的真实 issue示意repo:https://example.invalid/acme/ordersbase_commit:9f2c1ab4e7d05c3b8a6f1d2e4b7c9a0f3e5d8b21environment:image:registry.example.invalid/acme/orderssha256:0f1e2d...# 按摘要固定install:pip install -r requirements.txt --require-hashesjudge:fail_to_pass:# 改动前失败、改动后必须通过-tests/test_refund.py::test_partial_refund_with_couponpass_to_pass:# 改动前后都必须通过用于防回归-tests/test_order.py::test_create_ordertimeout_seconds:600三、这类评测回答了什么、没回答什么先说它能回答的。能不能定位到该改的文件。在一个有几百个文件的仓库里从一句 issue 描述出发找到目标文件本身就是一个独立能力。仓库级任务把这一步纳入了评测范围而单点补全从定义上就跳过了它。能不能改对。原来失败的测试是否变绿是客观、可复现的判定不依赖任何人的主观印象。会不会改坏别的。原来通过的测试是否仍然绿把「回归」这件事纳入了计分。这一点在单点评测里完全没有对应物。多次尝试下的稳定性。允许重试若干次时第一次就对和第五次才对工程含义完全不同。报告里把一次通过和多次通过分开列才看得出「能探索」和「一次就对」的区别。这四条里后两条是仓库级评测相对单点补全多出来的。单点评测天然是一次性的给一次上下文看一次输出。仓库级任务可以给多次尝试于是「一次就对」和「多试几次能对」被分开了。这个区分在工程上很实际前者能放进自动化流程后者更适合当交互式助手用。再说它不能回答的这部分同样重要因为它决定了结论的边界。改动是否可维护。能过测试的代码可能是把三十行逻辑塞进一个嵌套 if 里。测试绿了代码债留下了。评测不会为此扣分。是否符合团队规范。命名、分层、日志字段、错误处理约定这些不在测试覆盖范围内自然也不在评测范围内。评审成本是多少。一个三百行的 diff 和一个三十行的 diff测试结果可能一样但人看它们花的时间差一个量级。评测只看结果不看代价。是否真的解决了 issue。测试是 issue 的近似。issue 里没写清的边界测试也测不到测试全绿不代表用户的问题真的被解决了。真实环境的阻力。评测在沙箱里跑仓库、依赖、数据都是准备好的。真实环境里可能连仓库权限都拿不到。能回答不能回答能不能定位到该改的文件改动是否可维护能不能让失败的测试变绿是否符合团队规范会不会把原有测试改坏评审要花多少时间多次尝试下的稳定性真实环境里的权限与数据阻力一句话概括仓库级评测把「正确性」这一维测实了但它没有测「工程性」。把「测试全绿」当成「可以合并」是把两个不同的判断混成了一个。四、对工具选型的含义读榜单要问的四个问题分数本身信息量很低重要的是它测的是什么、怎么测的。拿到一份仓库级榜单先问四个问题。第一覆盖哪些任务类型。任务是修缺陷、加功能、做重构、补测试还是依赖升级这几类对能力的要求差别很大加功能考的是理解需求修缺陷考的是定位重构考的是不破坏行为。只覆盖一类的高分不能外推到另一类。第二环境是否公开可复现。镜像摘要、依赖锁、测试命令是否随任务一起给出没给出的话这个分数不可复现只能当宣传材料看不能当选型依据。第三允许重试几次。一次通过和若干次通过是两件事。只报一个最高分、不区分重试次数的榜单等于把「会试错」和「一次就对」混成了一栏。第四判定里有没有测试。如果判定仍然是文本相似度或者事后人工打分那它压根没走出单点补全的老问题换的只是任务外壳。这四个问题的顺序有讲究。第一个决定分数能不能外推——任务构成和你仓库不像后面三个都不用问了第二个决定分数可不可信——环境不公开数字就无法验证后两个决定这个数字代表哪一种能力。跳过前两个直接看排名是选型时最常见的误用。要问的问题有信息量的回答危险信号覆盖哪些任务类型明确列出修缺陷、加功能、重构等构成只报一个总分不说任务构成环境是否公开可复现镜像摘要、依赖锁、测试命令齐全只说「我们内部跑过」允不允许重试一次通过与多次通过分开列只给一个最高分判定是否含测试说明失败转通过、通过保持通过两组仍用相似度或事后人工打分举一个外推出错的例子一份榜单里的任务以「修缺陷」为主你的团队想用工具做「加新功能」于是拿这份榜单的高分去选型。接入之后会发现工具在已有代码里定位缺陷很准但让它从零加一个模块就很吃力。不是它退步了是榜单测的能力和你需要的能力不是同一个。比读分更实在的做法是挑三个和你仓库最像的任务自己在本地复现一遍。能复现榜单对你有信息量复现不了那个分数和你没关系。⚠️ 代码待验证# 把榜单上一个仓库级任务在本地还原示意命令按你的栈调整gitclone--filterblob:none https://example.invalid/acme/orders.gitcdordersgitcheckout 9f2c1ab4e7d05c3b8a6f1d2e4b7c9a0f3e5d8b21dockerbuild-torders-eval:local.dockerrun--rm-v$PWD:/work-w/work orders-eval:local\python-mpytest tests/test_refund.py::test_partial_refund_with_coupon-q# 改动前这条命令应当是失败的改动后重跑变绿才算任务通过五、对团队自测的含义把仓库级评测搬进内部公开榜单能告诉你平均情况告诉不了你「在你们这套代码、按你们的规范能不能用」。这正是内部集的价值所在。把仓库级评测的思路搬进团队走三步就够。从历史 PR 里抽任务。找已经合并、且带测试变更的 PR改动前的提交是起点改动前那条测试应当是失败的改动后通过。这是天然的、自带标注的任务不需要额外造题。用 CI 判定。判定标准直接复用你们已有的流水线跑哪条命令、哪些测试必须绿、超时给多久。不要为评测另写一套判定——两套判定迟早会漂移到时候你分不清是能力变了还是判定变了。建一个小而真的内部集。规模不用大十几到几十个任务就能看出趋势。关键是每个任务都来自真实仓库、真实 issue、真实约束。任务的「真」比任务的「多」重要。筛选条件为什么反例已经合并说明改动被团队接受未合并的实验分支带测试变更提供客观判定标准只改了文档或注释改前测试失败、改后通过任务有明确的可解性改动前后测试都绿改动规模适中单次改动能被人审阅上千行的大重构抽任务这件事可以脚本化判定标准直接取自 PR 当时用的 CI 命令。⚠️ 代码待验证defselect_tasks(merged_prs):从已合并的 PR 里筛出可以当评测任务的样本。picked[]forprinmerged_prs:ifnottouches_test_files(pr.files):continue# 没有测试变更就没有客观判定beforerun_tests(pr.base_commit,pr.changed_tests)afterrun_tests(pr.head_commit,pr.changed_tests)ifnot(before.failedandafter.passed):continue# 只收改前失败、改后通过的任务picked.append({task_id:pr.number,base_commit:pr.base_commit,issue_text:pr.body,# 描述直接取 PR / issue 原文judge_command:pr.ci_test_command,fail_to_pass:pr.changed_tests,})returnpicked每个任务落成一个文件后面重跑、退役、统计都围绕这个结构走。⚠️ 代码待验证task_id:orders-pr-217source:历史 PR已合并带测试变更base_commit:4d1e8f0a2b6c9d3e5f7a1b2c4d6e8f0a2b4c6d8eissue_text:|退款金额没有按优惠券抵扣后的实付金额计算 部分退款时返回原价导致对账出现差额。judge:command:pytest tests/test_refund.py -qfail_to_pass:-tests/test_refund.py::test_partial_refund_with_couponpass_to_pass:-tests/test_refund.py::test_full_refundenvironment:image_digest:sha256:7a2b...timeout_seconds:900内部集要回答的是你们自己的问题接进你们的仓库能不能自己找到该改的文件遇到你们的测试框架会不会卡住改完能不能过你们的静态检查这些公开榜单答不了。完整版资料清单本文用到的评测任务模板与术语对照都整理在里面了扫码即可获取六、自己搭内部评测集时的四个坑内部集的难点不在「搭」在「维持它的质量」。四个坑反复出现。坑一任务描述里含答案。最典型的写法是把描述写成操作指令比如直接点名某个函数里的某个比较符要改。这样模型不用定位、不用理解业务照抄即可。改法是描述只写现象和期望「部分退款时返回的是原价应为抵扣后的实付金额」——不写文件、不写函数、不写行号。坑二环境不可复现。任务在你机器上能跑换一台就挂依赖没锁版本、测试连的是本地数据库、镜像没有固定摘要。这类问题最隐蔽因为它只在「换人、换机器」时才暴露。改法是把依赖锁进版本库、镜像按摘要引用并且让任务在开始前先跑一次环境自检。坑三只收成功案例。只挑一眼就能过的任务分数会很好看但没有区分度。真正有信息量的是那些「第一次做不对」的任务——它们才是把不同方案区分开的部分。改法是任务入库前先用两三个不同方案各跑一遍全都一次通过的任务降级为冒烟用例不必进主集。坑四样本永不更新。仓库在演进半年前的任务到今天可能已经失效函数被重构掉了、测试被删掉了、依赖大版本升级了。改法是让内部集跟主干走——每隔一段时间对全量任务重跑一遍跑不通的要么修环境要么退役。坑典型表现后果改法描述含答案写明文件、函数、行号任务退化成抄写只写现象与期望环境不可复现依赖不锁版本、测试连本地库换机器就失败锁依赖、镜像按摘要固定只收成功案例专挑一眼能过的任务分数高但无区分度入库前用多个方案先跑样本永不更新对应代码被重构掉旧任务集体失效跟主干定期重跑与退役环境自检可以做成一条固定命令每次入库前跑一遍把依赖指纹一起存档。⚠️ 代码待验证# 任务入库前的环境自检换台机器必须得到同样的结果dockerrun--rmregistry.example.invalid/acme/orderssha256:7a2b...\bash-lcpip install -r requirements.txt --require-hashes pytest -q# 记录本次运行的依赖指纹与任务一并存档便于回溯pip freeze--all|sort|sha256sum这四个坑有一个共同点它们都不影响「任务能不能跑起来」只影响「跑出来的数能不能信」。而一个内部集的可信度由其中最不严谨的那个任务决定——十个任务里只要有一个描述里带了答案整体结论就会被它拉偏而且从总分上完全看不出是哪一条在拖后腿。七、结论落到人身上时间该花在哪评测范式变了工程师的时间去向也该跟着变。该花时间的有三件事都是模型替不了的。定义任务。把一句用户反馈写成一个可复现、可判定的任务起点是哪个提交、现象是什么、期望是什么、边界在哪。这需要懂业务、知道约束、能把话说清楚是纯人力活。定义判定标准。哪些测试必须由失败转通过、哪些必须保持通过、超时给多久、允不允许重试、重试几次。这是新范式里的核心资产——判定标准有多可信评测结论就有多可信。维护内部集。让任务跟着仓库演进定期重跑、修环境、退役失效样本。这是长期投入价值随积累增长。不该花时间的是另外两件。反复调提示词去刷公开榜。榜单测的是别人的仓库、别人的规范。分数刷上去不代表在你们代码上能用。把分数当结论。一个分数只能回答「在这套任务上表现如何」回答不了「在你们仓库里能不能用」。有一个判断标准可以用如果一个所谓的评测优化动作没法翻译成「我们哪一类任务的通过情况变好了」那它是在为榜单工作不是在为工程工作。评测的最终产物不是排行榜上的数字而是一组你们信得过的任务和判定标准——它们让你在换工具、换版本、换方案时能用自己的数据做决定而不是靠别人的名次。完整版资料清单本文用到的评测任务模板与术语对照都整理在里面了扫码即可获取附表 A关键取舍一览本文涉及的所有工程判断集中在这里方便按需回看。取舍本文结论判断依据位置评测单元从一段代码换成一个仓库里的一次改动单点任务太窄区分度消失第一章单点补全指标的定位只适合窄任务不能代表工程能力上下文短、无跨文件依赖第一章答案判定方式用测试通过替代文本相似度相似度会把正确解判错第一章仓库级评测的必备块环境、快照、测试判定、真实 issue缺任一块结论都会失真第二章起点的选择绑定具体提交不用主干主干会漂移任务会过期第二章防回归必须统计通过保持通过的那组否则改坏老功能也算满分第二章任务描述来源取自真实 issue不翻写 diff翻写会把答案位置交代出去第二章对评测结论的理解测了正确性没测工程性可维护性与评审成本不在范围内第三章读榜单的方式先问覆盖、复现、重试、判定总分信息量低第四章选型动作挑三个任务本地复现一遍复现不了分数与你无关第四章内部任务的来源从已合并且带测试变更的 PR 抽自带标注不用造题第五章内部判定标准复用现有 CI不另写一套两套判定会漂移第五章内部集规模小而真不必大任务的真比多重要第五章任务描述写法只写现象与期望写明定位信息等于送答案第六章任务入库门槛先用多个方案跑一遍全都一次通过的任务无区分度第六章内部集维护跟主干定期重跑与退役仓库演进会让旧任务失效第六章时间投向定义任务与判定标准这两件事模型替不了第七章不该花的时间刷公开榜、把分数当结论榜单测的不是你的仓库第七章附表 B术语速查表术语含义单点补全在给定光标或注释处补全代码片段评测单元是一段代码文本相似度用编辑距离、序列匹配等比较生成结果与参考答案的接近程度仓库级任务在一个真实仓库快照上完成一次改动的评测单元fail to pass改动前失败、改动后应当通过的测试集合pass to pass改动前后都必须通过的测试集合用于防止回归回归新改动破坏了原本正常的功能仓库快照冻结在某个具体提交上的仓库状态任务起点唯一镜像摘要用内容哈希而非标签引用容器镜像保证环境可复现依赖锁文件记录依赖精确版本的文件用于在不同机器上得到一致环境内部评测集团队基于自己仓库与规范自建的任务集合一次通过不允许重试时任务被解决的比例与多次通过含义不同环境自检任务执行前先验证环境可还原、结果可复现的步骤写在最后这篇用到的资料写这篇文章时我把几套评测口径的公开说明和任务模板都对了一遍顺手整理成几份配套的东西大模型学习路线图从 LLM 基础到 Agent 开发各阶段该学什么、用什么资料大模型全套教程按主题分好的视频与文档清单大模型实战好书24 本附每本适合的阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「大模型」优先通过。拿到之后建议先看学习路线图那一份先定位自己在哪个阶段再决定学什么比一上来就啃框架效率高得多。