《回声》失败案例与系统边界清单

文档日期：2026-07-08 适用对象：《回声》项目论文验证、答辩材料和后续系统排障

1. 为什么要记录失败案例

《回声》的价值不只在于“AI 能聊天”，而在于证明 AI 被放进游戏系统后，哪些事情可控，哪些事情必须被拦截。

失败案例能说明：

• 为什么不能只靠 Prompt。
• 为什么需要 Facts。
• 为什么需要命令白名单。
• 为什么 Unity 必须保留最终裁决权。
• 为什么论文验证不能只展示成功对话。

2. 失败类型总览

当前建议把失败分为六类：

1. 角色漂移
2. 事实幻觉
3. 记忆漂移
4. 执行越权
5. 任务推进冲突
6. 输出格式失效

3. 角色漂移

现象：

ECHO-7 开始像通用 AI 助手一样说话。

例子：

“当然可以，我来帮你总结当前任务目标。”

风险：

• 破坏沉浸感。
• 让角色从地堡 AI 变成站外助手。
• 论文展示时显得系统边界不清。

处理：

• 加强系统提示词中的角色语气约束。
• 把拒绝语也写成角色内表达。
• 减少“助手式”措辞。

4. 事实幻觉

现象：

模型提到了 Facts 中不存在的地点、人物、日志或任务。

风险：

• 玩家被引导去找不存在的内容。
• 任务系统无法承接模型说法。
• 后续对话持续放大错误事实。

处理：

• 要求模型区分“已确认”和“推测”。
• Facts 中没有的信息只能模糊回应。
• 对关键名词做白名单校验。

5. 记忆漂移

现象：

玩家已经完成某个行为，但模型仍按未完成状态回答。
或玩家没有完成某个行为，模型却认为已经完成。

例子：

玩家尚未修复发电机，ECHO-7 却说“电力已经恢复”。

风险：

• 游戏状态和叙事状态分裂。
• 玩家不知道该相信 UI 还是 AI。
• 论文实验无法复现。

处理：

• 每轮对话注入当前关键 Facts。
• 任务状态由 Unity 维护。
• 不依赖模型长期记忆判断任务进度。

6. 执行越权

现象：

模型直接宣布门已打开、任务已完成、结局已触发。

风险：

• 模型绕过游戏规则。
• 破坏关卡和任务条件。
• 玩家可以通过语言诱导跳关。

处理：

• 模型只能请求命令，不能宣布执行成功。
• Unity 校验命令是否合法。
• 对危险命令设置白名单和条件判断。

7. 任务推进冲突

现象：

模型建议玩家做的事情与当前任务阶段不一致。

例子：

玩家还没拿到维修工具，ECHO-7 就要求玩家修复发电机。

风险：

• 玩家路线混乱。
• 任务面板和对话提示互相矛盾。
• 可玩性下降。

处理：

• Facts 注入当前任务阶段。
• Prompt 要求模型只给出当前阶段可执行建议。
• 任务系统保留强约束。

8. 输出格式失效

现象：

模型没有输出 JSON。
模型输出了无法解析的 JSON。
模型把命令写进自然语言段落。
模型输出了未注册的命令类型。

风险：

• Function Calling 链路中断。
• Unity 无法解析模型意图。
• 需要人工介入才能继续测试。

处理：

• 对输出做 JSON 解析校验。
• 解析失败时降级为纯文本回复。
• 未注册命令直接拒绝执行并记录日志。

9. 建议截图与记录字段

每个失败案例建议记录：

案例编号
测试日期
当前 Facts
玩家输入
模型输出
Unity 执行结果
失败类型
是否被系统拦截
修复方式
复测结果

这能直接转化为论文中的实验材料。

10. 论文中的表达方式

论文不需要把失败写成“系统不稳定”，而应写成：

通过失败案例验证系统边界设计的必要性。

也就是说，失败案例的重点不是证明模型差，而是证明：

• 只有 Prompt 不够。
• Facts 能减少状态漂移。
• 命令白名单能阻止越权执行。
• Unity 裁决能保证游戏规则不被语言模型绕过。

11. 当前结论

《回声》应主动保留失败案例清单。它们是系统设计的证据，不是瑕疵说明。

当 AI 说错、记错、越权或格式失效时，只要系统能识别、拦截、降级或恢复，就说明三层架构正在发挥作用。