子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

当你把鸿蒙游戏拆成：

Store（状态）
System（规则）
Engine（调度）
UI（展示）

你会发现一件事：

玩家行为很好处理
点击 → System → 状态变化

但一旦你开始做这些内容：

NPC 行为
敌人决策
自动战斗
动态难度

问题就来了：

“AI 到底应该写在哪？”

很多人第一反应是：

写在 BattleSystem 里
写在 UI 里
甚至直接写 if-else

结果就是：

逻辑越来越乱
行为越来越不可控
难以扩展

所以需要我们要建立一个关键能力：

AISystem：让 AI 成为“行为驱动层”，而不是“逻辑补丁”

一、为什么不能把 AI 写进 BattleSystem？

看一个典型错误：

class BattleSystem {

  update(store: GameStore) {

    // 玩家逻辑
    this.handlePlayer(store)

    // AI 逻辑
    if (store.enemyHp < 30) {
      this.escape()
    } else {
      this.attack()
    }

  }

}

问题：

规则 + 决策 混在一起
AI 无法复用
行为不可扩展

本质上：

你把“怎么做”和“做什么”写在了一起

二、一个关键拆分：规则 vs 决策

你必须把这两件事分开：

System

攻击怎么计算？
伤害怎么算？
冷却怎么处理？

AISystem

什么时候攻击？
什么时候逃跑？
选择哪个技能？

一句话总结：

System 决定“能做什么”，AISystem 决定“现在做什么”

三、AISystem 的核心职责

AISystem 不做三件事：

不直接改 Store
不写具体规则
不控制流程

它只做一件事：

输出“行为决策”

四、AISystem 的最小模型

export class AISystem {

  decide(store: GameStore): Action {

    if (store.enemyHp < 30) {
      return { type: "ESCAPE" }
    }

    return { type: "ATTACK" }

  }

}

然后由 System 执行：

const action = ai.decide(store)

battleSystem.execute(store, action)

五、从 if-else 到“行为模型”

初级写法：

if (hp < 30) run()
else attack()

进阶之后你应该写成：

1、行为枚举

enum ActionType {
  ATTACK,
  DEFEND,
  ESCAPE
}

2、行为选择器

decide(store): ActionType {
  // 决策逻辑
}

3、行为执行器

execute(store, action) {
  switch(action) {
    case ATTACK: ...
    case ESCAPE: ...
  }
}

好处：

结构清晰
可扩展
可测试

六、AISystem 的三种进阶模式

1、规则驱动

if (hp < 30) escape

特点：

简单
可控
适合基础 AI

2、权重驱动

score_attack = 0.7
score_escape = 0.9

选择最高：

ESCAPE

示例：

decide(store) {
  return maxBy([
    { type: ATTACK, score: calcAttack(store) },
    { type: ESCAPE, score: calcEscape(store) }
  ])
}

3、模型驱动

const decision = await model.decide(context)

特点：

灵活
智能
但不可预测

七、AISystem 与 System 的协作关系

正确结构：

AISystem → 决策
System → 执行

错误结构：

AISystem → 直接改 Store 错误

正确示例：

const action = ai.decide(store)

engine.dispatch(action)

八、引入“行为调度层”

当 AI 变复杂后，你不能直接：

ai.decide()

你需要一个：

AI Engine

class AIEngine {

  aiSystems: AISystem[] = []

  run(store) {
    return this.aiSystems.map(ai => ai.decide(store))
  }

}

作用：

统一 AI 执行
支持多 AI
可组合

九、避免 AI 失控的关键机制

AI 一旦复杂，很容易失控。你必须加三层保护：

1、约束

if (store.stunned) return NO_ACTION

2、校验

if (!isValid(action)) fallback()

3、优先级

ESCAPE > ATTACK

十、AISystem 在多端中的作用

在多设备场景下：

AISystem 只能在“主节点”执行

否则：

每个设备各算一套 AI
→ 状态漂移

正确方式：

Host 运行 AI
其他设备同步结果

十一、一个关键认知升级

初学者会觉得：

AI = 一段逻辑

但进阶之后你会理解：

AI 是一个“行为生成系统”

系统运行变成：

状态（Store）
   ↓
AISystem（决策）
   ↓
System（执行）
   ↓
状态变化

十二、最终架构

           ┌──────────────┐
           │   Store      │
           └──────┬───────┘
                  │
          ┌───────▼────────┐
          │   AISystem      │
          └───────┬────────┘
                  │ Action
          ┌───────▼────────┐
          │   System        │
          └───────┬────────┘
                  │
               Engine
                  │
                  UI

总结

在鸿蒙游戏中：

System：定义规则
AISystem：决定行为

两者缺一不可。如果用一句话总结：

System 决定“世界能做什么”，AISystem 决定“角色此刻做什么”。

而当你真正用好 AISystem，你的游戏就会从：

“写死逻辑”

进化为：

“行为驱动的动态世界”