第151期 - 当AI写了90%的代码，会发生什么？

📝 本期摘要
当一个大型互联网团队超过90%的代码由AI生成后，他们发现系统复杂度的增长远超维护能力——根源不在代码质量，而在需求端的失控。
AI压缩了交付周期，也降低了提需门槛，"先做做看"成为默认心态。
这个问题在游戏项目中尤为严重，因为系统间的高耦合度让一个需求的返工代价远高于互联网产品。
本期从需求失控的根因、游戏项目的特殊性、以及PM可落地的三个应对策略三个层面展开讨论。
❓ 本期讨论了这些问题
* AI Coding为什么导致需求端失控而非代码端出问题？
* 为什么游戏项目的技术债比互联网产品积累得更快？
* 组织的激励结构如何推动"做更多"而非"做更对"？
* PM如何在自己的影响范围内守住需求入口？
* AI应该被用来生成需求文档还是审查需求文档？
🔥 本期核心内容
1. AI Coding的最大风险在需求端，不在代码端
AI压缩了交付周期，需求方的心理门槛随之降低。"先做做看"成为默认选项，模糊需求和试探性需求大量涌入系统。单个需求看似合理，总量却在悄然失控，最终导致系统臃肿到无法快速迭代。
2. 游戏项目的"爆炸半径"远大于互联网产品
互联网产品模块相对独立，一个功能做砸了回滚即可。游戏项目中改一个战斗技能的判定方式，可能同时牵动动画、数值、碰撞、联机同步四个组。同样一个没想清楚的需求，在游戏项目里的返工成本是数倍级别的。
3. 重构治不了需求端的失控
代码审查、技术债清理、研发规范完善——这些都是下游筑坝。当每个人的KPI都在催"多做、快做"，没有人的考核指标是"这个需求不该做"。激励结构推着每个人做出局部最优、全局恶化的选择。
4. PM的三个可落地策略：换问题、锁需求、审而非写
需求评审从"能不能做"升级为"值不值得做"；用Feature Freeze在明确时间点后锁住新增需求；让AI辅助审查需求文档的边界条件和耦合点，而非只用来生成文档。这三个动作是PM在自己影响范围内能守住的阵地。
🏷️ 本期提到的人物与概念
概念：AI Coding、技术债 / Technical Debt、Feature Freeze、需求评审 / Requirements Review、系统耦合 / System Coupling、需求入口管理 / Requirements Gate
📌 关于我
我是 Hao，游戏行业项目管理从业者，10年经验。
课程 · 咨询 · PM成长社区 → pmnote.ai