Claude Sonnet 4.5的发布，很容易被浓缩成一个数字：77.2%。Caylent的介绍称，这是该模型在SWE-bench Verified上的成绩。Yahoo财经转述Anthropic的说法时，也提到公司依据SWE-bench Verified等行业基准，将它定位为全球最佳的电脑程序设计模型。
成绩值得关注，但它不能直接换算成Pull Request的合入率。一个模型能在基准测试中修好问题，不等于它提交的每一份代码都符合真实团队的工程要求。
跑分看的是解题，合入看的是责任边界
SWE-bench Verified关注的是：面对软件问题和仓库上下文，模型能否生成通过相应评测的修复。它比单纯考察代码补全更接近软件维护，也因此成为观察AI编程能力的重要窗口。
边界同样明确。评测验证的是特定任务下的修复结果，不负责回答这次修改是否符合某个团队的架构选择、依赖政策和发布安排。77.2%描述的是模型在这套评测中的表现，不是“每100个PR就有77.2个可以直接合入”。
真实仓库里，代码经常卡在另外几道门槛上：
- 测试没有覆盖全部影响。 补丁解决了已描述的问题，也通过了相关测试，但未被评测覆盖的调用路径仍可能受到影响。
- 仓库有自己的约束。 公共接口能不能改、是否允许增加依赖、错误应该如何处理，通常由项目规范决定，不会自动写进每一条任务描述。
- 上下文已经变化。 模型生成补丁后，目标分支可能又有新提交。原本成立的修改，会遇到冲突或重复实现。
- 维护者关注长期成本。 一段代码可以运行，却可能改动范围过大、重复已有抽象，或者让后续维护变得更难。这些问题不一定表现为测试失败，却足以让评审者拒绝合入。
通过测试，也可能不是团队要的补丁
设想一个常见场景：修复问题最快的办法是调整公共接口。关联测试通过后，这份补丁在评测中可能已经完成任务；但在真实项目里，维护者还要考虑现有调用方和兼容性，最终可能要求改用另一种实现。
引入新依赖也是类似情况。它或许能让代码更快跑通，但项目本身未必接受这项依赖。此时不能简单地说模型“写错了”，更准确的判断是：模型解决的问题，比团队真正需要解决的问题更窄。
这也是SWE-bench成绩最容易被误读的地方。它衡量的是模型找到有效修复的能力，而代码合入还包含另一层判断：这份修改是否适合进入当前仓库，并由团队长期承担。
高分缩短的是首版补丁距离
Claude Sonnet 4.5在SWE-bench Verified上的表现，说明AI处理软件问题、生成候选补丁的能力仍在提高。对开发团队来说，它更适合被放在问题定位、首版修改和测试补充等环节，而不是被当成自动放行代码的依据。
更稳妥的使用方式，是在生成代码前明确允许修改的文件、兼容性要求和依赖限制；得到补丁后，再让模型说明改动范围、未验证的假设和可能影响。最终是否合入，仍交给现有的CI、代码评审和发布流程。
团队评估这类工具时，也不必只盯着榜单。候选补丁需要多少轮评审、开发者花多少精力核对、最终是否符合仓库规范，往往比一个公开跑分更接近实际使用价值。
Claude Sonnet 4.5的高分是一个更强的起点，不是合入许可。榜单告诉我们模型更擅长把问题变成补丁；仓库最终要回答的，仍是这份补丁是否值得长期维护。
资料来源：
