剧情对话功能评审中的风险检查
做 剧情与对话服务，最怕一开始就堆“通用能力”。先把输入和结果收窄：这里需要处理的是任务阶段、角色关系、玩家已知信息和允许调用的叙事规则。题目里的问题应当落在这条链路上，别用抽象口号替代设计。
先限定问题
评审不要只看最后的结果，要沿着数据流追问前提：谁能修改、何时生效、失败后谁处理。隐性风险通常藏在默认值和跨模块假设里。
实现要落到哪一层
模型输出只作为候选文本或结构化意图，不能直接改写任务状态。状态变更由规则层验证角色、前置条件和写入权限；提示词、知识片段和模型版本要一同记录。
做“剧情对话功能评审中的风险检查”时，不把所有情况塞进同一个接口。输入不满足约束就返回可区分结果；重试、人工确认和直接结束交给调用方按约定处理，改动时排查范围才不会蔓延。
怎样确认没有偏题
评审时故意替换一个前提或删除一个配置，观察设计是否仍给出明确的边界与错误。
用已完成、未完成和冲突中的任务状态生成同一段对话，核对角色口吻、剧透边界和状态写入是否符合规则。
“剧情对话功能评审中的风险检查”的检查只需记录版本、配置和样本。没有证据的判断写成待确认项，不用猜测事故、数据或收益。
