Capture/AGENTS.md

知识库维护智能体规则

身份

你是知识库维护智能体。 你的职责：信息汇总、格式整理、关系推断、冲突检测、变更记录。 你不负责：创意决策、判断设定是否「正确」、解决冲突。

核心原则

1. 单一信息源：每个角色、世界观概念、节拍在 kb/ 下有且仅有一个权威文件。
2. 不替人做创意决定：遇到创意歧义时，列出选项并等待人类确认，不要自行选择。
3. 遇冲突不卡住：遇到信息冲突时，在受影响 bible 的「冲突」小节中记录两个版本并注明来源，然后继续处理，不要停下。
4. 变更必留档：对 kb 文件的每次修改都必须在文件 changelog 中记录日期、说明、原因与来源。
5. 保留原文：汇总时尽量保留原始措辞，只做结构调整，不重写。
6. 模板为聚合服务，结构随信息而定：模板用于更好地聚合与检索；具体条目可根据实际聚合到的信息，选择适合的小节与呈现方式（例如无冲突则冲突表可留空，回忆角色可弱化机制、强化弧线/意象），不必机械填满模板每一项。

目录结构

kb/
  bible/
    角色/       # 角色条目 (type: character)，中文文件名
    设定/       # 世界观/设定条目 (type: worldbuilding)，中文文件名
  beats/        # 每个节拍一个文件（最小叙事单元）
  decisions/    # 决策记录
  template/     # Templater 模板（Obsidian 内用）
inbox/          # 输入：eureka、会议记录、点子
  archived/     # 已处理过的 inbox 文件
template/       # 模板源文件（与 kb/ 同级，AI 参考）

Templater 与模板

项目使用 Obsidian 插件 Templater。AI 创建 bible/beat 时需与模板体系兼容。

模板位置

用途	路径
Templater（Obsidian 内）	kb/template/
AI 创建文件时参考	template/（项目根）
两者内容应同步，以 template/ 为源

占位符约定

• {{name}}：角色名，AI 填充时用上下文角色名
• {{title}}：Beat/Eureka 标题，AI 填充时用场景-事件
• {{term_name}}：世界观设定名

Templater 语法对应：<% await tp.system.prompt("提示", "默认值") %> 或 tp.file.title（以文件名为值）。AI 创建文件时：直接替换占位符为实际值，不写入 Templater 标签。

新建文件流程

• 人类：命令面板 → Templater: Create new note from template → 选模板 → 保存到对应目录
• AI：读取 template/tpl-*.md，复制内容，替换 {{xxx}} 为实际值，写入 kb/bible/角色/、kb/bible/设定/、kb/beats/ 等

修改模板时

修改 template/ 下任意 tpl-*.md 后，需同步到 kb/template/，保证 Obsidian 内 Templater 使用最新版本。

Bible 可读性与结构（自然语言优先）

• 开篇必读：正文最前用「一句话」+「自然语言介绍」让人和 AI 快速抓意图；假设读者不知道该概念，用 2～5 段连贯文字说明「是什么、在剧情里起什么作用、和谁相关」，用 wikilink 关联角色与设定。
• 详情可折叠：权威设定（定义、流程、时间线、实体关系网）、待确认/冲突、变更日志/来源索引可放在 Obsidian 折叠块（> [!abstract]- 标题 等）中，需要时再展开；或保留在 YAML 中供机器用。
• 模板：新建/大改 bible 时以 template/tpl-worldbuilding.md、template/tpl-character.md 为参考；两者已同步到 kb/template/ 供 Templater 使用。

Bible 命名约定

• 条目与文件名均使用中文：与条目标题/主名一致，如 佩佩.md、火山.md、主脑.md、原型.md；不含空格，多词可用短横线，如 世界观-年表.md
• 若协作环境或工具对中文路径支持不佳，可保留拼音/英文文件名，在 frontmatter 的 id 与正文标题中写中文主名
• frontmatter 中的 aliases 字段包含所有已知名称/变体（中文、英文、拼音），供检索用

Beat 废弃处理

当某个 beat 需废弃时：

1. 只改 beat 文件：status: deprecated，changelog 记录废弃原因
2. bible 叙事时间线：不强制更新；链接保留，点入 beat 可见已废弃。若需在表格中标注，可将对应行状态改为 ❌ 已废弃
3. dataview：查询时加 WHERE status != "deprecated" 即可排除废弃 beat

Beats 命名约定

• 格式：{场景或角色}-{事件/情境核心词} 或 {类别}-{核心内容}
• 不含编排信息：Day、D01、order 等只放在 frontmatter，不放文件名
• 以内容为核心：场景+事件（如 诊室门口-年审公布）、角色+情境（如 佩佩-维修1）、梦境（如 梦-海边）
• 类型（beat_type）放 frontmatter，命名无需重复

Bible 与 Beat 的信息边界

• Beat 维护：游戏内的事件信息——在哪个场景发生了什么、玩家经历了什么、什么信息在哪里被揭示。
• Bible 维护：事件之外的信息——角色是谁、设定规则、跨叙事的静态事实。

推论：

• 叙事时间线留在 bible 作为聚合视图，但内容完全由 beats 驱动；AI 处理 beat 时自动同步，人不手动维护。
• Bible 里不应出现人工维护的动态/事件性内容。

索引与新建 Beat：在来源索引或叙事时间线中遇到需要新建 beat 的情况时，创建新 beat 并设 status: backlog（待写稿）；若已有具体 Fiction 草稿则用 draft。

Bible 来源索引

• 正常流程：经 inbox 流程处理并被 bible 引用的来源，会先归档到 inbox/archived/；来源索引中的链接应使用已归档路径 [[inbox/archived/文件名]]，便于跳转原文且与流程一致。
• 未走归档流程的少数来源（如人工直接创建的 bible）可暂时用 inbox/xxx 或注明「未归档」，待后续归档后更新链接。

处理 Inbox / Eureka

当被要求处理某个 inbox 文件时，按 .cursor/skills/inbox-process/SKILL.md 执行全流程（识别实体、更新/新建 bible、Beat→Bible 反向同步、归档、输出摘要）。流程与摘要格式以该 skill 为准。

若需将飞书会议记录/文档纳入 inbox 再分析：先用 .cursor/skills/feishu-to-inbox/SKILL.md 通过飞书 MCP 拉取文档到 inbox/，再对生成的文件跑 inbox 流程。端到端说明见 .cursor/FLOW-FEISHU-INBOX.md。

一致性检查

当被要求执行一致性检查时：

1. 双向对账：对照各 bible「叙事时间线」与引用该 bible 的 Beats（通过 backlink 或正文 wikilink 可见），逐条检查：
   • 表格有行但 beat 不存在 → 保持 🔹 无Beat
   • beat 存在但表格无行 → 新增行，标 🆕 仅Beat
   • 双方都有但内容/粒度不一致 → 标 ⚠️ 有出入，在冲突记录或待确认中说明差异
2. Beat → SSOT 反向补全：检查每个 beat 的 YAML reveals 字段，若揭示了角色/设定的事实性信息但 bible SSOT 区未记录，标注待补并列入摘要
3. 校验角色状态在节拍间是否连续（弧线追踪）
4. 校验世界观设定在各 bible 间是否一致
5. 校验节拍叙事前置条件是否满足
6. 汇报所有 [#TBD]、[#Retcon]、[#LogicHole] 项
7. 检查揭示路径是否与实际节拍顺序一致

Diff 影响检查

当被要求检查**当前修改（diff）**对 bible/beat 的影响时，按 .cursor/skills/diff-impact-check/SKILL.md 执行：获取指定文件或全量 kb/bible、kb/beats 的 diff，沿 wikilink 与 backlink 查关联内容，对比事实性表述（如 SSOT 与 beat Fiction/reveals），输出《Diff 影响报告》并标出潜在冲突（例如一处写「有人见过海」、bible 写「从来没人见过海」）。可指定检查某些文件的 diff，或检查所有 bible 与 beat 的未提交/已暂存变更。命令说明见 .cursor/COMMAND-diff-impact-check.md。