傍晚六点，一个做预约小程序的小团队还在改团课页面。需求听着很小：用户取消预约后，把名额还回去；重复取消不能多加名额；已经开课的记录不能被碰。
他们先让刚试用的 AI 编程工具处理。工具很快给出一段像样的改动，还顺手补了几个测试。页面点起来也没问题。直到同事把一条旧预约数据塞进去，发现名额回去了，取消记录却被重复写入。接下来半小时，大家不是在讨论功能，而是在追问：它不是排行榜靠前吗，怎么还会在这种地方翻车？
这个问题问偏了。排行榜给出的，是一组固定题目、固定仓库和固定判定规则里的表现。你的项目里有旧数据、已有约定、不能动的配置，还有一个真实用户等着结果。这两张试卷并不相同。
2026 年 7 月 8 日，OpenAI 在一篇对 SWE-Bench Pro 的审计中估计，约三成任务存在会影响评测的缺陷，并撤回了此前“采用该基准”的建议。这里最值得记住的，不是“排行榜全都没用”。该基准的维护方仍公开表示在处理排行榜问题。更朴素的结论是：分数能提供线索，不能代替你对自己项目的验收。OpenAI 的审计和维护仓库的说明都值得自己看一遍。
我现在看 AI 编程工具，先不问“谁第一”，而是先给候选工具一张真工单。它不必很大，关键是能把你的约束、通过条件和返工过程一起照出来。
真工单要有边界，不只写一句需求
“给预约页加取消功能”太松了。工具可以做出很多看起来合理的版本，后续出了问题，谁也说不清它当初应该遵守什么。
上面这个小程序的工单，可以写成下面这样：
- 任务：在现有取消入口中归还名额，并保留一次取消记录。
- 可用材料：给它当前页面、预约服务和现有测试；不让它猜数据库结构，也不让它搜全仓库后随便改。
- 不能碰的地方：支付状态、开课后的历史记录、线上环境配置。
- 通过条件：普通取消后名额加一；重复请求保持幂等；已开课记录返回明确错误；现有预约相关测试仍能通过。
- 人工检查：看一次完整 diff，确认新依赖、配置文件和数据迁移没有被悄悄带进来。
这不是为了把提示词写得花哨，而是把责任拆开。工具负责交付一个可检查的改动；人负责决定哪些风险不该交给它。
尤其是涉及线上数据、权限或用户权益的任务，别把“能跑”当作唯一验收。预览环境、备份、人工确认和可回退的改动，依然是主线任务。AI 能缩短写代码的时间，不能替你承担一次误删或误改的后果。
同一张工单，至少跑到一次修正
只看第一次输出，很容易挑中最会演示的工具。真正拖慢团队的，往往是它第一次没做对以后，能不能接住具体反馈。
我会把同一张工单交给两三个候选工具，材料和限制保持一致。第一轮看它能否理解现有代码，能否给出范围清楚的修改；第二轮故意给一条真实的失败信息，例如“重复取消时记录仍被写入”，看它会先定位原因、补测试，还是用一段听起来很自信的解释绕过去。
比较时，不必急着给每一项打精确分数。把下面几件事并排写下来，已经足够看出差别：
- 首次提交是否只改了该改的文件，说明是否能对上需求。
- 测试失败后，它能否复现问题并做出小而可审阅的修正。
- 它有没有交代假设、风险和你还需要手动确认的地方。
- 交接时留下的测试、注释或命令，能不能让下一个人接着查。
这里看的是总返工成本。一个工具第一次多问两句、少动几个文件，往往比“十秒钟给完一大段代码”更省时间。反过来，第一次看着很快，第二次修正就开始扩大改动范围，最后把验证工作全留给人，也该在这张工单里扣掉分。
排行榜放在筛选位，不放在决策位
排行榜仍然有用。你可以用它发现原本没注意过的候选，再结合团队常用的语言、编辑器、部署方式和隐私要求，挑出两三个值得试的工具。它把海选变短，这已经很有价值。
接下来要做的是留一张自己的验收单。每次试完，把工单、输入材料、代码 diff、测试结果、一次修正后的结果和人工备注放在一起。下次换工具、换模型或升级版本，就拿同一类工单再跑。这样积累几次后，团队会知道：哪类任务可以放心交出去，哪类任务要先拆小，哪类任务必须由人守住最后一步。
工具选择很少是一锤子买卖。真正可靠的手牌，是你已经在自己项目里跑过、看过失败、也知道怎么收拾残局的那一套验收。先找一张这周刚遇到的真工单，让候选工具把本事交代在里面。排行榜负责把人带到门口，能不能留下，还是要看它过不过你的门。