当"作念得快"成了默许预期，游戏神态的本事债正在以你没强劲到的速率累积

一个大型互联网团队，跨越90%的代码由AI生成。系统范围31万行，还在快速推广。

听起来像效用遗迹。但团队很快发现，系统复杂度的增长速率远超珍重才调。

原因不在AI写的代码质地——是需求来得太多、太快、太猖厥。

AI把拜托周期压缩了，需求方的心态也随着变了。"归正作念得快，先作念了碰庆幸。"暗昧的需求、试探性的需求、"先作念再说"的需求，运转大齐涌入系统。每一个单独看齐不大，加在系数，系统就变得越来越肥胖、越来越难改。比及信得过需要快速迭代的时候，反而改不动了。

这个振作正在软件行业延迟。

游戏神态对这个问题可能比互联网居品更明锐——系统间的耦合度更高，一个没想领路的需求能激发的四百四病更大。AI让"作念"变快了，但"想领路"的老本一分没少。

当系数团队齐在为速率提高答允的时候，需求礼貌在暗暗发生变化。

AI让建造变快了，但需求变烂了？

上头的案例不是孤例。AI Coding铺开之后，近似的脚本在反复献技：

拜托时期镌汰了，需求方的提需门槛也随着责怪了。

过去一个需求要排两周，大家提之前几许会推测一下。现时三天能出，心态就变了——"先作念作念看呗"成了默许选项。

我在神态里不雅察到相通的趋势。磋议运转用AI援救写需求文档，产出速率较着提高。文档变长了，神情也漂亮了。但磋议案的中枢——玩法判断、系统畛域、体验选定——这些AI帮不了。

文档变长了，信得过该被扣问的问题反而被归拢在更多的笔墨里。

有一段时期，神态里一周内冒出十几个新需求，每个单独看齐"不大"，齐"合理"。莫得任何一个需求是错的。但加在系数，径直吃掉了一个月的排期余量。

这种失控很难那时就强劲到。因为每个需求齐走了平常进程，每个建议者齐有合理的事理。是总量在暗暗失控。

AI Coding最大的风险不在代码端，在需求端——它让通盘东说念主误以为"作念"的老本接近于零，但"想领路再作念"的老本并莫得变。

游戏神态的本事债，蕴蓄速率超出预期

许多软件居品的模块相对落寞，功能之间互不插手，出了问题回滚就好，涉及范围有限。

但游戏神态的系统结构自然不同。

改一个构兵技能的判定样子——动画要从头配节律，数值要从头算均衡，射中判定框要重作念，联机模式下同步决议要从头考据。一个需求，四个组同期被拽进来。

一个需求的"爆炸半径"大得多。

相通一个没想领路的需求，在互联网居品里可能仅仅一次小迭代的阔绰。在游戏神态里，可能是五个模块同期返工。

跟几个制作主说念主聊过这个话题，大家广大的主见是：磋议案的前端是想法，省略情味很高，跟尺度本色不同。越基于详情味的东西越妥当AI，但需求自己恰正是最省略情的部分。

这里有一个要津矛盾。AI在详情味任务上很强——写代码、生成资源、神情化文档。但需求阶段恰正是系数研发管线里最省略情的神情，需要的是判断力，不是坐褥力。

游戏神态的返工，根子上频频不在实施神情——需求自己就不该以阿谁形态参加建造。AI仅仅让这个过程来得更快了。

重构救不了需求端的失控

濒临系统复杂度推广，常见的应答想路是重构——用AI作念代码审查，必一(中国)渐进式清算本事债，完善研发方法。

这些妙技有用。但它们齐是不才游筑坝。

水是从上游来的。

需求端不收口，代码层面作念再多治理，新的复杂度照旧会抓续涌入。今天清算的本事债，下个月又会被新一轮"先作念了再说"的需求填满。

要在需求端收口，难度比瞎想中大得多。

每个东说念主的KPI齐在催你多作念、快作念。守护层要证实注解AI转型灵验率——看的是AI生成率、拜托速率、需求浑沌量这些数字。研发要证实注解我方在跟上变化——看的是有莫得在用AI、效用提高了几许。磋议和PM认为"归正作念得快，多探索几个主见"——毕竟谁也不想因为"没试过"而错过好点子。

莫得东说念主的窥探贪图是"这个需求不该作念"。

这怪不到某个东说念主头上。是激励结构在推着每个东说念主作念出局部最优、全局恶化的选拔。

游戏行业还有一个独特之处：制作主说念主自然追求体验齐全度，磋议自然倾向于"多作念"。AI让"多作念"的显性老本看起来更低了——建造快、出稿快、改版块快。但隐性老本没变，致使在加多：系统耦合度更高、珍重职守更重、团队相接这套系统的领路负荷更大。

大组织濒临这个问题险些是结构性无力的。从根上处理，意味着要跟系数激励体系拒抗——从头界说什么叫"高效"，把"少作念"酿成不错被奖励的行径。这个难度太大了。能作念这件事的东说念主，不如径直去开一个新盘子，ROI高得多。

留在组织里面的东说念主，能作念的是在我方的影响范围内守住一些东西。

PM的信得过战场：守住需求进口

大的改不了。但若是你是PM，在我方的神态里，有三件事值得作念。

需求评审的中枢问题变了。

过去评审的要点是"能不成作念"——本事上是否可行、资源够不够、排期合离别理。

现时要加一个前置问题：值不值得作念。

AI能作念不即是应该作念。每个参加排期的需求，齐该被问一句：砍掉它，居品会怎么？若是谜底是"没什么影响"，它就不该进来。

这话提及来节略，作念起来需要勇气。大部分东说念主倾向于作念加法，"归正建造老本低嘛"。PM需要站出来说的是：系统老本不仅仅建造老本，还有耦合老本、珍重老本、团队相接这个系统的领路老本。这些不会因为AI写代码变快而减少。

用Feature Freeze守住版块节律。

我在神态里推的一个战术是"锁需求"而不是"锁代码"。

传统作念法是锁代码提交——尺度不成再改了。但问题频频不出在尺度乱改，而是需求端一直在加。版块后期，磋议说"就加一个小功能"，尺度说"篡改不大"，每个单独看齐不至于出事。十个"不大"加在系数，版块就乱了。

Feature Freeze把闸门前移：在一个明确的时期点之后，不再经受新功能需求。仍是参加管线的需求，团队不错专注作念好；没进来的，等下个版块。

锁的不是尺度的手，是需求端的口。看起来会让节律变慢，实践上它保护了已有需求的拜托质地。这个想路我在课程里作念了更系统的拆解——版块守护的中枢不是排更多的需求，是确保参加管线的需求能被崇拜作念完。

让AI援救需求审查，而不仅仅需求生成。

现时大部分东说念主用AI的样子是让它维护写——写需求文档、作念初稿、整梦想路。没问题，但只用了AI一半的才调。

另一半是让它帮你查漏。

需求文档写完之后，用AI跑一遍：畛域条目是否齐全？跟已有系统的耦合点是否识别？对其他模块的影响范围评估了莫得？相配情况的处理决议有莫得写？

AI擅长发现东说念主容易忽略的遗漏。与其让它写文档，不如让它审文档。这个用法对需求质地的提高，可能比让它写代码更大。

这些齐是每天在神态里发生的真是情况。在PM成长社区里，我会抓续更新一线的想考和踩坑耕作。

AI期间PM最值钱的才调，不是"用AI提效"，是"敢对AI能作念的事说不"。

阿谁90%代码由AI生成的团队，最终发现需要处理的不是代码问题，是需求问题。

游戏神态也一样。

当"作念"变得越来越低廉，"想"的价值反而在升高。

AI改变的不是建造速率，是"想领路"的重量——它把"想领路"从一种良习酿成了一种生计技能。

对PM来说，这可能是这一轮本事变革里最进击的信号：你的中枢责任正在从"鼓励实施"酿成"守住判断"。

@Hao的游戏PM条记 · pmnote.ai

必一(中国)