story-decisions

故事决策

故事决策比代码决策更容易消散。角色年龄、会议场景的基调、时间线顺序、被否决的情节线索背后的考量，往往留在被压缩的头脑风暴环节、已经结束的对话中，或作者两次写作之间的脑海里。一个月后，问题再次浮现：“为什么我们让角色 8 岁而不是 10 岁？”而当初的理由已经不见了。更糟的是，写作 Agent 可能会草拟出与某项无人记录的决策相矛盾的场景。

趁思路还清晰时记录决策——在做出选择的当下，而不是事后补记。经过漫长的头脑风暴后凭记忆记录决策，会抹平其中的细微差别：备选方案变得模糊，约束失去具体性，理由也变成事后辩解。

记录什么

每条决策记录都要回答三个问题：决定了什么、选择它的原因，以及还考虑过哪些其他方案。

• 选择本身。 具体说明——指出受影响的角色、场景、机制或世界元素。“我们决定采用更轻松的基调”很模糊。“路线 1 的会面采用误会喜剧，而非共同面对威胁的情节”才是一项决策。
• 理由。 是哪些约束、目标或创作直觉促成了这个选择？是叙事节奏、角色口吻，还是主题一致性？没有具体内容的理由只是观点——“感觉合适”无法帮助六次创作环节之后需要落实这项决策的作者。
• 被否决的备选方案。 指明这些方案，并说明否决原因。“我们考虑过以战斗开场的会面，但否决了，因为角色还没有战斗经验，而且这会要求我们解释角色为何如此擅长战斗”是任何故事决策记录中最有价值的一句话——它能避免下一次头脑风暴时有人再次提出已被否决的方案。
• 发现的约束。 决策本身往往不如迫使我们做出决策的约束有意思。“时间线不允许在路线 1 上停留超过两天”比“我们压缩了路线 1 的故事线”解释得更清楚。
• 变更内容。 如果这项决策修订了先前的决策，请注明它取代了什么，以及情况为何发生变化。故事方向会演变——这没问题，但演变过程应当可以追溯。

决策存放位置——内联记录，而非单独存放

决策应内联写在 kb 中与之相关的资料里（meridian context kb）。不要放在单独的决策文件中，也不要放在总日志中。

角色年龄决策应记录在相关角色文件中，并标注在年龄信息所在处。时间线顺序决策应记录在时间线中，并标注在事件顺序处。世界机制决策应记录在相关世界条目中，并标注在相关系统描述处。

这样一来，决策就与其约束的事实放在一起。作者载入角色文件时，看到的不仅是当前状态，还有为何如此。连续性检查器标记出时间线问题时，排序的理由就在旁边。

注释格式

Character is 8 years old at story start.

使用 HTML 注释记录决策——它们不会显示在渲染后的 Markdown 中，但会保留在源文件里。请注明会话引用，以便在需要时通过 meridian session 找回完整讨论。

何时记录——何时跳过

当某人有理由做出不同选择，且仅凭故事本身无法显而易见地理解其原因时，就记录这项决策。判断标准：写作 Agent 是否需要这些背景信息才能正确撰写场景？

以下情况尤其重要：

• 收窄头脑风暴的选项（被否决的方案和最终选定的方案同样有价值）
• 确立会限制未来场景的角色特征
• 安排时间线事件的顺序，且顺序会影响情节逻辑
• 为关键场景选择基调或处理方式
• 推翻评论者的结论（记录协调者为何持不同意见）
• 修改先前的决策（记录改变了什么，以及原因）

如果某项决策可直接从已确立的正史或项目惯例中推导出来，就跳过。如果故事已经明确某个角色还不能战斗，那么避免战斗的场景简报就不值得记录为一项决策——这只是一个限制条件。

主动捕获与回溯挖掘

主动——随时记录

随着头脑风暴逐步收窄选项、方向逐渐明确，故事协调者和知识协调者会实时记录决策。这是质量最高的做法——当下捕获的决策保留了完整背景。

在头脑风暴会议探讨了各种选项、作者选定方向后：立即派遣 session-miner 提取决策，并将其内联写入 kb。不要等待——对话刚结束时，会议背景最完整。

回溯——挖掘过往会议

如果当时没有捕获决策（这种情况很常见），session-miner 可以使用 meridian session 从以往会议的转录中提取决策。这样可以找回原本会丢失的信息，但质量较低——经过压缩的会议内容可能已经失去细节，挖掘器也只能重构推理过程，而非当时直接记录。

以下情况可使用回溯挖掘：

• 写作者或评论者遇到一个没有记录推理过程的事实
• 开始创作新的篇章，需要汇集所有会对其形成限制的既有决策
• 加入已有历史记录、但没有决策注释的项目

session-miner 会读取转录，并将决策注释内联写入相关 kb 条目，同时标记来源会议，以便追溯。