AI写代码≠能上线

你在 Cursor 或 Claude Code 里打开项目，说了一句"把这个用户模块重构一下，加上权限控制"。

AI 嗖嗖地读完了项目结构、接口定义、现有的认证逻辑，然后直接在三个文件里改了代码。它改得很认真——加了 Role 枚举、更新了接口鉴权、还顺手补了注释。

你看了下 Diff，确实比你预想的干净。提交，合入。

CI 跑了三分钟，然后……

测试失败了。

不是因为 AI 改的逻辑有问题，而是因为它引入了新的权限字段，但下游依赖这个接口的另一个服务还在用老版本——那个服务也在重构，但 AI 并不知道它们会在同一天合入。历史代码里埋着时间差，AI 看不到。

你修了接口版本依赖，再跑。CI 通过。部署。线上跑了十分钟，告警来了——新加的权限字段没有做空值保护，边界情况漏了。

从"AI 直接改了代码"到"功能真正上线"，中间大概隔着：接口兼容性、测试覆盖、边界条件、CI/CD 流程、线上监控。

这不是某个人的问题。这是每个引入 AI 的工程团队，都在交的学费。

真实数据印证了这个感受。

这是某互联网大厂一年 AI 使能实践里，最扎心的两个数字。

生成率 30-50%：当开发者向 AI 工具发起请求，有三到五成的概率，AI 能给出一段看起来可用的代码。

听起来挺高了？别急着高兴。

采纳率 20-30%：AI 给出的代码，真正被开发者直接使用（不做修改或只做微小修改）的比例，不到三成。

换句话说：AI 吭哧吭哧生产出来的东西，十次里有七次，工程师还得重写或者大改。

换句话说：AI 十次出力，七次白干。

这个 Gap 来自哪里？AI 生成代码只是整个研发流程的一个起点，之后还有编译、单元测试、集成测试、Code Review、缺陷修复、合并部署……每一个环节都是一道坎。

AI 强在中间那一格。周围全是活儿。

核心洞察：AI 是加速器，工程能力是底盘。

底盘不稳，加速越快，漂得越远。

在内部推进 AI 使能时，部署了多个工具，覆盖代码生成、测试生成、知识管理三个核心场景。我们一个一个拆。

AI 代码生成工具是最早上线的 AI 编程产品，定位是"代码生成加速器"。

开发者可以在 IDE 里直接提问，比如"帮我实现一个用户鉴权的接口"，AI 就会在项目中直接修改或新增代码文件——不再只是输出文字建议，而是真的写进去。

实际效果怎么样？

初期数据：生成率（AI 能给出代码建议的比例）约为 35-45%，在简单、常见的编程任务上表现较好——比如生成 CRUD 接口、常见工具函数、简单算法。

采纳率：早期只有 20-25%，与平均水平一致。

为什么采纳率低？问题出在哪里？

场景理解偏差。这类工具的对话上下文有限，它不知道你正在处理哪个服务、哪个数据模型、哪个接口规范。它给的是"一般正确"的代码，而工程需要的是"这个项目正确"的代码。

缺乏真实上下文。AI 看不到你们的内部依赖、团队约定、历史债务。它写的是标准答案，你们考的是开卷考试。

边界条件缺失。AI 倾向于生成"happy path"——理想情况下的正常流程。但生产代码需要处理：超时、重试、鉴权失败、网络异常、参数越界……AI 在这些地方往往"偷懒"。

怎么改的？思路很简单：让 AI 少做它不擅长的事，多做它擅长的事：

几轮迭代后，采纳率提升到 35-40%。不是 AI 变聪明了，是工程手段弥补了它的不足。

智能测试生成平台，目标是解决"测试覆盖率不足"这个老大难问题。

研发团队都知道测试重要，但写测试是个苦活儿：无聊、费时、短期看不到收益。所以测试覆盖率长期低迷，一出问题就是线上故障。

AI 来写测试，看起来是完美的解法。

实际情况呢？

生成率：约 40-50%，覆盖率较高的场景（接口规范、数据模型清晰）AI 表现较好。

采纳率：初期只有 15-25%，比代码生成还低。

问题在哪里？

测试用例不等于测试价值。AI 可以生成大量测试用例，但不一定生成有价值的测试用例。很多 AI 生成的测试，是在测试"边界条件A调用了函数B"这种无意义的路径，而不是真正高风险的业务逻辑。

断言质量差。AI 生成的断言往往是默认值（assert response.status_code == 200），但真正有价值的断言要检查数据正确性、副作用、并发安全——这些 AI 给不出来，除非有人告诉它"你们关心的是什么"。

可维护性问题。AI 生成的测试代码往往缺乏清晰的组织结构和注释，三个月后工程师自己都看不懂当初的测试在测什么。

改进路径同样不是让 AI 升级，而是补充工程约束：

平台迭代后，测试采纳率提升到 30-35%。更重要的是，覆盖率从 45% 提升到了 68%，这是实打实的工程保障。

这是内部的代码问答与知识总结工具，目标是让分散在代码评审、文档、会议纪要里的知识，被 AI 自动整理、沉淀、检索。

工具的逻辑很简单：工程师日常产出大量有价值的经验，但散落在各个角落，没人整理。AI 把它们挖出来、归好类，需要的人随时能搜到。

这个方向本身没错。但知识沉淀从来不只是技术问题——它是个社会学问题。

没人愿意主动贡献知识。这是企业内部知识库的通病：读的人多，写的人少。这类工具用 AI 自动生成知识摘要，降低了贡献门槛，是一个正确的方向。但 AI 生成的质量不稳定，有些总结有用，有些则是正确的废话。

知识的上下文消失了。一段代码评审结论，放在原始 PR 里是有上下文的（为什么这样做、为什么不那样做、历史原因是什么）。AI 提取出来单独呈现，上下文丢失，用的人不知道边界在哪里，容易误用。

知识的保鲜问题。AI 总结的是某一时刻的知识，代码在变、架构在变、人员在变，沉淀的知识很快就会过时。如果没有人持续维护，平台里的内容会逐渐变成"历史档案"而不是"工作参考"。

改进思路也是补充工程机制：

这个案例说明一件事：AI 工具可以降低知识整理的成本，但无法替代知识管理的意愿和机制。工具再好，没人维护，也是无源之水。

三个工具的实践指向同一个结论：AI 能生成内容，但端到端交付还需要三样东西——链路、数据、机制。

把 AI 工具当独立产品用，是最大的误区。代码改了不知道影响谁，测试插入了没人管，知识沉淀了没人更新。

把 AI 工具直接嵌进 CI/CD 流水线：

这样，AI 生成的内容不是直接交给人，而是先过工具链。人的角色从"审核 AI 输出"变成"定义规则、设定阈值、处理异常"。效率和安全同时提升。

链路化的本质，就是用工程流程的可预测性，兜住 AI 的不确定性。

AI 工具的第二个关键，是建立真实的反馈闭环。

采纳率 20-30%，剩下的 70-80% 发生了什么？被拒绝了，为什么拒绝？修改了，改了什么？这些数据才是让 AI 工具持续变好的原材料。

内部建立了一套反馈采集机制：

这套机制的核心逻辑很简单：你用什么数据训练，AI 就擅长什么。没有真实反馈，AI 永远只能用通用数据给出通用答案。

回到最初的问题：AI 能生成代码，为什么不等于能端到端交付？

因为端到端交付需要的，不只是"生成代码"这一个能力。

它需要：编译检查、测试覆盖、Code Review、缺陷追踪、数据反馈、流程机制、知识管理……每一样都是工程能力，不是 AI 能力。

AI 使能的本质，是用 AI 能力叠加在已有的工程能力上，放大效率，而不是用 AI 替代工程能力。

没有测试框架，AI 生成测试就是空中楼阁。没有 CI/CD 流程，AI 生成的代码就是裸奔。没有反馈机制，AI 工具永远停在初始版本。

工程能力是底座，AI 是顶上的加速层。底座越扎实，加速效果越好；底座不稳，AI 越快翻车。

回到开头的那个场景：AI 直接在项目里改了代码，但接口兼容性、测试覆盖、边界条件、CI/CD 链路，每一道都需要人来兜底。

这不是 AI 不够好。是 AI 做了它能做的事，而你还需要做它做不了的事。

那些事情是什么？

定义问题。AI 能写代码，但你得先告诉它：解决什么问题、用什么接口、数据格式是什么。

验收质量。AI 生成的代码能跑，但能跑不等于正确。你得定义"正确"的标准是什么，然后验收它。

管理上下文。AI 不知道你们团队的约定、历史债务、业务约束。你得补充这些信息，或者设计流程让 AI 能读到这些信息。

建立机制。工具再好，没有维护机制也会退化。反馈机制、知识更新机制、持续优化机制——这些不能少。

AI 不会让程序员失业。

但会用 AI 的程序员，正在重新定义"写代码"这件事的边界。

那条边界，已经从"写出正确的代码"，移动到了"交付有价值的功能"。