正在加载，请稍候
Devin 靠老系统升级与跨平台迁移做到 4.92 亿美元 ARR。AI Agent 开发适合确定性高、可自动验证的任务，本文给任务画像、反例与企业试点护栏三步法。
Cognition 在 2026 年披露：Devin 的年化收入运行率（ARR）已达 4.92 亿美元，企业版用量连续 6 个月环比增长 50%，客户包括梅赛德斯-奔驰、NASA 与高盛。这家估值 260 亿美元的公司，主战场不是炫酷的新功能，而是老系统升级。对想落地 AI Agent 开发的团队，这个信号值得读三遍。
代码 Agent 的价值兑现点，正在从「写新代码」转向「清老账」。
Devin 创始人 Scott Wu 对产品的定位很直白：Devin 主要承担长尾 grunt-work——老软件升级、跨平台迁移、重复改造。这不是谦虚，而是对智能体能力的诚实校准。
Cognition 官方博客记录了奔驰的部署：Devin 与 Windsurf 进入其全球工程组织，起步就选了三块——老系统现代化（legacy modernization）、云原生开发、物流系统。官方博客还专门写过 COBOL 现代化与 .NET Framework 迁移两个主题，后者给出的数字是：过去要数月的工作，现在最快两周。
Nubank 的案例更具体。这家巴西数字银行的 ETL 单体有 8 年历史、600 万行代码、约 10 万个 data class 实现，原计划 1000 多名工程师花 18 个月迁移。把迁移交给 Devin 后，Data、Collections、Risk 三个业务单元数周内完成，工程耗时压缩 8-12 倍，成本节省 20 倍以上。官方案例引用了高级产品经理 Jose Carlos Castro 的原话：工程师不需要把迁移任务做完 100%，只需 review Devin 的改动、做小幅修正、再 merge PR。
奔驰和 Nubank 的任务有一个共同点：确定性高、边界清晰、可自动验证。
我们给客户做老系统现代化时，判断一个任务能不能交给代码智能体，先看三件事：目标状态是否明确、有没有自动验证手段、失败成本是否可控。三个都过，才值得试点。
| 任务类型 | 确定性 | 验证方式 | 表现 |
|---|---|---|---|
| 老系统升级（COBOL / Java 8→17） | 高 | 编译 + 测试 + 回归 | 强，两周级 |
| 框架迁移（.NET Framework→.NET Core） | 高 | 构建 + 测试套件 | 强，官方案例两周 |
| 重复改造（数据类迁移、import 修正） | 高 | 批量校验脚本 | 强，Nubank 8-12x |
| 漏洞修复、测试生成、文档补全 | 中高 | 漏洞复现 + 覆盖率 | 中，适合起步 |
| 需求模糊的新功能 | 低 | 无基准 | 弱，不建议 |
| 核心架构设计 | 低 | 人工判断 | 弱，不建议 |
表格最后两行是多数踩坑团队的起点：让智能体去干它最不擅长的事，再抱怨它不如人。
第一类，核心架构设计。智能体没有组织的架构上下文，也不对系统未来五年负责。让它做模块拆分、技术选型，等于让实习生签架构评审单。
第二类，需求模糊的新功能。没有验收基准时，智能体会「自我发挥」，产出看着能用、一上生产就出事的代码。
第三类，强合规审计链路。银行、医疗、政务场景要求每个改动可追溯、可解释，智能体的执行链路目前还达不到审计粒度。
反面教材我们见过不止一次：某团队让智能体全权改核心交易模块，一周内回滚 3 次。根因不是智能体写不出代码，而是任务本身缺验证基准——交易正确性无法靠编译和单测兜底。想系统了解智能体能力边界，可以看我们这篇关于普林斯顿 6 天实验的复盘。
Cognition 自己的实践也承认这条边界。他们在多智能体的经验总结里写得很清楚：agents contribute intelligence while writes stay single-threaded——智能体贡献智力，写入权限保持单线程、由人掌控。原文在此。这与我们之前判断的单线程 Chat 退场、多智能体换轨方向一致。
我们站内前几篇 AIcoding 商业化系列（如AIcoding 商业化分水岭：Claude Opus 5 系统提示词全泄露解读）讲的是工具选型与团队流程：怎么选模型、怎么搭协作流。这篇要补上另一块：任务分配与验收——哪些活给智能体，哪些活必须留给人。
工具解决「用什么干」，任务边界解决「给什么活」。多数落地失败的团队，问题不在模型，而在把智能体用在了错的活上。
Q：代码 Agent 适合哪些任务？
A：老系统升级、框架迁移、重复改造这类目标明确、能自动验收的任务。参考 Nubank 的 ETL 迁移与奔驰的老系统现代化。
Q：AI Agent 开发会取代程序员吗？
A：短期取代的是 grunt-work，不是工程师。Nubank 案例里工程师从「搬数据类」变成「review PR + 管理迁移」，岗位内容变了，岗位没消失。
Q：怎么判断一个任务适不适合交给智能体？
A：三问：需求是否明确？有没有自动验证手段？失败成本是否可控？三问都过，才值得试点。
Q：智能体写的 PR 要不要人工评审？
A：必须。Nubank 与 Cognition 自己的实践都是 PR 人工 approve，写入保持单线程。
Q：我们没有老系统，能用代码智能体吗？
A：可以从漏洞修复、测试生成、文档补全起步，这些同样满足「边界清晰、可验证」。
有老系统现代化需求的客户，可以先看看我们的案例页，或者私信我们做一次任务边界评估——我们会告诉你哪些活适合交给代码 Agent，哪些不适合。