在上一篇 《AI原生游戏开发 —— 从管线重构到动态体验》 里,我提出过一个判断:AI Native 真正改变的不是 AI 生成资产,而是游戏工业第一次从”资产生产能力的竞争”,转向”体验验证速度的竞争”——最有竞争力的团队,不一定是拥有最多美术资产的团队,而是能最快验证”什么好玩”的团队。
那篇讲的是为什么。这一篇,讲怎么做。
如果验证速度是新的竞争焦点,那么紧接着的问题就是:当你想让玩家有某种体验时,AI 到底怎么帮你把”想要的体验”,变成”可玩并且验证过的原型”? 上一篇把战斗、敌人、关卡这些管线分别谈了一遍;这一篇,我要把它们收进一套统一的框架里——让”从体验到验证”这件事,在每个系统上都走同一条路。
所以这篇是一张地图。每个系统怎么从体验目标出发、怎么用 AI 协作落地、怎么验证迭代,我都会展开讲清楚——包括为什么这么做,以及边界在哪。后面我还会用具体实例去扩展每个系统,这篇先把完整的体系立起来。
一条贯穿全篇的主线
不管是战斗、敌人还是关卡,做法其实是同一条线:
体验目标 → 功能 + 数值(配置驱动)→ AI 协作落地 → 验证迭代
这四步看起来朴素,但每一步的顺序和分工都有讲究。
第一步,体验目标。 先想清楚你要让玩家有什么感受——手感、情绪、节奏、成长。这是一切的起点,也是 AI 无法替你做的判断。很多团队跳过这一步直接做功能,做到一半发现”不好玩”,却说不清到底哪里不好玩——因为从来没定义过”好玩”是什么样。体验目标不是一句空话,它必须能被翻译成可验证的东西,否则后面三步都没有靶子。
第二步,功能 + 数值。 代码定骨架,数值定表现。这里的关键纪律是:迭代尽量靠改数值,而不是反复改代码。 频繁改代码,每次都有引入 bug 的风险、要重新测试、要重新评审;改数值则是热重载,不动逻辑,风险几乎为零。所以最好的可靠性,其实是少写代码、少改代码——把所有”可能变的东西”在写代码时就暴露成配置。
第三步,AI 协作落地。 AI 找参照、做翻译、批量生成。注意分工——人做决策,AI 落地操作。 AI 不替你判断”这个数值好不好”,它帮你把判断快速变成现实。
第四步,验证迭代。 机器跑 + 真人测,对照体验目标看达没达成。不达标就回去改,形成闭环。
这条线上最关键的一句话是:先验证好玩,再投入资产。 传统开发最大的浪费,是美术做了三周才发现玩法方向错了,这时候推翻成本极高,于是只能硬着头皮”赌方向”。而当玩法能用占位资产 + 数值快速验证时,你在第一时间就能发现方向不对,改个参数就行,没有人受伤——拒绝坏方向的成本几乎为零。这才是 AI 给玩法开发带来的根本改变:不是让你做得更快,而是让你更早地拒绝错误。
下面三个系统,都是这条主线的具体展开。区别只在于:每个系统锚定的”体验”不一样。
战斗系统:锚点是战斗体验
战斗系统的体验锚点是战斗体验——而手感,是达成这个体验的手段。手感本身太虚,做起来要拆成两层:功能(命中、伤害、技能、Buff 这些机制)和数值(TTK、暴击、后坐力、冷却这些参数),再加上 3C(角色、镜头、操作)。每一层都是”功能 + 数值”的组合——功能撑起骨架,数值决定手感,而手感最终是为了那个让人想一直打下去的战斗体验。
这里有个反直觉、但极其重要的顺序:功能要在数值之前。
举个具体例子。同一个”ADS 灵敏度 1.2″,在不同的功能实现下意义完全不同:镜头 FOV 是用线性过渡还是缓动?灵敏度是否随 FOV 同比缩放(也就是有没有启用 ADS multiplier)?切换瞄准的过程中能不能开火、被打断了怎么处理?这些全是功能层面的设计。如果功能没定下来,你调的那个”1.2″根本没有锚点——它在某种实现下是稳的,换种实现就飘了。所以正确的顺序是:先把功能想清楚、实现出来、把参数接口暴露好,数值才有意义。
AI 在战斗系统的角色,我把它概括成一句话:AI 找参照,人做决策。
具体是这样跑的。策划用品类语言描述意图——比如”对标 CoD 的射击手感,但移动更灵活一点”。注意,策划说的是意图,不是具体数字。然后 AI 去做两件事:先理解功能机制(把”CoD 的 ADS 做了什么”翻译成”我们要实现什么”——FOV 切换曲线、multiplier、切换中能否开火),再协助实现(生成可跑的代码骨架,把所有可调参数暴露出来,写好热重载和单元测试)。功能落地了,AI 再去拆数值:从对标游戏抽出参数,按”移动更灵活”这个需求做差异化偏置(移动 +15%、转向阻尼 −20%),每一项都带引用来源,可追溯。
然后是这套流程里我认为最关键、也最容易被忽略的一步——人和 AI 一起共创测试用例。
传统的”评审”是单向的:人对着 AI 的产出找毛病,给意见。但共创测试用例是双向的:人提出体验意图(“近距离遭遇战,玩家应该 0.5 秒内能决定打还是跑”),AI 把这种模糊的意图翻译成可执行的测试场景(“玩家 5 米距离、弹夹剩 8 发、敌人正面,检查 TTK 是否 ≤ 0.5 秒”)。这一步的真正价值,是逼着人把”我觉得好玩”这种直觉,显式化成”在什么场景下应该怎样”的具体标准。这些用例会成为团队的共识,后面机器跑、真人测,大家都对着同一组用例,不会出现”我说好玩你说不好玩”的扯皮。而且用例可以复用、可以持续沉淀——这是小团队第一次有机会建立 AAA 级的测试基线。
最后是双轨验证。
一条轨道是机器跑:让程序里的虚拟玩家按用例条件跑上千场自动化战斗,统计每条用例的实际 TTK、命中率、胜率,验”数值对不对”。它的强项是快(秒级)、客观、量大,但测不出手感。另一条轨道是真人 playtest:真人拿手柄实打,用例库当 checklist 一条条勾,验”手感爽不爽”。它能测出数值对了但打起来”肉、没反馈”这种问题,但慢、样本少。
关键在于这两条轨道是分工,不是替代:机器筛数值,真人调手感。真人的起点已经是机器筛过的好版本,所以只需要微调最后那 5%。
跟传统的”凭经验给个数值 → 进游戏盲调 → 改 → 再调”循环相比,这套方式的差别不是”AI 帮你写得快”,而是:起点从一个随机的点,变成了一个被市场验证过的基线。 传统方式可能要循环 20 到 50 轮才能找到一个”还行”的点,而且没有客观参照,容易陷进”我觉得还差点意思”的死循环;新方式有对标、有用例库,客观可辩论、可回归,一两轮就收敛。周期从两到四周压缩到一到三天。
敌人系统:锚点是战斗体验带来的情绪价值
如果说战斗系统锚的是”打起来是什么战斗体验”,敌人系统锚的就是这个战斗体验所带来的情绪价值——玩家打完这一场,带走了什么。情绪价值不是凭空产生的,它是战斗体验之上长出来的结果:先有好的战斗体验,敌人才能在这个体验里制造出值得记住的情绪峰值。
这是敌人系统最容易被做错的地方。很多团队把心思花在”这只怪有多强、行为树多复杂”上,却忘了问一个更根本的问题:这个设计有没有给玩家制造一个”高光时刻”? 一场战斗的体验不是均匀的,它是一条有起伏的曲线,而真正让玩家记住的,是曲线的峰值——那些”危机 → 转折”的瞬间。
我用三个变量来锚定它:TTK × OODA × 情绪价值。
- TTK(Time To Kill)是一次交战的时长容器,它决定了玩家能跑几轮 OODA。
- OODA(观察 Observe → 定向 Orient → 决策 Decide → 行动 Act)是玩家在这段时间里的认知循环。简单理解:OODA 就是玩家从”发现问题”到”解决问题”的一轮完整思考过程。
- 情绪峰值就产生在 OODA 循环里那个”危机 → 转折”的临界瞬间。
把它讲具体:玩家被一只敌人锁定(危机),用一个滑铲躲掉、反手爆头(转折)——爽。弹夹只剩 2 发面对满血敌人(危机),头铁命中(转折)——爽。队友倒下(危机),一打三杀光(转折)——这是高光。这些都不是”敌人设计得难”或”设计得弱”的问题,而是敌人有没有制造出 OODA 循环里的临界点。
而 TTK 决定了这些临界点有没有机会发生。TTK 太短(比如 0.1 秒),玩家来不及观察、判断、行动,就被秒了,只剩挫败和迷茫;TTK 太长(10 秒以上),OODA 跑太多轮,就疲劳、无聊、拖沓。恰到好处的 TTK + 一次完整的危机到转折的 OODA = 高光体验。
所以敌人系统的每一项功能和数值,都要回到这个问题上来:它是否在 TTK 内,让玩家跑完 OODA 并产出了情绪峰值?这把整个评估标准重写了。行为树不只是”让 AI 会动”,它要制造威胁信号让玩家进入观察;招式不只是”造成伤害”,它要有可读的前摇留出反应时间;反应延迟要留白,让玩家的行动有空间。AI 鬼畜瞬反是反面教材——因为玩家根本来不及 OODA;AI 站桩挨打也是反面教材——因为玩家不需要 OODA。HP 和伤害这些数值也一样:HP 决定这只敌人的 TTK,伤害决定玩家被秒前的 TTK,两者都必须容得下至少一到两轮 OODA。
单只敌人的 OODA 是微观的。当多个敌人组合在一起,会产生宏观的 OODA——”我先打谁?”这种优先级判断。所以整体编排(波次、Squad、AI 导演)要在情绪曲线的低谷时介入:玩家太顺就加压,玩家太苦就给喘息。
那么”情绪”这种主观的东西,到底怎么验证?
我把验证分成三步,层层收敛——量在前,质在后。
第一步,机器跑硬指标。 虚拟玩家打上千场,统计 TTK、玩家反应时间、OODA 次数/分钟、死亡率、敌人击杀分布。这些是客观数据,每个指标都有期望区间(这些区间也是 AI 拆对标游戏拆出来的,不是凭空猜)。不达标的用例先标红筛掉一大批。这一步能从上千个用例收敛到上百个。
第二步,从玩家行为反推情绪。 这一步是敌人系统验证特有的,也是最巧妙的。AI 不会”感受”情绪,但它能识别情绪发生时的客观特征。原理是:情绪峰值会引起玩家的特定行为,反过来就能从行为反推情绪。具体分三个动作:你告诉 AI”残血反杀算高光”,AI 把这句话翻译成精确判定(击杀时 HP < 20% 且该敌人此前攻击过玩家);AI 写脚本从百万行日志里自动扫描,标出每场战斗在第几秒触发了哪些信号;再把这些离散信号拼成一条情绪曲线,跟设计目标对照,圈出”该高光但没出现”的区段。整个过程不需要 AI 有任何”感情”,它做的只是规则定义 + 数据扫描 + 对比——全是 AI 的强项。
第三步,LLM 看回放。 前两步有个死穴:它们只能识别你预先定义过的信号,而且行为是间接推断(“玩家闪避了”不等于”玩家觉得爽”)。LLM 看回放就是来补这两个洞的。把游戏录像和操作日志丢给多模态大模型,让它像一个”看过上万小时游戏视频的资深玩家”那样,在时间轴上打点:0:15-0:22 紧张、0:22-0:25 高光(残血翻盘)、0:40 挫败(卡关)。它能 work,是因为它训练时见过海量游戏视频和解说,认识”高光时刻看起来什么样”——它不感受情绪,但能识别情绪发生时的画面特征。要说实话:这一步还在早期,准确率在快速提升但没到完全可信,适合当辅助筛选,不替代真人终判。
这三步配合的意义在于:只跑数据,数值对了但可能还是不好玩;只靠真人,成本又爆炸。 三步分工,才能既快又准地验证情绪。而且每个”未对齐”的点,都是一条明确的改动指引——回到对应的功能或数值象限去改。
关卡系统:锚点是节奏与探索
关卡系统的体验锚点是节奏与探索。但跟前两个系统不同,关卡这一层有个特殊性:它是组装层。
关卡设计师真正交付的,是四样东西的协同布置:POI(兴趣点)、路网、怪物、资源。 这里要划清边界——怪物的设计归敌人系统(这只怪多强、行为树怎么写),资源的数值归经济系统(一个医疗包回多少血),但”在这张图的这个位置摆什么、刷几只、放哪些补给”——这是关卡系统的事。关卡系统拿敌人系统提供的怪、经济系统定义的资源、场景系统的地形,按体验目标布置到具体位置。
而这四样东西的核心难点是:它们必须协同,指向同一个体验目标,不能互相抵消。
举几个反例就明白了。如果怪物摆得很密(想制造紧张),但资源给得很足(让人放松),两者就互相抵消,玩家根本不紧张。如果 POI 想引导玩家往东(鼓励探索),但路网只有往西的路,设计意图就落空了。如果稀有资源堆在某个 POI,但那个 POI 在死胡同、路网根本不经过,玩家就拿不到,白摆。所以关卡设计的真正手艺,是把”这段要紧张”翻译成一套配方:战斗 POI 靠拢 + 路网收窄成单线 + 怪物高密度 + 资源断供——四样一起服务”紧张”。每个配方,就是一个”体验目标 → 四样布置”的打包规则。
这里 AI 的定位必须说清楚:AI 自己不懂关卡设计。 这一点我不回避。AI 做的是承接专业策划的经验——把”什么体验用什么配方”这种零散、隐性的经验,结构化地沉淀成一个配方库,在制作时调用、在验证后回填。第一次用可能很空(没经验),但用得越多、回填越多,这个库越值钱,最后变成团队的资产。这跟战斗系统的”测试用例库持续演进”是同一个道理——都是把人的隐性经验,沉淀成团队的显性资产。
配方有了,怎么落地?这里只说方法论上的一点,具体的 UE 实现留给关卡系统的实战篇。
核心思路一句话:配置表驱动。 四样配方全部落进配置表,由程序化的方式读表生成——策划改表定意图,工具读表自动落地,改表就能重新生成,不动代码。这正是前面那条主线”配置驱动”在关卡系统里的体现:程序把能力做好暴露成配置,策划靠改表迭代,谁都不用频繁改代码。
把它讲清楚一点:每一样设计产出(POI、路网、怪物、资源),都有对应的落地手段,而中间把”设计意图”和”工程实现”连起来的,是配置表这个交接界面。设计师在表这一侧表达”要什么”,工程在表那一侧负责”怎么生成”。两边解耦,迭代就快。
最后,关卡做出来怎么验证?同样是回采数据看是否达成体验目标——玩家轨迹、停留、死亡点埋点,生成热力图,对照配方意图看:紧张段真紧张了吗(四样没抵消?)、该去的 POI 去了吗、走的路对吗。哪个配方实跑有效就强化入库,哪个翻车就修正参数——配方库越用越准。
后续方向:同一套框架还能装什么
战斗、敌人、关卡讲完,这套框架其实还能套到更多系统上。
成长养成、掉落经济、任务叙事,是跟战斗/敌人/关卡平级的游戏系统,都能复用同一套主线:体验目标 → 功能与数值 → AI 协作 → 验证迭代。运行时 AI 导演和 PCG × AI 则是两种横向能力,贯穿所有系统——前者让游戏对每个玩家”活起来”,后者让内容”长出来”。运行时导演的架构上一篇已经详细谈过(波次编排、事件注入、内容变异那套),这里不重复;只重申那条边界——上一篇的说法是”LLM 做’想什么’,行为树做’怎么做'”,放到这套框架里,意思就是 LLM 只做局间编排,不下场做每帧的 Tick 决策。
这些先点到为止,后续会逐个展开。
技术底座:让这一切真正可靠、可普及
前面讲的全是”做什么”。但这一切能不能落地,取决于两个技术底座。
第一个底座:AI 写代码怎么才可靠。
我的答案是——可靠性不靠”AI 更聪明”,而靠一条固定的开发流程(SOP):确定框架/Skill → 制定 Plan → Skill 下执行 → 功能验收 → 配置化 → 数值验收。
这里只点出几个最核心的判断,完整的流程会另起一篇《AI Coding SOP》专门展开。其一,把 AI 框在已有的客户端框架内——它是填空,不是从零盖楼。其二,先出设计 Plan 让人审,绝不允许跳过 Plan 直接写代码。其三,也是跟玩法体系最相关的一点——两道验收:功能验收管”代码对不对”,数值验收管”数值对不对”。功能验收不过,回去改代码,成本重;数值验收不过,只改配置表,不碰代码,成本极轻。这正是整篇反复强调的”迭代靠数值不靠改代码”在工程上的落地——代码是骨架,尽量一次过;数值是调整层,可以反复改、反复验。
第二个底座:让所有人都能用,不只是程序。
前一个底座降的是程序的成本。这一个底座降的是所有人的成本——而且聚焦在玩法设计和原型搭建阶段。
AI 在这里当的是人与编辑器之间的翻译层。传统流程里,美术、策划要落地一个想法,得先学会编辑器一堆复杂操作、菜单、参数含义,然后手动在编辑器里搞。而有了翻译层,他们直接用人话表达玩法意图(“给我把近距离 TTK 0.4 秒的霰弹枪””这段要紧张那段给喘息”),AI 翻译成编辑器里的实际操作和配置,快速落地成可玩原型。
它降的是三种成本:学习成本(不用学编辑器的操作、菜单、参数含义)、使用成本(不用手动一个个点,AI 批量执行)、配置成本(不用记字段名、不怕填错,AI 按意图生成并校验)。
而且这一层直接接上前面四个系统的原型搭建。策划说”对标 CoD 手感、移动更灵活”,AI 翻成 3C 参数配置,直接进游戏调;策划说”会包抄的近战怪,三只一组刷”,AI 翻成占位怪 + 行为配置 + 刷怪表;策划说”这段紧张那段喘息”,AI 翻成 POI/路网/资源配置由 PCG 生成。每一个都是”策划说意图 → AI 翻译 → 可玩原型,立刻验证”。
但边界必须划得很清楚:这一节只搭”玩法原型”,不碰美术表现。 这个阶段的美术,正是上一篇说的四阶段里的第一阶段——验证期:给玩法提供够用的占位(方块人、灰模、商城资产、临时特效),服务玩法体验,而不是做好看的成品。目标是”够用 + 快”,因为这阶段是验证玩法。后面的采购、调优、替换,以及美术表现、渲染、光影材质,不在这一节,留待后续章节。
这层的意义在于一个视角的转变:AI 降的从来不是”程序的成本”,而是所有人的成本——让每个岗位都从”折腾工具”里解放出来,把精力放回”判断玩法好不好玩”上。而 AI 降的也只是”操作成本”,不是”判断”——玩法好不好玩,永远是人的判断。AI 落地,人决策。
写在最后
把这张地图收成一句话:
AI 不替人做判断,而是让”从体验到可玩原型”这条路快 10 倍。
人定体验目标、做判断;AI 找参照、落地、跑验证。三个玩法系统各有自己的体验锚点——战斗锚战斗体验、敌人锚战斗体验带来的情绪价值、关卡锚节奏与探索——而锚点决定了”验证什么”,验证又驱动迭代。没有体验锚点,就不知道该验证什么,AI 也无从协作。锚点,是一切的起点。
这篇是地图。接下来,我会把:
- 战斗系统
- 敌人系统
- 关卡系统
- AI Director
- AI Coding
逐个拆开。
这篇是地图。后面的文章,会是一次真实开发过程的持续记录。
不是讨论 AI 能做什么。
而是讨论——当 AI 真正进入游戏开发之后,一个团队是如何理解系统、验证体验、重构玩法,并最终把想法变成游戏的。
地图已经画好。接下来,是走进每一条街道。