Claude Fable 5在CursorBench得分72.9%：代码库试车显真章
当各类编码模型的公开评测榜单分数不断刷新，不少使用代码辅助工具的开发者却发现一个尴尬的现象：纸面成绩亮眼的模型，放到真实的代码仓库里测试时，表现往往和预期相差甚远。最近，一款主流代码辅助工具的评测团队，就用一套贴近真实开发场景的测试流程，验证了高端编码模型的实际能力。
这次测试的核心对象是一款定位为处理复杂长任务的编码模型，其官方定价并不低廉。该工具团队的评测工程师的工作，就像是给新车做试驾：不会只看厂商宣传的纸面参数，而是直接开进真实的通勤路况和复杂弯道，检验车辆的实际表现。
该团队早在今年3月就推出了专门的编码模型评测基准，推出的初衷正是因为公开的静态代码评测分数，和开发者的实际使用体验出现了严重脱节。传统的静态评测题目通常会给出完整的需求说明、明确的目标文件和预设的测试用例，模型只需要按照给定的流程完成任务即可，就像在封闭赛道里开车。但真实的软件开发场景却完全不同：开发者可能只会丢出一段报错日志，只留下一个简单的“修复”指令；或者明确要求修改A模块，但问题的根源其实藏在完全不相关的B模块里。如果模型只会机械执行指令，就可能在错误的地方反复修改，最终产出大量代码却没能解决核心问题。
因此这套评测基准特意没有提供完整的任务信息，所有测试题目都来自真实的工具会话、内部代码和受控开发场景，主要从四个维度评估模型：最终结果是否正确、代码质量是否达标、完成任务的步骤是否精简，以及模型与用户和工具的交互是否合理。其中有一道题目还会故意引导模型指向错误的修改模块，想要拿到高分，模型需要先识别出这条错误路线，再去寻找真正的根因。比起编写代码，发现题目本身存在的误导性才是最大的挑战。
在这套评测基准中，有一道极具代表性的题目：只粘贴一段完整的报错栈信息，然后只附上一个单词fix。没有需求文档，没有指定修改的文件，也没有验收标准，完全复刻了开发者日常收到的线上工单场景。
这款定位高端的编码模型，在该评测基准的最高难度档位拿到了72.9%的分数，刷新了当时的榜单纪录。但这个亮眼的分数并没有让评测团队立刻满意，反而让他们觉得这个成绩有些可疑。于是工程师们挑出了测试中最难的一批任务，逐条查看模型的执行日志，就像回放智能体的“监控录像”来还原整个思考和执行过程。
如果只看最终的测试结果，不少模型都能顺利通过，但查看执行日志后就能发现巨大的差异：有的模型能快速定位到根因，完成修改、验证后直接收尾；而有的模型则修改了数十个无关文件，绕了一大圈之后碰巧让测试通过，实际留下了大量隐患。榜单上的“完成”只是纸面结果，放到真实代码仓库里，两种情况带来的技术风险完全不同。
通过分析执行日志，团队发现这款高端模型确实有两个明显的优势：它能找到其他模型没能发现的解决方案，而且完成相似任务所需的操作步骤更少。在长周期的开发任务中，少走一次弯路省下的不只是Token成本，还有工程师后续清理残局所花费的大量时间。
除了标准化的评测基准，工程师还设计了一个更具挑战性的非标准化测试：从零开始创建一个太空飞行模拟器，再开发一枚可以飞往月球并完成着陆的火箭。在之前的测试中，另一款热门模型执行这个任务时，连续工作了12到16个小时，最终却因为不断修补问题反而陷入恶性循环：火箭升空后耗尽燃料，加油后又重到无法突破大气层，始终没能完成登月目标。
这款高端模型的第一次尝试也没能成功登月，但它做出了完全不同的选择：先将火箭送入低轨道，收集遥测数据后主动返航。在拿到第一手测试数据后，它重新调整了设计方案，在第二次尝试中成功完成了着陆，整个过程耗时约两小时。
这个细节体现了该模型最关键的能力之一：它没有为了维持“正在完成登月任务”的表象而硬撑，而是主动接受第一次尝试只是试飞，将未完成的结果作为下一轮计划的输入。工程师将这种表现总结为更强的全局推理能力——简单来说，就是模型不仅能写出当下的代码，还能在数小时的长任务中始终记得最终目标，愿意为了达成整体目标临时调整路线。
这个非标准化测试并没有固定的评分体系，也没有经过多轮重复验证，更像是一段有参考价值的工程实践录像，但它清晰地展示了长周期编码任务中最棘手的部分：写出下一行代码并不罕见，难得的是在连续工作数小时后，依然能记得最初的任务目标。
很多人会觉得“最难的1%任务”是指只有顶尖程序员才能解决的算法难题，但该团队给出的解释要接地气得多。软件开发中的任务可以分为两类：一类是已经明确知道从A到B的路线，只需要按部就班执行，比如批量修改接口、补充测试用例、移动文件或者更新依赖，这类任务用轻量模型就能高效完成，成本低且失败后容易重试；另一类任务则只有明确的起点A，连终点B在哪里都完全未知，比如排查跨模块的故障根源、规划大型重构的第一步、决定是否替换多年无人敢动的核心系统设计。
让这款高端模型去做批量修改接口这类简单任务，就像派一支勘探队去帮忙搬桌子，完全是大材小用。它真正擅长的是带着工具进入一片没有地图的区域，一边探索一边确认终点的位置。目前该团队已经开始将这款模型应用在这类场景中：比如在智能体修改共享代码之前，先读取团队成员最近的提交记录，确认是否有人正在修改同一片代码区域，提前标记潜在的冲突风险，再决定具体的修改路径。
这个动作看起来并不炫酷，但却是靠谱工程师的常规操作。修复一行写错的代码并不困难，真正麻烦的是模型埋头执行了数小时之后，才发现团队已经修改了核心的依赖逻辑。这也让编码智能体的竞争方向发生了变化：早期大家只关注“这一行代码写得对不对”，现在开始追问“几小时之后，整个任务是否还在正确的方向上”。上下文窗口只是智能体的“背包”，能否在执行过程中不断收集新证据、调整旧计划、始终紧扣任务目标，才决定了它能走多远。
这款高端模型的API定价并不低廉，每百万输入Token收费10美元，每百万输出Token收费50美元，再加上每道评测题平均17美元的测试成本，如果将它设置为所有请求的默认模型，成本会快速攀升。更合理的选择是采用模型路由策略：对于路径明确、反馈快、失败成本低的任务，交给速度更快的轻量模型；只有当任务终点模糊、需要跨模块探索、一次失败会浪费工程师数小时时间时，才调用这款高端模型。
在选择这类高成本模型时，可以遵循三个判断标准：
- 路线清楚吗？如果路线明确，就用快模型执行，不必为普通的重复性工作购买探索能力。
- 中间结果能验证吗？必须配套测试、构建、日志和代码审查流程，如果缺少验证环节，模型运行越久，积累的未知风险就越多。
- 失败到底有多贵？如果一次错误只需要几分钟就能重试，便宜的轻量模型更合适；如果一次失败会浪费一名工程师半天的工作时间，那么17美元的单题成本反而显得划算。
这套策略其实并不复杂，核心思路就是用便宜的模型处理已经明确的任务，用昂贵的模型探索未知的路径：当路线清晰时，快模型负责高效执行；当连地图都没有时，再让这款高端模型去寻找终点。
