背景摘要： 在某开放世界 3A 项目的研发迭代中，随着策划人数和数据量的膨胀，传统的数据维护模式面临巨大挑战。本文复盘了我在 2025 年针对"多分支并行开发"、"自动化校验管线"以及"编辑器实时性能监控"三个核心维度的技术探索与实战反思。
【我的探索】
分支 tag 功能
此功能的初衷是为了降低策划在多个分支上维护表格数据的难度（例如需要拉取多个仓库，在表格工具中切换多个仓库等），还能通过分支合并工具来对不同分支的数据进行合并，这样在分支开发结束时就能快速收敛表格内容到开发分支上。
实际运行中遇到了一些问题。
- 虽然在某些操作流程降低了复杂度，但是增加了额外的复杂度和学习成本，例如 tag 的优先级规则、以单元格为单位的合并规则、tag 和分支的对应关系、（复杂度没有转移。只是消失了）。
- 根据需求单迭代号限制提交功能无法直接生效，因为每个分支的数据都放在了相同的表格文件和同一个仓库。虽然在 SVN 上做了 hook，但是非常不灵活。
最后的解决方案是：不同分支使用不同的表格仓库，策划在不同仓库中维护表格内容。我们开发了自动合并工具，并通过流水线的方式，自动将每一个分支表格中的内容合并到开发分支中。
需要注意的问题有：
- 不同表格仓库需要有不同的 lua 检查脚本，以及 lua 检查所需的 lua 文件备份（从 Perforce 仓库中获取），这些内容都需要新建流水线来实现，新增流水线会使得流水线出错导致数据阻塞的可能性提升。好在流水线的维护比较简单和固定化，遇到问题能够快速解决。
- 此外，不同仓库理论上会有不同的 hookscript，好在根据目前的策划需求，暂时不需要这个功能。
性能检测工具
性能检测功能的初衷是在策划布设前就能在关卡编辑器中知道布设这个实例带来的性能压力增量是否会导致当前区域的性能指标过载。
最开始的设计思路是给每个物件进行一个性能打分，如果打分高，表示它带来的性能压力较大，如果打分低，表示它带来的性能压力小。
布设实例时，遍历布设位置周围一定范围内所有实例的性能分数并进行求和，总和大于一定值时，会禁止策划进行实例的布设。
实际开发中遇到的问题是：
- 性能指标很难用一个数值来衡量。一个物件主要的性能压力来自图形渲染和逻辑计算，对硬件的影响不同。有可能图形渲染压力已经超标了但是逻辑计算还有很大空间。
- 任务逻辑和机关逻辑使异步加载的情况普遍出现。例如原神璃月港的同一个空间里面有非常多 NPC 和物件、有的只在海灯节出现、有的只在主线任务出现，有的只在活动任务出现。虽然同一个区域布设了非常多物件，但他们并非同时出现。单纯靠物件的性能打分来计算的话，容易出现表面上这个区域超标了，实际运行时发现稀稀拉拉没有几个物件。
- 我尝试解决实例异步加载的问题，试图通过任务流程和机关逻辑流程来判断某些物件是否会同时出现。但是在这一步，只能判断同一个 flow 文件引用的物件是否会同时显示，而同一个任务会引用多个 flow，使得难度大增。在此基础上，玩家接取任务和完成任务的顺序不是固定的，如果多个任务引用的物件都在同一个区域，实在很难判断到底哪些会同时显示。
- 开发此功能时，策划已经布设了大量的关卡数据，如果性能检测开关打开，会导致绝大多数正在开发的区域无法再进行布设。我开发了一个性能打分热力分布图来查看性能压力分布，发现策划实际布设时的性能压力呈现高度的两极分化，重要区域性能压力极高，不重要区域几乎是无人区，没有性能压力。差不多是只有 1000 分和 1 分的差异，中间并没有平滑过渡。这给我的启示是：开放世界游戏一开始就应该对性能压力进行规划，如果无法规划，至少应当进行限制，在开发过程中逐渐降低限制要求和门槛，也比毫无限制的效果更好。
- 开发此功能的重点几乎全部是没有太多技术要求和技术提升的前端工作，并且花费了不少时间。在发现这套方案不合适后，我们将功能暂时关闭，这导致程序十分愤怒，因为做这个花时间也不提升技术，以后应当避免直接开发此类功能需求，好在 AI 时代降临了，我可以先用 AI 开发功能原型来探索解决方案的可行性，避免浪费程序的宝贵时间。
- 为了客观评价一个物件的性能压力指标，我开发了一个有些搞笑的功能。用一个蓝图，对所有的物件进行性能检查。检查方式是在几乎空白的场景中，在玩家附近一定范围内随机放置 100 个物件，观察性能指标的变化量，除以 100 就是这个维度的性能压力指标。这个方法在公版引擎中是可用的，但是在项目引擎中需要魔改关键引擎节点，无法进行流水线化的操作，我们有上千个物件，跑一遍需要时间很长，不可能人工操作。而且在项目引擎中，卸载物件后需要很长时间性能指标才会恢复到创建物件之前的状态，有时候甚至不会恢复，我也不知道为什么。所以这个方法告吹。以后做新项目的时候可以尝试一开始就把这个功能完整实现。
lua 检查
提交表格时进行 lua 检查可以防止业务逻辑错误被上传，但是有一些问题。
- 业务逻辑正确性需要多个 lua 进行关联检查。本地 lua 如果是旧的，有可能出现本地通过，服务器挂掉的情况。
- 如果提交表格时把本地 lua 全部更新，可能会导致策划的本地测试环境坏掉（策划希望在旧 lua 环境中配置，而非最新的 lua 环境）。
最后最合理的方案是：
- 设置流水线 A，其作用是，当服务器上 lua 更新时，将所有 lua 同步到表格 SVN 仓库中的一个临时 lua 目录中，相当于这个目录始终和最新 lua 环境保持一致。
- 设置流水线 B，其作用是，当服务器上 lua 检查脚本更新时，将所有 lua 检查脚本同步到表格 SVN 仓库中的一个检查脚本目录中，相当于这个目录始终拥有最新的检查脚本。
- 提交表格时，表格工具调用 B 中的检查脚本，对 A 中的 lua 进行检查。
- 保留本地导出 lua 的功能，方便策划进行本地测试。
这其中有一些问题：
- 流水线多了，错的概率也大了。
- 每创建一个新分支，都需要新的流水线 A 和流水线 B，维护成本小幅提升。
好在流水线出错的范围比较固定，解决起来速度比较快。 - lua 检查脚本的新增是由不同程序新增的，检查报错的可读性和指引性普遍较差。这部分内容只能亲自沟通。下一个项目可以考虑自己实现。
【我的反思】
- 策划提需求时总是说很急，现在就要，尽快。但是做好以后没有反馈。之后需要增加评估环节和反馈机制，如果开发完成后一段时间内没有反馈，就降低对应策划的需求优先级。
- 策划侧需求结构性变更较大，容易使过去的功能彻底失效。这个和开放世界类型项目的探索阶段有关，属于正常现象。
- 策划工作时需要了解的前置文档内容过多，团队成员之间交流少，新人有问题不问导师，有时甚至不知道需要了解哪些文档。今年会通过 AI 彻底解决这个问题。
- 工具管线调整流程较长迭代不及时，今年会将 SOP 固化，优化流程。
- 策划执行素质参差不齐，总体偏低（相对于我经历的其他项目），今年将会通过考试的形式来强化新人策划上岗前的知识储备。