“它会写代码”在2026年已经不算新闻了。真正的问题是，它写的代码你敢不敢直接合并到生产环境，而不需要花比亲自手写更多的时间去审查和修复？

我们给三个自主编程代理分配了同一个生产级任务，并用唯一有意义的指标来评估结果：这代码，我们敢不敢上线？

打开网易新闻 查看精彩图片

任务内容是为一个已有的Express.js API添加速率限制功能，要求使用Redis支持的滑动窗口算法，能通过路由装饰器按接口配置限额，输出标准的HTTP响应头，在Redis不可用时能优雅降级，并提供全面的测试覆盖。这不是一个玩具基准测试，而是一个每个季度都会出现在真实团队冲刺待办列表里的功能需求。

参与测试的三个代理分别是：Devin，通过Cognition公司改名后的Windsurf桌面平台使用，月费20美元；Claude Code，在月费100美元的Max计划下运行，搭载Opus 4.8模型；以及Cursor的Agent模式，月费20美元的专业版，使用Composer 2.5。我们为每个代理提供了完全相同的代码仓库、需求文档和评估标准。执行过程中没有任何人工干预，我们只是把任务交给它们，然后让它们自己工作。

现有的代码库在中间件注册、错误响应格式以及测试组织方面已经形成了既定模式。我们想看看哪些代理会遵循这些模式，哪些会强行引入自己的代码规范。

Devin自主工作了大约22分钟。它探索了代码库结构，识别出现有的中间件模式，创建了实现文件，然后运行测试套件来验证自己的工作。它在实现中采用了Redis有序集合来实现滑动窗口算法，这是一个可靠的技术选择。每个接口的配置采用装饰器模式，与代码库现有的中间件架构风格保持一致。Redis交互代码很干净，有序集合的实现正确，HTTP头格式无误，并且Devin在动笔之前明显分析过现有的中间件结构。

然而，代码没能达到可交付的标准。问题出在Redis故障时的优雅降级处理上，那里有一个致命的缺陷。当Redis不可用时，中间件并没有按照需求文档要求的那样让请求通过并记录警告日志，而是抛出了一个未被处理的Promise拒绝。错误处理路径只实现了一部分，代码里确实有个try-catch块，但catch块内部的逻辑并未正确完成，导致了未捕获的异常。