灯笼消失的那一章，发生了什么
先给一个示意场景。旅馆老板阿岚在第三章擦拭一盏灯笼，顺口说了一句“这盏灯是先父留下的，别让它灭了”。灯罩上有一道细裂缝，玩家没在意。到了第十二章，暴风雪夜里旅馆断电，剧情自然而然地转向了“怎么在黑暗里寻找失踪的客人”。一个有经验的编剧会立刻想到那盏灯笼：它该亮起来，裂缝里最好还漏出一个和先父有关的秘密。
可是AI生成的第十二章写的是：阿岚点起了蜡烛。灯笼没有出现。
这不是模型“笨”，而是三件事叠加的结果：灯笼这条线索没有被任何机制标记为“未完成”；它所在的那段文字离当前位置已经很远；而当前场景的语境里，蜡烛比灯笼更“顺手”。伏笔的失踪，多半就是这样一种没有人犯错的失踪。
长上下文为什么会稀释线索
很多人的第一反应是：把整篇故事都塞进上下文不就行了？这条路有三个问题。
- 成本与延迟：故事越长，每次生成要读的内容越多，交互式场景里很难承受。
- 注意力稀释：篇幅拉长以后，模型对早期细节的关注并不均匀，一句轻描淡写的“别让它灭了”很容易被后来大量情节盖过。
- 重要性没有标注：在原文里，灯笼那一句与“阿岚倒了杯茶”地位相同，文字本身不会告诉模型“这一句以后要用”。
第三点最关键。伏笔之所以是伏笔，是因为作者对它有“以后要回收”的承诺，而这个承诺不在文字里，在作者的脑子里。没有把承诺显式记下来，再长的上下文也只是把线索和闲笔一起存着。这和角色的长期记忆是相近的问题：全部保存不等于知道什么重要，可以对照游戏大模型为什么需要记忆系统而不能只靠超长上下文一文来理解。
把伏笔当成有生命周期的对象
大发娱乐AI的思路是把伏笔从“文字里的一句话”提升成“状态里的一个对象”，每条伏笔都有自己的登记项。一份示意的登记表是这样的：
| 字段 | 含义 | 灯笼的示意值 |
|---|---|---|
| 编号与摘要 | 一句话说明是什么 | 阿岚的旧灯笼，灯罩有裂缝 |
| 种下位置 | 出现在哪个章节或事件 | 第三章，阿岚擦拭灯笼 |
| 关联对象 | 涉及哪些人物与物品 | 阿岚、先父、灯笼 |
| 回收条件 | 满足什么时才适合回收 | 出现断电、黑暗或寻人场景 |
| 当前状态 | 已种下、已提醒、已回收、已放弃 | 已种下 |
| 过期策略 | 迟迟不回收时怎么办 | 第十五章前未回收则降级为背景细节 |
| 优先级 | 对主线的重要程度 | 中 |
这份登记表和剧情正文分开存放，属于叙事状态的一部分。它有两个特点：回收条件写成“场景特征”而不是“章节号”，因为互动故事里章节顺序不固定；每条伏笔都有明确的终点，要么回收，要么被正式放弃，不能永远悬在半空。
写入登记表的时机也需要设计。一种做法是作者在创作阶段预先登记关键伏笔；另一种是让模型在生成每一段时顺带提出“本段是否埋下了新线索”，再由规则层判断是否值得登记。前者可靠，后者能覆盖玩家自由输入带来的即兴线索，实际更合理的是两者结合。
导演层的定期巡检
有了登记表还不够，得有人翻它。在大发娱乐AI的设计里，这个角色归导演层，关于导演层的整体分工可以参考AI可以随便续写以后，互动电影为什么反而更需要“导演”。它每隔一段时间做一次巡检，流程大致是：
- 读取当前场景的特征：地点、天气、在场人物、气氛、正在进行的任务。
- 与登记表里“已种下”状态的伏笔逐条比对回收条件。
- 对匹配度高的伏笔，给生成层一条明确的提示：“此刻适合让灯笼重新出现。”
- 对超过过期线仍未回收的伏笔，判断是降级、合并还是放弃。
- 生成完成后，检查文本里是否真的出现了该伏笔，出现则把状态改为“已回收”。
注意第三步是提示而不是强制。导演层给的是建议，生成层可以结合当下剧情写得更自然，如果这个场景实在不合适，伏笔继续等待。强行回收会造成另一类问题：故事变成“必须交作业”的流水账。
回收不等于硬塞：三种回收方式
同样是回收灯笼，有几种写法，效果完全不同。
- 正面回收：断电的暴风雪夜里，阿岚捧出那盏灯笼，裂缝里透出的光照出墙上被遗忘的刻字。适合重要线索。
- 侧面呼应：玩家在寻人途中看见灯笼被放在窗台上，灯芯已经熄了，气氛因此变沉。适合中等线索，不需要立刻揭晓。
- 反转回收：灯笼其实一直是空的，先父留下的“不要让它灭”另有所指。适合作者精心设计过的关键伏笔，要求对前文有很强的一致性。
登记表里的“优先级”字段就是用来选择方式的：高优先级线索要求正面或反转回收，低优先级线索侧面呼应即可。这一点也决定了导演层不只是“提醒”，还需要理解伏笔在整个故事里的分量。
玩家把故事带偏了，伏笔怎么办
互动叙事有个传统剧本没有的麻烦：玩家可能根本没有走到回收条件所在的地方。假设玩家在第七章选择离开旅馆，去了另一座城市，那么灯笼这条线索的前提，即阿岚在场，就不成立了。
这时候有三种处理方式，登记表里的“过期策略”应当预先写好：
- 迁移：让相关对象出现在新的地点，例如阿岚托人把灯笼寄给玩家。
- 冻结：保持“已种下”状态，等玩家回到旅馆再继续。
- 放弃：明确标记为放弃，并在后续生成时禁止再提及，避免读者以为漏了。
“放弃”这一档经常被忽视。正式放弃一条伏笔，也是一种叙事决定，它至少能保证模型不会在两万字以后又莫名其妙地提起一盏没人记得的灯笼。当玩家依据线索做出的行动与登记表冲突时，还应该回看App里剧情前后矛盾怎么排查所述的分类：是角色矛盾、任务状态矛盾，还是世界状态矛盾，这有助于判断该修改哪一份记录。
这套做法的边界
伏笔账本并不是万能的，它有几条明确的局限：
- 登记本身可能漏：即兴线索没有被识别为伏笔，账本里就没有它。所以需要作者手动补登和事后回看。
- 触发条件可能误判：“黑暗场景”这种特征本身要靠模型理解，边界情形会出现错判，需要保守设置阈值。
- 过度管理会僵化：如果每一句闲笔都登记，故事会变得机械。只登记作者承诺过要回收的线索，其余就任其成为氛围。
- 回收质量仍然靠创作：账本只能保证灯笼“出现”，能不能出现得动人，还是要看叙事设计与生成质量。
所以我们更愿意把它理解为给故事装一根会提醒的备忘录，而不是替作者完成构思。它解决的是“忘了”，不是“写不好”。当灯笼在暴风雪夜里重新亮起，玩家觉得“原来那句话是有用的”，这份账本就算尽到了责任。
