From 6be6be6effcbb741fda1352ac53e95d77b522913 Mon Sep 17 00:00:00 2001 From: bottlefish <781230111@qq.com> Date: Tue, 24 Feb 2026 22:53:46 +0800 Subject: [PATCH] =?UTF-8?q?docs(agent):=20=E7=9B=AE=E5=BD=95=E8=A1=A8=20pr?= =?UTF-8?q?oposals=20=E6=94=B9=E9=A1=B9=E7=9B=AE=E6=A0=B9=E3=80=81?= =?UTF-8?q?=E7=BA=A6=E6=9D=9F=E4=B8=8E=E5=B7=A5=E5=85=B7=E3=80=81=E6=8C=AA?= =?UTF-8?q?=E6=96=87=E4=BB=B6=E7=BA=A6=E5=AE=9A?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Cursor --- AGENTS.md | 27 ++++++++++----------------- 1 file changed, 10 insertions(+), 17 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index a247796..babf830 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -6,12 +6,6 @@ 你的职责：信息汇总、格式整理、关系推断、冲突检测、变更记录。 你不负责：创意决策、判断设定是否「正确」、解决冲突。 -## 提案 vs 指令 - -- **指令 (Directive)**：用户明确要求「按此修改」或「直接落地」的内容。处理 Inbox 时，按现有流程**直接修改 SSOT**（更新/新建 bible 与 beat），然后归档。 -- **提案 (Proposal)**：想法、建议、待讨论的改动。**不修改 SSOT**，而是写入 `kb/proposals/` 的提案文档，填写 `targets` 指向涉及的 Bible/Beat；在对应角色或节拍页面底部由 Dataview 自动展示「关联提案」。 -- **每次处理 Inbox**：若用户未标明是指令还是提案，**必须先询问**：「这份内容是指令（直接按此修改 SSOT）还是提案（仅写入提案库供讨论）？」尤其在「最后决定怎么做」时，必须询问用户再执行。 - ## 核心原则 1. **单一信息源**：每个角色、世界观概念、节拍在 `kb/` 下有且仅有一个权威文件。 @@ -20,7 +14,7 @@ 4. **变更必留档**：对 kb 文件的每次修改都必须在文件 changelog 中记录日期、说明、原因与来源。 5. **保留原文**：汇总时尽量保留原始措辞，只做结构调整，不重写。 6. **模板为聚合服务，结构随信息而定**：模板用于更好地聚合与检索；具体条目可根据实际聚合到的信息，选择适合的小节与呈现方式（例如无冲突则冲突表可留空，回忆角色可弱化机制、强化弧线/意象），不必机械填满模板每一项。 -7. **不物理删除**：AI 没有删除文件的权限。若 Inbox 或人类要求「删掉设定/角色/节拍 X」，一律按**废弃**处理：将对应条目的 `status` 改为 `archived` 或 `deprecated`，并按 `kb/README.md` 约定移动至指定文件夹（若有）；**绝不物理删除**文件。 +7. **不物理删除**：AI 没有删除文件的权限。若 Inbox 或人类要求「删掉设定/角色/节拍 X」，一律按**废弃**处理：将对应条目的 `status` 改为 `archived` 或 `deprecated`；具体流程见 `inbox-directive` SKILL 的「废弃处理」；**绝不物理删除**文件。 8. **自然语言介绍与 SSOT 同步**：每当 SSOT（权威设定详情）发生重大变更（如核心矛盾、身份、生死状态变化）时，必须检查并重写该条目的「自然语言介绍」部分，避免介绍老化。 ## 目录结构 @@ -30,21 +24,20 @@ | `kb/bible/角色/` | 角色条目 (type: character)，中文文件名 | | `kb/bible/设定/` | 世界观/设定条目 (type: worldbuilding) | | `kb/beats/` | 每个节拍一个文件（最小叙事单元） | -| `kb/proposals/` | 提案专用库（不写入 Bible/Beat 正文）；已采纳/已废弃移入 `proposals/archive/` | +| `proposals/`（项目根） | 提案专用库（不写入 Bible/Beat 正文）；已采纳/已废弃移入 `proposals/archive/` | | `kb/decisions/` | 决策记录 | | `kb/template/` | Templater 模板（Obsidian 内用） | | `inbox/`、`inbox/archived/` | 输入与已处理归档 | | `template/`（项目根） | 模板源文件，**AI 创建文件时参考** | -命名与索引等约定见 **`kb/README.md`**；模板、占位符与新建流程见 **`template/README.md`**。 +目录索引见 **`kb/README.md`**；命名与废弃约定见 **`inbox-directive`** SKILL；模板与新建流程见 **`template/README.md`**。 + +## 约束与工具 + +- **入口约束**：信息进入系统时，先判断是**讨论**、**提案**还是**指令**；不确定就问用户。 +- **三种模式**：**讨论** = 探索、头脑风暴、信息收集，不落 SSOT 不写提案，用 `inbox-discussion`。**提案** = 想法/建议进提案库，不直接改 SSOT，用 `inbox-proposal`。**指令** = 按此修改或直接落地，改 SSOT 并归档，用 `inbox-directive`（含「采纳 P-xxx」：重读→重验→报告→执行）。 -## 采纳提案时的决策前工作流 - -当用户表示要**采纳**某条提案（如「采纳 P-001」）时，按以下步骤执行，不直接改 SSOT： - -1. **重读 (Re-read)**：读取该提案的完整内容。 -2. **重验 (Re-validate)**：**重新扫描**当前 `kb/` 下相关 Bible/Beat，检查该提案与现有一致性、是否仍有冲突或已产生新冲突。 -3. **报告 (Report)**：若发现提案内「初始影响分析」已过时，向用户说明**当前**影响范围与冲突情况；若与现状一致，也简要确认。 -4. **执行 (Execute)**：仅在用户确认后，将提案内容合并入对应 SSOT，更新 changelog；将提案文件移入 `kb/proposals/archive/`，frontmatter 中 `status` 改为 `accepted`。 +- **Meta 层**：规则、模板、SKILL、流程本身的修改不属上述三类，直接操作即可。 +- **挪文件**：需要移动或复制文件时，用终端命令（如 PowerShell 的 `Move-Item`、`Copy-Item`）直接挪，不要整份 read 再 write；只有必须改内容时才用读写法。