## 三种重构方案

从标签协议到动画系统的完整设计对比

A

### 双标签独立解析

情绪和动作各自独立标签，各自独立事件，前端各管各的。

[动作:wave]
[情绪:joy/0.8]
你好呀！
后端：TagParser 解析两种标签 → emit `chat:emotion` + `chat:action`
前端：emotion 持续驱动动画 + blendshape，action 一次性播放

#### 优点

- 职责分离清晰
- 各自独立扩展
- action 可放在回复任意位置

#### 缺点

- 两个标签要写两行
- LLM 可能忘记写 action

B

### 统一行为标签（推荐）

一条标签同时表达情绪和可选动作，紧凑且 LLM 不易遗漏。

[表现:joy/0.8]
你好呀！
[表现:joy/0.8,动作:wave]
太棒了！我一直在等你！
后端：BehaviorParser 一次解析 → emit `chat:behavior`{emotion, intensity, action?}
前端：统一处理——emotion 持续驱动，action（如有）一次性播放后回退

#### 优点

- 一个事件搞定一切
- LLM 只需记一种格式
- action 可选——不写就纯情绪

#### 缺点

- 格式稍复杂
- action 不能穿插文中（但实际也不需要在文中）

C

### 自然语言驱动（激进）

去掉结构化标签，让 LLM 在 system prompt 的约束下用自然语言描述行为，后端用正则/关键词提取。

（开心地挥手）你好呀！
（惊讶地睁大眼睛）真的吗？
后端：正则匹配 (xxx地yyy) 模式 → 映射到 emotion + action
前端：同方案 B

#### 优点

- LLM 最自然的表达方式
- 对用户可见（显示时保留或剔除都行）

#### 缺点

- 解析不可靠——LLM 可能不遵循格式
- 中文分词/语义映射容易出错
- 调试困难

### 我推荐方案 B

方案 B 在可靠性（结构化标签 LLM 容易遵循）和简洁性（一个标签一个事件）之间取得了最佳平衡。方案 C 太脆弱不值得冒险——哪怕 5% 的解析失败率都会让宠物表现很怪。

如果选 B，后端改动约 50 行 Go（改 emotionPromptSuffix + EmotionParser），前端改动约 80 行（重构 VRMPet 动画状态机）。