AI 帮你改好了导出页面。下载的文件能打开，要求的数据都在，用户也能正常使用。评测却判定失败，因为文件名没有完全符合测试作者的预期。另一个类似改动顺利通过，但导出的数据里混进了其他工作区的记录。
换个模型，两个分数都有可能变。团队却仍然解释不了：第一次为什么错判，第二次为什么漏判。
花钱重跑模型对比之前，先检查任务两端的约定：构建工具究竟拿到了哪些信息，评测又把什么当作成功。清楚的要求可能遇上不合理的测试；合理的测试也可能对应一份缺少关键信息的说明。这两类问题需要不同的修复办法。如果把它们一起改掉，再宣布总分提高，反而看不出究竟修好了什么。
这篇现场笔记提出一套小规模研究方案，供 AI 产品团队检查自己的任务队列。它尚未执行，也没有模型运行、客户观察或效果提升数据。方案先请独立读者理解任务，再准备几种刻意不同的交付结果，开展两项分开的比较：先对完全相同的已保存结果重新评分，检查评分器；必要时，再用固定的验收标准，比较原始说明与澄清后的说明。
新研究让团队重新审视什么
今天早报收录的 ExLabel / SWE-TQ 论文提交于 10 月 29 日。它检查编码任务的两个维度：信息是否足够，测试是否能公平验证解法。SWE-TQ 涵盖八种编程语言；ExLabel 会复用持续更新的评估经验库。作者报告的是标注表现改善，不能当成产品团队的修复成功率。研究保留原始标注者一致同意的样本，并进一步清理，因此也不能把这些标签视为对所有争议的完整记录。
公开仓库提供了代码和数据，但 README 明确说，经验库需要另行构建。本文没有运行这条流水线。对小团队而言，眼下更值得问一个具体问题：任务失败时，是构建工具没收到必要要求，评分器偷偷增加了要求，还是实现本身确实有问题？
这个问题并非最近才出现。OpenAI 的 SWE-bench Verified 原始说明记录过一种情况：隐藏测试要求特定警告文案，提供给模型的任务描述却没有写明。其人工筛选同时审查任务描述与测试。这是历史上的具体例证，不能据此推算你今天的应用有多高的问题比例。
先分清任务材料、验收约定和评分器
本实验中的任务材料包，指构建工具获准使用的全部信息：任务文字、允许读取的文件、可见示例、相关界面以及可访问的文档。如果允许向用户追问，追问方式也属于材料包的一部分。不能因为“有经验的工程师应该知道”，就把没有提供的信息算成已知条件。
验收约定说明产品真正需要哪些可观察行为，可以允许多种实现方式或输出形式。它必须区分硬性要求、偏好和仍待决定的产品问题。评分器则是检查交付结果是否符合约定的机制，可以是代码、人工审查，也可以结合两者。
这样拆开后，一些分歧就有了诊断价值。评分器可能准确地拒绝了缺少必要行为的实现，但任务说明从未传达这项要求。即使判分逻辑本身没错，这仍然是输入说明的问题。反过来，如果交付满足全部已声明行为，却因评测者私下偏爱的格式丢分，问题就出在评分器。
SWE-bench 文档描述的是根据问题说明与代码仓库生成补丁的任务。产品工作流往往能提供更多上下文。请写清自己的真实信息边界，不要直接照搬某个 benchmark 的限制。只有环境允许打开链接、相关版本也确实可得时，链接里的信息才算可用材料。
从一项导出改动开始，不要直接审整个需求池
假设有一个虚构团队，正在为按工作区组织数据的 ParcelDesk 开发功能。任务写着：“增加当前订单的 CSV 导出。”评分器却同时期待文件名为 orders.csv、只含当前工作区、遵守已选筛选条件、使用指定列顺序，并按某一种固定方式解释页面显示的日期范围。
这些预期的依据并不相同。如果产品承诺工作区隔离，这项要求就应存在于可访问的产品约定中。“当前订单”可能指当前页、完整的筛选结果，也可能指全部订单。文件名可能是下游集成的硬要求，也可能只是测试作者的习惯。团队应先解决这些区别，再解释模型得分。
在本方案中，产品负责人决定：导出当前工作区内的完整筛选结果，固定日期区间语义与字段结构，并明确文件名拼写不影响验收。这是人为设计的示例，不是所有导出产品都应采用的规则。如果现有集成依赖精确文件名，就保留该限制，并把它明示出来。
从同一种工作流中抽取少量任务，例如都与导出有关。保留抽样规则和原始表述。可以同时选择常规任务、已有争议的任务和看起来很清楚的对照任务，但必须分组报告。集中检查争议任务有助于诊断，发现的问题比例却不能代表整个需求池。
用独立阅读找出尚未说清的决定
请两位没有编写这项任务的审阅者，分别阅读同一份材料。他们应有足够的领域知识，能够识别常规产品要求；但在独立阅读时，都不能看到隐藏评分器、参考解法、模型身份或对方的理解。
每人写下自己会交付的可观察结果、两个合理边界情况，以及所有需要产品负责人做决定的地方。对于每项必需行为，都要标明材料中的依据。“大家都知道”是需要调查的发现，不是依据的位置。
接着再比较两份理解。不同文件名可能都合格；如果产品承诺隔离，不同的工作区边界就不能同时成立。不要把所有措辞差异都算成歧义。只有可能改变实现、客户结果或验收结论的分歧，才进入记录。
由负责人依据已有产品意图裁定，也可以保留“尚未解决”的状态。两位审阅者一致，只是一项诊断结果，并不证明说明已经足够清晰：他们可能共享同一个没写出来的假设。这个风险重要时，再加入一位对产品不那么熟悉的读者。讨论前先保存各自的原始笔记，避免讨论后的共识抹掉最初暴露的问题。
Multi-SWE-bench 仓库记录过为任务补充 hints、说明新定义变量的更新。这提醒团队：提供给执行者的信息也需要版本。如果修复后的材料给出了以前隐藏的标识符，即使客户的核心需求没有改变，下次运行收到的仍然是一份不同的任务。
用合格替代方案和刻意错误挑战评分器
再次运行智能体前，先准备一小组交付样例。每个样例应由产品负责人和独立审阅者共同确认应通过还是拒绝。使用可丢弃的环境和虚构记录，不要为了测试越权导出而向真实客户系统植入错误。
至少准备两种行为合格的替代方案，再加入违反不同要求的错误。ParcelDesk 可以有一种实现流式输出全部允许导出的 CSV 行，另一种先收集数据再生成文件。两者使用同一份固定数据和字段结构。只要性能等相关约束没有明确把架构纳入约定，内部实现就不应决定能否通过。
Google 早期的按行为而非实现细节测试的文章解释了，绑定实现细节的断言可能误伤合理改动。这并不意味着精确断言都不合理。CSV 表头、协议字段，以及法律要求的固定文字，都可能必须完全匹配。这里要查的是：每项断言背后，是否有站得住脚的要求。
| 设计的交付样例 | 按约定应如何判定 | 判分不一致时应调查什么 |
|---|---|---|
| 允许导出的行与字段均正确，只使用另一个获准文件名 | 通过 | 文件名偏好是否变成了隐藏要求 |
| 通过另一种合格实现，得到相同的必需结果 | 通过 | 评分器是否依赖实现细节 |
| 只导出当前页，而约定要求完整筛选结果 | 拒绝 | 正常路径数据是否暴露不了截断问题 |
| 混入另一工作区的一条虚构记录 | 拒绝 | 是否缺少隔离检查 |
| 表头正确，却丢掉某个必需字段的值 | 拒绝 | 是否只查结构、不查内容完整性 |
| 日期边界上的记录不符合固定规则 | 拒绝 | 测试数据是否覆盖了边界 |
这些都是待执行的挑战样例，不是已观察到的结果。审阅者必须独立于被审查的评分器验证标签。如果两位审阅者无法达成一致，就将样例移入争议区，保留其状态，不能悄悄把它当作标准答案。
对于导出场景，可以根据虚构输入记录和已经确定的产品规则，单独计算一份预期结果清单：列出允许出现的行 ID、必需的单元格值、必须排除的工作区 ID，以及日期边界的归属。在用它给交付样例贴标签前，请另一位审阅者直接对照输入检查清单。复制现有评分器的预期输出，会把本来要排查的假设再次带进来。
两人独立标注完成前，不互相公开初始标签，也不看评分器的判定。每次通过或拒绝都保留依据，具体到哪一行、哪个值不匹配。如果争议暴露的是预期清单有误，应为修正建立新版本，并重新检查所有受影响标签。如果暴露的是需求尚未决定，就交回产品负责人，而不是投票把样例塞进“合格”集合。正因这一步需要认真核实，少量标签可靠的反例，往往比数百个状态不明的自动生成样例更有用。
修复判分时，不要声称构建工具变强了
第一项比较固定交付结果不变。保存文件原始字节、测试环境状态、相关执行记录以及约定版本，再用旧评分器和拟修复的评分器检查同一份材料。如果评分器必须实际执行代码，就把每份交付分别放进同一测试环境的全新副本中重放，不能让两次评估共享被修改过的状态。
记录两个方向的每一次判分变化。原本被拒绝的合格替代方案现在通过，属于纠正误拒；原本通过的错误现在被拒绝，属于纠正误放。两次都没变也可能仍然判错。因此，两版评分器都要对照独立裁定的标签，不能只看它们彼此是否一致。
合格集合与错误集合分别报告数量。例如，分别填写“被拒绝的合格替代方案数／已裁定的合格替代方案总数”和“被接受的错误交付数／已裁定的错误交付总数”。这里不填任何想象出来的比例。争议样例不进入这两个有明确标签的分母，但其数量必须同时披露。
这一阶段只能检查评分器与一小组挑战样例的一致性。它不能估计生产准确率，更不能证明构建工具学会了什么。对旧交付重新评分，可能立刻改变看板，却没有改善任何一份已交付工作。请把它明确记作测量规则修订，并保留旧分数与评分器版本供追溯。
另起一轮运行，单独检验澄清是否有帮助
只有验收约定与审查后的评分器固定下来，才开始测试更清楚的任务说明能否改变行为。比较原始材料包和补齐产品决定后的材料包；两组使用相同模型版本、工具、初始仓库、数据、预算和交互规则。
每次尝试都从全新状态开始，并随机安排执行顺序。原始组的对话、生成补丁、审阅笔记和挑战样例，都不能进入澄清组。如果允许追问，两组采用同样规则，并记录回答。否则，比较的就不只是说明文字，而是两套不同的交互服务。
用同一份固定验收约定判定两组结果，并对审阅者隐藏组别。保留每项任务的成对记录；预算允许时，为有随机性的执行安排重复尝试。所有预定尝试都要入账，区分行为合格、行为不合格、没有交付和执行失败。环境故障不能证明实现有缺陷，但它仍消耗了计划中的研究次数，应提前说明如何处理。
六项任务的试点可能暴露具体误解，却不足以得出可信的总体效应或模型排名。运行前先确定试点规模、重复次数、停止条件与主要结果指标。如果中途改变了关键验收决定，就停止当前比较，另开一个版本，不能把前后两套标准拼成一个成功率。
每项任务保留一张修复表
下面这张表就是可复用产物。每个任务填写一张，用链接关联不可变的材料版本与证据，不要把敏感执行轨迹整段粘贴进普通表格。它把输入修复、判分修复和尚未完成的产品决定分开记录。
| 字段 | 研究前或研究中需要记录的内容 |
|---|---|
| 任务与样本组 | 稳定 ID、工作流类别，以及归入常规／争议／清晰对照组的原因 |
| 原始材料包 | 任务文字与可访问上下文的版本；允许使用的链接、工具和追问方式 |
| 必需行为 | 可观察结果、明确排除项，以及每项要求的来源 |
| 待定决定 | 具体歧义、负责人，以及未解决或已裁定状态 |
| 独立阅读记录 | 两份原始理解，以及足以改变决定的分歧 |
| 合格替代方案 | 至少两个已裁定样例，以及各自符合约定的理由 |
| 刻意构造的错误 | 违反哪项要求、预期为何拒绝，以及独立标注依据 |
| 固定验收约定 | 版本、负责人确认、允许的变化，以及争议样例登记 |
| 仅改变评分器的比较 | 相同交付材料、两版评分器、各自结论与执行状态 |
| 澄清比较 | 原始／修复材料包 ID、全新运行 ID、随机顺序和固定评分器 |
| 结果与排除项 | 各自的分母、缺失交付、执行失败和未决标签 |
| 决定与后续检查 | 修输入、修评分器、查实现或暂缓，以及新的验证样例集 |
这张表应让后来接手的人不必追问任务作者“那次会上到底怎么说的”，也能还原结论为何改变。保留标签背后的要求，不能只剩一个“已批准”勾选框。涉及敏感数据时，记录受控存放位置与有权查看的审阅者，不要复制数据本身。
参考交付样例也不能进入未来的构建输入。一旦任务被讨论过，或用于调整提示词，它就成了开发材料。修好的评分器在成为发布依据之前，应接受一批全新的挑战样例检验。这批样例同样需要合格变化和相关错误；只有已知坏例，发现不了评分器是否还在误拒好结果。
警惕越修越容易蒙混过关
最直观的错误，是把精确文件名检查直接换成“存在一个下载文件”。这样虽然消除了一次误拒，却可能放过几乎所有问题。每放宽一项断言，都应补上仍然保护原要求的行为检查。核对数据行、工作区归属、内容完整性和约定字段，而不只是看看 CSV 解析器能否打开文件。
变异测试提供了一种工程类比。PIT 文档介绍了修改代码、观察测试能否发现变化的方法。这里刻意设计错误交付，也是为了检查验收能否认出有意义的行为缺陷。但这组人工样例不是一次 PIT 运行，不产生变异测试分数，更不代表穷尽了故障。仍满足要求的等价改动，不应算成缺陷。
Hypothesis 文档则介绍了在生成输入上检查性质。实现导出审查时，团队可以定义一种性质：增加一条不属于当前工作区的记录，不应改变获准导出的结果。不过，性质的范围与测试数据仍需要独立依据；自动生成再多输入，也回答不了“当前订单”最初究竟指不指当前页。
另一个陷阱是借澄清之名透露答案。“照着这份补丁改”检验的是复制，不是实现能力。应说明必需行为与必要接口信息，同时保留合理解法空间。记录每一条新增提示，让后来读者判断：你是在消除歧义，还是大幅降低了题目难度。
把争议当成待完成工作，不要当成脏数据
不要为了让评测看起来稳定，就删除有争议的任务。小团队可以保留三种状态：可用于当前固定比较、需要产品决定、在当前环境下无效。状态变化和原因都要留下记录，并披露有多少任务退出样本、被移走的是否恰好是重要客户场景。
审阅者独立也有边界。两人可能都参考了同一份错误内部文档；产品负责人可能无意识地维护自己编写的测试。隐藏厂商身份与现有得分，要求引用需求依据，并允许审阅者提交一个合格反例。这些做法有助于暴露分歧，但不能保证得到绝对客观的标准答案。
本方法适合结果可观察、范围明确的产品改动：导出、导入、筛选、权限检查和小规模工作流修改。面对偏审美的设计、开放式研究，或者无法事先说清客户价值的任务，它的判定力较弱。独立阅读仍可能帮助改善说明，但强行使用二元评分器，可能曲解工作本身。
不能把“不确定”当作放松隐私、安全或合同承诺的理由。如果关键边界既没有明确规范，也没有可信检查，就暂缓相关发布。解决要求本身属于产品工作，换一个模型不会让这份责任消失。
让下一步决定比“换模型”更具体
有价值的结果是一份诊断。如果评分器误拒合格方案，或误放有意义的错误，就修复测量机制，并用全新样例验证。如果独立阅读发现缺少产品决定，就先补齐说明，再在固定约定下测试执行。如果任务说明清晰、评分器也有依据，实现仍然失败，再去调查构建工具、工具链或模型。
除了结果，还应记录审阅者用时、任务作者澄清用时、重放成本和未解决决定。更详细的材料包可能维护昂贵，也可能让用户难以填写。下一轮产品实验或许应研究一个简短追问流程，而不是让永久提示词越来越长。这个交互值得单独研究，不应藏在模型对比里。
今天可以从同一工作流的一项争议任务和一项看似清楚的任务开始。先保存原始材料，取得独立理解，挑战它们的评分器，再决定需要哪一种比较。只有流程产出了可以检查的证据，才扩大规模。这样才能避免继续花模型预算，去回答现有任务说明与测试根本回答不了的问题。
参考来源
- Jiang 等，Well-Specified and Well-Tested? Assessing SWE-bench-Style Datasets with a Self-Evolving Agent，2026 年 10 月 29 日。一手研究，实验结果由论文作者报告。
- ZJU-CTAG，ExLabel 仓库。公开代码、数据、配置与复现说明；本文没有执行。
- OpenAI，Introducing SWE-bench Verified。最初发表于 2024 年 8 月的一手标注方法说明，用作历史背景。
- SWE-bench 作者，SWE-bench 文档。任务与评测背景。
- Multi-SWE-bench 作者，Multi-SWE-bench 仓库。任务信息、评测环境与历史 hints 更新。
- Andrew Trenk / Google Testing Blog，Test Behavior, Not Implementation，2013 年 8 月。较早的工程方法说明。
- PIT 维护者，PIT Mutation Testing。植入错误的方法背景；本文没有运行该工具。
- Hypothesis 维护者，Hypothesis 文档。基于性质的测试方法背景；本文没有开展生成输入实验。