产品经理视角：为何感知不到AI Coding带来的研发提效？

抱歉，这次标题可能有点“标题党”。但这确实反映了近期一个技术社区热帖中的一种普遍看法：随着AI编程工具在开发团队中普及，很多产品经理并没有感觉到需求上线速度有明显提升。那么，站在产品经理的视角来看，这玩意儿到底“有个毛用”？

1月初，我在社区发起了一个讨论：

问一个很严肃的问题。AI Coding对程序员的赋能已经是很明确的事情，那么大家有感知到对口的研发部门明显提速吗？产品需求有比过去更快上线吗？更快更多的需求上线对产品有什么改变吗？

最常见的回复是：

• 在我所处的环境下没什么提速的效果，甚至有很强的“皇上不急太监急”的感觉。
• 目前没有观察到明显提速，极少数核心骨干可以提效，大部分人还是“被PUSH使用”的情况。
• 提效不明显，效率更多是卡在开发流程上。

后来我把这个话题发到微博上，收到了程序员朋友更直白的“热情反馈”：

• 产品经理感觉不到提效很正常，因为排期不会变，AI半小时能干完的活，之前报的两天，现在还是报两天。开发时间肯定还是按原来的排，何必压榨自己。
• 之前团队加班多，现在加班少了，运动打球时间多了，排期肯定不能变，都是牛马，压缩时间的话那不是自找没趣嘛。
• 牛马压榨自己，老板就会觉得牛马太多了，然后砍掉一些牛马。

这他妈的……一边喊着AI提效两倍/三倍/十倍，一边产品进展纹丝不变，那么AI Coding的意义到底在哪里？

微博评论区有人一语道破：“作为大厂员工，PM无感知是因为我们不想让PM感知到，这是最大的现实。”

好吧，我们聊点更深层次的原因。后续的社区讨论总结了AI Coding对个体研发提效，却无法转化为需求上线速度提升的四个主要原因：

1. 认知偏差：部分程序员倾向于“用AI解答不会的事情”，而不是“用AI提升效率”，他们对于加快需求上线这件事本身可能就漠不关心。
2. 时间占比误区：编码（Coding）在整个研发工作中所占的时间比例，可能并没有产品经理想象的那么大。
3. 流程不匹配：提效首先惠及个体，但整体的业务流程并没有适配这种新的个体速度。AI加速了编码，但加速不了需求评审、技术设计、联调、测试、发布等环节。
4. 主动调整工作节奏：也就是俗称的“摸鱼”。

以上四点中，“摸鱼”其实是最不重要的因素。最核心的问题在于，研发管理流程没有为AI Coding时代进行迭代优化，就像给马车装上了汽油发动机，团队规模越大、原有流程越规范，改变起来就越困难。

不过，也不是完全没有成功案例。在相对成熟的业务里，只收集到两个：

案例一（后端业务）：纯Web的简单项目会变得更快。比如我的工作流是：调试好本地html，每个页面或功能是一张独立的html截图，把AI写的PRD复制到文档，研发把数据拆出来，复用html样式和交互实现功能，省去了设计时间，以及研发跟设计反复修改细节的时间。现在研发的主要精力放在了后端策略的实现上。

案例二：在我们的业务里，显著提速已经变成共识，随着越来越多程序员主动或者被动拥抱AI，我感觉我有点hold不住了，我每天都得动脑子想需求和提需求……

案例二也太他妈的令人羡慕了吧！
我追问对方，他这个“hold不住了”的成功案例有什么前提条件？

首先，有足够多技术能力不错的程序员深度使用AI Coding；
其次，开发流程不严格（代价是交付质量一直不好，不过这个问题倒是被AI Coding改善了很多）；
最后，需求和需求的优先级我能决定，权限足够大。

明白了。他这个案例的业务规模不小，但因为位于一条独立的公司业务支线上，所以管理相对松散。研发团队拥抱AI的氛围和松散的研发流程，二者缺一不可。这再次印证了“团队规模越大，原有的业务规范越严谨，改变就越难”的规律。

那么，流程更灵活的创业团队，是否能从AI Coding中获得明显加速呢？
一位创业合伙人表示：

总的来说比以前在大厂时提效太多了。但这可能部分归功于组织架构自由：我不用跟别人商量需求，不用汇报和需求评审，开发也不用排期和技术评审，也没有专职测试，所以原来做一个月的需求现在估计一周。但我相信，原来那一个月里，一半以上时间是被流程拖慢的，并不是真实写代码的时间。

所以你看，真正拖慢速度的，往往还是流程本身。

后续讨论中还提到一些有价值的观点：

• 即便是成熟产品，如果另开新产品线，或者进行大范围重构，在没有历史代码包袱的前提下，AI Coding可以明显提速。一旦涉及对老业务、老代码的迭代，加速效果就微乎其微。
• 有创业同学反馈，用了大半年AI Coding，代码质量越来越堪忧，尤其是和系统耦合度高的迭代，经常影响老功能，正在思考如何在推动AI的同时控制代码质量。
• 还有一个“大功能”成功案例：程序员临时接手一个极其复杂陌生的大功能，规格文档就有2000多页。工程师必须借助AI来阅读和理解文档中的各种机制细节，没有AI助力几乎不可能完成这个任务。

为了获得更专业的视角，我邀请了一位在积极拥抱AI的Google资深工程师加入讨论。他的回复含金量很高：
在写简单代码时，AI真的很有效。但在实际项目中，大部分代码并不简单，因为：

1. 项目本身的代码和架构可能就是“一坨”（是的，在Google也有这种情况）。
2. 由于上述原因，代码逻辑没有清晰地隔离在AI模型可以获取的上下文里，也不一定在用户的上下文中，所以AI很有可能遗漏关键信息。
3. 他的项目集成（Integration）很多，相关的API契约、安全性、合规性等考虑，都是AI无法自行获知的。

因此，稍微复杂一点的代码，虽然大部分是AI写的，但比自己写不一定省时间。经常出现“AI用20分钟写完100行业务逻辑，我却要花3小时帮AI把测试写好（因为有些架构和测试本身就是一坨）”的情况。

此外，除了编码时间，提交代码可能还需要1到2个小时。提交之后，一周只发布1到2次，还经常被卡住。因为是集成项目，很多测试依赖发布后才能进行。

他的结论是：对他在Google的工作而言，AI Coding恐怕并没有对需求上线产生明显的提效效果。但他同时也指出：大厂很难加速，但初创公司（Startup）很可能不是这样。

因为初创公司没有太多遗留代码或“一坨坨”的架构，大部分代码相对简单；也没有复杂的集成，一切从头开始；从编码到发布（Code to Ship）非常快，顺利的话可以小时计；不一定需要严格的测试，即便需要，从头用AI做测试驱动开发（TDD）也很容易写对。另外，工具链也是一个很大的变量，大厂可能只能使用内部受限的工具，而初创公司可以自由选择最好的。

最后，他也不同意“AI会写出屎山代码”的说法，他认为“是差的程序员会用AI写出屎山代码”。而且有了AI，因为耗时和代码行数（LoC）不一定成正比，程序员反而有更高可能写出行数更多但结构更好的代码。

这场讨论非常精彩，堪称当月社区热帖TOP1。它揭示了一个关键矛盾：技术工具的进步是迅猛的，但组织流程和人的工作模式的进化往往滞后。AI Coding不是银弹，它放大的是个体能力，而能否将这种个体能力转化为团队和产品的整体动能，考验的是管理智慧和流程设计的弹性。