迷思与常见架构错误

开始写复杂 AI 之前，先排掉五个最常见的雷。这些问题在建项目时不起眼，后期会发展成"AI 团队的地狱"。

迷思一：AI 越聪明越好

"聪明"是有代价的：感知频率、EQS 查询、行为树规模都会吃性能。玩家觉得 AI 聪明，靠的是表现而不是算力：

• 一个"会找掩体"的 AI，表现上只需要它真的会跑掩体 —— 而不是每帧都重新计算最优掩体；
• 一个"会包抄"的 AI，表现上只需要它移动时绕个弧线 —— 而不是真的做了多智能体路径规划。

设计 AI 的正确姿势是：先定表现（玩家看到什么），再定实现（算到什么程度）。

迷思二：行为树可以写一切

行为树擅长"条件 → 行动"的组合，但不擅长：

• 明确的阶段（这时候用 StateTree 更清晰）；
• 复杂的数值记忆（用黑板 + 数据结构更糟，不如专门的组件）；
• 需要持续轮询的状态（行为树的 Tick 服务有开销）。

迷思三：Tick 里做决策

行为树的 Service 节点确实会周期性执行，但它的频率要控制。见过把 Service 设成每 0.1 秒跑一次的，100 个 AI 就是 1000 次 / 秒的决策计算。决策应该是事件驱动的：感知有了新信息再重新思考。

迷思四：全部 AI 共用一个行为树实例

行为树资产可以共享（数据资产），但黑板必须每个 AI 一份（记忆是私有的）。把黑板配置放到共享资产里没问题，运行时数据实例化必须分开。

迷思五：只在编辑器里测

编辑器里一切良好 → 打包后 AI 全傻。常见原因：

每次版本都做一次打包后的 AI 冒烟测试——这比任何编辑器验证都可靠。