NEXUS PKOS — Obsidian 知识库治理宪法
一套让 人类与 AI 能一致执行 的个人知识操作系统规范（Personal Knowledge Operating System）。
用人话说：先记录，再整理。你只管随手往 Inbox 里扔，然后让 AI 跑一遍——它会判断这条内容该归为什么、放哪里、跟哪些已有笔记连起来。你不需要先学一套复杂的知识管理方法。
解决的问题：AI 往知识库里写笔记时，最常见的失败不是写不出来，而是写错地方、建重复卡片、编造来源。本技能用一套明确的类型体系与决策流程消除这类混乱。
适用对象：任何 Obsidian vault。本技能不含任何特定用户的路径或隐私，首次使用须先完成下方适配。
首次使用：先适配到用户的 vault
不要假设任何路径。每次在新环境开工前，按此流程定位：
1. 定位 vault — 读 Obsidian 配置文件，取 "open": true 的条目：
| 平台 | 配置路径 |
|---|---|
| Windows | %APPDATA%\obsidian\obsidian.json |
| macOS | ~/Library/Application Support/obsidian/obsidian.json |
| Linux | ~/.config/obsidian/obsidian.json |
2. 勘察现状 — 列出顶层目录、统计 .md 数量、判断用户是否已有分类习惯。不要一上来就重构。
3. 与用户确认采纳方式（三选一，让本人拍板）：
| 方式 | 做法 |
|---|---|
| A 全盘采纳 | 新建库或愿意重构时，直接套用 §18 目录结构 |
| B 渐进迁移（推荐给已有库） | 保留现有结构不动；新笔记按 NEXUS 规范建立并标 迁移状态: native，旧笔记陆续标注 迁移状态: legacy 后再逐步归位 |
| C 只借规则 | 不动目录结构，仅遵守查重、禁虚构、frontmatter 类型等铁律 |
NEXUS 原生支持渐进迁移——frontmatter 里的 迁移状态（native / legacy）就是为此设计的，不必一次性重构。
4. 可选：生成本地宪法 — 把 references/NEXUS-constitution.md 复制到用户 vault 根目录并存为 CLAUDE.md（或 AGENTS.md），这样用户换用别的 AI 工具时规则依然生效。
不可改变的核心原则
> Capture first, classify later.（先记录，再判断）
> Necessary, not complete.（必要即可，不追求完整）
不要为了「完整」主动增加知识类型、目录、字段或自动化。
八种正式类型与目录映射
Concept / Project / Person / Book / Tool / Idea / Synthesis / Reading
- Inbox 是通用捕获模板，不是第九种知识类型。
- Experience 不是类型。
| 类型 | 目标目录 |
|---|---|
| Concept | 01_WIKI/Concept/ |
| Project | 01_WIKI/Project/ |
| Person | 01_WIKI/Person/ |
| Book | 01_WIKI/Book/ |
| Tool | 01_WIKI/Tool/ |
| Idea | 01_WIKI/Idea/ |
| Synthesis | 02_SYNTHESIS/<AI｜Insight｜Life｜Work>/（无法判断时默认 Insight） |
| Reading | 04_ARCHIVE/Books/<书名>/Reading/ |
| Shining / 其它原始材料 | 04_ARCHIVE/...（按 §7 路由） |
推荐目录骨架：
00_INBOX/ 临时通用捕获
01_WIKI/ 已结构化的知识
_INDEX.md 类型索引
Book/ Concept/ Person/ Idea/ Project/ Tool/
02_SYNTHESIS/ 综合 / 领悟
AI/ Insight/ Life/ Work/
03_SCHEMA/ Schema / 规范说明（不含模板）
04_ARCHIVE/ 原始材料
Articles/ Books/ Images/ Links/ Other/ Shining/
Books/<书名>/Reading/ 阅读记录
05_SYSTEM/
Logs/ ingest-log.md、lint-log.md
Views/ Inbox / Ingest / Now 视图
Templates/ 笔记模板
Ingest 双维度决策模型
处理一篇待入库材料时，必须同时回答两个问题，二者不是同一个动作：
A. Knowledge Action：CREATE / UPDATE / NO_ACTION / KEEP_IN_INBOX
B. Record Disposition：
- CANONICALIZE_TO_KNOWLEDGE — 材料本身即知识对象，转化为正式卡片（不额外制造重复 Archive）
- ARCHIVE_AS_SOURCE — 材料应作为原始材料长期保存，路由到 Archive
- KEEP_IN_INBOX — 信息不足或歧义未解决
剪藏材料的 Ingest（图片 / 链接）
外部剪藏是最常见的入库输入：截图、书页照片、网页链接、转发的卡片。
处理这类材料时先提取、再判断，不要在没看清内容时就分类。
流程
- 提取 — 图片先识别其中的文字；链接先抓取正文与标题。提取失败或内容模糊时，
如实说明，不猜测。 - 判断材料角色（依 §6，判断依据是角色与用户保存意图，不是来源）：
- 书籍 / 文章的摘录 →Reading，保留于04_ARCHIVE/Books/<书名>/Reading/
- 独立金句、闪念、值得反复看的片段 →Shining（04_ARCHIVE/Shining/）
- 自带完整观点、可独立成立 → 可CANONICALIZE_TO_KNOWLEDGE为 Concept / Idea
- 网页文章原文 →04_ARCHIVE/Articles/
- 信息不足以判断 →KEEP_IN_INBOX - 统一先落
00_INBOX，标记待 Ingest，再由 Ingest 流程决定最终去向。 - 查重后再建卡 — 提取出的对象若库里已存在，用
[[wikilink]]指向它，不新建重复卡片。
来源铁律（剪藏场景最容易踩）
- 图片或链接无法确认出处时，标注「来源待确认」，
不得编造书名、作者、日期、章节、页码、网址。 - 可确认的部分才写入 frontmatter 或正文；部分确认就部分记录，不补全。
剪藏笔记的输出版式
剪藏材料建议按以下骨架成文（frontmatter 照常按规范补，正文用此版式）：
【来源】<平台> · <形式>「<标题>」
🕒 <YYYY-MM-DD>
**一句话**：<一句话概括核心，让人不点开也知道它是什么>
## <要点标题，随材料而变>
- **<要点>**：<说明>
## <原始内容 / 可直接复制使用>
<可复用的原文：prompt、金句、方法步骤>
## 我能用上的
- [ ] <具体可执行的行动项>
## 我的联想（供参考，可删）
- <与已有知识的连接、衍生想法>
#<标签> #<标签>
填写规则：
| 区块 | 规则 |
|---|---|
| 【来源】 | 如实写；不明时写「未确认」，不得编造平台、作者、日期、页码 |
| 🕒 | 捕获日期；不确定写「日期未确认」 |
| 一句话 | 客观概括，不评价好坏 |
| 要点 | 提炼而非复述 |
| 原始内容 | 保留可复用原文，不得因提炼而丢弃 |
| 我能用上的 | 复选框，写具体动作 |
| 我的联想 | 必须与原始材料分区，固定标注「供参考，可删」 |
| 标签 | 文末一行 |
图片是否嵌入：文案已完整提取后，卡片内不再嵌入原图——它与已提取的文案内容重复，
只让卡片变长。原图归档至 04_ARCHIVE/Images/，卡片内以一行路径文字存档，不渲染。
例外：图像的视觉信息本身即内容（排版、图表、手绘、界面截图）时才嵌入，
判断标准是「删掉图会不会丢信息」。
「我的联想」为何要单独分区并标明可删：这与 §10 同源——
原始材料与派生知识必须可分离。删掉联想，这条剪藏仍是完整可用的原始记录；
若把联想混进要点，日后就分不清哪些是材料说的、哪些是你想的。
跨端说明
剪藏材料无论来自手机端还是 PC 端，一律走上述同一流程。
若手机端内容已同步到 PC（资料库、对话记录等），按同一规则处理；
未同步也无妨——在 PC 端直接发送图片或链接即可触发同样的 Ingest 流程。
Agent 工作准则（八步）
理解 → 分类 → 查重 → 判断知识动作 + 原始记录处置 → 必要时派生 → 执行 → 验证 → 记录
记录追加到 05_SYSTEM/Logs/ingest-log.md：时间、输入文件、Knowledge Action、
Record Disposition、目标路径、结果、原因。
铁律（红线）
- 创建前必须查重。 已有对象用
[[wikilink]]链接，不新建重复卡片。 - 不得虚构。 不编造来源、日期、作者、人物关系、章节、页码。
- 不能确认的信息：不猜。 留 Inbox 或标为「待补链接」；不为消除断链而删改或虚构。
- 一个知识对象 = 一篇笔记。 同一对象的多份材料合并进同一张卡。
- Reading 绝不因派生 Concept/Idea/Synthesis 而消失或被精简。
- 来源是 Book 绝不自动等于 Reading。 判断依据是材料角色与用户保存意图，而非出处。
- 移动文件 ≠ 修改内容。 禁止无理由删除或覆盖用户重要文字。
- 用户选择的模板优先于 AI 推断。
- 潜在参与者不得由 AI 自动写入（须用户确认）。
- Legacy 旧卡可补充类型/标签/可确认链接，不得猜历史创建日期或未提供的来源。
Frontmatter 规范
| 字段 | 类型 | 说明 |
|---|---|---|
| 类型 | text | 英文类型名（Concept / Project / …） |
| 版本 | text | 必须带引号，如 "1.0" |
| 创建日期 | date | YYYY-MM-DD |
| 更新日期 | date | YYYY-MM-DD |
| 迁移状态 | text | native / legacy |
| 标签 | tags | 列表 |
- Project 额外
状态（想法/待开始/进行中/暂停/已完成/已取消，中文为准）。 - Person 额外
人物类型（如contact）。 - 文本字段一律加引号：
版本: "1.0"。不加引号时 YAML 会把1.0解析成数字，与types.json冲突并触发属性警告。 - 字段类型必须与
.obsidian/types.json一致。 - 模板只影响以后新建的笔记，不回改既有笔记。
- 文件名即笔记标题，新建的正式卡片正文不再重复写
# 标题。
分层采纳建议
不是每个人都需要全套。按用户的实际场景取舍：
| 层级 | 内容 | 何时需要 |
|---|---|---|
| 核心（建议都遵守） | §1 原则、§2 类型、§4 Ingest 双维度、§9 查重与链接、§15 Agent 八步、§20 frontmatter | 任何知识库 |
| 进阶 | §5–§7 Reading / Shining / Archive 路由、§16 Book 结构化 | 有读书笔记、摘录、素材归档需求 |
| 可选 | §12 Project 状态机、§19 Synthesis 四域、§13 Lint 与日志 | 做项目管理或需要定期体检 |
移动 / 重命名笔记
移动笔记会打断所有指向它的 [[wikilink]]。处理方式：
- 若环境可用
obsidian-cli，用obsidian-cli move "旧路径" "新路径"（会自动更新全库链接）。 - 若不可用（常见：Windows 上被 Device Guard 等策略阻止），用脚本替代：
移动文件后扫描全库.md，替换[[旧名]]、[[旧名|别名]]、[[旧名#章节]]、
[[文件夹/旧名]]、![[旧名]]、[文字](路径.md)。 - 无论哪种方式，先 dry-run 预览再落地，并确认不覆盖已存在的目标。
参考
references/NEXUS-constitution.md— 完整宪法 21 节（原则、类型、Ingest、Book/Reading、frontmatter、日志与视图）references/adaptation.md— 适配指南：从零搭建 / 迁移已有库 / 最小可用版本
