AI写代码快十倍，交付为何没提速

Google在Cloud Next上给出的数字是：新代码里75%由AI生成，半年前还是50%。OpenAI内部更激进，普通工程师约99%的输出Token来自自研Codex，手敲键盘已经接近象征性动作。

单看这些比例，AI的代码生产能力似乎已经压过大多数工程师。我们深度用了半年AI Coding，最初也是这个判断——直到把它塞进真实的企业系统里跑，才发现代码生成变快之后，浮出水面的是另一批问题。它们过去一直被”写代码慢”这个瓶颈挡在后面。

蜜月期里那种不真实的顺畅

从代码补全，到读需求、搜资料、分析代码、出方案，再到自己改代码、写测试、跑验证，Coding Agent的边界两年内扩了好几轮。它不再只是”帮工程师敲字”，开始承接完整的开发任务。

我们也经历过一段明显的蜜月期。以前一个中型需求，从接手到看见第一个Demo，要过需求分析、代码阅读、技术调研、方案设计、内部讨论、实际开发这几道关，哪怕需求不复杂，从开工到出结果通常也得数周。上了Agent之后，这个尺度完全变了：一两天内跑完理解、搜索、调研、设计、开发和测试，一口气产出两三万行C++也不稀奇。相对独立的问题，几小时甚至一两小时就能拿到完整结果。

更让人上头的是，它不只写得快，还能先甩出一套看着相当专业的方案，再让工程师判断采不采纳。这种体验很容易催生一个判断：人提需求，AI做实现，软件研发是不是要换阶段了。

生产环境很快给了我们一个反例。

半天写完的跨分区Join，卡了两周

DolphinDB有一部分Join算子需要支持跨时间分区计算。用户一般按交易日分区存数据，方便分布式执行。但加密资产是7×24小时连续交易，数据不天然以自然日为边界，跨天、跨时间分区的计算需求越来越多，这块能力得补上。

任务交给了当时最新一代GPT模型驱动的Agent。结果确实惊人：不到两个工作日，从分析现有代码、理解需求、设计方案，到写功能、补测试、生成设计文档和使用文档，整套流程基本走完，初步测试也没发现明显问题。按传统流程，这类需求牵扯底层执行逻辑、分区机制和多个Join算子，人工开发往往要数周。第一反应不是怀疑，是兴奋。

测试范围一扩大，问题开始冒头。而且不是简单的”代码写错了”。Agent对需求的理解基本正确，算法设计也没明显毛病。真正的麻烦在于，它没有完整掌握几十万行代码背后那些分散的技术约束：哪些分区方式有特殊限制，哪些数据类型还没支持，哪些能力只存在于SQL层而函数式接口没实现，哪些历史遗留限制会影响新功能。测试阶段最终挖出若干大类、几十个预期外问题。

这次经历没降低对AI的判断，反而更确信：AI Coding已经够强了，真正该重新想的是——代码生产速度大幅提升之后，企业的研发体系该怎么改。

编码提速了，交付没跟上

一个需求从提出到上线，远不止编码。需求分析、方案设计、开发、Review、测试、发布，每一环都可能是瓶颈。过去编码占大头，提编码效率收益明显；Agent几小时干完过去几周的活之后，其他环节的权重迅速上升。

这里可以算一笔粗账。假设开发从5天压到1天，Review仍要2天，测试仍要3天，发布仍要2天，总周期从原来的十几天下不来多少，甚至可能更长——AI产出的代码和PR更多，Review和测试的工作量跟着涨，原本不突出的环节变成新堵点。这就是阿姆达尔定律在软件工程里的样子：加速比受限于未加速部分。

实操上可以用一个简单方法定位瓶颈：统计一个需求从提交到合并的端到端耗时，拆成编码、评审等待、测试执行、发布四段，分别算出占比。哪一段占比超过30%且没有并行化手段，就是下一个该动刀的地方。如果编码段已经从40%降到10%而评审段升到35%，继续优化AI写码速度的边际收益接近于零。

“两小时写完，后续几周填坑”这种现象，多数时候不是AI写错了，而是复杂系统里修Bug本质上是在补原有架构和能力的缺口。局部功能可以快速完成，但要进生产系统，依赖、验证、兼容性这些事远超功能本身。

所以下一阶段的关键不是让AI写得更快，而是让整条交付链路接得住这个速度。Code Review、自动化测试、CI/CD、发布和运维，都得逐步进入AI驱动的工程体系。

真正的障碍不是幻觉，是隐性约束

AI在复杂老系统里出错，最容易归因到”幻觉”。我们的感受不太一样。Agent找到的资料、分析出的结构、设计的方案可能都合理，问题在于这些信息只是系统事实的一部分。

一个跑了多年、几十万行代码的软件，真正的约束不会全写在架构文档里。它们藏在历史接口实现里、异常处理逻辑里、事故后留下的保护代码里，或者团队默认的规矩里。人类工程师未必一次看清全部，但至少知道哪里可能有坑，知道该问谁、重点查什么。

Agent像个能力很强但刚入职、没受过公司培训的新人。给它一个独立的新系统——没有历史债、架构清晰——它表现出色。扔进运行多年的大型系统，面对”分区””别名”这种看着普通的功能，背后可能压着一堆历史代码和技术债。它能理解一部分，但保证不了覆盖所有隐藏约束。

所以企业AI Coding的核心问题，不是简单堆Token、堆文档、堆Context Window。这已经超出Context Engineering的范畴，走向更广义的Environment Engineering。

代码越便宜，越容易重新造轮子

代码生成变便宜之后，”重新实现一遍”变得异常容易。但企业真正稀缺的从来不是代码。

一家跑了多年的科技公司，沉淀下来的是数据库、计算引擎、中间件、内部SDK、业务组件，以及围绕它们形成的生产验证能力。熟悉技术栈的工程师默认会复用：要处理数据，不会重写数据库；要复杂计算，调用已有引擎；要业务能力，找现成组件。

Agent不一样。如果这些能力没有被显式暴露出来，它很可能根本不知道企业已经有，转头就把轮子重造一遍。这不是Agent笨，是环境没给它看见。

把工程环境改造成Agent能读懂的形态

既然问题出在环境，就得从环境下手。我们把这件事拆成三层来检查，每层都有可验证的落点。

知识层：架构文档、接口约束、历史事故记录是否可检索、是否结构化。验证方式很直接——让Agent回答”这个模块有哪些已知限制”，答不全就说明知识没暴露到位。

能力层：内部SDK、计算引擎、业务组件是否封装成Agent可调用的形式，比如通过MCP暴露工具接口。检查项是让Agent完成一个需要复用内部组件的任务，看它是调用现成能力还是自己重写。

治理层：用户身份、权限边界、执行过程是否对Agent透明且可审计。至少要能回答：这个Agent以谁的身份执行、能碰哪些资源、调用链有没有留痕。

这三层过去是为了方便人协作，现在同样决定Agent能不能真正干活。我们做DolphinX时核心考虑的就是这个：不是给企业再加一个Coding Agent，而是为Agent提供进入企业软件环境所需的完整条件——知识可沉淀可检索，重复工作封装成Skill，历史交互形成Memory，企业已有能力通过MCP等机制被调用，身份、权限和执行过程纳入统一治理。这样Agent面对企业系统时，不用每次从零理解，也不用把企业知识复制一份到外部AI系统里。

过去是工程师适应企业的软件环境。AI时代，还得让软件环境能被Agent理解。

基础设施是杠杆，不是被替代的对象

AI能生成Python、SQL，不代表它自动取代数据库、计算引擎、中间件和业务系统。PB级数据仍然要数据库存和查，复杂数据处理仍然要专业计算引擎，实时数据仍然要流处理，系统之间仍然要可靠的数据服务和中间件，权限和审计仍然归企业治理体系管。

AI更合适的位置是理解用户意图，然后选择和组合那些已经存在、具有确定性的能力。以DolphinDB为例，它在金融、能源、工业场景里经过多年生产验证，沉淀了数据模型、计算函数库、流处理框架和分布式执行能力。这些东西不是几行代码能替代的，是企业在真实业务里一点点磨出来的。Agent不需要也没必要”重新实现”一个计算引擎，它只需要知道这些能力存在、理解怎么调用，把精力放在理解意图和组合能力上。

代码进CI那一刻才是真正的考验

AI生成的代码要变成可交付成果，绕不开CI流水线。这里有几个典型断点值得提前设防。

一是依赖漂移。Agent容易引入训练数据里常见但企业未批准的第三方库版本，门禁上应锁定依赖白名单，构建阶段校验lock文件是否被意外改动。二是测试覆盖虚高。Agent补的测试常覆盖正常路径，边界和异常分支缺失，可以在流水线里加覆盖率增量门禁，要求新增代码的分支覆盖率不低于阈值，而不是只看总覆盖率。三是提交粒度失控。一次PR塞进多个不相关改动，Review成本翻倍，用提交规范检查加PR体积阈值拦截。四是敏感信息泄露。Agent可能把示例密钥写进代码，secret扫描必须在pre-commit和CI两处都跑。

这些门禁配置本身不复杂，难的是在AI提速之后仍然坚持执行。流水线一旦为了”让AI的PR快点过”而放松，前面所有讨论都白搭。

三个结论，换个说法

第一，从Coding Efficiency走向Delivery Efficiency。AI Coding最容易量化的是代码生成量、Token消耗、PR数量、开发耗时，但这些指标不天然等于业务结果。AI让一个工程师一天开十个PR，而评审、测试、发布只能消化两个，企业得到的不是十倍交付能力，是八个排队等处理的PR。AI Coding的ROI最终要回到端到端的交付效率上，自动化测试、代码评审、CI/CD、发布策略、质量验证体系得同步升级。AI解决的是生产代码，企业要解决的是消化代码。

第二，建设Agent可理解的工程环境。Agent面对复杂企业系统，问题往往不是完全不会，而是抓不住分散在代码、文档和人员经验里的隐性约束。架构要更清晰，组件要更可发现，知识要更易检索，历史经验要可复用，工程规范要可表达，工具要可调用，权限边界要对Agent透明。这就是前面说的三层检查清单要实现的事。

第三，基础设施是AI的杠杆，不是替代品。AI不会因为能生成代码就取代数据库、计算引擎和业务系统。它更适合理解意图、组合已有能力。企业多年打磨的基础设施承载的是确定性，Agent把不确定性部分——理解需求、编排调用——接过去，两边各司其职。