本系列第二篇 · 实战开篇。承接总纲篇《AI 原生游戏开发——从资产复用到经验复用》，由其确立的方法论在此进入真实项目的实证阶段。
一个必须先回答的问题
总纲篇系统梳理了”AI 能在游戏开发的哪些环节发挥作用”——检索参照、转译方案、生成代码、调校数值、执行验证、接入资产。论述是完整的。
但论述完成之后，一个问题始终悬而未决：这套方法，究竟是停留在演示层面的设想，还是一条真正可以落地运转的管线？
理论推演的价值有限。因此从本篇起，本系列将把这套”AI 辅助开发管线”置于一个真实项目中完整运行一遍，以检验它是否成立。
项目定义如下：在一套已升级至 UE5.7、且大多数系统现成的射击框架之上，构建一个搜打撤（Extraction Shooter）玩法的第三人称射击原型，其战斗与编排体验对标某款 PvE 射击标杆。周期三个月，由开发者主导，AI 辅助。
此处有一个必须明确的前提——原型本身只是载体。真正接受检验的，是 AI 辅助开发这套管线。 这一判断是整个系列的主轴，后文将反复回到它。
为什么选择搜打撤，为什么对标这款标杆
搜打撤的核心是一条闭环：空降进场 → 搜刮物资 → 完成目标 → 承压撤离。它的吸引力不在于某个单一的炫目系统，而在于”继续深入还是安全撤离”的持续权衡，以及撤离阶段那段”最后坚守”所形成的张力。
作为对标对象的这款标杆，将上述体验推向了极致：大量敌人同屏逼近所形成的压迫感、以指令序列呼叫天降支援所带来的反馈快感、厚重而非轻捷的重装移动质感、每一次命中都具备分量的射击反馈，以及一个关键设定——它是一款四人协作的游戏，单人作战在其机制下难以持续。
本项目要复现的是这种”体验感受”，而非照搬其系统实现。 这一界定，决定了 AI 在本项目中应当承担什么、不应承担什么。
动手之前的第一项工作：完成一次系统性盘点
一种常见的设想是：用 AI 做游戏，即打开编辑器令 AI 直接生成。本项目的第一步恰好相反——先让 AI 完整梳理这套框架，厘清哪些系统已现成、哪些需补足、哪些须从零构建。
这正是 AI 能力中最被低估的一项：代码考古。盘点结论使整体格局一目了然：
- 基本现成（调整配置即可）：武器伤害（数据表驱动）、搜刮拾取、撤离空降、角色基础操控
- 部分现成（需补足关键环节）：相机（第一人称完整，缺第一↔第三人称切换）、敌人 AI（行为树与群体管理完备，缺潮水波次）
- 有积累但尚未打通：目标素材的资产管线（解包、材质逆向、关卡逆向工具链均已成熟，但尚未接入框架）
真正需要从零构建的，仅有三项：第一↔第三人称视角切换、战备召唤系统、潮水波次系统。其中战备召唤是唯一一个全新玩法系统——其余皆为复用、调校与资产接入。
这一判断确立了整个计划的取舍：精力不投入于重复造轮子，而集中于这三项以及”调出准确的体验”。
🔧 设计复盘 · 为何先盘点再动手
为什么这样设计：未经盘点即开工，最大的风险是重复建设——耗费两周去实现框架中已完成九成的功能。先令 AI 厘清现状，精力方能投向真正的空白处。
踩过什么坑：盘点并非让 AI “通读代码后给出无问题的结论”。它必须产出可落实到具体调用链、具体数据表字段的现状清单，否则等同于未盘点。
传统方案差在哪：人工通读数十万行陌生代码以厘清一套框架，是以”周”为单位的工作量。代码考古将其压缩至以”天”为单位——这是整个计划得以纳入三个月周期的前提。
一项由盘点得出的判断：联机并非负担，而是既有红利
盘点中的一项发现，直接修正了对工作量的预估。
搜打撤的核心在于协作。一个常见的预期是：在三个月的单人原型周期内，实现联机会导致工作量失控——状态同步、属性复制、多端一致，通常都是吞噬研发周期的难点。
但对框架网络层的梳理给出了不同的结论：这是一套生产级的联机射击框架。 仅一个核心模块中即存在近两百处网络复制声明，角色移动、属性、状态机均已按复制机制设计。
这意味着联机的定位，从”是否要做”转变为一个截然不同的命题：并非”构建网络层”，而是”复用既有网络层，且避免将新系统实现为不可联机的单机逻辑”。
因此联机未被单独设立为”里程碑”——那将导致联机被置于最后接入，而前期系统全部以单机方式实现、继而返工。它被确立为一条贯穿性原则：自第一个里程碑起，所有新系统均按可联机方式设计，状态沿用既有的复制路径。验证环节直接以多人协作的方式完成。
那么”按可联机方式设计”具体是何种约束？它并不抽象，落实到代码即是若干明确的准则。
举一个最易出错的反例。战备召唤中，玩家输入指令序列、投掷信标、数秒后天降一发轨道炮击。不可联机的实现方式是：客户端在本地检测信标落地、本地生成轨道炮击、本地结算伤害——单机环境下运行顺畅，一旦联机便会失效：各客户端各自计算，队友所见的落点、伤害、乃至”该次支援是否到达”都可能不一致。可联机的实现方式是：信标投掷作为一个请求，由服务器判定落点与时机、由服务器生成支援实体、由服务器结算伤害，再将结果复制至所有客户端。表现层（弹道、震屏、音效）可在本地呈现，但任何影响游戏状态的判定，都必须归属唯一权威端。
同一准则贯穿每个系统：敌人的血量与死亡由谁判定、任务进度由谁推进、撤离倒计时以谁为准——答案始终是”服务器权威，客户端表现”。这并非高深架构，而是一种编码时的默认习惯：每新增一个会改变游戏状态的字段，先确认”它是否需要复制、由谁修改”。
这恰是 AI 辅助最能发挥作用、同时也最易出错之处。发挥作用在于：AI 能够理解框架既有复制宏的用法，按现有范式为新系统的状态字段接入复制。易出错在于：若缺乏人工把关，AI 生成的代码会倾向于采用”本地直接修改、运行即可”的单机逻辑——因为在其训练所形成的倾向中，单机实现更简短、也更”自洽”。因此在联机这条线上，人的职责是持续追问”该状态在联机环境下是否一致”。
此处单独论述，是因为它指向一个更具普遍性的判断——在 AI 辅助开发中，人最不可替代的，往往不是编写代码，而是持有那些处于 AI 视野之外的系统性约束。 AI 擅长在一个被界定的局部内给出迅速而准确的解；但”这段代码须在联机环境下成立””这个字段将被四个客户端同时观察”这类约束，并不在其当前上下文之内，因而难以被其纳入考量。联机只是此类约束中最典型的一例。纵观整个原型，真正的工作量重心不在”令 AI 产出代码”，而在”为 AI 守住其无法看见的边界”。这也正是本系列要验证的核心之一：这套”人持约束、AI 出解”的分工，能否稳定运转。
🔧 设计复盘 · 为何联机是原则而非里程碑
为什么这样设计：若将联机作为独立阶段置于末尾，等同于默许前期所有系统先以单机方式实现、再行改造——这是返工成本最高的一种排布。
踩过什么坑：初版排布曾将其归入”后续再议”的独立模块。真正的风险不在网络层（其已现成），而在于新系统是否会被随手实现为不可复制的单机逻辑。将其前置为原则，正是为了从源头规避此类返工。
传统方案差在哪：传统做法常将联机化视为一场专门的”改造工程”。当底层网络层已成熟时，更经济的方式是令其隐于无形——融入每个系统的设计约束之中，而非单独立项推进。
路线：先打通”可玩”，再充实”耐玩”
十三周的推进顺序经过设计，而非按编号顺次排列。
阶段一 · 立项 + 三项前置验证（W0-1）。 确认框架可完成整工程编译、可启动编辑器；同时对三条最不确定的管线进行前置验证——资产（能否解包并接入）、网络（多人能否起服运行）、任务/HUD（现成程度）。将高风险事项在首周即予暴露，而非拖至末期方才发现不可行。
阶段二 · 视角改造（W1-3，首个交付）。 将第一人称视角改造为第三人称。这恰是总纲篇”将 FPS 改造为 TPS”这一论点的首次实证。
阶段三 · 移动与射击手感（W4-5）。 重装移动的厚重质感，与扎实的射击反馈。
阶段四 · 战备召唤（W6-7，从零构建）。 以指令序列呼叫天降支援——这是标杆游戏最具标志性、也是本项目唯一从零构建的玩法系统。它相对独立、不依赖敌人，因此被有意提前至怪物之前，以便在空场环境下即可验证”输入→信标→天降”的完整链路。
需单独指出：这是整个原型中，唯一一个真正从 0 到 1 设计的全新系统——其余里程碑或为改造现成系统，或为在既有架构上做增量，唯有它始于一张白纸。也正因如此，它将成为检验”AI 辅助从 0 到 1″是否成立的试金石。前述”复用、调校”环节中，AI 的价值相对可预期；而面对一个框架中毫无先例的系统，AI 能否从方案转译一路支撑至代码生成——这是整个项目最大的未知数，也是本阶段需重点观察的指标。
阶段五 · 怪物（W8-9，从零构建）。 单体敌人的威胁可读性，与群体的潮水压迫。
阶段六 · 循环 + 任务 + 联机（W10-11）。 将各部件整合为一局完整可玩的搜打撤。本阶段并置三项内容，因为它们本就是”一局”不可分割的三个侧面：循环骨架、任务系统、多人协作。
阶段七 · 耐玩打磨 + 资源接入（W11-13）。 调出”再来一局”的驱动力，并将标杆游戏的资产全量接入。而 UI/HUD 不归属于某一周——它贯穿全程，伴随每个系统逐步补足：缺乏清晰的信息传达，再完善的系统玩家亦无从感知。
第六阶段三项内容中，最值得单独论述的是任务系统
循环、任务、联机并置于同一阶段，并非因其琐碎而打包处理，恰恰相反——它们是”一局”不可或缺的三个侧面。其中任务系统，是最易被视作”附属功能”、却最不应被如此对待的一项。
先陈述一个反直觉的事实：一条表面完整的搜打撤循环，可能完全处于空转状态。
空降、搜刮、交战、撤离——这四步串联起来，玩家确实能够自始至终走完。但若缺少”本局的目标为何”，它便等同于一台原地运转的设备：玩家投入大量操作，却没有任何理由前往地图更深、更危险的区域。理性的玩家会得出一个令体验失色的最优解——着陆、就近搜刮一轮、随即撤离。风险最低，收益尚可，循环依然闭合。但这一局毫无张力，因为没有任何机制促使玩家承担风险。
任务系统正是促使玩家承担风险的机制。它为本局设定一个主目标——摧毁一处设施、采集一份样本、上传一段数据——而该目标恰好位于地图深处，且恰好需要时间。一旦引入它，玩家的决策便随之具备实质：是否为完成主目标而深入险地？支线提供的额外收益，是否值得多停留两分钟、多承受一波潮水？
更关键的是它与撤离的耦合方式。撤离不应是随时可用的逃生通道，而应受主目标完成度的约束。 未完成主目标即撤离，本局仅算半数达成；完成主目标后，撤离点方才真正激活、或撤离条件方得优化。这一耦合，将”搜打撤”从三个独立动作，焊接为一条具备起始动机、过程高潮与代价的完整叙事——玩家带着任务进场，在潮水中完成它，再于更猛烈的潮水中撤离。”最后坚守”的张力正源于此：玩家所守护的，不仅是搜得的物资，更是本局艰难达成的目标。
明确其为驱动核心之后，实现路径反而清晰。原型阶段不计划堆叠大量任务类型——以一两种验证体验为宜，例如”摧毁设施”与”采集样本”。但任务将实现为数据驱动：目标类型、目标点位、完成条件、与撤离的耦合关系，全部抽象为配置，而非硬编码至某一关卡。如此一来，体验验证完成之后，扩展更多任务类型仅为配置层面的工作，无需回头改动核心循环。
这套”先验证体验、再以配置放量”的思路，实则贯穿整个计划——战备种类、敌种、波次曲线均循此路径。其背后是一个朴素的判断：原型阶段须验证的是”这套体验是否成立”，而非”内容是否充足”。 内容是体验成立之后才值得放量的部分。AI 在此处的角色，是协助设计这些系统的配置结构、填充首批数据；而”这套体验是否成立”的最终判断，仍由开发者作出。
将其称为驱动核心而非功能，原因正在于此：功能是可事后追加的部件；驱动核心则决定整个系统的发力方向。
🔧 设计复盘 · 任务系统：一项从”功能清单”中重新提取出的驱动核心
为什么这样设计：循环骨架（空降→搜刮→交战→撤离）看似完整，却缺少”为何进入本局”这一环。没有局内目标，搜打撤将退化为单纯的刷怪场。任务系统才是驱动玩家深入地图、并形成”完成目标再撤离”张力的核心。
踩过什么坑：初版计划中它并不存在。回头审视循环时才暴露出问题——那是一条缺乏起始动机的循环。它不应是某个里程碑的附属功能，而应与”撤离条件”直接耦合。
传统方案差在哪：将任务视作”再增一项功能”，循环便是原地空转的设备。将其视作驱动核心，循环才具备方向。
内核：AI 在这套管线中，被界定为承担什么
这才是真正接受检验的内容。但在谈 AI 承担什么之前，须先交代一个贯穿全程的拆解方式——它决定了 AI 的发力点落在何处。
每一项体验目标，都被拆解为「功能」与「数值」两部分。 功能是骨架：开火能命中、信标能召唤、敌人能成群推进——它解决”有没有”。数值是手感：后坐力多大、TTK 多长、波次以怎样的曲线爬升——它解决”对不对”。功能搭好之后，真正决定体验成立与否的，几乎全在数值这一侧。
关键认知在于：这里的数值调优，本质是体验向的，而非工程向的。 把后坐力曲线从 A 调到 B，表面是改一个配置项，实质是在回答”这把枪打起来够不够扎实”；把波次密度上调三成，表面是改一个刷新参数，实质是在回答”被淹没的窒息感够不够”。数值不是冷冰冰的配置，它是体验本身被量化之后的形态。正因如此，调数值这件事不能完全交给 AI——因为”调到什么程度才对”是一个体验判断。
这一拆解方式，正是下面三条分工的共同前提：AI 在”功能”侧能大量代劳，在”数值”侧只能辅助逼近、由人定夺。
🔧 设计复盘 · 为何”数值即体验”，而非”数值是配置”
为什么这样设计：把体验拆成功能与数值，是为了让模糊的”手感好不好”落到可操作的对象上。而其中数值一侧之所以被特别强调，是因为它最容易被误当作纯工程参数对待——一旦如此，调参就退化为”凑一个不报错的值”，体验便无从谈起。
踩过什么坑：数值的危险在于它看起来太像普通配置，因而极易被”顺手填一个合理值”敷衍过去。但 TTK、散布、波次曲线背后站着的是玩家的真实感受，填错一个值，骨架仍能运行，体验却已塌掉——而这种塌陷不会报错，只能靠人感知。
传统方案差在哪：传统分工常把”数值策划”与”程序实现”割裂，数值沦为表格里的孤立条目。将数值明确锚定为”体验的量化形态”，调参才有了判断依据——它对照的不是某个技术指标，而是一个具体的体验目标。
其一，参照对齐优先。 对于视角、移动、射击这些”手感类”环节：由开发者考察标杆、确定方向，AI 负责将”厚重””扎实”这类难以言明的感受，归纳为一张可调的「参数基准表」——臂长、肩部偏移、后坐力曲线、加速度，继而依据基准进行调校。AI 在此处的价值，是将主观手感转化为客观可调的数值。
其二，机器采数 + 人评估。 对于敌人、压迫、平衡这些”验证类”环节：由机器负责运行、埋点采集数据、并将数据整理为曲线——反应窗口是否充足、原地静止多久即被击杀、压力峰值出现于何处。但“体验是否准确”的判断权，始终归开发者所有。AI 不参与评分。
这一条须重点说明，因其最易被偏移执行。一种常见设想是：令 AI 观看一段录像并自动评分即可。本项目刻意没有采用此种做法。 “该敌人是否具备威胁感””这一波压迫感是否准确”，属于体验判断，而非数据判断。AI 承担的，是将模糊的体验转化为可供审阅的客观数据，使判断有据可依；但最终决断由人作出。
这守住了整个系列的主轴：AI 辅助，人决策。 验证环节亦不例外。
其三，从零构建时着重功能与表现。 对于战备召唤这类全新系统：重点在于系统功能完整、召唤具备反馈快感，AI 的代码生成退居辅助位——它协助将设计迅速转化为代码，但”该系统应当呈现何种形态”由开发者确定。
🔧 设计复盘 · “AI 不评分”是退步还是进步
为什么这样设计：将评分权交予 AI，表面上更趋自动、更显先进。但体验优劣并无客观标准答案，令 AI 评分，无异于将一道没有标准答案的题目，交给一个会一本正经地虚构答案的应答者。
踩过什么坑：一种更激进的设想是让 AI “观看回放、评估情绪曲线”。但其边界很清楚——它能够依据导出的数据序列进行推断，”自行观看整段视频流并为体验评分”则既不可行、亦不应为。与其包装为全自动，不如明确划清边界。
传统方案差在哪：传统做法是投入人力开展问卷、焦点小组以测度体验。AI 并不取代这一判断，但它将”采集数据、整理曲线”这一繁重环节自动化，使人的判断来得更快、更有依据。
尚不确定之处（先行列明）
依照惯例，将目前没有把握的事项列明：
- 框架能否完成整工程编译、能否启动编辑器——目前仅确认部分模块已编译通过，”全工程可运行”尚未实测。这是阶段一首要解决的事项，也可能在首周即构成阻碍。
- AI 归纳的”参数基准表”实际效用如何——这是整个”参照对齐”思路的关键所系。基准若偏离实际，这条管线的价值便须打折。
- 联机的”可复制设计”是否处处存在隐患——网络层现成，不等于新系统接入后即保持一致。多端状态一致性须经实际运行方能确认。
- 验收标准中的数值（命中耗时区间、单局时长）目前均为占位值，须待实际产出后方知真实取值。
这些不确定，恰是本系列值得记录的原因——若一切皆有定论，便无验证的必要。
后续
本篇为立项说明。自下一篇起，将随开发进度推进：先实践，后记录。 完成即如实记录完成，受阻即如实记录受阻，包括 AI 未能提供有效帮助的环节。
本系列要验证的从来不是”AI 的能力上限”，而是——一名开发者借助 AI，能否将一个原型从一套现成框架推进至可玩状态。
这一答案尚无定论，而验证过程本身即是本系列的价值所在。
总纲篇中确立的那些判断——AI 能够检索参照、转译方案、调校数值，并守住”由人决策”的底线——是否成立，三个月后，这个原型将给出回答。
（本文为系列立项说明。所涉游戏名称全程匿名化处理。后续实战篇将随开发进度产出。）