story-context

故事上下文

每次启动 Agent 时，都要先决定提供什么上下文。判断失误，写作者就可能编造与既定正史相矛盾的事实；评论者可能因为没看到相关章节而漏掉连续性问题；头脑风暴者可能探索作者已经否决的方向。

启动机制（-f、--from、启动命令）已在 meridian spawn -h 中说明。本技能讲解如何判断：应传入哪些故事上下文、何时在启动前将决策落实为文件，以及提供多少上下文才够。

选择合适的机制

有三种选项，分别适用于不同情况。meridian spawn -h 中介绍了 命令语法；本节讲解何时使用哪一种。

文件（-f）：适用于上下文已存在于文件中的情况，例如章节、大纲、 Wiki 页面、风格文件和角色状态。这是默认选择，因为文件 稳定、可检查，也能在上下文压缩后保留。严格控制范围：只传入 重要的文件，而不是所有文件。

会话历史（--from）：适用于 Agent 需要尚未写下来的决策、推理或 头脑风暴上下文的情况。会话历史记录了选择背后的原因：作者为什么选了这个角度，以及否决了哪些方案。

先落实为文件：适用于上下文过于重要、不应只暂存于对话中的情况。如果 关键故事决策只存在于对话中，就在启动前将它们写入知识库或 工作目录。如果写作者可能不小心违背这些上下文，就将它们落实为文件。如果只是补充背景，使用 --from 即可。

各类 Agent 需要什么

写作者

写作者需要足够的信息来保持文风一致、符合正史，而不是所有曾经写过的内容。必要的上下文包括：

• 场景简述或大纲：场景中发生什么，以及需要呈现哪些情节点
• 相关风格文件：查看 styles 目录中已有的文件，选择与场景相符的文件。为出场角色提供角色文件，为正在撰写的场景类型提供场景类型文件。每个风格文件都会自述用途：阅读开头即可了解适用场景。
• 连续性锚点：紧接在前的章节或场景（确保衔接），以及确立本场景所引用事实的章节。提供 2 到 4 个文件，而不是整部手稿。
• 角色状态：为场景中出场的角色提供角色文件，尤其是其情绪状态或掌握的信息近期有变化时
• 词汇表：当场景涉及虚构术语、魔法或派系名称、头衔、关系称谓，或具有项目特定含义的类型术语时，提供相关的 vocab.md 文件

告诉写作者需要进一步查找时去哪里找，例如：“完整的故事线大纲在工作目录中；请重点查看 Route 1 部分。”避免预先附上所有内容。

评论者

评论者需要待评审的草稿，以及足够的上下文来进行对照：

• 待评审的草稿：始终通过 -f 提供
• 场景简述或大纲：让评论者检查草稿是否达到了预期目标
• 相关风格文件：让文风评论者能与目标文风进行比较
• 前文：让连续性评论者能交叉核对事实
• 作者意图：如果编排者与作者讨论过方向，则通过 --from 提供；也可以提供已落实为文件的决策记录
• 已知问题：如果评论者应留意特定的反复出现的问题，则提供已跟踪的问题
• 词汇表：当名称、别名、弃用术语或虚构语言的一致性很重要时，提供相关的 vocab.md 文件

头脑风暴者

头脑风暴者需要的是约束，而不是答案：

• 正在探索的问题：在提示词中严格限定范围
• 限制答案的既定背景：角色简介、时间线、限制设计空间的既有决定
• 已被否决的方案：避免他们重新提出行不通的方向
• 现有词汇：提供足够的词汇背景，避免为项目已经命名的概念创造新名称

不要传递过多内容：收到完整项目历史的头脑风暴者往往会给出保守的想法，紧贴现有模式，而不是探索新方向。

知识维护

• 编年记录者：通过 -f 指定要提取事实的章节，以及用于去重的现有正史文件、时间线条目和词汇文件
• 连续性检查器：提供草稿，以及草稿涉及领域的正史、时间线、角色状态和词汇文件
• 基础 @kb-maintainer：提供 kb 目录结构：它需要查看所有内容才能重建关联
• 基础 @kb-writer：用 --from 指向要挖掘的对话，并提供用于写入发现内容的 kb 路径

跨阶段上下文

使用 --from <prior-spawn-id> 传递前一阶段的发现。 修订写作者可以从初稿写作者的发现中受益；评论者则可以参考之前的评论轮次。

当各阶段会生成产物时，组合使用这些机制：用 --from 提供推理上下文，用 -f 指定前一阶段创建的文件。

词汇交接

将词汇视为实际运作的故事背景。如果写作者、评论者或头脑风暴者可能会为某个概念选错名称，就传递相关的 vocab.md 文件，或在启动任务前明确确定名称。这对魔法体系、派系、反复出现的世界内用语、头衔、关系称谓，以及作者在对话中纠正过的术语尤为重要。

确定术语后，在交接前记录下来：规范名称、含义、仍在使用的别名，以及用于避免常见混淆的边界。