ARTICLE · 1121918
AI 写代码越来越快,为什么项目还是交付不快?
大家好，我是老王。
设想一个场景：AI 很快写好了功能，你打开页面，按钮能点，结果也能显示。但这个需求还不能交付。
业务边界要确认，异常情况要测试，依赖的接口还没准备好。代码提前写完了，后面的事仍然要一件件处理。
那 AI 省下来的时间，到底怎样才能变成项目提前交付的时间？关键就在于，代码写完后，下一步能不能接着往前走。
01 · 代码量，算不出工作进度
判断 AI 编程的效果，很容易先看它生成了多少代码。这个数字直观，却漏掉了那些没有体现在代码行数里的工作。
一个修改只有几行，却可能要先确认业务规则、排查历史数据，再等相关团队确认接口。另一个修改生成了几百行结构相似的代码，需求本身却很明确。
按行数看，后者的 AI 贡献可能更高。按解决问题的难度看，未必。
AI 写了多少行，回答不了这个需求还剩多少工作。
一个公开案例可以作为参照：据 InfoQ 刊载的菜鸟内部实践，AI 生成代码占提交代码的比例超过 90%，但有无 AI 参与的需求，变更周期只相差约 10%。这是单一企业的观察，不能直接推广成行业结论。[1]
一个指标统计代码来源，另一个统计交付时间，它们本来就不能直接换算。要理解其中的落差，得回到具体需求：写代码究竟占了多少时间，其余时间又花在哪里？
02 · 写代码省一天，项目为什么没提前一天
用一个简化例子算算。
假设一个需求原本用 10 天完成，其中编码占 3 天，其余 7 天用于澄清需求、联调、测试和交付。这里是为了说明关系而设定的数字，不是某个项目的实测。
如果 AI 把编码从 3 天压到 1 天，其他环节不变，总周期是 8 天。编码时间减少了三分之二，整个需求周期减少了五分之一。
即使编码瞬间完成，剩下的 7 天也还在。
实际排期还会更复杂。假设测试环境周四才可用，代码从周三提前到周二完成，测试仍然只能周四开始。工程师确实腾出了一天，可以处理别的工作，但这个需求的交付日期没有提前。
个人省下了时间，项目缩短了周期，是两种不同的收益。
要把前一种收益变成后一种，就要继续追问：代码提前完成后，下一步能不能提前开始？
如果答案是不能，继续压缩写码时间，对交付日期的影响就会越来越小。
03 · 代码出来以后，还有三道关
拿“给订单列表加一个导出按钮”举例。下面仍是说明流程的假设场景。
AI 很快补好了按钮、接口和文件生成逻辑，页面也能点了。这时离交付还有多远，取决于三个问题。
要做的东西，是否已经说清楚。
导出当前页还是全部筛选结果？普通员工能否看到金额？数据量太大时怎么办？这些问题没有决定，实现得越快，越可能更快做出一个需要重写的版本。
把任务交给 AI 之前，至少要把会改变实现方向的歧义挑出来。否则“先做出来再说”省掉的沟通，很可能变成后面的返工。
做出来的东西，是否已经证明可用。
按钮能点，只验证了最顺利的一条路径。越权请求会不会被拦住，空数据能不能正常导出，生成失败后用户能否重试，都需要检查。
AI 可以参与这些工作，但生成了测试代码，与测试实际运行通过，仍然是两回事。验收要看可检查的结果。
已经验证的东西，是否有人接着往下推。
测试通过后，如果还要等人整理结果、找评审者、补交付说明，下一个环节就可能停住。一天里每次只等一小会儿，累加起来也会改变排期。
这些等待还要细分。等一次有必要的业务决定，和等人手动转发一份已经生成的报告，处理方法完全不同。
把所有确认都取消，会放过错误；保留每一次机械转交，又会浪费已经省下来的时间。
04 · 下一步该改的是任务的交付边界
如果给 AI 的任务到“代码写好”就结束，后面的工作自然全部留给人。
边界可以往后推一段。
仍然是导出功能，可以要求它完成修改后，运行约定的检查，整理测试结果，说明涉及哪些文件、有没有数据变更，再提交一份可评审的改动。遇到需求歧义、权限不足或验证失败，就停下来，把问题说清楚。
这样，人接到的内容才足够支持下一步决定。
每一步需要什么输入、产出什么结果、满足什么条件才能继续，都要有着落。
规则可以写进项目文档，但仅仅写下来还不够。测试需要能执行，结果需要能读取，失败需要被识别。否则一份很长的规则文件，也可能只换来一句“已完成”。
对普通团队，可以先找一段边界清楚、能够连续执行的工作。例如，从代码修改到测试报告：检查通过就整理结果，检查失败就保留错误信息，需要人判断时再停下。
这一段跑通，再考虑下一段。每多接上一段，都要检查是否真的减少了人工接力，有没有把错误带到更后面。
业务取舍、敏感权限和生产发布要保留明确的决策责任。减少流程里的空等，也需要知道哪里必须停下来。
05 · 下一个需求，记下它在哪里停住
要判断 AI 有没有帮上忙，可以从一个范围明确的小需求开始，留下四个时间点：需求确认、代码可评审、验证完成、交付完成。
中间如果停住，再记一句原因：等接口、等环境、等业务确认，还是因为实现不对返工。
不必一上来搭复杂的效能看板。这份记录已经能帮助你定位下一步。
如果大量时间花在理解和修改代码上，优先改善任务描述、项目上下文与代码检查。 如果代码完成后一直等测试，把环境准备、测试执行和结果整理接起来。 如果反复返工，先补需求边界和验收样例。 如果卡在跨团队依赖，明确负责人和交接条件。
比较前后效果时，还要看需求规模和质量。不能把需求切得更碎，就算交付数量增长；也不能提前宣告完成，把故障和返工留到上线之后。
AI 的价值可以体现在周期缩短，也可以体现在同样时间里多交付一些工作、少一些重复劳动。每一种收益都值得看，但要分别量。
代码写完以后，工作还在哪里停着？
找到那个位置，才知道下一次该让 AI 多做什么，或者该由团队改变什么。
OpenAI DevDay 发了 25 项更新，真正改你账单的是那张额度表