一份可复用的分工清单

看完原理，给一份可以直接贴到项目 wiki 上的分工表。原则只有一条：按"修改频率 × 执行频率"决定归属。

判断某个功能该放哪儿，问自己三个问题：

1. 它多久会被改一次？（频繁 → 越靠蓝图）
2. 它多久执行一次？（每帧 ×大量对象 → C++）
3. 改它的人是谁？（策划/美术 → 蓝图或配置表）

三个问题的答案经常是冲突的，这很正常——工程就是权衡。但有了这张表，讨论"放哪里"的时候就不再是立场之争，而是对着同一套标准做取舍。

一个典型的三层结构

以"技能系统"为例，三层可以这样分：

C++ 框架层（半年不改）
  USkillComponent         // 拥有技能、管理冷却、网络同步
  USkillAsset（DataAsset） // 一个技能的静态数据：ID、冷却、消耗
  蓝图基类 BP_SkillBase    // 框架提供的"技能蓝图"父类
蓝图表现层（每周都改）
  每个技能是 BP_SkillBase 的子蓝图
    - 受击特效怎么播、音效怎么排
    - 数值从 SkillAsset 里读，策划改表不改蓝图

这个结构里，程序员半年维护一次框架；策划改数值直接改 DataAsset；要调"火球术的手感"就去改对应的技能蓝图。三种角色的修改互不挡道。

数字"配置化"是混合开发的一半

很多人把"混合开发"理解为"C++ 写一半、蓝图写一半"，其实中间还有一层常被忽略：数据资产。把数值、ID、资源引用从代码和蓝图里剥离出来，能让"调数值"这件事完全脱离程序员：

• 动作游戏的角色属性 → UCharacterDataAsset
• 商店的商品列表 → DataTable
• 武器的手感参数（后坐力曲线、射速） → UWeaponDataAsset

当策划在编辑器里改一个数字就能改变游戏行为时，你就真正用上了混合开发的红利。

分工反模式（先看反面）

在进入正面设计之前，列四种最常见的错误分工，大家对号入座：

1. 全蓝图：原型很爽，项目后期每次加载都卡，一个核心函数被 30 个蓝图复制粘贴。
2. 全 C++：每个参数都要程序排期，策划形同测试员，迭代速度趋零。
3. 蓝图里写核心算法：寻路、背包规则、伤害公式全在蓝图，性能与维护双重灾难。
4. C++ 与蓝图互相拷贝逻辑：同一套伤害计算，C++ 有一份、蓝图有一份，改了一处忘了另一处，线上事故。

第 3 章会讲到用接口和事件分发器把 C++ 与蓝图解耦，第 4 章讲性能反模式，第 5 章用一个完整案例把分工落地。

本章小结

• 分工原则：按修改频率 × 执行频率 × 修改者身份决定归属。
• 中间还有"数据资产层"：把数值配置化，是混合开发最容易被忽略的红利。
• 四种经典反模式：全蓝图、全 C++、蓝图写核心算法、两份逻辑互相拷贝。