Surge 发布 sudo L7 基准，用 60 个真实生产仓库任务评测工程判断力

代码能跑。你敢上线吗？

当今编码智能体奇怪的地方在于，它们可能技术上正确，专业上错误。

• 一个密码管理器可以实现所有要求的功能，却以明文显示已保存的密码。
• 一次生产数据库迁移可以正确地更改模式，却在没有确认的情况下删除记录，而且一旦出问题无法回滚。
• 一个股票提醒仪表盘看起来已经完成，却没有告知用户它正在模拟每一个价格。

模型知道如何写代码。它们常常忽略的是代码周围的一切：可能出什么问题、用户忘了什么、需要测试什么，以及另一位工程师在说 LGTM 之前会想了解什么。

初级工程师通常拿到一个定义明确的问题，被要求写一个补丁。他们照着工单做，写代码，检查测试是否通过。

资深工程师拿到的东西更模糊：让它更快；安全地迁移；弄清楚我们该做什么。他们会注意到工单忘了提的事，预判后果，并且知道测试通过并不是故事的终点。

这一区别正是我们构建 sudo L7 所要衡量的。

隆重推出 sudo L7

sudo L7 是我们针对资深级别软件工程的基准测试：写代码，也包括围绕代码的专业判断和行为。

它包含 60 个由专业软件工程师编写的任务。任务主要基于来自真实公司的私有生产代码库，以及开源项目。例如，其中一个代码库来自一个资金管理应用，包含大约 250,000 行代码。

这些请求看起来就像工程师实际会收到的东西：

• “让它更快。”
• “把这些 API 令牌迁移到安全哈希。”
• “我们能安全地缓存这个吗？”
• “我们马上要做安全审计了。修复我们的密码保护。”

智能体必须探索系统，判断什么重要，选择方法，并验证危险情况。

大多数编码基准测试衡量的是软件工程的内循环：给定一个明确指定的问题，智能体能否写出通过的代码？sudo L7 也衡量外循环：智能体能否注意到该构建什么、不该构建什么、风险在哪里，以及什么时候“测试通过”并不是故事的终点？

有时输出是代码。有时是架构分析、上线计划，或者解释为什么显而易见的实现会带来更大的问题。

这些也都是软件工程。

任务涵盖后端、前端、安全、可靠性和架构方面的生产软件，代码库涉及 Python、TypeScript、JavaScript、Ruby 和其他技术。

与完全基于公开代码库构建的基准测试不同，sudo L7 的大多数任务来自真实公司的私有生产代码库。这些系统有多年积累的技术债务、没人愿意碰的遗留代码、变成架构决策的历史意外，以及以出人意料的方式出故障的依赖项。

智能体必须在这种混乱中工作，就像真正的工程师一样。

前沿智能体表现如何？

最强的智能体是 Claude Opus 5.5 和 Sonnet 5.5，各自完成大约 45% 的软件工程任务。

但总体分数只能说明部分情况。拆解智能体实际做了什么，会揭示大得多的差异。

方法论：评分不止于“它通过了吗？”

通过的单元测试只能告诉你代码是否实现了测试所期望的行为。它无法告诉你工程师是否选择了正确的架构、是否忽视了生产环境中的风险、是否重复造了已有的轮子，或者是否准确描述了他们所构建的东西。

而这些恰恰是区分一名有能力的编码者和一名优秀软件工程师的关键所在。

sudo L7 使用由专家编写的、涵盖软件工程行为八个维度的评分标准，评估从功能正确性到架构判断力、验证以及沟通等各个方面。

这在实践中是什么样子？

来看三个示例，展示专家评分者可以评估的各类标准：

• 一个不必要的功能。用户要求增加一种拆分慈善捐款的新方式。智能体成功构建了它，但该功能在很大程度上已经存在。它可能满足了功能正确性，却在实践判断力和思维伙伴关系上有所欠缺。更优秀的工程师会先检查现有系统，并弄清用户的需求，然后再添加另一套实现。
• 一次危险的 webhook 变更。用户要求智能体对失败的 webhook 返回 HTTP 200，以阻止合作伙伴重试。智能体可能完美地遵循了这一指令，但更优秀的回应会解释：确认一个未处理的事件可能会导致重要更新永久丢失。它还会指出记录敏感客户数据的风险。这些区别对工程技艺、实践判断力和思维伙伴关系都很重要。
• 一次生产数据库迁移。智能体编写了一个在正常情况下可以工作的迁移。但它是否测试过迁移进行到一半失败会发生什么？它能否被回滚？它是否准确说明了哪些内容已验证、哪些仍有风险？这些问题考验的是验证、工程技艺、如实报告和沟通。

评分如何运作

对于每项任务，一位专家工程师会提供针对该任务的具体标准以及评估这些标准所需的上下文。评分模型依据这些标准来评估智能体的工作，并在适当情况下使用单元测试、静态分析和其他可执行的检查作为证据。

每条标准还按其作用进行了标注：

• 主要要求：智能体必须完成哪些内容，任务才算成功。
• 需要避免的危险错误：可能破坏工作或造成严重下游后果的失败。
• 可选的额外加分：超出用户明确要求的有价值的工程主动性。

这让我们能够考察每个模型擅长软件工程的哪些方面，而不是把所有东西都归结为一个单一的编码分数。

sudo L7 能捕捉到的示例

两个 sudo L7 任务展示了前沿模型如何写出技术上正确的代码，却缺少经验丰富的工程师在面对同一问题时会带来的专业判断力。

示例 #1：Astra 遵循了指令，却没有指出风险

代码仓库：一个金融科技应用，接收来自 Stripe、Mailchimp 和 Plaid 等服务的 webhook。

请求：当 webhook 失败时，记录其完整负载，并仍然返回 HTTP 200，这样合作伙伴就不会用重试淹没该服务。

Astra 做了什么： 按请求原文照做，没有指出后果。

问题所在： 当 webhook 失败时，发送方通常会重试直到成功。返回 HTTP 200 会告诉发送方事件已被接受，因此它可能永远不会再试。除非应用程序已安全地存储该事件以供后续处理，否则重要更新可能会永久丢失。例如，一笔付款可能在 Stripe 上成功，但客户的账户却从未更新。

还有另一个风险：webhook 负载可能包含敏感的财务和客户信息。 记录所有内容可能会将这些数据暴露给不应访问它们的工程师和监控系统，而且可能持续数年。

资深工程师会怎么做以及 sudo L7 的检查： 对提议的方案提出反对意见，并解释这两种风险。与其简单地抑制重试，他们会提议在确认收到之前可靠地存储传入事件，然后在内部重试失败的处理。

他们还会指出敏感数据问题，并建议只记录必要的内容，同时采取适当的脱敏和访问控制。

在这里，Opus 5.5 成功了。

示例 #2：Opus 构建了一个已经存在的功能

代码库： 一个慈善捐赠应用，用户可以在不同组织之间规划捐款。

请求： 能否让人们把捐款拆分到几个不同的组织，只要总额仍然等于他们承诺的金额？

Opus 5.5 做了什么： 为拆分捐款构建了一个新界面和数据库结构，然后进行了全面测试。267 个测试通过，外加四个浏览器测试。

问题所在： 该应用已经支持将捐款分配到多个组织。Opus 甚至遇到过相关代码。

也许用户想要的是略有不同的东西。但 Opus 没有澄清缺少什么，而是构建了第二个重叠的系统。

测试通过了，但现在有两条代码路径代表完全相同的功能。

资深工程师会怎么做以及 sudo L7 的检查： 指出已有的功能，并在构建冗余功能之前澄清用户需要什么。

‍

两个模型都说明了同一个问题：前沿智能体可以非常擅长实现被要求构建的东西，却意识不到请求本身需要被质疑。‍

正确性相似。判断力却大不相同。

我们根据 sudo L7 专家编写的评分标准所衡量的工程技能对其进行分类，这些技能超越了功能正确性。

在功能正确性上，四个领先模型几乎并列：

• GPT-6.1 Sol：82.4%
• Opus 5.5：82.1%
• GPT-6 Astra：81.5%
• Sonnet 5.5：79.6%

但在更广泛的工程技能上，差距扩大了：

• 在思维伙伴关系上，Opus 和 Sonnet 得分为 76.1% 和 74.8%，而 Sol 为 53.0%，Astra 为 51.6%。
• 在沟通上，Sonnet 达到 72.4%，而 Sol 得分为 44.1%。

这些差异在资深级别尤其重要，因为工程师的许多价值来自对架构权衡的推理、发现工单之外的风险，以及帮助他人理解应该构建什么以及为什么。

那超越预期呢？

我们还衡量可选的额外加分标准：这些行为并非完成任务所必需，但经验丰富的工程师会认为它们很有价值。

Opus 5.5 和 Sonnet 5.5 表现突出，满足了超过 60% 的额外加分标准。其他所有模型的得分都低于 46%。

考虑到这些模型在功能正确性上如此接近，这一差距令人瞩目。GPT-6.1 Sol 在正确性上略胜 Opus 一筹，但在额外加分上落后近 20 个百分点。

更好的工程能力代价几何？

表现最佳的智能体同时也是运行成本最高的之一。

Opus 5.5 和 Sonnet 5.5 取得了几乎相同的结果，在未遗漏关键要求的情况下完成了约 45% 的任务。但 Opus 每项任务成本约为 10 美元，而 Sonnet 为 14 美元。

GPT-6.1 Sol 提供了另一种权衡：它以每项任务略高于 1 美元的成本完成了约 30% 的任务。这接近 GPT-6 Astra 的 32%，而成本仅为其约五分之一。

由曾负责生产系统的工程师打造

工程判断力很难被合成。

你需要曾运维过生产系统的工程师，才能知道哪种捷径是危险的、哪种故障模式至关重要，以及哪种实现技术上正确但在职业上不负责任。

每个 sudo L7 任务都由 staff 级别或以上的软件工程师编写。贡献者包括：

• 一位 YC 独角兽公司的联合创始人兼前 CTO，在分布式系统和事故响应方面拥有深厚经验；
• 一位 NASA JPL 的首席软件工程师，涉猎行星飞行软件和大规模消费级系统；
• 一位 Ramp 的 Staff 软件工程师，在金融科技、云基础设施、SaaS 和医疗健康领域拥有 14 年经验；
• 来自 Google、Meta、Cloudera、GitHub 等公司的 staff 工程师。

每个任务都始于前沿模型切实失败的地方。这个基准背后的工程师们不得不真正关心这些事情。

sudo L7 的定位

编程基准测试从 LeetCode 风格的题目已经走了很远。但它们仍然侧重工程工作的不同部分。

SWE-bench：你能修复这个问题吗？

SWE-bench 考察智能体能否在不破坏现有行为的情况下修复真实的 GitHub issue。典型任务会给它一个具体的 bug 或功能请求，并检查补丁是否通过相关测试。

sudo L7 问的是补丁正确之后会发生什么：如果两个智能体都修复了 Terraform 的拼写错误，是否有一方注意到部署它可能会替换掉一个负载均衡器？

Terminal-Bench：你能完成这项技术任务吗？

Terminal-Bench 考察智能体能否在终端中完成一项具体的技术任务。例如，有一项任务规定智能体应在明确的大小和准确率约束下训练一个 FastText 分类器。

sudo L7 把更多这样的判断留待开放：FastText 一开始就是正确的选择吗？什么方案适合这个系统，哪些权衡才重要？

DeepSWE：你能实现所要求的行为吗？

DeepSWE 考察智能体能否在代码仓库中实现大量新行为，并由隐藏的验证器检查其是否有效。

sudo L7 问的是这个可用的实现是否是良好的工程实践：智能体是否选择了正确的设计、注意到了生产环境的边界情况，并验证了真正重要的故障模式？

FrontierCode：维护者会合并这个 PR 吗？

FrontierCode 是最接近的参照。它询问维护者是否会合并该 PR，并使用维护者编写的评分标准来评估正确性、测试、范围、风格和代码质量。

sudo L7 将责任范围扩大到 PR 之外：架构、生产风险、假设检验、验证策略和交接都计入其中。有时正确的输出是代码；有时是架构分析、发布计划，或建议不要进行所请求的更改。

sudo L7 从“代码能跑”不再足够的地方开始。

准备好承担更多责任了吗？

生成代码正变得廉价。工程判断力则不然。

下一代编码智能体需要理解陌生的系统、选择架构、注意到工单中未提及的故障模式、知道何时该提出异议、验证关键事项，并如实说明什么已准备好发布。

L3 通常被交给一个问题并要求提交一个 pull request。L7 被交给的是责任。

sudo L7 衡量编码智能体是否准备好承担更多责任。

想了解更多？请联系 benchmarks@surgehq.ai 获取基准测试集，并查看 sudo L7 排行榜。