产品经理视角：AI Coding 有个毛用

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

• 在我所处的环境下没什么提速的效果，甚至有很强的皇上不急太监急的感觉。

• 目前没有观察到明显提速，极少数核心骨干可以提效，大部分人还是 “被 PUSH 使用” 的情况。

• 提效不明显，效率更多是卡在开发流程上。

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

一边喊着 AI 提效两倍/三倍/十倍，一边产品进展纹丝不变，那么 AI Coding 又有毛意义啊？

微博评论区：作为大厂员工， PM 无感知是因为我们不想让 PM 感知到，这是最大的现实。

好吧，聊点更有深度的。犬校这一帖随后讨论了 AI Coding 对研发提效，但对需求上线无法提效的四个主要原因：

1. 部分程序员倾向于 “用 AI 解答不会的事情”，而不是 “用 AI 提升效率”，似乎他们对于加快需求上线漠不关心。

2. Coding 在研发工作中所占的时间比例没有你想象的那么大。

3. 提效首先给个体带来收益，整体业务流程和提效后的个体速度并不匹配，AI Coding 加速编码但加速不了流程，程序员的时间更富裕了，业务流程的时间原封不动。

4. 程序员主动摸鱼。

以上四点中，摸鱼其实是最不重要的因素，最重要的因素是研发管理并没有迭代流程去适配 AI Coding 时代，汽油发动机套在马车上跑。团队规模越大，原有的业务规范越严谨，改变就越难。

不过也有成功案例。

在相对成熟的业务里，犬校只收集到两个成功案例。

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

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

案例二也他妈的……太令人羡慕了吧！

我问他，有想过你这个 “hold 不住了” 的成功案例的约束是什么吗？

首先有足够多技术能力不错的程序员深度 AI Coding；

其次开发流程不严格（代价是交付质量一直不好，这个问题倒是被 AI Coding 改善很多）；

最后需求和需求的优先级我能决定，权限足够大。

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

既然如此，创业团队是否能从 AI Coding 中明显加速呢？

150 多人的犬校也有不少创业团队的产品经理。一位创业合伙人表示：

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

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

后续讨论中，一位犬校同学提到即便是成熟产品，如果另开新产品线，或者大范围重构，在没有代码历史包袱的前提下，AI Coding 可以明显提速，一旦涉及老业务老代码就没什么加速效果。

另一位创业同学聊到，AI Coding 搞了大半年，代码质量越来越堪忧，尤其是有些和系统耦合高的迭代，经常影响老功能，最近正在想怎么在推动 AI Coding 的同时控制代码质量。

还有人讲了一个 “大功能” AI Coding 成功案例，在当时的环境下，程序员临时接手相当复杂且陌生的大功能，单单 spec 就有 2000 多页。工程师必须借助 AI 阅读 spec，把各种机制细节搞清楚，理解 context，没有 AI 助力完成这个任务可就太难了。

这一帖聊了 40 多楼，除了产品经理七嘴八舌之外，我邀请一位 Google 资深工程师加入讨论，问他怎么看这个话题？（他在 Google 热情拥抱 AI 并在犬校分享了许多经验）

他的回复含金量很高：在写简单代码的时候，真的很有效。但是在项目里，大部分代码不简单，因为：

1. 本身的代码和架构就是一坨 (是的，在 Google 也有这种代码) 。

2. 因为 a, 导致代码逻辑没有 isolate 在模型可以获取的 context 里，也不一定在用户的 context 里，所以很有可能遗漏。

3. 我过去的项目 integration 很多，相关的API contract，security，compliance 等等考虑，都是 DevAI 自己无法获知的。

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

再说除了 Coding Time，提交代码还需要 1 到 2个小时。提交之后，一周只发布 1 到 2 次，还经常卡住。因为是 integration，很多测试依赖发布后才能测试。

结论是对 Google 工作的他来说，恐怕并没有对需求上线明显提效。但他同时也说：大厂大概很难加速，starup 大概率不是这样。

因为 startup 没有太多 legacy code 或者一坨坨，大部分的代码都是简单代码。也没有 integration，全都从头来过。code to ship 非常快，好的可以以小时计。不一定需要测试，即便需要，从头用 AI 做 TDD 也很容易写对。另外还有一个很大的变量是 “可以使用的工具”，比如字节只能使用 Trae，而 startup 有什么上什么。