前段时间，团队里有个同事借助 AI 做了一个功能模块。
一周多，代码基本写完了。放在以前，这个模块开发时间可能要排上一两个月。
项目编译启动没问题，主流程也走通了。AI也帮忙跑了几十上百个测试用例，全部通过。看到这里也许你会觉得这应该算是一个很典型的 AI Coding 提效案例？
然后，它到了测试环节的时候卡住了。事情的原因是这样的：测试看完改动后，问了几个比较很实在的问题：这次到底影响了哪些链路？历史数据怎么处理？和其他系统联动失败了怎么办？出了问题能不能回滚？
有些问题开发能回答，有些却很难一口说清楚。
于是就出现了这样一个尴尬的局面。开发觉得：“代码已经写完了。” 测试想的是：“这东西我怎么敢接？”
后来，这个一周多写完的模块，在上线前拖了几个月。
你也许会有点不理解。代码都写好了，为什么不能赶紧测、赶紧上线？
今天我们详细展开来聊聊这个事情。
你的需求真的做完了吗？
站在开发的角度，功能能运行、主流程能走通，确实可以说代码做完了。
但测试接手时，面对的是另一套问题。
这次改动碰了哪些数据库表？会不会影响老用户？线上有没有特殊数据？失败之后会不会产生脏数据？原来的接口有没有其他业务在偷偷使用？
这些问题不弄清楚，测试就很难判断该测到什么程度。
测少了，怕漏掉风险；全部重新测一遍，成本又高得吓人。
测试同学并不是不愿意接。他们拿到的是一份能够运行的代码，却没有拿到一份足够清楚的影响说明。
开发完成了实现，但整个团队还没有完成对这个需求的理解。
企业研发里经常有这样的情况：写代码的人觉得事情已经到了终点，后面的人却发现，完整的流程都还没弄清楚。
自从有了AI之后，这种落差变得更明显了。这也是我很怕经验不足的同事使用AI快速交付代码出问题的原因。
以前开发要花一个月写代码，很多问题会在这个过程中慢慢冒出来。写到某个逻辑时，开发会发现历史数据不对；联调某个接口时，会发现还有一套旧版本在使用；改一个字段时，会顺便找到几段不能删除的兼容代码。
现在，AI 可以在几天内把代码推出来。
代码提前到了终点，那些原本会在一个月里陆续出现的问题，却没有一起消失。它们只是被集中推给了后面的测试、评审和上线环节。
AI 省下了编码时间，省不了理解和验证
现在 AI 写代码确实很快。
搭一个接口、写一个页面、补一段脚本、做一个 CRUD 模块，只要目标说得比较清楚，很快就能得到一版像模像样的实现。
以前要自己查文档、搭结构、写样板代码，现在很多都可以交给 AI。对于开发个人来说，这种效率提升非常直接。
但企业里的需求，很少只是“帮我写一段代码”。
真正麻烦的，通常藏在兼容性，比如：“兼容历史数据”。历史兼容落到具体系统里，可能要先弄清楚：哪些年份的数据需要兼容，老版本存的是什么格式，过去有没有人工修过数据，异常记录要不要跳过，重新计算会不会影响已经出过的报表。
最后写出来的迁移脚本也许只有几十行，前面把这些事情弄明白，却可能要花几天。
AI 知道数据库迁移通常怎么写，也知道异常处理有哪些通用方式。但它不知道你们几年前为什么留下了一段看起来很奇怪的判断，更不知道那段代码背后是不是发生过一次线上事故。
很多企业系统真正重要的上下文，并不在文档里。
它可能藏在老代码里，藏在某次故障复盘里，藏在一个已经离职的同事留下的注释里，甚至只存在于某个老员工的记忆里。
AI 能帮人更快地敲出实现，却不能自动补齐这些背景。
所以它省下的主要是编码动作，不是理解业务所需要的判断。
而在真实项目里，后者往往更贵。
当代码一下子出现，验证就成了新的瓶颈
以前代码是慢慢写出来的。
开发一边写，一边理解，一边修改。很多判断虽然没有沉淀成文档，至少在写代码的人脑子里走过一遍。
现在不一样了。给 AI 一段需求，它很快就能生成几百行代码。有时开发自己还没完全想清楚实现细节，代码已经摆在面前了。
接下来省下来的时间，并不会凭空变成交付效率。
开发还要读代码，确认它有没有误解需求；Review 的人要判断边界条件有没有遗漏；测试要重新梳理影响范围；上线前还要确认监控、灰度和回滚是否可靠…
这些事情只要少做一步，风险就会继续往后传。
开发没有认真确认，风险就传给 Code Review。
Review 没发现，风险就传给测试。
测试也没覆盖到，最后接住它的就是线上用户。
所以 AI 生成的代码越多，团队越不能只盯着“生成速度”。
更重要的是，这些代码有没有单测，关键改动有没有说明，影响范围有没有人确认，失败以后有没有回退机制。
这也是为什么有些团队用了 AI 之后，开发者个人感觉明显变快，整个团队的交付速度却没有太大变化。
原来最慢的是写代码。
现在写代码快了，大家才发现，真正堵住交付的可能是需求边界、跨系统协调、测试环境、历史数据，或者根本没人愿意承担上线风险。
AI 没有制造这些问题，只是把它们提前暴露了出来。
个人变快之后，组织的瓶颈仍在
软件交付不是开发把代码提交以后，其他人依次点一下确认就走完流程了。
一个需求从提出到上线，中间要经过很多人。
产品要把边界讲清楚，开发要确认实现方式，测试要知道改动会影响哪里，相关系统要配合联调，运维或者平台团队要准备发布，出了问题还要有人处理。
如果开发这个环节突然提速了一倍，其他环节却没有变化，结果不一定是整条流程变快。
更常见的情况是，后面的队列变长了。
以前测试一周接两个需求，现在开发借助 AI 一周交过来五个。每个需求都说“主流程已经跑通”，但缺少完整的影响说明，测试只能自己重新梳理。
从开发的视角看，效率提升非常明显。
从测试的视角看，工作量变多了。
从公司的视角看，真正上线的需求可能并没有增加。
这也是为什么我现在越来越不太相信“AI 代码占比”这个指标。
AI 写了 60% 还是 80% 的代码，只能说明大家在使用 AI，不能直接说明研发效率提高了。
企业最后需要的也不是更多代码。
我更愿意看的是，一个需求从确定到上线到底花了多久，返工有没有减少，测试是不是更轻松，线上问题有没有增加，以及团队能不能持续、稳定地交付更多需求。
如果 AI 生成代码的比例越来越高，但 Review 越来越累，测试排期越来越长，上线越来越谨慎，那只是开发动作变快了。整个团队并没有真的变快。
能跑和敢上线，中间还隔着工程
上面说了这么多，并不是劝退大家用 AI 做东西。
恰恰相反，我很支持产品、运营、设计、财务或者数据同学用 AI 做小工具、页面和 Demo。
过去一个想法要先写需求、找研发、等排期。现在自己花半天做出一个能操作的版本，先看看有没有价值，这是一件很好的事。
很多内部小工具，本来也没有必要一开始就进入完整的研发流程。
但 Demo 能跑，不等于它已经是一个生产系统。
接上真实数据库、写入用户数据、调用外部接口、保存密钥、处理权限之后，事情就变了。
这时需要考虑的，已经不只是页面好不好用、功能能不能运行，还包括数据写错了怎么办，权限配大了怎么办，密钥泄露了怎么办，第三方接口失败了怎么办，以及出了问题由谁处理。
这些恰好是非研发人员最容易忽略，也是 AI 最容易用一段“看起来没问题”的代码糊过去的地方。
所以 Vibe Coding 当然可以大胆尝试，但要知道边界在哪里。
做 Demo 时，“能跑”是一个不错的标准。
进入生产环境以后，标准得换成“别人敢不敢接，团队能不能兜底”。
写在最后
回头看那个一周多写完、几个月还没上线的模块，我不觉得它是一个失败的 AI Coding 案例。
它反而把剩余的阻碍开发流程的问题都暴露出来了。AI 已经有能力迅速完成实现，但我们的需求说明、影响分析、测试准备和上线机制，并没有以同样的速度跟上。
下一次再用 AI 加速开发时，目标不能只是尽快交出代码。
还要尽量交出后面的人能够承接得住的东西：清楚的改动范围、关键业务边界、必要的测试依据，以及出问题后的处理方式。
否则，AI 省下来的开发时间，迟早会变成其他人的确认成本。
代码会越来越便宜，这件事大概已经不可逆了。
但知道为什么要这样改，知道哪里最容易出错，知道什么情况下不能上线，并且愿意为最终结果负责，这些事情并不会因此变便宜。
所以以后再看到“AI 写了多少代码”，我更想问一句：这批代码，后面的人接得住吗？
