AI 全上了,交付速度没变——瓶颈卡在了问题定义

上个月周会，我突然发现一个尴尬的事实：团队接入 AI 编码工具已经快半年了，Copilot + Claude + 本地大模型全用上，代码生成率飙到 70-80%，但项目交付周期跟去年完全一样，甚至有个模块还延期了一周。

这不太对劲。

按常规逻辑，编码效率翻倍，总周期怎么也该缩短。我在团队里问了一圈，发现大家都在忙：需求改回改，设计稿改回改，联调卡壳，测试发现逻辑有问题，需要重新理一遍方案……代码部分反而是最顺的环节。

换句话说，AI 在流程的最末端发了力，但前面的瓶颈没动一下。

这次我没着急找什么新工具或流程模板。反倒想起自己这两年养成的一个习惯——每次接到需求，我会先花时间（有时候比写代码还长）做一个完整的"问题梳理"：要做什么、怎么做、做成什么样。不是文档意义上的完整，而是能回答三个具体问题：

奇怪的是，这个习惯让后面的事都顺了。需求评审时间短了，改动少了，联调的问题少了，测试发现的逻辑 bug 也少了。

我读到阿里云 CIO 蒋林泉说过一句话："定义清楚问题，问题就解决了 95%"

那时候只觉得这话听上去很正确但有点空。现在我信了。

因为我们团队的情况就是反面案例：把 95% 的工作量堆在了编码层面，却在问题定义层面只投入了 20% 的精力。AI 编码工具再快，也快不过根本方向错了的一整套重做。

part 01

编码只占 20%，我们却投入了 80% 的工具

通常一个项目的时间成本分布是这样的：需求理解 + 方案设计占 30-40%，技术评审占 15-20%，开发实现占 20-25%，联调测试占 20-25%。

开发实现只占 20-25%。而我们团队搞到的 AI 工具，90% 的能力都用在加速这 20% 上。

结果就是：代码写得飞快，但写的是错的代码。一个需求理解不透彻、方案没评审清楚的功能，再快生成出来也是债。生产环境的代码一旦落地，就变成了负债——维护成本、技术债、甚至业务风险。

💡 我见过不少团队陷入这个坑：生码率成了考核指标，大家优化的是怎么让 AI 生出更多代码，而不是生出对的代码。这是毒药指标。

还有个新词叫"Vibe Coding"（凭感觉写代码），在新项目或 POC 里挺爽的。但在存量系统里，这套很危险——你不清楚既有架构，凭感觉写出来的代码往往跟主流程冲突。

part 02

我现在的工作流

第一步，问题场景化

不是接受需求文档，而是先问：这个需求背后的用户场景是什么？为什么会有这个需求？有没有是因为前面设计有缺陷，才需要补丁？

有次商业化团队要加个"用户行为埋点"新模块。我没直接排期，而是问了一轮：到底想埋什么数据，是用来做分析还是做决策？结果发现，真实需求只需要改现有系统的数据上报逻辑，根本不需要新模块。这一轮对话省了两周开发。

第二步，方案极简化

强制自己用一张白板讲清楚：最少要改哪些东西，最坏情况下会影响哪些链路。很多需求听起来复杂，其实是因为没人把复杂度写出来。一旦画出来，往往能发现有些部分可以砍掉。

第三步，衡量标准提前定

不是做完再说"好"或"不好"，而是开始前就定：这个功能上线后，我们用什么数据判断成功了？这样如果中途方向有问题，能早点叫停。

part 03

这套方法有边界

说完好话，也说实话。

这个方法特别适用于：迭代周期相对长的功能、有明确业务目标的需求、涉及多个团队协作的项目。

⚠️但不适用于：紧急 bug 修复（你没时间梳理）、完全的探索性项目（问题本身没定义好）、简单的体验优化（真的只需要改一行 CSS）。

另外，这个习惯对 PM 的要求比较高——得有能力问对问题，也得有底气说"这个需求理由不足"。不是所有组织文化都支持这种对话的。

part 04

那 AI 工具的角色是什么

AI 编码工具在这套流程里的作用，是在问题定义清晰之后，加快实现的效率。我们现在的做法是：需求梳理和方案评审人工主导，这部分工具帮不了。但一旦需求和方案定了，代码实现、单元测试、基础设施代码这些，AI 全上。

关键是不能反过来：为了用上 AI，就加快问题定义的速度。那就本末倒置了。

特别焦虑要用上新工具的团队，往往问题定义的功课做得最不够。反倒是那种看起来"不务正业"的团队——花大量时间在需求评审上、在方案讨论上——交付效率往往更高。

没有充分的问题定义，AI 工具只会把你的错误放大 10 倍。反过来，问题定义清楚了，再加上 AI 编码，才是真正的组合拳。