大模型剧情实验的验证方法

叙事状态、角色知识和可调用的任务工具里，最难的通常不是把主路径跑通，而是明确谁能改状态、失败后留下什么，以及怎样复现判断。下面只围绕一个可落地的做法展开。

演示只证明一条路径

演示往往使用最干净的输入和最理想的环境。评估时要补上缺数据、旧版本、边界资源和中断操作，才能知道能力边界。

放到这个主题里，模型负责措辞和有限范围内的选择，任务状态、奖励和剧情分支必须由权威状态机写入。 上下文按角色设定、当前任务、最近对话和禁用信息分层组装；工具调用只暴露查询和受约束的提案接口，不直接修改存档。

验证不要只看一次结果

把演示样本与未参与调参的样本分开，记录两类结果的差异。

用同一段任务状态复跑对话，检查角色不会泄露未解锁信息，工具请求也不会越过任务前置条件。

留下可接手的记录

记录本次使用的版本、配置、样本范围和已知限制。这样下次调整时，可以先复核假设，而不是从一段看似正常的结果里猜当时的取舍。（本篇聚焦：大模型剧情实验的验证方法）

把剧情知识分层检查

剧情实验最容易被漂亮的台词蒙住。角色说得合乎人设，并不代表它使用的信息是正确的。测试用例应当明确哪些事实已经解锁，哪些只是设计者知道、玩家尚未得知。比如玩家还没找到钥匙时，守卫可以催促他继续调查，却不能准确指出钥匙藏在哪个房间。把这类“看起来合理但提前剧透”的情况单独列出来，才能检验知识边界。

设计样本时，最好让同一个角色面对两份只差一个任务标记的上下文。前一份里它应该保持含糊，后一份里才可以给出具体线索。若两次回答没有明显差别，就说明任务状态没有真正参与约束。对于多人叙事，还要检查 A 角色得知的秘密不会自然流入 B 角色的口中；这类串线在单角色演示中很少暴露。

观察工具调用后的叙事连贯性

工具接口即使没有直接写存档，也可能影响玩家体验。角色先查询任务进度、再给出建议时，建议应与查询结果一致；查询失败时，它应当承认信息暂时不可用，而不是编造完成状态。测试记录里可以同时保存工具参数、返回摘要和最终文本，必要时只脱敏保留关键字段。这样发现矛盾时，能迅速判断是工具数据、提示组装还是生成文本出了问题。

验证结束后别只报一个通过率。把失败按“越权知情、状态矛盾、调用无效、语气失真”归类，团队更容易决定先修哪一类。剧情系统本来就允许一定的表达差异，但任务规则和信息边界不能靠运气维持；这正是验证要替创作团队守住的底线。

样本也应定期更新。剧情调整、任务重写或新增角色后，旧用例可能仍会通过，却不再覆盖新的风险点。把每个用例关联到任务章节或设定版本，能避免测试集悄悄变成只证明历史版本正确的装饰品。

如果创作人员要临时查看失败对话，应同时看到当时的解锁条件。脱离任务状态单独评价一句台词，很容易把规则问题误当成文风问题，也会让修正方向跑偏。