AI 编程提效的困局：为什么出码率上去了，效率却没来？
近日，阿里高德团队发布了一项研究，将 AI 生成代码在项目总代码中的占比从 53% 提升至 80%-90%。
这一数字看似亮眼，结果却令人意外——项目交付周期几乎未有效缩短，开发者的实际工作负担也未见显著减轻。
代码输出率近乎翻倍，开发效率却停滞不前。
这种现象并非孤例。许多借助 AI 进行编码的开发者都有类似体会：AI 确实能快速产出大量代码，但整体项目推进速度并未因此加快。问题究竟出在哪里？今天我们就来深入探讨。
AI 写代码的三个核心痛点
在剖析根本原因前，先梳理 AI 编码本身存在的几个常见问题。
其一，生成内容与业务脱节。 AI 缺乏对业务背景和团队编码规范的认知，生成的代码往往“功能无误，但风格与现有架构格格不入”。例如，要求它编写一个登录模块，它可能给出三种可运行的方案，但每一种都与代码库的既有风格不协调。
其二，交互反复导致效率下降。 这听起来有些反常，但许多开发者都有切身体验。当给 AI 的指令不够精确时，人机对话会演变成反复拉锯：你要求修改，它给出新版本；你认为不达标，再让它调整……几轮下来，自己手动编写可能早已完成。
其三，上下文记忆能力有限。 任务规模扩大后，AI 开始丢失关键信息。你在对话开头强调的架构约束和编码规范，到后期可能被遗忘。对话越长，AI 越倾向于只关注最后一条指令。
这些问题在去年已被不少团队注意到。当时的应对策略大致有三类：通过项目文档和规则约束 AI 行为、优化提示词以提升指令清晰度、实施上下文管理以防止信息丢失。
这些方法虽然有效，但解决的仅是表面问题。
出码率上去了，效率为什么没跟上？
真正的瓶颈并不在于 AI 写代码本身，而在于更宏观的层面。主要原因可以归纳为以下几点。
开发并非只有写代码
一个需求从构思到上线，中间需要经历多个环节：产品经理撰写需求、团队评审、技术方案设计、编码开发、代码审查、测试、前后端联调、部署上线。
编码只是其中一环。一些团队的统计数据显示，纯编码时间仅占整个交付周期的 30% 左右。
这意味着，即便将编码效率提升 50%，在整个研发链路中，整体提效可能仅有 15%。而且，AI 生成的代码往往需要更长的审查时间——开发者需要投入更多精力确认代码的正确性，以及是否存在潜在隐患。
因此，仅聚焦于编码环节的优化，效果必然有限。真正的效率提升应覆盖从需求到上线的完整链路。
“VibeCoding”存在风险
“氛围编程”指的是那种随口给 AI 几句描述，便让它直接生成大量代码的使用方式。
在个人小项目中，这种方法或许可行。但在企业环境里，尤其是在运行多年的存量项目中，这种做法无异于埋下隐患。存量代码包含历史遗留问题、隐式调用关系和大量隐藏在逻辑中的业务知识。这些信息 AI 无法知晓，它只能按照自身理解生成代码。
已有开发者踩过这样的坑：AI 生成的代码更改了一个核心接口的参数顺序，所有单元测试均通过，表面看似正常。然而上线后，三个依赖该接口的下游服务全部报错，排查了整整一天才找到问题根源。
这就是存量项目中“氛围编程”的代价——问题不在开发阶段暴露，而是在上线后才爆发。
AI 难以处理复杂任务
还有一个现实问题：当需求涉及十几个模块、前后端联动时，不可能通过一次对话完成。AI 的注意力和上下文窗口都有限，任务越复杂，它越容易遗漏细节、顾此失彼。
这三个问题指向一个共同结论：要让 AI 在团队研发中真正发挥作用，不能依赖个人使用 AI 工具单打独斗，而应将其升级为一套有规范的工程体系。
如何破局
高德团队给出的答案是两个核心工具：SDD 和 Harness。一个负责“做什么”，一个负责“怎么控”。
SDD 规范驱动开发
SDD 全称为 Specification-Driven Development，即规范驱动开发。
在传统开发流程中，需求文档和设计文档本质上只是“参考资料”，真正起决定作用的是代码。文档与代码脱节是常态，文档过期也无人问津。
SDD 扭转了这一关系：规范成为唯一的依据。不是先写代码再补文档，而是先将需求说清楚、说精确，将其转化成 AI 能直接理解的结构化格式，再让 AI 依据规范生成代码。需求变更时，先修改规范，再让 AI 根据新规范重新生成。
SDD 工作流程包含四个阶段：
- 明确需求：人与 AI 反复讨论，将模糊想法转化为明确规范，包括用户场景、验收标准、技术约束
- 拆解执行计划：AI 将规范翻译为具体技术方案和任务清单
- 分任务执行：AI 按任务清单逐步完成，生成代码
- 自动验证：根据规范自动生成测试用例，确认代码与规范一致
其中最关键的是验收标准。好的验收标准必须具体、可测试。“登录成功后跳转到首页”这种描述过于模糊；“登录成功后 3 秒内跳转到首页，首页顶部显示用户昵称”才是合格的验收标准。
Harness Engineering 驾驭工程
Harness 解决的是另一个问题：即使规范已写好，AI 在执行过程中是否可能偏离方向？
想象你骑一匹力气大但没有马具的马，你无法有效控制它。Harness 不是去改造这匹马（模型本身），而是给它装上缰绳、马鞍，让你能够驾驭它。
Harness 包含四个方面的控制手段：
上下文信息。 不是简单地将文档丢给 AI 检索，而是有组织地提供信息。维护一份“单一事实来源”，让 AI 清晰了解项目结构、当前进展和最新文档。AI 不应自行猜测的信息，就不要让它去猜。
架构约束。 这是最硬的一道防线。例如，如果架构规定前端代码不能直接调用数据库，就通过代码检查工具将此规则强制执行——AI 生成的代码一旦违反分层规则，在提交前就会被拦截，连语法检查都无法通过。不依赖“建议”，而依赖“强制”。
自我修正。 AI 必然犯错，关键在于犯错后的应对。方法是建立自动化闭环：AI 写完代码 → 执行测试 → 测试失败 → AI 读取错误日志 → 修改代码 → 重新测试。更重要的是，每次人工修复一个问题后，就将修复经验记录为规则，确保同类错误不再出现。系统从“越改越乱”转变为“越改越稳”。
人工兜底。 人的角色从“编码执行者”转变为“审核把关者”。核心职责是定义 AI 无法处理的模糊业务边界，审核 AI 的产出，并持续优化整套控制体系。
从“跟 AI 说话”到“驾驭 AI”
将上述内容串联起来，可以看出一条清晰的演进路线：
- 最初，大家关注的是提示词工程——如何与 AI 沟通才能让它输出期望的代码
- 随后，演进到上下文工程——重点不在于如何说话，而在于 AI 应该看到哪些信息
- 如今，走向 Harness Engineering——不仅提供信息，还施加约束，让 AI 在受控环境中运行
这三者并非相互替代，而是在不同维度上逐步叠加。对话质量、信息供给、运行约束，三者缺一不可。
写在最后
AI 编程发展至今，瓶颈已不再是“AI 能否写代码”，而是“AI 生成的代码是否可靠、能否真正减轻人的工作量”。
出码率是一个容易产生误导的指标。它衡量的是 AI 生成了多少代码，而非你节省了多少时间。真正值得关注的，是整个交付周期的缩短、返工率的降低，以及开发者的实际负担是否减轻。
要实现这些目标，仅靠让 AI 写更多代码远远不够。需要建立一套完整的体系：需求先规范再执行，过程有约束有兜底，从需求到部署形成闭环。
下一篇将详细拆解这套体系在具体项目中如何逐步落地——知识库如何搭建、需求如何处理、任务如何执行、部署如何自动化。
