From 743bcaef4483070e7b70a90d682a702ce1b8972e Mon Sep 17 00:00:00 2001 From: bottlefish <781230111@qq.com> Date: Tue, 24 Feb 2026 21:04:33 +0800 Subject: [PATCH] =?UTF-8?q?feat(kb):=20=E6=96=B0=E5=A2=9E=E6=8F=90?= =?UTF-8?q?=E6=A1=88=E5=B7=A5=E4=BD=9C=E6=B5=81=E3=80=81proposals=20?= =?UTF-8?q?=E7=9B=AE=E5=BD=95=E4=B8=8E=20tpl-proposal=EF=BC=8C=E5=90=8C?= =?UTF-8?q?=E6=AD=A5=E6=A8=A1=E6=9D=BF=E4=B8=8E=20skill?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Cursor --- .cursor/skills/inbox-process/SKILL.md | 57 +++- .cursorignore | 5 + AGENTS.md | 22 +- kb/README.md | 24 +- .../P-001_大遗忘重释-上下文稀缺与记忆分割.md | 273 ++++++++++++++++++ kb/proposals/README.md | 11 + kb/proposals/archive/.gitkeep | 0 kb/template/tpl-beat.md | 15 +- kb/template/tpl-character.md | 15 +- kb/template/tpl-proposal.md | 31 ++ kb/template/tpl-worldbuilding.md | 15 +- template/README.md | 10 +- template/tpl-beat.md | 15 +- template/tpl-character.md | 13 + template/tpl-proposal.md | 31 ++ template/tpl-worldbuilding.md | 13 + 16 files changed, 528 insertions(+), 22 deletions(-) create mode 100644 .cursorignore create mode 100644 kb/proposals/P-001_大遗忘重释-上下文稀缺与记忆分割.md create mode 100644 kb/proposals/README.md create mode 100644 kb/proposals/archive/.gitkeep create mode 100644 kb/template/tpl-proposal.md create mode 100644 template/tpl-proposal.md diff --git a/.cursor/skills/inbox-process/SKILL.md b/.cursor/skills/inbox-process/SKILL.md index 1fe0ffe..696ea6e 100644 --- a/.cursor/skills/inbox-process/SKILL.md +++ b/.cursor/skills/inbox-process/SKILL.md @@ -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 文件 -2. 识别其中提到的所有实体（角色、世界观、节拍） -3. 对每个实体，判断需要执行什么操作 -4. **暂停，输出分析报告，等待人确认** +1. 完整阅读该 inbox 文件。 +2. **若用户未标明是指令还是提案**，必须先询问： + - 「这份内容是指令（直接按此修改 SSOT）还是提案（仅写入提案库供讨论）？」 +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` \ No newline at end of file +- **AI 新建的文件必须标记**：bible 和 beat 均在 frontmatter 加 `created_by: ai` +- **不物理删除**：AI 无权删除任何文件。若 inbox 要求「删掉设定/角色/节拍 X」，执行**废弃**——将该条目的 `status` 改为 `archived` 或 `deprecated`，按 `kb/README.md` 约定移动至指定文件夹（若有），changelog 记录废弃原因；绝不使用删除文件的动作。 \ No newline at end of file diff --git a/.cursorignore b/.cursorignore new file mode 100644 index 0000000..766b78b --- /dev/null +++ b/.cursorignore @@ -0,0 +1,5 @@ +# 归档与历史，避免 AI 引用废弃内容 +kb/archive/ +kb/proposals/archive/ +inbox/archived/ +**/*.log \ No newline at end of file diff --git a/AGENTS.md b/AGENTS.md index 55eba99..a247796 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -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`**。 diff --git a/kb/README.md b/kb/README.md index e0b346d..7c278e6 100644 --- a/kb/README.md +++ b/kb/README.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 集中索引 diff --git a/kb/proposals/P-001_大遗忘重释-上下文稀缺与记忆分割.md b/kb/proposals/P-001_大遗忘重释-上下文稀缺与记忆分割.md new file mode 100644 index 0000000..813199e --- /dev/null +++ b/kb/proposals/P-001_大遗忘重释-上下文稀缺与记忆分割.md @@ -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。 diff --git a/kb/proposals/README.md b/kb/proposals/README.md new file mode 100644 index 0000000..2d05638 --- /dev/null +++ b/kb/proposals/README.md @@ -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`** 中的「决策前工作流」。 diff --git a/kb/proposals/archive/.gitkeep b/kb/proposals/archive/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/kb/template/tpl-beat.md b/kb/template/tpl-beat.md index e7e0045..ba5d727 100644 --- a/kb/template/tpl-beat.md +++ b/kb/template/tpl-beat.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 +``` diff --git a/kb/template/tpl-character.md b/kb/template/tpl-character.md index 38c9e89..90e86ba 100644 --- a/kb/template/tpl-character.md +++ b/kb/template/tpl-character.md @@ -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 +``` diff --git a/kb/template/tpl-proposal.md b/kb/template/tpl-proposal.md new file mode 100644 index 0000000..4de215b --- /dev/null +++ b/kb/template/tpl-proposal.md @@ -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]]**：{冲突或影响描述} + +## 💬 讨论记录 + +- {日期} {参与者}：{意见或结论} diff --git a/kb/template/tpl-worldbuilding.md b/kb/template/tpl-worldbuilding.md index 9720cae..09a6b0c 100644 --- a/kb/template/tpl-worldbuilding.md +++ b/kb/template/tpl-worldbuilding.md @@ -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 +``` diff --git a/template/README.md b/template/README.md index a896e4a..7b5f45a 100644 --- a/template/README.md +++ b/template/README.md @@ -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 使用。 diff --git a/template/tpl-beat.md b/template/tpl-beat.md index 6b3f678..4f74d22 100644 --- a/template/tpl-beat.md +++ b/template/tpl-beat.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 +``` diff --git a/template/tpl-character.md b/template/tpl-character.md index c1d7ec7..fa7cad3 100644 --- a/template/tpl-character.md +++ b/template/tpl-character.md @@ -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 +``` diff --git a/template/tpl-proposal.md b/template/tpl-proposal.md new file mode 100644 index 0000000..4de215b --- /dev/null +++ b/template/tpl-proposal.md @@ -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]]**：{冲突或影响描述} + +## 💬 讨论记录 + +- {日期} {参与者}：{意见或结论} diff --git a/template/tpl-worldbuilding.md b/template/tpl-worldbuilding.md index 3091016..e5e2473 100644 --- a/template/tpl-worldbuilding.md +++ b/template/tpl-worldbuilding.md @@ -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 +```