Devin 改老系统省下 37%：老系统就是验收标准

一家物流公司要把订单录入和整个运输生命周期的规则，从 Access 表单和 VBA 宏里搬出来。预算固定，交付窗口很紧，而原来那套业务规则一条都不能丢。7 人的 Cognizant 团队用 Devin 完成这次转换，把表单重写成云原生应用，同时生成测试、部署流水线和文档；每一处改动都要由技术负责人或架构师签字之后才允许合并。项目上线后，客户自报的净成本比常规重写方案低 37%。

37% 是怎么算出来的

这个数字来自 Cognizant 与 Cognition 在 9 月 23 日发布的新闻稿，Odyssey Logistics 的 CIO 在稿里署名背书，说他们把 AI 用在了该用的地方，并且人留在关键决定上。也就是说，数字由当事双方提供，没有第三方审计。稿子里写明的对照对象是「常规重写方案」；如果换成另一家供应商的报价和另一套范围，37% 会立刻变化。买方在谈判桌上要做的第一件事，是让供应商把对照基线和范围写进合同，否则这个比例无法复核。

稿子里还有一句更值得看的话：交付吞吐量大约涨了三分之一。成本降了 37%，吞吐只涨三分之一，两个数字之间的差距说明省下来的不是「写代码的手」。那省下来的到底是什么，答案藏在这次工作的性质里。

转换类工作为什么能被压住：老系统就是标准答案

多数 AI 项目卡在验收这一关：什么叫做完了，谁来判。转换类项目没有这个困难，因为目标行为已经被现有系统写死了。旧表单怎么算、按什么顺序校验、遇到异常怎么处理，全都能在运行中的代码里查到旧行为。新系统写完一条规则，拿同一批输入在两个版本上各跑一遍，输出不一致立刻就能看见。验收标准不需要重新定义，它已经在生产里跑了十年。

换句话说，AI 在这里的产出可以被自动过筛。验证的边际成本低，生成的量才能被吃下去；验证跟不上，写得再快也只是堆在队列里。这次能在固定预算下承诺交付，靠的也是同一件事：范围由旧系统划定，不依赖需求文档写得完不完整。

这三条同时成立，自动化才谈得上省成本。少一条，验证的活就得人来做，账立刻反过来：多出来的差异要逐个解释，解释不了的地方还要重新设计。

同一份稿子里的另一组数字，性质不一样

Cognizant 在稿里也给了自己内部工程的数字：释放就绪的代码时间缩短超过一半，绿地开发提速 5 到 6 倍。这两个数字和 37% 不是一类东西。它们是内部工程指标，没有对照方案，也没有外部核验，只能当方向看。

更值得留意的是它们指向的工作类型。绿地开发没有老系统当标准答案：需求是新写的，验收标准来自人的判断，很难自动判定。同一份材料里，有标准答案的活报出了与常规方案对比的成本差，没有标准答案的活只能报速度倍数。这个并列本身就是一条可以带走的边界。

钱从谁的手里流到谁的手里

传统重写项目按人天或人月报价，预算跟着人头走一年。这次的事实是：7 个人交付了原来要按一年期配人的范围，客户按固定预算结算。也就是说，被压掉的不是人的能力，是计划里那些「备用人力」和等待时间。

这里有一个利益方向的问题值得买方留意。在按人天计价的合同里，验证自动化的收益归客户，不归供应商，所以双方对这件事的积极性并不一样。要让效率真的落到自己的账上，合同结构得先改——固定预算加明确的验收标准，比按人天结算更容易把节省留在客户一侧。

瓶颈在复核，不在生成

7 人团队、每一处改动都要签核，这两件事合起来说明了吞吐上限由谁决定：能读懂这次改动的人有多少，一轮能签多少件。Devin 生成多少代码并不改变这个上限，它只是把等待从「写」挪到了「审」。

落到立项上，第一个该问的问题不是模型多强，而是复核带宽有多少：谁签字、按什么标准签、一天能签多少件。这个数字决定了项目能开多大，也决定了 agent 该以什么粒度交付改动——一次交一个表单，还是一次交一个模块。

什么情况下这套方法不成立

• 规则不在代码里。如果业务规则只活在人脑和口头流程中，旧系统给不出标准答案，转换会退化成重新设计，AI 的速度优势会被需求澄清吃掉。
• 复核带宽不足。产出堆在待签队列里，吞吐由签字的人决定，不由 agent 决定，成本也不会降下来。
• 旧系统的缺陷也是标准答案的一部分。把遗留缺陷忠实复制进新系统是真实风险，项目要先区分规则与缺陷，这一步目前没有自动化，只能靠人划线。
• 口径差异。37% 是相对常规重写方案的净成本，既不等于单条任务的成本，也不包含上线之后的运维与变更成本。

这次案例没有回答的问题

稿里没有说这 37% 是否已经包含返工。转换项目里最常见的时间消耗就是上线之后发现行为差异再回头改，如果返工成本记在后面几个阶段，净节省的数字会变。稿里也没说这套方法产出的代码由谁维护、后续变更怎么继续用同一套比对。这两条在尽调时都该问，问不到就按未证实处理。

把老系统当验收标准，先得让老系统跑起来

标准答案不会自己出现。要让旧系统的行为成为可比对的东西，团队得先把它在隔离环境里跑起来：装上已经没人维护的运行时，把上游依赖换成桩，把历史输入整理成一批可以反复重放的样本。表单类工作流逻辑有个好处，它的依赖通常局限在数据库和文件目录，重建运行环境比核心交易系统便宜得多。

换句话说，标准答案不是白拿的，它是一项前期工程。不少转换项目卡住不是卡在生成代码，而是卡在旧系统已经跑不起来：运行时找不到、依赖的下游接口早下线、批处理窗口被别的业务占着。谁在立项前把这件事查清楚，谁才有资格承诺固定预算。这一段工作不出现在任何案例稿里，但它决定了后面所有数字能不能成立。

对供应商来说，这笔账落在损益表的哪一行

效率的收益要归供应商，交付方式就得从人天换成固定价加可复用资产。传统集成业务按人头计价，用的人少了收入就少；只有把转换过程沉淀下来——旧代码的解析器、测试生成、行为比对工具链——下一个同类项目才能用更少的人交付同样的范围，节省才会留在供应商自己手里。这也解释了这类合作为什么会从单个客户项目长成一组标准服务。

买方可以顺着这个逻辑问两个问题：转换用的模板和比对工具链归谁，项目结束后能不能留在自己这里；如果这套资产留在供应商手里，下一个项目的报价里有多少是重复建设的钱。问得越具体，后面的续约越省事。

我们的判断

这个案例里真正可复制的不是 Devin，也不是 37%。Odyssey 在把主平台交出去之前，先在一个独立的老应用上把同一套方法跑了一遍，21 天收口，用那次的结果决定要不要继续。这是一道证据门：它不证明 agent 有多强，它证明这套方法在他们的数据、他们的规则和他们的复核能力上能收口。

第二句更硬一些：把老系统当验收标准，等于把 AI 的不确定性关进一个能自动判分的笼子里。买方真正买到的不是「自动写代码」，而是「每一次改动都能被证明与旧行为等价」。这句话可以直接写进合同语言，也可以直接写进验收清单。

反过来看，绿地开发就是这个笼子之外的地方。那里没有标准答案，速度的倍数再漂亮，也换不成一份可以签字的验收结论。同一家供应商在同一份稿子里给出的这两组数字，刚好把这条边界标了出来。

采购和交付方现在能做的四件事

• 先在一个独立的老应用上跑一遍，把那次结果当立项依据，而不是拿供应商的案例当依据。
• 在合同里写清对照基线与范围，让成本比例可以被复核。
• 把签核人和签核标准写进交付流程：谁签字、签的是行为等价还是代码风格、一天能签多少件。
• 把可自动比对的旧行为覆盖率列为项目指标，用它决定范围能不能扩大；每纳入一个新模块，都要重新测一次覆盖率，因为新模块未必具备同样可比对的条件。

同一套方法搬到别的行业，先看三个条件

转换类的工作几乎每个行业都有：保险的保单规则、制造业的工单流转、银行的报表预计算、各类 ERP 的定制模块。它们能不能用这套方法做，取决于三个条件同时成立：旧行为可枚举、输入可以重放、差异可以自动判定。这三条不成立时，项目会从转换变成重新设计，工期和预算的算法也跟着变。

• 旧行为可枚举：规则写在代码或配置里，不必靠人的记忆还原。
• 输入可以重放：历史输入能整批取出来，并且不依赖已经下线的外部系统。
• 差异可以自动判定：两条结果的差别是机器能判的，不需要人解释像不像。

反过来看，如果所谓的规则实际上靠人的判断维持——催收话术、定价里的例外审批、老员工口中的经验——旧系统里就没有对应的行为可查。这类活要先做流程显性化，收益周期会长得多，也不该拿转换类项目的比例去承诺。

迁移做完之后，比对这套工具留在谁手里

转换完成并不意味着这套东西就废了。旧系统的行为在项目结束后仍然是一份回归基线：下一次改表单、加字段、动校验顺序，都可以拿同一批历史输入再跑一遍，看新版本有没有把别的地方碰坏。把这套比对留在日常变更流程里，迁移项目才会从一次性交付变成持续可用的资产。

这件事对买方比省下的 37% 更有长期价值，因为它把「每次改动都有人签字」从项目期的纪律，变成了上线后的默认流程。反过来，如果比对工具链留在供应商手里、按项目计价，这笔钱每换一次需求就要重新付一次。

参考来源

• Cognizant 新闻稿：Cognizant and Cognition put autonomous AI engineering into production at Odyssey Logistics（2026-09-23）
• Analytics India Magazine：Cognizant, Cognition Claim AI Engineering at Odyssey Logistics Saved 37% Costs
• 第三方市场分析的保留意见：单次受控部署加强制人工复核，不足以证明自主编码的单位经济学（AllMind，非独立审计）