Orbital
Ring

01 · 设计挑战

我没有让模型直接续写剧情。

模型直接决定剧情时，回复可能很自然，也可能偏离目标、创造不存在的信息，甚至把玩家带进无法继续的对话。我只让它理解和表达，把实际可做的行动限制在当前节点的 action list 里。

02 · 受控结构

模型负责理解和表达，规则负责决定后果。

玩家可以用自己的语言提问或建议，但系统只接受与当前场景有关的动作。命中后先显示对应按钮、需求和消耗，由玩家确认后推进；模糊表达不会直接改写剧情状态。

03 · 压力与反馈

每次询问和扫描都有时间成本。

我用轮次和 time cost 表达压力。扫描的信息更可靠，但消耗更多时间；直接询问成本更低，结果却会受到 Lia 当前压力、信任与身体状态影响。玩家需要在速度、信息质量、资源和风险之间做取舍。

04 · 测试设计

真正容易坏的是边界输入和分支状态。

• 意图识别检查同义表达、无效建议、未命中动作与确认后推进是否一致。
• 格式降级为 JSON 掉格式、超时和不可用回复准备 fallback，避免剧情中断。
• 分支回归开发章节跳转与数值调试入口，用于重复验证关键节点和结局。
• 叙事约束检查回复是否添加新人物、地点或物品，是否提前泄露后续剧情。

当前限制：现有文档是一份测试清单与开发设计记录，并不等同于所有条目均已通过。归档构建已完成启动检查；尚未对六章内容进行一次完整回归。

05 · 我的工作与开发说明

这是协作项目，模型、插件和 AI 辅助代码也参与了实现。

现存 Notion 记录、演讲稿和 Git 历史可以交叉支持：我制定了交互目标、章节结构、状态规则、意图映射、回退策略与测试范围，并参与 Unity 集成和持续迭代。项目使用 Fungus、LLMUnity、本地 Qwen 模型以及 AI 辅助编程；早期概念图、UI 框架和插图也包含生成式工具辅助。

我负责的部分是交互目标、章节结构、状态规则、意图映射、回退策略、测试范围和 Unity 集成。模型生成、插件能力、生成图像和辅助代码不会写成我从零创作的内容。