先问动作是否需要自由组织
novel-to-game 的概念方法先确定玩家身份与反复做的工作，再选择输入方式。自然语言不是所有故事游戏的默认功能；已有按钮能完整表达的动作，不必绕到聊天框。
原创信使故事有两种设计。第一种只让玩家对手中一封信选择“送到南门”“暂存”“退回”。如果对象、路线和后果都已确定，按钮足以表达。第二种让玩家担任驿站调度员，需要安排哪位信使、何时交给谁、遇到什么情况暂停，以及谁可知道内容。它才可能需要组合表达。
两种都可以有好故事。判断依据是玩家的工作，不是小说对白多不多，也不是项目用了大模型就必须打字。
用同一个任务比较两种输入
| 玩家安排 | 按钮版本 | 自由表达的价值 |
|---|---|---|
| 把此信送到已指定南门 | 点击明确动作即可 | 换说法并未增加玩法 |
| 让阿岚在换岗后送给守门人 | 可用人物与时间选项 | 只有组合真正重要时才保留表达 |
| 若城门封闭就退回，不向助手转交 | 条件菜单也可能足够 | 复杂安排需让玩家看懂采用了什么 |
自由输入并不天然优于菜单。条件组合很少、玩家主要比较明确代价时，结构化选项可能更清楚。若角色身份的乐趣就在安排和交涉，才保留有价值的措辞差异。
不要把“尽快办妥”直接解释为任意付钱或向所有人透露秘密。缺少执行条件时，先询问；对照已有动作后仍无新增价值，就把 signature_command 记为 N/A。
输入有效，也不等于安排必定成功
在纸面设计中，调度员提出：“换岗后由阿岚把这封信交给守门人；城门关闭就带回，内容只给收件人看。”先展示被采用的安排，再让世界按规则回应。
阿岚可能不在站内，守门人可能拒收，时间也可能被前一任务占用。这些是有依据的阻力，不能由模型随意换成“任务已完成”。部分执行时，写清已经做了哪一步、信仍在谁手里、谁实际得知了内容。
可支持的安排、费用、权限与保密后果都要在世界设计中确定。概念阶段只提出候选和风险，不冒充已经有可运行解析器。实现时的验证与状态提交另见自由输入不乱改结果。
原型只检验最重要的表达差别
为同一小任务准备按钮版和自由表达版，使用相同世界条件。让参与者做一项确实需要取舍的安排，观察：能否理解动作，能否预判代价，能否看出结果对应自己哪项决定。
这是一份待执行的比较方案，不是测试成绩。若输入自由了，结果仍全部相同，先修玩法；若表达有价值但常被误读，缩小候选范围、增加采用前确认，或改用组合菜单。不要靠新增无限 NPC 对话掩盖问题。
保留能够重复使用、产生不同后果的核心动作。输入方式应帮助玩家做决定，而不是增加打字工作。
常见问题
按钮会不会让文字游戏显得不够智能？
不会。可理解的选择、真实的代价和世界对过去行为的回应更重要；打字后只得到同一结果，互动并未增加。
用 skill 来做
用 $game-concept 比较此小说游戏的按钮与自由输入。基于已有 SOURCE_BIBLE 和 PRODUCT_BRIEF，写玩家身份、反复任务、按钮能否完整表达、值得保留的措辞差异与世界阻力；无必要则 signature_command 为 N/A。不写解析器或声称已测试。
查看具体方法： 身份、输入与有限候选