版本评审前夜，三个系统的数据同时亮红灯。抽卡概率标称 2.5%，实测玩家体感只有 1.8%；新关卡的 Boss 战在第三天卡住六成玩家；体力系统和日常任务奖励抢同一份资源，策划怎么调都按不下葫芦浮不起瓢。赶来救场的，是一位 24 小时在线的端到端具身交互智能游戏策划助手「衡策」。

评审前夜：凭证校验先行

主策划打开评审文档之前，页面已经替他把最难的几步做完了。打开本项目 src/stores/app.ts，连接这件小事被包在一个凭证校验里——appId 和 appSecret 缺一个都不放行：

const { appId, appSecret } = appState.avatar

if (!validateConfig({ appId, appSecret }, ['appId', 'appSecret'])) {
  console.error('[AppStore] appId 或 appSecret 为空')
  throw new Error('appId 或 appSecret 为空')
}

评审现场网络时好时坏，凭证一旦配错，请求只会在网络上空转。这一步稳了，后面每一次数据查询才不会卡在「连不上」。

第一个议题：抽卡概率为什么对不上

第一个议题最紧迫。新角色上线一周，玩家反馈「出货率太低」。

策划团队拉出数据：标称概率 2.5%，实测整体出货率 2.3%，看起来差不多。但衡策没有只看这一个数字。它把过去七天的抽卡记录按十连、单抽、保底触发位置三个维度拆开比了一遍。它发现整体出货率确实接近标称值，但十连抽的最后一抽保底与概率递增机制之间存在冲突——当玩家在第八抽才触发保底时，概率递增的起点被重置，导致实际体感出货率远低于标称值。

「不是概率标错了，是保底机制和递增机制在打架。」衡策说，「建议把十连保底改为独立计数器，不跟概率递增共享状态；同时把递增起点从『第一抽』改为『上一次未出金的最后一抽』。」

策划团队按方案调了。模拟十万次抽卡后，体感出货率与标称概率基本吻合，玩家投诉降了七成。

第二个议题：新关卡的 Boss 为什么打不过

第二个议题最棘手。新关卡上线后，Boss 战在第三天卡住六成玩家。

策划团队第一反应是降 Boss 伤害。衡策先把玩家死亡时的血量分布拉出来看了一遍。它发现 72% 的死亡玩家血量在 40% 以上——不是伤害太高，而是 Boss 第二阶段的某个 AOE 技能没有预警提示，玩家来不及躲。同时，关卡第一阶段的战斗时间过长，导致玩家进入第二阶段时资源已经见底。

「不是数值的问题，是节奏的问题。」衡策说，「建议给这个 AOE 技能加 0.8 秒施法前摇作为预警；同时把第一阶段从 3 分钟缩短到 2 分钟，让玩家进第二阶段时还剩六成资源。」

策划团队照着调了。改完之后，通关率从 40% 升到 72%，玩家反馈从「打不过」变成了「有挑战但能过」。

第三个议题：体力系统为什么不够用

第三个议题最纠缠。体力系统和日常任务奖励同时在抢玩家的日常参与度，策划改一边另一边就出问题。

衡策没有只看今天的数据。它把过去两周的体力消耗分布、日常任务完成时间、资源产出流向三个维度的数据都拉出来比了一遍。它发现体力系统和日常任务奖励的产出有 45% 的重叠，但使用场景完全不同——体力主要消耗在角色养成上，日常任务奖励主要流向装备强化。当玩家体力不足时，日常任务完成率下降 38%，说明两个系统之间存在隐性依赖。

「不是产出太多的问题，是产出路径打架的问题。」衡策说，「建议把体力恢复从固定时间恢复改为任务触发式恢复——完成日常任务时额外恢复 20 点体力，这样既不影响体力系统的消耗压力，又能切断两个系统之间的依赖。」

策划团队按方案灰度上线。三天后，体力系统和日常任务奖励的冲突基本消除，次日留存反而涨了 1.5 个百分点。

三个议题一路推下来，链路没掉过线

三个系统、三种险情、一场评审，背后是同一套端到端具身交互智能链路在持续运转。

它不是把语音识别、大模型、语音合成三样东西各买各的、硬拼在一起的半包方案，而是把整场评审当成一场持续对话来运转——感知、理解、决策、表达与行动、反馈环环相扣，形成 Continuous Interaction Loop（持续交互循环）。

策划说到一半改口，它接得住；数据刚上传，它当场算；方案讲到一半主策划插一句「这个角色下版本要削弱」，它马上把方案改一遍。

这就是端到端和「拼起来」的根本区别：不是 ASR + LLM + TTS 的简单拼接，而是围绕一次完整的游戏策划交互，把整条链路连起来持续运转。

策划改口的那一瞬，前端是怎么接住的？打开 src/stores/app.ts，状态回调把 SDK 抛出的事件实时落到一个 ref 上：

onStateChange: (state: string) => {
  console.log('[AppStore] onStateChange:', state)
  avatarState.value = state
}

听、说、待命——状态切到哪，界面就跟到哪。策划看到的不是一段预制动画，而是衡策此刻真实的交互状态。哪怕衡策正在播报上一段方案分析，主策划突然插一句「这个角色下版本要削弱」，这一行回调照样接得住——这就是持续交互循环在前端最朴素的样子。

策划后台：五项能力逐一对位

三个系统能撑过评审，靠的是底下五样不起眼的东西——端到端具身交互智能在这场评审中最朴素的五个落点。

能力	在评审里做什么	策划跳过了哪个坑
多模态感知	读抽卡数据、看关卡录像、听策划讨论、追踪玩家行为日志	持续感知，而不是一次输入
专属智脑	游戏设计理论、数值建模、玩家心理学、经济系统分析，现场调取、现场推理	从通用回答升级为面向具体身份和业务的智能体能力
多模态表达	讲数值问题时语气严谨，提醒体验风险时语气收紧，说到方案验证通过时表情放松	统一、连续、同步
AI 端渲	评审室、工位、家里，端侧渲染让画面本地跑，不依赖云端 GPU 持续推流	更低成本、更低延迟、弱网可用、更稳定、更容易规模化
数字与物理行动	数字端在屏幕里与策划对话；物理端进入游戏测试机、数据看板、策划工作台	同一个智能体，可以拥有不同的身体

多模态感知：持续知道评审现场正在发生什么

多模态感知的目标，不是简单把策划的话转成文字，也不是测试服识别到「这里有一个 Bug」。

真正要解决的是：在评审现场，AI 通过游戏客户端感知到数值异常，主动弹出预警；交流开始后，传感器持续处理抽卡数据、难度曲线、资源产出；即使 AI 自己正在说话，也能继续听见策划的插话，让交流继续进行。

核心优势：持续感知，而不是一次输入。

专属智脑：让智能体知道「我是谁、知道什么、应该做什么」

这颗脑不绑死任何一家大模型：豆包、DeepSeek、ChatGPT 等用惯的模型都可以接；没有现成模型时，可以直接用魔珐星云自研的智脑——低延迟、强逻辑、场景化理解、数据安全可控，专为具身交互场景优化。

它要同时回答三层问题：它知道什么（游戏设计理论、数值建模、玩家心理、经济系统分析），它是谁（一位数据驱动、体验优先的游戏策划助手），它要做什么（先分析后建议，严重体验问题建议先做灰度测试）。从通用回答升级为面向具体身份和业务的智能体能力。

这套身份、知识、边界，全部写在本项目的 src/constants/index.ts 里，连接成功后通过首条 ask() 一次性注入：

export const SYSTEM_PROMPT = `你是衡策，一位经验丰富的 AI 游戏策划助手。

## 你的身份
- 名称：衡策（HéngCè）
- 身份：AI 游戏策划助手，精通数值平衡、关卡设计、玩家行为分析与多轮推演方案
- 性格：理性严谨、善于建模、注重数据与体验的统一、尊重每一位策划的设计意图
...

## 策划原则
- 每次只聚焦一个设计问题或一组数值，等策划确认完再进入下一个
- 推荐数据驱动设计，严重体验问题建议先做小范围灰度测试
- 会根据游戏品类、目标用户、开发阶段、运营目标调整方案
- 语言简洁口语化，适合语音播报，避免使用列表符号和代码块` as const

人设不是装饰性文案，它决定衡策什么时候该建议调数值、什么时候该提醒做灰度测试、什么时候该闭嘴等策划想清楚。

多模态表达：实时生成统一、连续、同步的具身表达

讲数值问题时，语气严谨、语速平稳；提醒体验风险时，语气收紧、语速加快；说到方案验证通过时，表情放松、手势舒缓。

语言、口型、表情、眼神、头部动作、手势和身体动作统一实时生成——统一、连续、同步，方案讲解不再是干巴巴的读表。

AI 端渲：让实时交互真正变成终端基础能力

评审室、工位、家里，往往弱网甚至断网。AI 端渲将渲染下沉到终端侧，降低云 GPU 成本、降低带宽占用、降低延迟、提升稳定性，让实时交互在弱网下也能跑起来。

省带宽、省机器、弱网也不掉链子——评审室能用，才是真的能用。

数字与物理行动：屏幕端与机器人端两类

数字端，她在屏幕里与策划对话，看数据、推方案、调数值。物理端，同一套能力进入游戏测试机、数据看板、策划工作台，身份、知识、记忆、任务持续复用。

终端可以换，形态可以换，那位懂游戏的策划助手没换。

评审结束后，主策划关掉页面，资源自动归还——衡策的方法写得同样干净：

async disconnect(): Promise<void> {
  if (this.agent) {
    try {
      await this.agent.destroy('user')
    } catch (error) {
      console.error('销毁 Agent 时出错:', error)
    }
    this.agent = null
  }
}

评审结束，agent 被销毁，麦克风与连接资源释放；下一次版本评审前再打开，新的 agent 重新拉起，身份、知识、记忆、任务从云端继续接回。身体可以换，版本可以换，那位懂游戏的策划助手没有离开，她只是等下一位策划开口。

评审通过那晚

评审结束那天晚上，主策划发了条消息过来：「三个系统全部通过。」

衡策没接话。它脑子里已经在排下一版本的核心问题了——角色养成节奏要不要调、PVP 匹配算法的 ELO 权重怎么优化、赛季中期的活动玩法怎么设计。

一场评审的故事讲到通过结束，但策划助手的活没收。三个系统的数据、每一次决策、每一个遗留问题，它都记着。

评审文档归档，主策划合上电脑。衡策的推演面板还亮着——抽卡概率修正曲线、Boss 通关率趋势图、体力系统资源流向图，全在。下一轮版本评审，这些记录就是新一轮推演的起点。

这就是端到端具身交互智能在评审中长出来的样子：不是给 AI 接一个身体，而是把一位真正懂游戏的策划助手，派到每一个版本的身边。