一、为什么写这篇
上一篇我们讨论了AI Native游戏开发的方法论，核心观点是”体验验证前置”——在正式资产到位之前，游戏已经可以被完整游玩和验证。
方法论说起来很美，但落到真实项目里到底什么样？
这篇用一个真实案例来回答：我们手里有一个FPS工程，想把它改造成TPS。不是从零做一个TPS，而是在已有FPS系统的基础上，让它变得”像一个TPS”。
这不是一篇TPS相机技术文。这是一篇关于AI如何参与真实开发现场的纪录——从理解一个陌生的系统开始，到产出完整的改造方案和开发计划。
二、起点：一个FPS工程想变成TPS
我们面对的是一个已经运营了一段时间的FPS射击工程，基于UE开发，代码量不小，多个团队经手过。工程里确实有TPP模式——有一个CameraMode组件支持FPP/TPP切换，切过去相机确实到了角色身后。
但切到TPP之后你会立刻感觉到”这不是TPS”。相机距离固定在216cm，肩部偏移只有24cm，跟随没有任何Lag，感觉像把一个摄像头刚性焊在角色背上。瞄准的时候相机直接切回FPP，TPS视角下根本没法正常ADS。开枪几乎没有相机反馈——后坐力、开火震动这些系统存在，但只在FPP下生效。贴墙时相机直接怼进墙里。整体更像是一个”从背后看FPS”，而不是真正的第三人称射击体验。
传统做法大家都清楚：策划凭经验写一份相机需求文档，列一堆”要加的功能”，程序排期开发，做完联调，发现不对，改，再联调，再改。几个月下去，可能还在调基础手感。而且因为不清楚现有系统的全貌，很可能重复造轮子——某个功能其实已经有了，但没人知道。
一开始我们也是这么想的。
后来换了个思路：与其凭经验猜”要做什么”，不如先让AI把整个相机系统翻一遍，搞清楚”已经有什么”。
三、AI不是在”生成功能”，而是在”理解系统”
这是整个过程中最出乎意料的部分。
AI读完整个相机系统的源码后，我们发现了一个令人意外的事实：这个工程的相机框架能力其实很强。
SpringArm组件支持15种以上的移动状态——站立、蹲下、趴下、翻越、跳伞、游泳、被背负、NPC对话……每种状态都有独立的相机距离、偏移、高度配置，通过一个叫BasicLayerConfig的TMap在蓝图里配置，完全数据驱动。CameraModifier体系更是一字排开：武器后坐力Modifier、枪械摇摆Modifier、受击相机Modifier、开火震动Modifier、趴姿冲击Modifier、车载相机Modifier……十几个Modifier各司其职。瞄具系统有一张完整的CSV配置表，50多种瞄具各自的缩放倍率、FOV、景深参数全部可配。FPP/TPP切换有完整的优先级机制，支持多个系统同时请求相机模式切换并按优先级仲裁。
框架能力远比我们预想的强。
但AI同时也发现了另一面。让AI翻一个运营多年的工程代码，很像在考古——你不断挖出一些东西，有的还在用，有的被埋了，有的做了一半就停了。
Sprint相机层——完整的加速/稳定/减速相机变化逻辑，大约60行代码，但整段被 #if 0 包裹。这不是”没做”，而是做过，被遗弃了。
后坐力系统——非常精细，支持按姿态分别配后坐力模式，有弹簧阻尼恢复。但检测到非FPP直接return。一个工程”像不像TPS”，有时候只差一行代码。
ADS瞄准——触发瞄准时直接强制切FPP，没有任何配置开关。TPS体验断裂，往往不是缺系统，而是系统之间没有真正协作。
代码里还有大段标注”废弃逻辑”的注释块——左右肩射Camera层、喷气背包Camera层，全部写了配置属性声明但被注释掉。之前有团队规划过一套完整的TPS肩射相机系统，但在某个时间点被整体搁置了。这些废墟和活代码混在一起，一个运营多年的工程往往不像”一个系统”，更像多个时代叠加起来的遗迹。不是AI标出来，很难分辨哪些是活的哪些是死的。
AI还顺着调用链一路往下翻，挖出了几个更意外的东西。
FPP/TPP切换的过渡时间不对称——切进FPP是0.1秒snap，切回TPP是0.6秒平滑过渡，两个方向各有独立easing曲线。这不是随便写的数字：快速zoom out看起来突兀，所以进FPP要快，回TPP要慢。一个嵌在代码里的体验设计决策，没有任何文档记录过为什么。AI读到这组数字的时候，我们才意识到前人在这里做过非常细致的考量。
相机模式有7级优先级。有意思的是玩家手动切换FPP/TPP的优先级排在第5——高于载具。代码注释写了：”玩家的主动切换优先级很高，如果业务逻辑需要覆盖，需要先单独调用清理接口”。一个UX哲学嵌在代码里：玩家的选择权高于大部分系统行为。
最意外的发现：AI顺着Retarget逻辑往下翻，发现即使玩家在TPP模式，只要武器开镜，动画会悄悄切到FPP模式。TPP下开镜瞄准时，角色的手臂动画其实在用FPP的。不读完整条链路根本发现不了。
一个工程看起来”不像TPS”，不是因为它缺少做TPS的能力，而是因为这些能力散落在各处，有的被禁用了，有的只给FPP用，有的逻辑写了但没配参数，有的做了一半被搁置了，有的藏在你不会注意到的条件分支里。
一开始以为”要做很多新功能”。后来发现”大部分功能已经有了，只是没用好”。
这个发现改变了整个项目的走向。如果按传统思路，我们会排一个”开发新TPS相机系统”的计划，可能要几个月。但实际上需要做的是”启用已有功能+调参数+修几个硬编码”，工作量小一个数量级。
更有意思的是，AI梳理出了一个完整的配置层级：底层是BasicLayerConfig控制各姿态的基础相机参数，中间层是IndoorLayerConfig在室内自动叠加偏移（每0.5秒向上做一次射线检测判断是否在室内），上层是瞄具表控制ADS时的FOV和景深。也就是说，很多”相机不对”的问题，可能根本不需要改代码，调表就行。但在AI分析之前，没人知道这套三层配置体系的全貌，更没人把它们之间的数据流画清楚过。
这让我们重新思考了一个问题：传统项目里，团队花在”开发新功能”上的时间可能没有想象中那么多。大量时间其实花在了”搞清楚现有系统到底是什么状态”上面。一个中大型工程里，某个功能被谁写了、被谁禁用了、当时为什么禁用、现在还能不能用、参数配在哪张表里——这些问题靠人肉翻代码可能要几天到几周。AI把这个过程压缩到了几个小时。
而且AI的”理解”不是简单的代码搜索。它能把分散在十几个文件里的逻辑串成一条完整的链路：玩家按下瞄准键→FSM Action触发→CameraMode组件按优先级仲裁→SpringArm状态切换→BasicLayerConfig查找对应参数→插值过渡到目标位置→CameraModifier逐个叠加后坐力/摇摆/受击效果→最终输出相机变换。这条链路横跨了GameplayFramework、Camera、Weapon、Animation四个模块，没有人能一次性在脑子里串起来。AI可以。
四、从Feature List到设计原则——每条原则背后都是一个坑
搞清楚系统现状后，第一版方案很自然地变成了一个Feature List：ADS要保持TPP、要加Sprint相机、要启用探头、要补全TPP射击反馈、要优化碰撞……
列了一大堆。
然后我们发现一个问题：功能列了这么多，但不知道什么该先做什么该后做，不知道什么该克制什么该加强，不知道两个功能冲突时听谁的。
Feature List缺的不是”做什么”，而是”为什么做”和”什么不做”。
于是我们开始建立设计原则。不是一开始就坐下来写一套完整的Camera Philosophy——那种东西写出来也没人看。而是每次踩到一个坑，就把教训沉淀成一条原则。五条原则，每一条都来自一个真实的问题。
Camera Philosophy：可读性 > 手感 > 演出 > 炫技
一开始想做很多动态运镜来增加”高级感”。相机跟随加大幅度的惯性，Sprint加强烈的FOV推进，受击加大幅度的画面偏移。看起来确实更”动态”了。
然后我们发现玩家打不到人了。
TPS视角下玩家需要同时关注角色位置、敌人位置、环境掩体，相机的动态效果每增加一分，玩家能分配给”瞄准敌人”的注意力就少一分。于是确立了这条原则：相机的所有变化都必须服务于Gameplay信息传递，可读性永远排在第一位。
Comfort & Stability：长时间不疲劳，ADS必须稳定
尝试了更强的Camera Lag和Sprint Shake。第一个问题不是”不够爽”，而是玩家开始晕了。
短时间体验”哇这个相机好有电影感”。30分钟后”我需要休息一下”。TPS是长时间游玩的品类，相机舒适度比短时爽感重要得多。于是这条原则把短期舒适（别晕）和长期疲劳（玩2小时别累）都涵盖了进去。
Transition & Rhythm：状态切换有节奏
每个Camera功能单独跑都没问题。但同时跑起来的时候，Sprint拉远还没恢复完就进了ADS，ADS还在过渡就触发了后坐力，后坐力还没回弹就吃了一个爆炸冲击。
问题不在于某个功能错了，而在于相机失去了节奏。
Consistency：同一行为永远同一反馈
ADS状态下的射击反馈和腰射的反馈不一致。有时Sprint出来拉远幅度不一样。有时ADS过渡快有时慢。
结果是：玩家永远无法形成稳定的肌肉记忆。每次操作都要”看一下相机在干什么”才能做下一步判断。TPS依赖肌肉记忆的程度比很多人以为的要高——你需要知道Sprint之后ADS拉回来要多久，才能在正确的时机开枪。
Safety Rules：Camera绝对不能坏
狭窄空间Camera疯狂抖动。ADS被爆炸效果强制拉开。贴墙时相机突然穿进角色。这些不是”体验不好”的问题，是”体验彻底崩溃”的问题。
Camera坏一次，玩家对整个操控系统的信任就会动摇。于是这条原则定义的不是”该怎么做”，而是”绝对不能发生什么”。
五、功能和数值分离——AI穷举可能性，人判断什么是对的
方案做到一半，我们发现了一个更本质的问题：很多Camera体验的好坏，不取决于”功能有没有”，而取决于”参数对不对”。
同样一个Sprint Camera功能，FOV多推2度和少推2度，相机拉远30cm和拉远50cm，感觉完全不同。功能做对了只是起点，参数调对了才是终点。
但功能开发和参数调优需要的能力完全不同。功能开发需要理解代码架构、改逻辑、处理边界情况；参数调优需要反复进游戏体验、凭感觉判断、做取舍。前者AI做得又快又稳，后者只有人能做。
于是我们把工作流拆成了两条线：
AI负责把功能做通——分析代码、启用被禁用的功能、补全缺失的逻辑路径、生成参数表模板带默认建议值。
策划负责把体验调对——拿着AI生成的参数表，进游戏反复体验，逐项调整，直到手感对。
更准确地说：AI更适合”穷举可能性”，人更适合”判断什么是对的”。 AI可以告诉你”这个工程有15种相机状态、8类Camera Modifier、50多种瞄具配置”，但只有人能判断”站立时相机离角色多远感觉最舒服”。
这不是AI的局限，是合理的分工。
举个具体例子。AI分析完射击反馈系统后，告诉我们”工程里十几个CameraModifier，其中后坐力、开火震动、FPP骨骼动画这三个只在FPP下生效，枪械摇摆和通用抖动在FPP和TPP下都生效，受击相机在TPP下生效但效果很弱”。基于这个分析，AI帮我们生成了一份按武器类型分类的TPP后坐力参数表模板。但”步枪的后坐力缩放到FPP的0.5感觉对不对””SMG的高频抖动会不会让玩家觉得烦”——这些判断只有人拿着手柄打几局才能回答。
AI不断输出”系统能做什么”和”参数可以怎么调”，策划不断在游戏里回答”这样对不对”。两条线并行，比传统的串行反馈模式快很多。
六、开发计划：先”像不像TPS”，再”瞄得准”，最后”打得爽”
有了方案和原则后，下一个问题是：先做什么？
TPS相机最大的问题往往不是”功能缺失”，而是”基础节奏没立住”。如果基础视角就不对，后面加再多高级功能也是在歪的地基上盖楼。
我们把P0拆成了7步，按严格顺序推进：
第一步是基础TPP视角和肩部位置。做完这一步只回答一个问题：”像不像一个TPS？”如果肩部偏移不对、相机距离别扭，后面所有东西都会跟着歪。
第二步是ADS。建立稳定的瞄准体验。这是最高风险的一步——会影响输入、FOV、后坐力、瞄准稳定性，牵一发动全身。所以放在第二步，尽早暴露问题。
第三步是碰撞处理。解决贴墙和室内的穿模问题。第四步是射击反馈，让TPP下开枪有感觉。第五步是Sprint相机，第六步是探头，第七步是受击反馈。
每完成一步立刻验证。不是写完所有功能再一起测，而是每一步都确认”对了”再进下一步。
为什么这个顺序很重要？因为TPS相机的依赖链是有方向的。基础视角不对，ADS拉近的目标位置就会偏；ADS不稳定，射击反馈就无从调起；碰撞没处理好，室内的所有功能都会出问题。后面的每一步都依赖前面的步骤是对的。如果跳着做，最终很可能要回头全部返工。
我们还给每一步标了风险等级。ADS改造是高风险——它牵涉输入、FOV、后坐力、瞄准稳定性，改一个地方可能影响五个地方。所以放在第二步，尽早暴露问题。Sprint Camera和探头是低风险——已有逻辑取消注释就能跑。低风险的可以快速推进，高风险的要留足调试时间。
整个过程有一条核心原则：除非影响核心体验，否则优先复用现有能力，避免大规模重构。 工程已经有的东西尽量用，能调参数解决的不改代码，能启用已有功能的不写新功能。
P0完成后锁定基础体验。后续的P1（高级感）和P2（高级战斗表现）不得破坏P0建立的基础——ADS稳定性、基础视角、碰撞行为、基础射击反馈，这些一旦锁定就不能再动。
七、AI真正的价值——压缩”搞清楚现状”的成本
回头看整个过程，AI没有自动做出一个TPS相机。
AI做的是把”摸清现状→发现问题→出方案→拆计划”这个过程从几周压缩到了几天。
传统流程里，一个新接手的程序要理解现有相机系统可能需要一到两周——翻代码、看注释、问原作者、跑测试。一个策划要写出靠谱的TPS相机需求可能也需要一到两周——查参考、写文档、和程序对齐理解。然后再花几周排期和开发。
AI改变的不是”开发效率”——真正改代码、调参数的时间没有本质变化。AI改变的是”理解效率”。
在这个项目里，AI第一次开始像团队里的一个高级程序员——不是因为它会写代码，而是因为它能快速理解整个系统。
AI在几个小时内读完了整个相机系统的源码，告诉我们：这里有什么、这里缺什么、这里被谁禁用了、这里的配置表长什么样、这里的数据流是怎么走的。然后基于这些事实（不是猜测），产出方案和计划。
传统流程是”先猜后验”——先凭经验猜需要做什么，开发完了再验证猜得对不对。AI Native流程是”先看后做”——先让AI把系统翻一遍，基于事实出方案，然后有针对性地开发。
这回扣了上一篇的核心观点，但维度有所不同。上一篇说的”体验验证前置”主要是指用占位资源验证玩法方向。这篇的实践让我们意识到：验证前置不只是验证玩法，也包括验证”现有系统的真实能力”。 在动手改之前先搞清楚手里到底有什么牌，这本身就是一种验证前置。
还有一个意外收获。AI产出的不只是一份方案，而是一份团队都能看懂的”系统地图”。以前只有写这段代码的人知道相机系统长什么样，现在AI把整个系统的架构、数据流、配置表、已有功能、被禁用的功能整理成了文档。新加入的程序和策划看完这份文档就能快速进入状态，不需要再花两周自己翻代码。
这可能是AI参与大型工程开发中一个被低估的价值：不只是帮你做事，更是帮你把隐性知识变成显性知识。很多工程里最大的资产不是代码本身，而是”为什么这么写”和”这里能做什么”的上下文信息。这些信息过去只存在于少数人的脑子里，AI让它变成了每个人都能查阅的文档。
八、这只是开始
相机只是TPS改造的第一步。
后面还会继续把移动系统、TPS瞄准、动画分层、武器挂载这些模块逐步拆开。不只是讲”最终方案”，而是真实记录AI如何参与一个大型游戏工程的持续重构。
目前很多问题其实还远没解决。AI能帮助团队更快理解系统、更快验证方向、更快搭出原型。但”什么是好的体验”依然需要人反复试、反复踩坑。相机的手感、射击的节奏、移动的重量感——这些东西没有任何AI能替你判断，只有人拿着手柄在游戏里跑几十个小时才能慢慢逼近答案。
到目前为止，AI最大的价值依然不是”自动生成游戏”，而是让团队第一次能够更快理解系统、更快验证方向、更快知道什么不好玩。
AI穷举可能性，人判断什么是对的。AI理解系统，人理解体验。
这是一个持续展开的AI Native开发纪录，不是一篇孤立的案例分享。如果你也有一个”明明有能力但跑起来不像那回事”的工程，试试先让AI把它翻一遍。你可能会和我们一样发现：答案可能就在代码里，只是从来没人完整地看过。