三种角色的协作流

混合开发不只是技术选择，还是组织设计。一个典型的 UE 团队有三种角色，混合结构让他们并行工作：

关键设计是：C++ 层提供"编程语言的确定性"，蓝图层提供"业务语言的灵活性"。程序员通过 BlueprintCallable 和数据资产，把能力"发布"给非程序员；非程序员在蓝图层组合这些能力，形成具体玩法。

一个具体的需求流转

假设策划提了一个需求："玩家被怪物攻击时，有 30% 概率触发闪避反击"。混合开发下的流程是：

1. 程序员在角色类里加一个 UFUNCTION(BlueprintCallable) 函数 TryEvade() 和一个 UPROPERTY(BlueprintAssignable) 事件 OnEvadeSuccess，半天搞定。
2. 策划在角色蓝图里订阅 OnEvadeSuccess，连线播闪避动画 + 反击判定，自己调概率参数，半天搞定。
3. 美术看到播放时机不对，自己把蒙太奇里的有效帧往前挪了一帧。

全程没有谁在等谁。对比一下"全 C++"项目的流程：策划写文档 → 程序排期 → 三天后程序说做完了 → 美术说要调 → 再排期……混合开发真正优化的不是代码，而是人。

代码评审：蓝图的"可读性"是双刃剑

蓝图便于评审这件事也有代价。一张密密麻麻的事件图表，看起来吓人，读起来也不轻松。几个让蓝图更可维护的习惯：

• 一个函数只做一件事，函数像 C++ 一样短小，不要一张图表几百个节点；
• 命名规范：变量 bIsEvading、事件 OnEvadeSuccess、函数 TryEvade——和 C++ 同一套规范；
• 用注释框（Comment Box）分区，把图表分成"输入校验 / 主逻辑 / 表现"几块；
• 引脚折叠（右键引脚 → 折叠节点），把长得难受的中间结果收起来。

交接：当程序员离职时

一个现实问题：蓝图资产属于项目，但蓝图的知识往往只存在于连它的人脑子里。降低交接成本的三个做法：

1. 框架留给文档，蓝图留给评审：C++ 框架写文档（类图、调用链），蓝图靠"连给大家看"评审。
2. 蓝图命名和目录规范：Blueprints/Player/BP_PlayerCharacter 这种路径本身就是文档。
3. 避免"魔法连线"：没有任何注释、绕了五个弯才到达目标的连线，是后人最怕的东西。

本章小结

• 混合开发是组织设计：让程序员、策划、美术并行迭代而不是互相等待。
• 典型流转：C++ 发布能力（BlueprintCallable + 事件）→ 蓝图组合玩法 → 美术调表现。
• 蓝图的可读性需要纪律维护：短函数、统一命名、注释分区、折叠引脚。
• 交接成本可以用"文档在 C++、评审在蓝图"来控制。