用 AI 重写鸿蒙游戏 NPC 的开发方式

这里的重点已经不是某个分支对不对，而是这个角色'像不像它自己'。这一步很容易被低估，但实际做起来，影响最大的往往就是这个。

调试方式也变了

传统调试是看代码路径，AI 调试更像在看输入和输出之间发生了什么。

console.log("state:", state)
console.log("action:", action)

你会发现，问题不一定出在代码本身，而可能出在 AI 对状态的理解不符合预期。于是排查重点就从'哪一行写错了'变成了'为什么它会这么判断'。

这件事不算轻松，但挺现实。AI NPC 的 bug 往往不是语法问题，而是行为偏差。

不确定性是优点，也是麻烦

AI NPC 最大的特点就是不能完全预测。

好处

• 更真实
• 更有趣
• 更耐玩

麻烦

• 难调试
• 难复现
• 行为可能偏离预期

比如下面这种情况：

// 有时候 NPC 突然不攻击

你会先怀疑是不是 bug，但它也可能只是 AI 在当前状态下做出了另一个选择。这个区别很关键。脚本 NPC 出问题，通常是逻辑错了；AI NPC 出问题，很多时候是决策边界没收紧。

鸿蒙上的几个实际优势

在 HarmonyOS 上做 AI NPC，比较有意思的一点是，它不只是'把模型接进来'这么简单，平台能力本身也会影响玩法。

端侧 AI

const action = localModel.infer(state)

本地推理的好处是响应快，也不依赖网络。对游戏来说，这比听起来更重要，尤其是要做实时反应时。

多设备感知

AI 可以结合手机输入、TV 状态、传感器数据等信息来判断：

agent.decide({ playerInput, deviceContext, environment })

这类能力的价值在于，NPC 不再只盯着单一画面里的参数，而是能拿到更完整的场景信息。

分布式协同

多个 NPC 也可以一起做决策：

teamAgent.decide(teamState)

这会让'单个角色聪明'升级成'整支队伍有配合'。当然，复杂度也会跟着上来，别一上来就把系统做得太满，后面会很难收。

一个最小可用的 AI NPC

如果先不碰大模型，做一个简单版本其实不复杂。

1. 定义 Agent

class NPCAgent {
  async decide(state) {
    if (state.hp < 20) return "escape"
    if (state.enemyDistance < 50) return "attack"
    return "patrol"
  }
}

这还不是完整意义上的 AI，更像是规则和智能决策之间的过渡形态，但已经够用来搭一个最小闭环。

2. 在页面里接入

const action = npcAgent.decide({ 
  hp: this.hp, 
  enemyDistance: this.distance 
})
this.execute(action)

3. 执行行为

execute(action: string) {
  switch(action) {
    case "attack": this.attack(); break
    case "escape": this.runAway(); break
  }
}

这套结构其实很清楚：

State → Agent → Action → Execute

先把闭环跑通，比一开始就追求'智能得像人'靠谱得多。

接大模型之后，角色感会更强

如果再往前走一步，接入大模型，NPC 的表达会更丰富。

async decide(state) {
  const prompt = `当前血量 ${state.hp} 敌人距离 ${state.enemyDistance} 你会怎么做？ `
  return await llm.generate(prompt)
}

这时候它不只是'做动作'，还可能会说话、解释、带情绪。游戏里的角色感会更强，但同时也更需要安全边界和输出约束，不然很容易跑偏。

实际开发里我会先做这几件事

先从规则和简单 AI 开始

不要一上来就把大模型塞进去。先把规则版跑稳，再替换成简单决策，最后再考虑 LLM。这样比较省事，也更容易定位问题。

保留安全边界

if (!validAction(action)) { action = "idle" }

这个兜底不能省。AI 结果再像样，也要有一层能收回来的保险。

记录行为日志

log.push({ state, action })

没有日志，后面很难复盘。尤其是当你发现 NPC 反应怪的时候，日志基本就是唯一靠谱的线索。

控制决策频率

setInterval(() => { agent.decide() }, 500)

不是所有状态都值得每帧决策。频率太高，代价会很明显；太低，又会显得迟钝。这个节奏要按玩法去定。

真正的变化不在代码，而在角色定义

传统 NPC 是你写'它做什么'。

AI NPC 是你先定义'它像什么样的人'，再让它在边界里自己做选择。

这两种写法差别很大。前者适合稳定、明确、低风险的场景；后者更适合想让角色有变化、有意外感的玩法。不是谁替代谁，而是看你想把复杂度放在哪里。

总结

在 HarmonyOS 上用 AI 做 NPC，重点不是把脚本换成模型，而是把角色设计方式换掉。

最明显的几个变化是：

if/else → AI 决策

写代码 → 设计行为

查 bug → 调 AI

NPC → 角色

如果你只是想要一个稳定执行指令的敌人，脚本足够了。可如果你希望角色有一点自己的判断，AI 就会很有用，只是它带来的不确定性也要一起接住。

当 NPC 不再只是被写出来，而是开始表现出自己的选择时，游戏世界会比以前更像一个真正运转的场景。