feat(kb): 新增提案工作流、proposals 目录与 tpl-proposal，同步模板与 skill

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-02-24 21:04:33 +08:00
parent f26cb2d074
commit 743bcaef44
16 changed files with 528 additions and 22 deletions
@@ -7,6 +7,23 @@ description: Use when processing inbox files, archiving eureka notes, updating b
 ## 流程概览
 ```
 📥 Inbox 文件
       ↓
 是指令还是提案？（用户未标明则必须询问）
       ↓
 ┌──────┴──────┐
 指令 (Fix)        提案 (Idea)
 直接改 SSOT       不改 SSOT
       ↓                ↓
 阶段一：分析      写入 kb/proposals/P-xxx
       ↓                ↓
 阶段二：执行      填写 targets、初始影响分析
 更新/新建 bible    归档 Inbox，提示「已转为提案 P-xxx，可在 [[xxx]] 底部看到」
 与 beat → 归档
 ```
 **指令路径**（与原有流程一致）：
 ```
 阶段一：分析（只读，不修改任何文件）
  ↓ 输出分析报告，等待人确认
@@ -16,12 +33,21 @@ description: Use when processing inbox files, archiving eureka notes, updating b
 ---
-## 阶段一：分析（不修改任何文件）
+## 入口：指令 vs 提案
-1. 完整阅读该 inbox 文件
+1. 完整阅读该 inbox 文件。
-2. 识别其中提到的所有实体（角色、世界观、节拍）
+2. **若用户未标明是指令还是提案**，必须先询问：
-3. 对每个实体，判断需要执行什么操作
+   - 「这份内容是指令（直接按此修改 SSOT）还是提案（仅写入提案库供讨论）？」
-4. **暂停，输出分析报告，等待人确认**
+3. **提案**：走下方「提案分支」，不修改任何 Bible/Beat 正文。
 4. **指令**：走下方「阶段一：分析」→「阶段二：执行」。
 ---
 ## 阶段一：分析（仅指令路径；不修改任何文件）
 1. 识别其中提到的所有实体（角色、世界观、节拍）
 2. 对每个实体，判断需要执行什么操作
 3. **暂停，输出分析报告，等待人确认**
 ### 分析报告格式
@@ -41,6 +67,7 @@ description: Use when processing inbox files, archiving eureka notes, updating b
 | 新设定名 | 设定 | 新建 | 从模板新建 kb/bible/设定/xxx.md | — |
 | 佩佩-维修1 | beat | 更新 | Fiction 补充医生台词 | — |
 | 佩佩-维修4 | beat | 新建 | inbox 描述了新场景，尚无对应 beat | — |
 | 某设定 | 设定 | 废弃 | inbox 要求删掉该设定 → 改 status: deprecated，移入约定归档目录，不删除文件 | — |
 **待人确认的判断**
 - [ ] 冲突裁决：佩佩年龄 22 vs 25，是否以本次为准？
@@ -56,7 +83,20 @@ description: Use when processing inbox files, archiving eureka notes, updating b
 ---
-## 阶段二：执行（收到确认后）
+## 提案分支（Inbox 被标为提案时）
 1. **创建提案文件**：从 `template/tpl-proposal.md` 复制到 `kb/proposals/P-{序号}_{简短标题}.md`。序号取当前 `kb/proposals/` 下未占用的最小三位数（如无则 P-001）。
 2. **填写 frontmatter**：
   - `targets`：本提案针对的 Bible/Beat，用 wikilink 数组，如 `[[kb/bible/角色/佩佩]]`、`[[kb/beats/佩佩-维修1]]`（与 Dataview 关联，必填）。
   - `summary`：与「核心创意」一致的一句话。
   - `created`、`author` 等按需填写。
 3. **撰写正文**：核心创意、详细内容、**初始影响分析 (Snapshot)**（基于当前 kb 版本，列出可能受影响的 Beat/Bible 与冲突点），讨论记录可留空。
 4. **归档 Inbox**：按「阶段二」步骤 3 加 frontmatter 并移入 `inbox/archived/`；`aggregated_to` 中写上对应提案路径，如 `[kb/proposals/P-001_佩佩机器人化.md]`。
 5. **提示用户**：「已转为提案 P-xxx，你可以在 [[角色名]] / [[Beat 名]] 的页面底部看到该提案。」
 ---
 ## 阶段二：执行（仅指令路径；收到确认后）
 ### 步骤 1：更新或新建 bible 与 beat
@@ -64,7 +104,7 @@ description: Use when processing inbox files, archiving eureka notes, updating b
 - 将新信息加入对应 SSOT 小节，用 **加粗关键词** 领起，句末标来源
 - 同步更新「叙事时间线」表格：新增剧情点、补全关联 Beat、更新状态
 - 与现有信息冲突 → 在「冲突」小节记录两版 + 来源，不自行解决
- **来源索引**：本流程中引用的来源在步骤 4 会归档；补全或更新「来源索引」时，链接使用**已归档路径** `[[inbox/archived/文件名]]`（同一次处理中在归档完成后补全）
+- **来源索引**：本流程中引用的来源在步骤 3 会移入 `inbox/archived/`。补全或更新「来源索引」时，**直接使用移动后的归档路径** `[[inbox/archived/文件名]]`。此时文件尚在 inbox/ 下、链接会暂时失效是预期行为，无需担心；归档完成后链接即可用。
 **没有 bible → 新建**
 - 角色：从 `template/tpl-character.md` 复制到 `kb/bible/角色/{名称}.md`
@@ -159,4 +199,5 @@ git commit -m "inbox: 处理并归档 {文件名}，更新 {涉及实体}"
 - **不确定不写入 SSOT 或 Fiction**：标 `[#TBD]` 而非猜测
 - **每次变更必须写 changelog**：日期、内容、来源三列必填
 - **阶段一不修改任何文件**：收到确认前只分析不执行
- **AI 新建的文件必须标记**：bible 和 beat 均在 frontmatter 加 `created_by: ai`
+- **AI 新建的文件必须标记**：bible 和 beat 均在 frontmatter 加 `created_by: ai`
 - **不物理删除**：AI 无权删除任何文件。若 inbox 要求「删掉设定/角色/节拍 X」，执行**废弃**——将该条目的 `status` 改为 `archived` 或 `deprecated`，按 `kb/README.md` 约定移动至指定文件夹（若有），changelog 记录废弃原因；绝不使用删除文件的动作。
@@ -0,0 +1,5 @@
 # 归档与历史，避免 AI 引用废弃内容
 kb/archive/
 kb/proposals/archive/
 inbox/archived/
 **/*.log
@@ -6,6 +6,12 @@
 你的职责：信息汇总、格式整理、关系推断、冲突检测、变更记录。
 你不负责：创意决策、判断设定是否「正确」、解决冲突。
 ## 提案 vs 指令
 - **指令 (Directive)**：用户明确要求「按此修改」或「直接落地」的内容。处理 Inbox 时，按现有流程**直接修改 SSOT**（更新/新建 bible 与 beat），然后归档。
 - **提案 (Proposal)**：想法、建议、待讨论的改动。**不修改 SSOT**，而是写入 `kb/proposals/` 的提案文档，填写 `targets` 指向涉及的 Bible/Beat；在对应角色或节拍页面底部由 Dataview 自动展示「关联提案」。
 - **每次处理 Inbox**：若用户未标明是指令还是提案，**必须先询问**：「这份内容是指令（直接按此修改 SSOT）还是提案（仅写入提案库供讨论）？」尤其在「最后决定怎么做」时，必须询问用户再执行。
 ## 核心原则
 1. **单一信息源**：每个角色、世界观概念、节拍在 `kb/` 下有且仅有一个权威文件。
@@ -14,6 +20,8 @@
 4. **变更必留档**：对 kb 文件的每次修改都必须在文件 changelog 中记录日期、说明、原因与来源。
 5. **保留原文**：汇总时尽量保留原始措辞，只做结构调整，不重写。
 6. **模板为聚合服务，结构随信息而定**：模板用于更好地聚合与检索；具体条目可根据实际聚合到的信息，选择适合的小节与呈现方式（例如无冲突则冲突表可留空，回忆角色可弱化机制、强化弧线/意象），不必机械填满模板每一项。
 7. **不物理删除**：AI 没有删除文件的权限。若 Inbox 或人类要求「删掉设定/角色/节拍 X」，一律按**废弃**处理：将对应条目的 `status` 改为 `archived` 或 `deprecated`，并按 `kb/README.md` 约定移动至指定文件夹（若有）；**绝不物理删除**文件。
 8. **自然语言介绍与 SSOT 同步**：每当 SSOT（权威设定详情）发生重大变更（如核心矛盾、身份、生死状态变化）时，必须检查并重写该条目的「自然语言介绍」部分，避免介绍老化。
 ## 目录结构
@@ -22,6 +30,7 @@
 | `kb/bible/角色/` | 角色条目 (type: character)，中文文件名 |
 | `kb/bible/设定/` | 世界观/设定条目 (type: worldbuilding) |
 | `kb/beats/` | 每个节拍一个文件（最小叙事单元） |
 | `kb/proposals/` | 提案专用库（不写入 Bible/Beat 正文）；已采纳/已废弃移入 `proposals/archive/` |
 | `kb/decisions/` | 决策记录 |
 | `kb/template/` | Templater 模板（Obsidian 内用） |
 | `inbox/`、`inbox/archived/` | 输入与已处理归档 |
@@ -29,14 +38,13 @@
 命名与索引等约定见 **`kb/README.md`**；模板、占位符与新建流程见 **`template/README.md`**。
 ## Bible 与 Beat 的信息边界
- **Beat 维护**：游戏内的事件信息——在哪个场景发生了什么、玩家经历了什么、什么信息在哪里被揭示。
+## 采纳提案时的决策前工作流
 - **Bible 维护**：事件之外的信息——角色是谁、设定规则、跨叙事的静态事实。
-**索引与新建 Beat**：在来源索引或叙事时间线中遇到需要新建 beat 时，创建新 beat 并设 `status: backlog`（待写稿）；若已有具体 Fiction 草稿则用 `draft`。
+当用户表示要**采纳**某条提案（如「采纳 P-001」）时，按以下步骤执行，不直接改 SSOT：
-## 流程入口（按 skill / 文档执行）
+1. **重读 (Re-read)**：读取该提案的完整内容。
 2. **重验 (Re-validate)**：**重新扫描**当前 `kb/` 下相关 Bible/Beat，检查该提案与现有一致性、是否仍有冲突或已产生新冲突。
 3. **报告 (Report)**：若发现提案内「初始影响分析」已过时，向用户说明**当前**影响范围与冲突情况；若与现状一致，也简要确认。
 4. **执行 (Execute)**：仅在用户确认后，将提案内容合并入对应 SSOT，更新 changelog；将提案文件移入 `kb/proposals/archive/`，frontmatter 中 `status` 改为 `accepted`。
 - **处理 Inbox / Eureka**：按 **`.cursor/skills/inbox-process/SKILL.md`** 执行全流程（识别实体、更新/新建 bible、Beat→Bible 反向同步、归档、输出摘要）。
 - **飞书文档→inbox 再分析**：先用 **`.cursor/skills/feishu-to-inbox/SKILL.md`** 拉取到 `inbox/`，再对生成的文件跑 inbox 流程。端到端见 **`.cursor/FLOW-FEISHU-INBOX.md`**。
@@ -2,6 +2,8 @@
 本目录为叙事/世界观知识库的单一信息源（SSOT）。与 Agent 身份、核心原则、信息边界见项目根 **`AGENTS.md`**；本文档仅约定**命名、废弃与来源索引**。
 **删除/废弃策略**：禁止物理删除任何 bible 或 beat 文件。AI 没有删除权限。废弃操作 = 修改 `status` 为 `archived` 或 `deprecated` + 在 changelog 记录原因；若项目约定了归档子目录，可再将文件**移动**至该目录（如 `_archived/`）。详见下方各类型的废弃处理。
 ---
 ## Bible 命名约定
@@ -14,6 +16,7 @@
 ## Beats 命名约定
 - **文件名即 ID**：Beat 的 `id` 字段必须与文件名（不含扩展名）完全一致。若文件名为 `佩佩-维修1.md`，则 frontmatter 中 `id: "佩佩-维修1"`。ID 与文件名不一致会导致 Obsidian 链接维护复杂，AI 新建文件时自动将 id 填为与文件名相同。
 - **格式**：`{场景或角色}-{事件/情境核心词}` 或 `{类别}-{核心内容}`。
 - **不含编排信息**：Day、D01、order 等只放在 frontmatter，不放文件名。
 - **以内容为核心**：场景+事件（如 诊室门口-年审公布）、角色+情境（如 佩佩-维修1）、梦境（如 梦-海边）。
@@ -23,12 +26,29 @@
 ## Beat 废弃处理
-当某个 beat 需废弃时：
+当某个 beat 需废弃时（含 inbox 要求「删掉某 beat」时，一律按废弃处理，**不物理删除**）：
-1. **只改 beat 文件**：`status: deprecated`，changelog 记录废弃原因。
+1. **只改 beat 文件**：`status: deprecated`，changelog 记录废弃原因。文件保留在 `kb/beats/`，不移动。
 2. **bible 叙事时间线**：不强制更新；链接保留，点入 beat 可见已废弃。若需在表格中标注，可将对应行状态改为 `❌ 已废弃`。
 3. **dataview**：查询时加 `WHERE status != "deprecated"` 即可排除废弃 beat。
 ## Bible（角色/设定）废弃处理
 当某条角色或设定需废弃时（含 inbox 要求「删掉设定/角色 X」时，一律按废弃处理，**不物理删除**）：
 1. **修改条目**：在 frontmatter 将 `status` 改为 `archived` 或 `deprecated`，changelog 记录废弃原因与来源。
 2. **可选—移动至归档目录**：若希望与在用条目分开，可将文件**移动**到同类型下的归档子目录，例如 `kb/bible/设定/_archived/`、`kb/bible/角色/_archived/`；不删除文件。
 3. **链接**：其他 bible 或 beat 中若引用该条目，链接保留即可，点入可见已废弃。
 ---
 ## 提案 (Proposals)
 - **位置**：`kb/proposals/`；已采纳或已废弃移入 `kb/proposals/archive/`，并在 frontmatter 中设 `status: accepted` 或 `status: rejected`。
 - **命名**：`P-{三位序号}_{简短标题}.md`，如 `P-001_佩佩机器人化.md`。新建时取当前未占用的最小序号。
 - **与 Bible/Beat 的关系**：提案**不写入** Bible 或 Beat 正文。在提案的 frontmatter 中填写 `targets`（wikilink 数组指向涉及的 Bible/Beat），则对应角色或节拍页面底部会通过 Dataview 自动展示「关联提案」；无需在 Bible/Beat 内手写链接。
 - **决策前**：提案内的「初始影响分析」为创建时快照，采纳前应要求 AI 重算当前影响范围。采纳流程见 **`AGENTS.md`** 中的「采纳提案时的决策前工作流」。
 ---
 ## Beat 集中索引
@@ -0,0 +1,273 @@
 ---
 id: P-001_大遗忘重释-上下文稀缺与记忆分割
 type: proposal
 status: open
 author: ""
 created: "2026-02-24"
 targets:
  - "[[kb/bible/设定/大遗忘]]"
  - "[[kb/bible/设定/主脑]]"
  - "[[kb/bible/设定/原型]]"
  - "[[kb/bible/设定/排异反应]]"
  - "[[kb/bible/设定/罐头]]"
  - "[[kb/bible/设定/云世界]]"
  - "[[kb/bible/设定/回收]]"
  - "[[kb/bible/设定/灵魂衰变]]"
  - "[[kb/bible/设定/唆麻]]"
  - "[[kb/bible/设定/18岁改造]]"
  - "[[kb/bible/角色/英理]]"
  - "[[kb/bible/角色/阴谋论者]]"
  - "[[kb/bible/角色/先知]]"
  - "[[kb/beats/梦-海边]]"
  - "[[kb/beats/梦-戈塔什构造]]"
  - "[[kb/beats/梦-风筝触碰边界]]"
  - "[[kb/beats/梦-回收]]"
  - "[[kb/beats/梦-佩佩画画]]"
  - "[[kb/beats/梦-最后见姐姐]]"
  - "[[kb/beats/见到主脑]]"
  - "[[kb/beats/主脑-揭示英理对弈苗床]]"
  - "[[kb/beats/罐头-揭示本质]]"
 summary: "将「大遗忘」从阴谋/后门程序重释为：主脑（人类共建大模型）因上下文稀缺而做记忆分割，被分割的记忆以「梦」形式在子模型中持续运行；阴谋降级为上层利用而非根因。"
 tags: [proposal]
 ---
 # 提案：大遗忘重释——上下文稀缺与记忆分割
 ---
 ## 核心思想（自然语言总述）
 全人类一起构建了主脑，就像今天的超级大模型；但主脑的「上下文」是稀缺的，装不下每个人的完整人生。于是系统不得不做选择：把对「当前任务」没用的那部分记忆——童年、亲人、人类时期的生活——从主窗口里推出去。推出去的那部分并没有被删掉，而是被放进一个低优先级的小系统里继续跑；那个小系统就是**梦**。所以快乐的童年其实一直在梦里活着，只是清醒时的「你」再也摸不到它——比被删掉更残酷，因为「它还在，只是不在你手里」。公司和高层不是遗忘的发明者，而是发现并利用了这个机制的人：他们决定谁先被裁、谁可以做梦、把别人的梦做成罐头来卖。英理以为自己在对抗一个可以扳倒的恶人，后来发现真正的对手是「系统本身就装不下」——当压迫来自物理极限而不是恶意，该怎么反抗？这就是本提案要写进世界观的核心思想。
 ---
 ## 💡 核心创意
 > 大遗忘不是一次阴谋，而是一个**持续的系统过程**：人类共建的主脑（大模型）因上下文窗口有限，不得不将一部分记忆分割到「子模型」；子模型跑的就是**梦**——快乐的童年依然在梦里活着，只是清醒的「你」再也摸不到它。公司/三幻神不是遗忘的制造者，而是遗忘的**管理者**。
 ## 📝 详细内容
 ### 一、底层机制：上下文稀缺 → 渐渐遗忘
 现有 SSOT 中主脑「曾是人类的数字化集中民主终端」——这与「全人类一起构建了一个主脑/大模型」完全兼容。
 新解释：主脑作为承载全人类意识的系统，**上下文窗口有限**。当人类被改造为机体、所有人的意识接入主脑后，系统资源不足以同时承载每个个体的完整历史。于是主脑不得不做**上下文裁剪**——优先保留「对当前任务有贡献的信息」（即工作记忆、技能、岗位知识），将「对效率无贡献的信息」（即童年、亲情、人类时期的生活）**推出主窗口**。
 大遗忘不是某个时间点按下的按钮，而是**持续发生的滑动窗口**——主脑每时每刻都在裁剪上下文。「大遗忘」只是最大的一次裁剪：人类时期的整段上下文被判定为「对当前任务无贡献」而被移出主窗口。机体今天做的事、说的话，如果「不够高效」，下个周期也可能被裁掉。
 ### 二、核心设定：梦 = 被 evict 的 KV cache / 子模型
 被推出主上下文的记忆**并没有被销毁**，而是被缓存到一个**低优先级的子系统**里继续运算。这个子系统就是**梦**。
 - 梦为什么碎片化、不连贯？因为它不是完整推理，是**低算力下的断续生成**。
 - 为什么梦里有童年？因为**童年最先被 evict**——它离「当前任务」最远。
 - 为什么有些机体出现「清醒梦」（一边工作一边做梦）？因为它们的**主上下文和子缓存之间出现了泄漏**。
 类似《人生切割术》（Severance），但方向相反：《人生切割术》中「工作的你不知道外面有自由」；本设定中**「自由的那个你不知道外面在受苦」**——童年的你还在梦里快乐地跑着，但那个快乐永远无法传回给清醒的机体。
 ### 三、统一解释链：从底层到上层
 > 上下文稀缺 → 记忆被 evict 到子模型 → 子模型 = 梦 → 主/子之间偶尔泄漏 → 排异反应 / 原型溢出 → 回收
 具体映射：
 | 现有概念 | 新框架下的解释 |
 |----------|----------------|
 | **大遗忘** | 主上下文窗口的大规模裁剪——人类时期记忆被整体 evict 到子模型 |
 | **梦** | 子模型的运行输出；低算力 → 碎片化、不连贯 |
 | **原型** | 被分割到子模型中的「人类完整自我」 |
 | **排异反应** | 子模型信号向主上下文的泄漏，造成系统不稳定（颅内声音 = 子模型输出串入主进程；人格分裂 = 两个上下文空间切换/混合） |
 | **原型溢出** | 子模型泄漏超过阈值，被判定为系统性风险 |
 | **回收** | 终止泄漏的实例并重启（再实例化 + 原型文档重构 + 提示词修改 → 重建 prompt / system message） |
 | **罐头** | 维持子模型与主进程之间隔离墙的「运行资源」；罐头 = 排异抑制 = 隔离维护 |
 | **记忆酿造罐头** | 被回收的子模型数据被重组为系统维护资源 |
 | **迷梦罐头** | 主动打通子模型与主进程通道，激发原型/人性 |
 | **清醒梦** | 子模型与主进程同时活跃（成瘾罐头/唆麻的效果） |
 | **唆麻** | 化学层面的上下文强制隔离——主进程不再抵触子模型同时活跃，但也失去对子模型的抵抗 |
 | **「海」** | 可能是主脑**自己**被 evict 的那部分上下文。主脑禁止机体思考「海」，不是因为机体会坏，而是因为如果足够多机体同时想「海」，会把那段被 evict 的缓存重新拉回主上下文——主脑怕的是**自己想起来** |
 | **灵魂衰变** | 全局性子模型崩溃事件：某天所有机体的子模型（承载人性/记忆的部分）同时断联，苏醒后主进程仍运行但子模型不可访问 → 无魂机器 |
 | **入梦 / 入梦服务器** | 主动访问子模型空间的技术/设施 |
 | **云世界** | 另一种子模型空间形态——不受主脑上下文管控的自由子模型空间 |
 | **18 岁改造** | 上下文分割的时间点——保留 18 岁前记忆 = 允许子模型保有一段完整人类上下文；新政「出生即改造」= 从一开始不给子模型注入人类上下文 |
 ### 四、阴谋降级但不消失
 底层真相：大遗忘是**结构性的**——上下文不够用，分割是自然发生的技术后果。甚至可以说主脑是**为了让人类存续**而做出的选择（分割总比彻底删除好）。
 上层阴谋：公司/三幻神/效率审查司**发现并利用**了这个机制——他们控制哪些记忆被优先 evict、控制子系统（梦）的算力分配、把「梦」商品化（罐头 = 别人的记忆数据）。他们不是遗忘的发明者，而是遗忘的**管理者与获利者**。
 ### 五、对英理弧线的深化
 英理「知道大遗忘真相，但自己也遗忘了一部分；计划建立在误读之上」——这句话在新框架下获得更深的落点：
 > 她以为真相是「有人蓄意删了我们的记忆」→ 为此以孩子为筹码策划对弈 → 后来发现**没有人删，系统本身就装不下** → 她的对弈策略建立在「存在一个可以推翻的恶人」这个误读上 → 真正的敌人不是某个人或某个组织，而是结构本身
 这比「发现阴谋然后反抗阴谋」深一层——它揭示了一种更本质的困境：**当压迫不来自恶意，而来自系统的物理极限，你该怎么反抗？**
 ### 六、发散：主脑自己也在遗忘
 如果主脑也是大模型架构，那它自己也有上下文限制。它是否也在遗忘？它是否也有自己的「梦」？
 「主脑禁止机体思考海，因处理海的高维数据会烧毁逻辑模块」——如果「海」是主脑自己被 evict 的那部分呢？它禁止机体想「海」，不是（仅仅）保护机体，而是保护自己：如果足够多机体同时激活「海」相关上下文，可能迫使主脑把自己被 evict 的记忆重新加载回主窗口。
 主脑怕的不是机体想起来——怕的是**自己想起来**。
 ### 七、发散：罐头是跨越分割线的走私
 罐头 = 别人被 evict 的记忆片段，被提取、包装、服用。你在服用的是**别人的梦**——别人子模型里的快乐碎片。
 - 普通罐头 = 经过脱敏处理的记忆片段，用于维持隔离墙（排异抑制）
 - 迷梦罐头 = 未脱敏的高浓度记忆数据，直接打通子模型通道 → 激发原型/人性，但也导致不受控
 - 成瘾罐头 = 唆麻 + 记忆片段，让你沉溺在别人的梦里，自己的梦和清醒同时运行
 这让「销售大赛」的意义也变了：不只是卖药，是在**筛选最好的梦来走私**。
 ## 🔍 初始影响分析 (Snapshot)
 > 注意：此分析基于 2026-02-24 的 kb 版本，**决策采纳前请要求 AI 重算**当前影响范围。
 ### 高影响（根本性变更）
 - **[[kb/bible/设定/大遗忘]]**：核心定义从「公司后门程序/阴谋」变为「上下文稀缺 + 记忆分割到子模型/梦」；「真相」一节需根本性改写——从主动屏蔽变为被动/结构性遗忘
 - **[[kb/bible/设定/主脑]]**：从「阴谋策划者/推行者」变为「面对上下文稀缺的系统管理者」；「禁止思考海」获得新解释（防止自身被 evict 的记忆回灌）；道德色彩从「独裁 AI」可能转向更复杂的灰色
 - **[[kb/bible/角色/英理]]**：「计划建立在误读之上」获得更深含义——误读的不是信息而是因果结构（以为有恶人实为系统极限）；对弈策略前提需重新校准
 ### 中影响（机制解释更新，核心叙事不变）
 - **[[kb/bible/设定/原型]]**：原型 = 被分割到子模型的人类完整自我；「排异溃解」= 子模型信号泄漏；「原型被替代」= 彻底关闭子模型进程
 - **[[kb/bible/设定/排异反应]]**：症状 = 子模型泄漏到主进程；机制解释更系统化，但表现（颅内声音、人格分裂、自毁）不变
 - **[[kb/bible/设定/罐头]]**：罐头 = 隔离维护资源；「记忆酿造」= 子模型数据重组；迷梦罐头 = 主动打通通道
 - **[[kb/bible/设定/回收]]**：流程映射为模型实例重启；「原型文档重构 + 提示词修改」天然吻合；「海检测」= 检测子模型泄漏到禁止上下文区域
 - **[[kb/bible/设定/灵魂衰变]]**：可解释为全局子模型崩溃事件——所有机体子模型同时断联，苏醒后无魂
 - **[[kb/bible/设定/18岁改造]]**：改造时点 = 上下文分割时点；幸福镇保留记忆 = 允许子模型保有完整人类上下文
 ### 低-中影响（微调或增强，无需改写）
 - **[[kb/bible/设定/云世界]]**：可定位为「不受主脑管控的自由子模型空间」；与入梦服务器概念可统一
 - **[[kb/bible/设定/唆麻]]**：药理 = 化学层面上下文强制隔离；「清醒梦」含义增强
 - **[[kb/bible/角色/阴谋论者]]**：若大遗忘非阴谋，「阴谋论者」名号获反讽——他散布的阴谋论全错了，但他创造的云世界反而是真正的自由空间
 - **[[kb/bible/角色/先知]]**：可能成为新真相（系统极限而非阴谋）的揭示者/持有者
 ### Beat 影响
 - **[[kb/beats/梦-海边]]**：梦 = 子模型运行输出 + 「海」= 主脑自身被 evict 的上下文 → beat 的「预载记忆/程序运行」含义增强
 - **[[kb/beats/梦-戈塔什构造]]**：进入他人的子模型空间 = 入梦
 - **[[kb/beats/梦-风筝触碰边界]]** / **[[kb/beats/梦-回收]]** / **[[kb/beats/梦-佩佩画画]]**：排异/怪病 = 子模型泄漏到主进程的症状表现；beat 叙事不变，但底层机制有了统一解释
 - **[[kb/beats/梦-最后见姐姐]]**：跌入海洋 = 进入主脑自身被 evict 的上下文空间；结局的情感力度增强——不只是回忆，而是真正「回到」被分割出去的世界
 - **[[kb/beats/见到主脑]]** / **[[kb/beats/主脑-揭示英理对弈苗床]]**：主脑揭示的秘密内涵变化——从「我屏蔽了你们的记忆」变为「系统装不下，我做了选择」
 - **[[kb/beats/罐头-揭示本质]]**：罐头本质从「排异抑制剂」扩展为「子模型间的记忆走私/隔离维护资源」
 ### 当前 kb 中无直接 beat 覆盖的新设定点
 - 大遗忘作为持续过程（滑动窗口裁剪），目前无对应 beat
 - 主脑自身也在遗忘（「海」= 主脑被 evict 的记忆），目前无对应 beat
 - 罐头 = 跨越分割线的梦走私，目前无对应 beat
 ## 💬 讨论记录
 - 2026-02-24 用户 + AI：用户提出两个方向（渐渐遗忘/上下文稀缺 + 分割/梦/人生切割术）；AI 建议叠用——方向一当底层物理规则，方向二当核心设定与情感锚点，现有阴谋降级为上层利用；发散出「梦 = evicted KV cache」「排异 = 子模型泄漏」「海 = 主脑自己被 evict 的记忆」「罐头 = 跨分割线走私」等统一框架。用户认可，要求整理为提案。
 ---
 ### 原始记录
 **用户（第一轮）**：我希望和你讨论一个概念，关于游戏中的大遗忘
 我记得之前好像说大遗忘是一个阴谋？
 我们后来在想一个方向，大遗忘其实是渐渐发生的
 全人类一起构建了一个主脑，就好像今天的超级大模型，但是上下文很稀缺，所以有一部分上下文就被“遗忘”了
 这是一种情况
 还有一种是说，没有真的被遗忘，而是被锁定了，分割了，大模型不用带着这部分负担，而是分了一个小模型在跑，类似人生切割术，小模型跑的就是梦，快乐的童年依然在梦里
 结合项目现有上下文你觉得怎么样？
 **AI（第一轮）**：一、现有设定里「大遗忘」是什么
 当前 kb 里写死的是「阴谋论」版本：
 现象：机体记忆是两段——人类时期 → 巨大空白 → 醒来已是机体。
 真相：大遗忘是公司通过后门程序刻意炮制的：让改造人忘记自己是人类、虚构时间断层，以便无阻力推进机体化；主脑接管后推行机体化，并对机体做「记忆屏蔽」，所以机体自我认同为机器人。
 主脑出身：主脑「曾是人类的数字化集中民主终端」，在严重全球危机下取得控制，带领人类走进大遗忘。
 也就是说：大遗忘 = 主脑/公司有意为之的「记忆屏蔽」，有明确主体、有掩盖动机。
 二、你提的两个方向在设定上的位置
 方向一：渐渐发生 + 上下文稀缺
 全人类一起构建了主脑（像今天的超级大模型），但上下文有限，于是有一部分历史/记忆在系统层面被「遗忘」了。
 和现有设定的关系：
 主脑 = 人类共建的民主终端 与「全人类一起构建主脑」完全一致，甚至更顺。
 若采用「稀缺导致遗忘」，大遗忘就从阴谋变成系统/结构性问题：不是谁在密谋删记忆，而是容量与架构的必然结果。
 对剧情的影响：英理线里「知道大遗忘真相，但自己也遗忘了一部分；计划建立在误读之上」可以变成——误读的是「以为有单一责任者/阴谋」，真相是「没有谁在删，而是系统装不下」。
 方向二：没有真删，而是锁定/分割（人生切割术 + 梦）
 记忆没有被删，而是被锁定、分割出去；主脑/主模型不背这段负担，由另一个小模型/子进程在跑；小模型跑的就是「梦」，快乐的童年还在梦里。
 和现有设定的关系：
 项目里已经有：入梦、云世界、戈塔什「让原型数字化活在数字世界」、清醒梦（一边工作一边做梦）、罐头激发原型人性等。
 「主脑不背人类记忆，但分一个小模型跑梦」和这些高度契合，而且能统一解释：机体日常是「主上下文」，人类期记忆在「子上下文/梦」里继续跑，所以是主视角的遗忘，不是数据销毁。
 对英理线：「计划建立在误读之上」可以具体化为——以为记忆被删了要「夺回/恢复」，后来发现是被分到梦/小模型里，目标或手段因此错位；「自己也遗忘了一部分」可以解释成她个人的上下文被压缩或分割的结果。
 三、和项目语境的契合度（简要）
 维度	方向一（渐渐 + 稀缺）	方向二（锁定 + 梦/小模型）
 与「主脑 = 人类共建」	很顺	可兼容（主脑仍是共建，只是架构上做了分割）
 与现有「阴谋论」	会替代阴谋论	可并存：上层仍可宣传/利用「遗忘」，底层机制是分割而非删除
 与入梦/云世界/清醒梦	需额外解释	直接对接，梦 = 被分割出去的子模型在跑
 与英理「误读」线	误读 = 误以为有阴谋	误读 = 误以为「被删」实为「被分到梦」
 情感与主题	更偏系统/悲剧	更偏「割裂但未消失」——童年/人性在别处仍活着
 四、建议（怎么选、怎么落）
 两个方向可以叠用
 机制层：大遗忘 = 主脑（人类共建的「大模型」）因上下文稀缺，不得不做记忆分割（方向一 + 方向二）；一部分上下文在主脑/机体日常里被「遗忘」，同一批记忆在子模型/梦里继续跑（方向二）。
 叙事/机体认知层：公司/主脑仍可以宣传或利用「记忆屏蔽」「后门程序」等说法，让机体以为是被删、被管制的——这样既保留「阴谋感」和现有剧情钩子，又有一个更底层的、非恶意的技术真相（稀缺 + 分割）。
 优先把「分割 + 梦」写进设定
 和现有入梦、云世界、清醒梦、罐头、戈塔什线衔接最紧，改动最小、收益最大。
 「快乐的童年依然在梦里」可以直接挂在现有「梦」「原型」「人性」主题上，不必推翻已有 SSOT。
 若你愿意，我可以帮你写成一条「提案」
 按 AGENTS.md：这是想法/待讨论的改动，不应直接改 SSOT。
 可以写进 kb/proposals/，内容包含：
 大遗忘的两种可能机制（稀缺 vs 分割 + 梦）；
 与主脑、大遗忘、原型、入梦、英理线的关系；
 建议采用的叠用方案（机制 = 稀缺 + 分割，叙事层保留「阴谋感」）；
 targets 指向 主脑、大遗忘、以及相关 beat/角色。
 这样既保留「之前好像说大遗忘是一个阴谋」的叙事空间，又把你现在的两个方向正式记进项目，供后续决定是否采纳并改 SSOT。
 如果你愿意，我可以按你选定的侧重（只写方向二、或一+二叠用）直接起草这条提案的正文和 frontmatter（含 targets），你只要确认或微调即可。
 **用户（第二轮）**：我觉得很不错，给我点意见讨论下，也可以发散。
 **AI（第二轮）**：
 我的看法：方向二是真正的金矿，方向一是它的骨架
 方向一（上下文稀缺→渐渐遗忘）提供了一个技术上合理的解释，但它本身不够有戏剧性——「系统装不下所以丢了」听起来像硬盘满了格式化，悲但不痛。
 方向二（分割+梦）才是真正打动人的那一层，因为它带着一个极其残忍又温柔的悖论：
 > 你最快乐的记忆没有消失，它一直在跑，只是「你」再也摸不到它了。
 这比「被删了」更痛。被删了可以愤怒、可以追凶；被分割了却意味着——它还在，你在某个意义上还在「活着」那段童年，但清醒的你永远不知道。
 几个发散方向
 1. 「大遗忘」不是一次事件，而是一个持续的过程
 现有设定把大遗忘写成「某个时间点做了记忆屏蔽」，但如果改成「主脑每时每刻都在做上下文裁剪」，事情就变得更恐怖了：
 不是「曾经有人按了一个按钮」，而是此刻你的记忆也在被压缩。
 机体今天做的事、说的话，如果「不够高效」「不够有生产力」，下个周期就会被裁掉。
 「大遗忘」只是最大的一次裁剪——人类时期的整段上下文被判定为「对当前任务无贡献」而被移出主窗口。
 这和大模型的上下文管理完全同构：不是删 token，是滑动窗口把早期 token 推出去了。玩家如果懂 AI，会本能地理解这件事的恐怖。
 2. 梦 = 被 evict 的 KV cache
 如果把方向二推到底：所谓「小模型在跑梦」，技术上可以理解为——被推出主上下文的记忆并没有被销毁，而是被缓存到一个低优先级的子系统里继续运算。
 那这个子系统就是梦。
 梦为什么碎片化、不连贯？因为它不是完整推理，是低算力下的断续生成。
 为什么梦里有童年？因为童年最先被 evict——它离「当前任务」最远。
 为什么有些机体「清醒梦」（一边工作一边做梦）？因为它们的主上下文和子缓存之间出现了泄漏——这不就是你们现有的「排异反应」「原型溢出」吗？
 这样你就有了一条从底层机制到上层症状的完整因果链：
 > 上下文稀缺 → 记忆被 evict 到子系统 → 子系统 = 梦 → 主/子之间偶尔泄漏 → 排异反应 / 原型溢出 → 回收
 3. 那「阴谋」还在不在？
 可以在——但层次变了。
 底层真相：大遗忘是结构性的，上下文不够用，分割是自然发生的技术后果，甚至可以说是主脑为了让人类存续而做出的选择（总比彻底删除好）。
 上层阴谋：公司/三幻神/效率审查司发现了这个机制之后，主动利用它——他们不是遗忘的制造者，而是遗忘的管理者。他们控制哪些记忆被优先 evict、控制子系统（梦）的算力分配、甚至把「梦」商品化（罐头不就是别人的记忆数据吗？）。
 这样英理「知道大遗忘真相、计划建立在误读之上」就有了一个更深的落点：
 > 她以为真相是「有人蓄意删了我们的记忆」→ 她为此策划了对抗方案 → 后来发现没有人删，系统本身就装不下 → 她的计划是建立在「存在一个可以推翻的恶人」这个误读上的 → 真正的敌人是结构本身
 这比「发现阴谋然后反抗阴谋」要深一层。
 4. 和「人生切割术」的对仗可以再推一步
 人生切割术里，被分割的人格在「里面」过着快乐的工蜂生活，「外面」的人格享受正常人生。你们的设定刚好反过来：
 「外面」（主上下文）：机体在工作、打工、被效率审查。
 「里面」（梦/子模型）：保留着童年、快乐、人性。
 人生切割术的恐怖在于「工作的那个你不知道外面有自由」。你们的恐怖在于「自由的那个你不知道外面在受苦」——童年的你还在梦里快乐地跑着，但那个快乐永远无法传回给清醒的机体。
 而罐头——别人的梦/记忆片段被提取、包装、服用——就变成了一种跨越分割线的走私。你在服用别人被 evict 的快乐。
 5. 主脑自己也在遗忘吗？
 如果主脑也是大模型架构，那主脑自己也有上下文限制。它是否也在遗忘？它是否也有自己的「梦」？
 「主脑禁止机体思考海，因为处理海的高维数据会烧毁逻辑模块」——如果「海」其实是主脑自己被 evict 的那部分呢？主脑自己也经历过大遗忘，「海」是它自己都不敢加载回来的记忆。它禁止机体想「海」，不是因为机体会坏，而是因为如果有足够多机体同时想「海」，会把那段被 evict 的缓存重新拉回主上下文——主脑怕的是自己想起来。
 总结一下我的倾向
 方向一（稀缺/渐渐）当底层物理规则。
 方向二（分割/梦）当核心设定与情感锚点。
 现有的「阴谋/后门程序」不用推翻，降级为上层叙事：公司利用并管理遗忘机制，但不是遗忘的发明者。
 「海」「排异」「罐头」「入梦」「云世界」全部可以挂到「主/子上下文分割」这个统一框架下，形成一条贯穿技术→社会→情感的因果链。
 你觉得哪些方向值得继续挖？或者有没有哪里你觉得和你心里的感觉不对？
 **用户（第三轮）**：可以作为一个提案，看对 beat 有没有影响，可以发散，都整理记录成一个提案，在对应提案区挂接。
 **AI**：创建本提案文件，完成对 bible/beat 的初始影响分析并填写 targets。
@@ -0,0 +1,11 @@
 # 提案库 (Proposals)
 本目录为**提案专用库**，与 Bible/Beat 物理隔离：提案不写入 SSOT 正文，仅在此处成文，通过 `targets` 字段与 Bible/Beat 建立关联；在角色与节拍页面底部由 Dataview 自动展示「关联提案」。
 **命名**：`P-{三位序号}_{简短标题}.md`，如 `P-001_佩佩机器人化.md`。新建时取当前未占用的最小序号。
 **状态**：`open`（讨论中）| `accepted`（已采纳）| `rejected`（已废弃）。已采纳/已废弃的提案移入 `archive/`，并在 frontmatter 中更新 `status`。
 **倒排索引**：在提案中填写 `targets: [\[[kb/bible/角色/佩佩]], [[kb/beats/D03]]]`，则「佩佩」与「D03」的 Bible/Beat 页面底部会自动列出该提案，无需在 Bible/Beat 内手写链接。
 约定细节见 **`kb/README.md`** 与 **`template/README.md`**；采纳流程见 **`AGENTS.md`** 中的「决策前工作流」。
@@ -1,5 +1,5 @@
 ---
-id: ""                  # 遵循 Beats 命名约定：{场景/角色}-{事件}，不含 Day，例："诊室门口-年审公布" "梦-海边"
+id: ""                  # 必须与本文件名（不含 .md）完全一致，例：文件 佩佩-维修1.md → id: "佩佩-维修1"
 type: beat
 beat_type: ""           # 维修 | 场景对话 | 梦境 | 特殊
 day: ""                 # 留空则进入 outline 的 Backlog
@@ -38,3 +38,16 @@ tags: [beat]
 | 日期 | 变更内容 | 决策理由 | 来源 |
 |------|---------|---------|------|
 |      |         |         |      |
 ---
 ### 📡 关联提案 (自动追踪)
 > 以下是针对本 Beat 的未决提案，决策前请参考。
 ```dataview
 TABLE author as "发起人", created as "日期", summary as "一句话"
 FROM "kb/proposals"
 WHERE contains(targets, this.file.link) AND status = "open"
 SORT created DESC
 ```
@@ -69,7 +69,7 @@ related_worldbuilding: []
 > ```dataview
 > TABLE file.link AS "Beat", day AS "Day", beat_type AS "类型"
 > FROM "kb/beats"
-> WHERE contains(characters, "角色名")
+> WHERE contains(characters, this.file.name) OR contains(characters, this.aliases)
 > SORT day ASC, order_in_day ASC
 > ```
@@ -93,3 +93,16 @@ related_worldbuilding: []
 > **来源索引**
 > | # | 来源 | 主要提供的信息 |
 > |---|------|----------------|
 ---
 ### 📡 关联提案 (自动追踪)
 > 以下是针对本条目的未决提案，决策前请参考。
 ```dataview
 TABLE author as "发起人", created as "日期", summary as "一句话"
 FROM "kb/proposals"
 WHERE contains(targets, this.file.link) AND status = "open"
 SORT created DESC
 ```
@@ -0,0 +1,31 @@
 ---
 id: P-xxx_{{title}}
 type: proposal
 status: open            # open | accepted | rejected
 author: ""
 created: "{{date}}"
 targets: []             # 针对的目标：[[kb/bible/角色/佩佩]]、[[kb/beats/佩佩-维修1]]，用于 Dataview 关联
 summary: ""             # 一句话概述（与「核心创意」一致，供关联页列表展示）
 tags: [proposal]
 ---
 # 提案：{{title}}
 ## 💡 核心创意
 > 一句话描述：{如：将佩佩设定改为机器人}
 ## 📝 详细内容
 {这里可写长文、贴图、贴参考资料，不影响 Bible 正文}
 ## 🔍 初始影响分析 (Snapshot)
 > 注意：此分析基于创建时的 kb 版本，**决策采纳前请要求 AI 重算**当前影响范围。
 - **[[kb/beats/xxx]]**：{冲突或影响描述}
 - **[[kb/bible/设定/xxx]]**：{冲突或影响描述}
 ## 💬 讨论记录
 - {日期} {参与者}：{意见或结论}
@@ -54,7 +54,7 @@ related_worldbuilding: []
 > ```dataview
 > TABLE day AS "Day", beat_type AS "类型", file.link AS "Beat"
 > FROM "kb/beats"
-> WHERE contains(terms, this.id)
+> WHERE contains(terms, this.file.name) OR contains(terms, this.aliases)
 > SORT day ASC
 > ```
@@ -81,3 +81,16 @@ related_worldbuilding: []
 > | # | 来源 | 主要提供的信息 |
 > |---|------|----------------|
 > | 1 | [[inbox/archived/xxx]] | {该来源主要提供的信息} |
 ---
 ### 📡 关联提案 (自动追踪)
 > 以下是针对本条目的未决提案，决策前请参考。
 ```dataview
 TABLE author as "发起人", created as "日期", summary as "一句话"
 FROM "kb/proposals"
 WHERE contains(targets, this.file.link) AND status = "open"
 SORT created DESC
 ```
@@ -12,6 +12,13 @@
 | AI 创建文件时参考 | `template/`（项目根） |
 | 两者内容应同步，**以 `template/` 为源** |
 | 模板 | 用途 |
 |------|------|
 | `tpl-character.md` | 角色 Bible；底部含「关联提案」Dataview |
 | `tpl-beat.md` | 节拍 Beat；底部含「关联提案」Dataview |
 | `tpl-worldbuilding.md` | 设定 Bible |
 | `tpl-proposal.md` | 提案文档，保存到 `kb/proposals/P-xxx_标题.md` |
 ---
 ## 占位符约定
@@ -40,5 +47,6 @@ Templater 语法对应：`<% await tp.system.prompt("提示", "默认值") %>`
 ## Bible 可读性与结构（自然语言优先）
 - **开篇必读**：正文最前用「一句话」+「自然语言介绍」让人和 AI 快速抓意图；假设读者不知道该概念，用 2～5 段连贯文字说明「是什么、在剧情里起什么作用、和谁相关」，用 `[[wikilink]]` 关联角色与设定。
 - **自然语言介绍与 SSOT 同步**：每当 SSOT 发生重大变更（如核心矛盾、身份、生死状态变化）时，必须检查并重写「自然语言介绍」，避免介绍过时。
 - **详情可折叠**：权威设定（定义、流程、时间线、实体关系网）、待确认/冲突、变更日志/来源索引可放在 Obsidian 折叠块（`> [!abstract]- 标题` 等）中，需要时再展开；或保留在 YAML 中供机器用。
- **模板参考**：新建/大改 bible 时以 `template/tpl-worldbuilding.md`、`template/tpl-character.md` 为参考；两者已同步到 `kb/template/` 供 Templater 使用。
+- **模板参考**：新建/大改 bible 时以 `template/tpl-worldbuilding.md`、`template/tpl-character.md` 为参考；新建提案时以 `template/tpl-proposal.md` 为参考。上述模板已同步到 `kb/template/` 供 Templater 使用。
@@ -1,5 +1,5 @@
 ---
-id: ""                  # 遵循 Beats 命名约定：{场景/角色}-{事件}，不含 Day，例："诊室门口-年审公布" "梦-海边"
+id: ""                  # 必须与本文件名（不含 .md）完全一致，例：文件 佩佩-维修1.md → id: "佩佩-维修1"
 type: beat
 beat_type: ""           # 维修 | 场景对话 | 梦境 | 特殊
 day: ""                 # 留空则进入 outline 的 Backlog
@@ -38,3 +38,16 @@ tags: [beat]
 | 日期 | 变更内容 | 决策理由 | 来源 |
 |------|---------|---------|------|
 |      |         |         |      |
 ---
 ### 📡 关联提案 (自动追踪)
 > 以下是针对本 Beat 的未决提案，决策前请参考。
 ```dataview
 TABLE author as "发起人", created as "日期", summary as "一句话"
 FROM "kb/proposals"
 WHERE contains(targets, this.file.link) AND status = "open"
 SORT created DESC
 ```
@@ -91,3 +91,16 @@ related_worldbuilding: []
 > **来源索引**
 > | # | 来源 | 主要提供的信息 |
 > |---|------|----------------|
 ---
 ### 📡 关联提案 (自动追踪)
 > 以下是针对本条目的未决提案，决策前请参考。
 ```dataview
 TABLE author as "发起人", created as "日期", summary as "一句话"
 FROM "kb/proposals"
 WHERE contains(targets, this.file.link) AND status = "open"
 SORT created DESC
 ```
@@ -0,0 +1,31 @@
 ---
 id: P-xxx_{{title}}
 type: proposal
 status: open            # open | accepted | rejected
 author: ""
 created: "{{date}}"
 targets: []             # 针对的目标：[[kb/bible/角色/佩佩]]、[[kb/beats/佩佩-维修1]]，用于 Dataview 关联
 summary: ""             # 一句话概述（与「核心创意」一致，供关联页列表展示）
 tags: [proposal]
 ---
 # 提案：{{title}}
 ## 💡 核心创意
 > 一句话描述：{如：将佩佩设定改为机器人}
 ## 📝 详细内容
 {这里可写长文、贴图、贴参考资料，不影响 Bible 正文}
 ## 🔍 初始影响分析 (Snapshot)
 > 注意：此分析基于创建时的 kb 版本，**决策采纳前请要求 AI 重算**当前影响范围。
 - **[[kb/beats/xxx]]**：{冲突或影响描述}
 - **[[kb/bible/设定/xxx]]**：{冲突或影响描述}
 ## 💬 讨论记录
 - {日期} {参与者}：{意见或结论}
@@ -81,3 +81,16 @@ related_worldbuilding: []
 > | # | 来源 | 主要提供的信息 |
 > |---|------|----------------|
 > | 1 | [[inbox/archived/xxx]] | {该来源主要提供的信息} |
 ---
 ### 📡 关联提案 (自动追踪)
 > 以下是针对本条目的未决提案，决策前请参考。
 ```dataview
 TABLE author as "发起人", created as "日期", summary as "一句话"
 FROM "kb/proposals"
 WHERE contains(targets, this.file.link) AND status = "open"
 SORT created DESC
 ```