核心概念
表格可用状态、进入条件、可见对白、可选动作、离开后的事实五列。状态不是场景名称：玩家同在仓库，第一次询问与已经借到盒子时应听到不同回应。尽量用明确的真假事实或有限取值，避免“差不多完成”这样的含混标记。
雾港练习：原创虚构示例
原创虚构示例：未询问时，岑禾解释干盒用途；已承诺归还但未领取时，提示盒子在柜后；已领取时，回应不再重复交付；已归还时，确认义务结束。四种状态共享一个地点，却有不同文本，防止玩家返回仓库后被再次当作陌生人。
写作步骤
先列主路径，再添加两类偏离：玩家提前拿到替代材料，或接受后暂时离开。逐格检查条件是否可能同时成立，若会重叠就确定显示优先级。最后从任务结束状态反推，确认关键物品和承诺都有去向，而非只写一句“完成”。
常见误区与边界
状态表是设计说明，不等于程序已经实现。本文不假定任何具体引擎语法。若后续使用叙事工具，应根据工具的实际条件与变量机制实现，并在目标环境验证。不要把纸面通顺直接宣称为软件测试通过，也不必为纯对白礼貌差异建立复杂状态。
改写对照
对照检查：已归还的玩家再进仓库，若仍听到“记得明早还盒子”，就是状态回应不一致。先确认归还动作是否改变记录，再确认完成状态的回应是否优先显示。纸面检查也可以按这个顺序进行，区别是只记录逻辑，不宣称已验证实际程序。
可执行检查单
- 01重复访问不重复交付。
- 02条件重叠时有确定处理顺序。
- 03任务结束后义务与物品有去向。
常见问题
重复访问一定需要全新对白吗？
不一定。一句简短确认即可，但不能重复发出已完成的指令。状态表的价值是保持事实准确，而不是让每次对话都无限增加文本。
动手写一版
试写练习：给借盒任务写四行状态，再加入“玩家已经用防水布完成运送”的替代条件。检查岑禾是否仍会要求领取盒子。对每行写一个故意错误的回应，例如已归还却继续催还，帮助自己明确该状态到底要保证什么。