核心用法
KG笔记法是一套面向Obsidian知识管理系统的结构化治理框架，通过"概念-某物-Skill-关系"四种笔记类型构建知识图谱。核心操作依赖kg系列命令：
- `kg "笔记名.md"`：完整治理流程（①-⑥检查→⑦查重→执行清单→⑧收尾）
- `kg 完善`：在基础流程上增加网络信息补全（⑨补完计划）
- `kg 检查`：生成清单后询问用户确认再执行
- `kg 查看`：分层加载笔记（L0 frontmatter/L1核心段落/L2全文）
系统强制使用双清单机制：任务开始前生成{任务名}_执行清单.md（预判所有操作步骤）和{任务名}_检查清单.md（极简进度跟踪0:1:0...），每步完成后立即patch更新状态，支持断点续接。
显著优点
1. 类型系统清晰：四种笔记各司其职——概念（抽象定义）、某物（具体实体）、Skill（可执行步骤）、关系（双向链接载体），避免标签混乱
2. 自动化治理链路：①内容检查拆分→②分类匹配→③名称规范→④图片保护→⑤直链检查→⑥关联处理→⑦查重→⑧收尾，9步闭环减少人工判断
3. 分层加载省token：L0仅读YAML frontmatter，L1按需加载核心段落，L2全文兜底，大幅降低大模型上下文消耗
4. 强制清单机制：步0检查同名任务防覆盖、步5检查其他未完成任务防遗漏，设计层面规避"做了A忘B"的系统性风险
5. 关系中转设计：主体笔记禁止直链，必须通过"A - 关系 - B"文件中转，确保图谱可遍历、关系可语义化命名
潜在缺点与局限
1. 学习曲线陡峭：R4/R5等规则嵌套、L0/L1/L2分层逻辑、关系笔记的"一句双链"格式，新手易踩"frontmatter冗余""直链未补先删"等陷阱
2. 过度结构化成本：小型笔记库（<500篇）应用此方案可能得不偿失——双清单维护、关系文件膨胀带来的管理开销高于收益
3. 网络依赖局限：⑨补完计划依赖外部搜索，对离线环境或专业领域（需付费数据库）支持有限
4. 命名冲突敏感：文件名变更触发连锁重命名，跨平台路径差异（大小写/特殊字符）可能导致清单执行失败
5. Agent执行风险：文件操作（mv/patch/delete）在检查清单状态误判时可能造成数据丢失，虽有多处校验但仍需用户最终确认
适合人群
- Obsidian重度用户，笔记数量>1000且增长迅速
- 知识工作者需要构建可检索的概念网络（学术研究、技术文档、项目知识库）
- 团队协作场景需统一笔记规范
- 愿意投入前期治理成本换取长期检索效率的人群
常规风险
| 风险等级 | 场景 | 缓释措施 |
|:-------|:-----|:--------|
| 高 | 未加载skill直接执行`kg`命令 | 系统强制`skill_view`前置，但用户绕过机制仍可能触发 |
| 高 | 跳过清单直接文件操作 | 流程设计层面禁止，但Agent异常状态下可能违规 |
| 中 | 关系笔记两端主体缺失 | ⑥关联处理有分支逻辑，但"两端都不是概念→不改动"可能遗留孤儿关系 |
| 中 | 批量任务中断后清单残留 | 步0续接检查，但用户手动删除清单文件会导致状态丢失 |
| 低 | 图片链接失效未替换 | ④图片保护仅标记不自动修复，需人工介入 |