AI生成了90%的代码，交付周期却几乎未变

一个数字就能说明大部分问题，而它并不是该团队最引以为傲的那个。在去年9月的云栖大会上，阿里巴巴高德大模型应用平台的Wang Shuxin报告称，技术设计和开发阶段的AI代码生成率为53%。半年后，同一个团队达到了80%至90%甚至更高。这一数字几乎翻了一倍。交付周期却没有明显缩短。开发者的工作量也没有减少。“我们发现了一个令人困惑的事实：效率提升并不明显，”Wang在发布于阿里云社区博客的一次演讲中说。

这两个事实之间的落差，正是教训所在。AI写了更多代码，软件却以同样的速度交付。Wang的团队得出的诊断，同样反驳了AI编程行业大多当作进展来报告的指标。

为什么翻倍的指标没有带来任何成效

第一个原因是软件行业自《人月神话》时代就明白的算术问题。开发只是一条长链中的一个环节：产品提案、产品与工程评审、方案设计、开发、代码评审、测试、集成、上线。每个环节都承担着沟通成本、等待时间和出错的可能。如果你把编码优化了50%，而编码只占整条链条的30%，那么整体收益就是15%。

第二个原因是隐性成本。AI生成的代码带来更多的代码评审时间、更多的调试、更多的返工。该团队的一个具体案例：AI改变了一个核心接口的参数顺序，所有单元测试都通过了，但上线后却导致三个下游服务出现故障。排查这个问题花了整整一天。

第三个原因是上下文。大型任务无法一次性装进模型的“脑海”。一项涉及十几个前端和后端模块的重构工作，无法在一次对话中完成；AI的注意力会分散，早期提出的约束条件会消散。Wang的结论很直白：在遗留应用中，AI编程必须从“凭感觉”转向“按约定”，并配有清晰的验收标准。

解法：让规范成为单一事实来源

Wang将vibe coding定义为“凭感觉编程”：随意向AI抛出几条提示词，让它几秒钟内生成数千行代码。他认为，这对新项目和小的脚本没有问题。遗留应用才是它失灵的地方：遗留应用承载着历史包袱、隐式依赖和嵌入在代码中的业务知识，一个看似合理的AI解决方案可能与这一切都不兼容。

高德的答案建立在它的Qoder工具之上，即规范驱动开发（Specification-Driven Development）。规范不再是一本会逐渐过时的散文式指南手册，而变成了结构化的“意图代码”，由智能体精确执行，同时也是代码必须匹配的单一事实来源。Qoder的Quest Spec模式会引导开发者逐一确认细节，而验收标准正是这套流程可测试之处。“用户登录成功后跳转到首页”是模糊的，Wang说；“登录成功后，用户在3秒内被跳转到首页，且首页显示用户的昵称”才是测试真正能够验证的。整个工作流分为四个阶段：

在SDD之外，高德还应用了它所谓的“缰绳工程”（Harness Engineering）。这个比喻是一匹野马：模型拥有巨大的力量，没有缰绳你就无法骑上它。缰绳有四个支柱：上下文工程，保持单一事实来源；架构约束，在提交前拦截违规行为，因此UI层代码被禁止直接触碰数据库层；反馈循环，测试运行、智能体读取错误日志并自我修正，人工修复的缺陷则固化为规则；以及人工监督，负责Wang所称的AI无法判断的那5%的模糊逻辑。部署则通过阿里巴巴内部CI/CD平台Aone提供的MCP工具形成闭环。

没人解决的指标问题

这一切并不意味着AI编程失败了。它意味着代码生成率从来就不是正确的仪表盘。一个把生成率几乎翻倍却毫无所获的团队，恰恰证明了这一数字衡量的是活跃度，而不是吞吐量。高德现在追踪的是从需求到上线的整个链条，AI在其中是基础设施，而不是一个被美化的自动补全工具。

Wang提出的未解问题诚实地反映了剩余的距离：规范生成仍需要人工干预，并且应该变得更具对话性；智能体团队需要更丰富的协作方式，包括多轮迭代和动态角色分配；知识管理需要更智能的提取和复用。在这些问题改善之前，生成率所承诺的与交付周期实际兑现之间的差距，将不断出现在PMO数据中。

没有人会把代码生成率发布上线。