你写的每一条规则，都是一次和 AI 讲清楚边界
一只阿木木约 19 分钟Module 3｜CLAUDE.md
你写的每一条规则，都是一次和 AI 讲清楚边界
这一讲只讲一个文件。但这一个文件，决定了整套系统是在为你工作，还是在随机漫步。
写在前面
我想先问你一个问题。
假设你雇了一个助理。
第一天，你什么都没交代，直接说："帮我整理文件吧。"
然后你出去开会了。
两小时后回来，你发现——
他把你按日期排列的合同，改成了按客户名字排列。 他认为"草稿"文件夹没必要，都归并到"文件"里了。 他创建了一个你从来没见过的分类系统，逻辑只有他自己懂。
你生气吗？
不应该。因为你没告诉他规则。
现在把这个场景换成 AI。
你喂了一堆文章进知识库，运行了 /wiki-ingest。
AI 创建了一堆页面。
有的页面你觉得很好，有的你觉得莫名其妙。 有些链接建立得很准确，有些你完全不理解为什么要关联。 有些标签非常合理，有些多到你不知道从哪里开始过滤。
问题出在哪里？
不是 AI 不够聪明。
是你没有告诉它，你的系统的规则是什么。
CLAUDE.md，就是你给 AI 的那份规则说明书。
它不是一个可选的配置文件。
它是整套系统能够稳定工作的前提。
3.1 CLAUDE.md 到底做了什么
我来说清楚它的工作机制。
每次你打开 Claude Code，指向你的 Vault 目录——
它做的第一件事，是读 CLAUDE.md。
不是你的笔记，不是你的 wiki 页面，不是你的项目文档。
是 CLAUDE.md。
这个文件告诉 AI：
这个 Vault 是用来干什么的 文件夹结构是怎样的，各自的用途是什么 各种类型的页面应该是什么格式 链接应该在什么情况下建立，什么情况下不建立 标签体系是什么 遇到矛盾内容怎么处理 有哪些 Skills 可以调用
读完 CLAUDE.md，AI 就从一个通用助手，变成了一个了解你系统的专业协作者。
没有 CLAUDE.md 是什么体验
我来描述一下没有这个文件的状态。
每次开启新会话，你需要重新解释：
"我的 Vault 是这样组织的，raw 放原始输入，wiki 放知识，你帮我处理文章的时候请把概念提取出来放到 wiki 里，用 wikilinks 格式……"
你解释完，AI 这次会话里表现还不错。
关掉，第二天重开，什么都不记得了。
你再解释一次。
三个月后，你发现自己每次会话的前十分钟都在重复这个过程。
更麻烦的是——
就算你每次都解释，因为你的表达每次略有不同，AI 每次的行为也略有不同。
你的 wiki 页面风格不统一，标签体系混乱，链接质量参差不齐。
一致性，是靠规则保障的，不是靠每次都说清楚保障的。
CLAUDE.md 解决的，就是这个问题。
一个类比
如果 Vault 是一家公司，
CLAUDE.md 就是这家公司的员工手册 + 操作规范 + 设计系统。
新员工（每次新会话的 AI）入职第一天，先读手册。
读完，他知道：公司做什么、规则是什么、遇到不确定情况怎么处理。
你不需要每次都从头解释。
文件即规则，规则即一致性。
3.2 CLAUDE.md 的五个模块
一个可以实际运转的 CLAUDE.md，需要包含五个部分。
我逐一拆解，每个部分讲：是什么、为什么需要、怎么写。
模块一：系统身份
是什么：
用 2-3 句话，说清楚这个知识库是谁的、做什么用的、服务于什么目标。
为什么需要：
AI 处理任何内容之前，需要知道"过滤标准"。
同一篇关于机器学习的文章，一个产品经理的知识库需要提取的东西，和一个工程师的知识库需要提取的东西，完全不同。
如果你不告诉 AI 你的视角，它会用一个通用视角处理——提取什么都有，但什么都不够深。
怎么写：
Markdown
## 系统身份我是 [你的名字]，主要工作在 [领域]。
这个知识库服务于 [你的具体目标]。
在处理任何内容时，优先提取和 [你的核心关注点] 相关的框架和原则。
一个好的例子：
Markdown
## 系统身份我是一个独立产品顾问，服务于早期创业公司。
这个知识库帮助我在做产品策略和用户研究时调用积累的框架和案例。
处理内容时，优先提取：可用于决策的框架、真实案例中的反模式、
以及可以直接给创业者讲的原则。
一个不够好的例子：
Markdown
## 关于我我对很多领域都感兴趣，喜欢学习新东西。
这个版本的问题：没有告诉 AI 任何过滤标准。AI 不知道"什么是对你有用的"，只能给你通用处理。
模块二：Vault 结构
是什么：
描述每个文件夹的用途、命名规范、文件归属规则。
为什么需要：
AI 需要知道把什么放在哪里。
"这篇文章处理完，概念页面放 wiki/concepts/，案例放 wiki/cases/，还是全部放 wiki/ 根目录？"
如果你没定义，AI 会做出它认为合理的选择。
但"合理"不等于"符合你的系统"。
怎么写：
Markdown
## Vault 结构### 目录说明
- raw/ 原始输入，只读，永不修改
- wiki/ AI 维护的知识库（见下方格式规范）
- concepts/ 概念和框架页面
- cases/ 案例和实例页面
- people/ 人物页面（作者、专家）
- books/ 书籍页面
- inbox/ 待处理碎片，零门槛输入
- projects/ 项目文档，由人主导
- active/ 进行中的项目
- archive/ 已完成的项目
### 命名规范
- Wiki 页面：全小写，用连字符分隔，描述性命名
例：product-market-fit.md，not-pmf.md
- 项目文档：日期前缀，例：2024-01-project-name.md
- 草稿内容：draft- 前缀，例：draft-framework-analysis.md
模块三：页面格式规范
是什么：
定义不同类型的 wiki 页面，应该包含哪些字段，按什么顺序排列。
为什么需要：
这是 CLAUDE.md 里最容易被低估的部分。
没有格式规范，你的 wiki 里每个页面结构都不一样。
有的有定义有的没有，有的有应用场景有的直接就是一堆笔记。
等你的 wiki 积累到 100 页，找信息会变成一场噩梦。
更关键的是：
统一的格式让 AI 在处理新内容的时候，知道要填什么字段，提取什么维度的信息。
格式本身就是提取标准。
怎么写：
Markdown
## 页面格式规范### 概念页面格式（wiki/concepts/）
---
title: [概念名称]
type: concept
tags: [类型标签] [领域标签]
source: [来源]
created: [日期]
updated: [日期]
---
## 一句话定义
[用自己的话，不超过两句话]
## 核心原则
[3-5 条可操作的原则，每条一行]
## 适用场景
[什么情况下调用这个概念？]
## 反模式
[使用这个概念时，常见的错误是什么？]
## 关联概念
[[ ]] [[ ]] [[ ]]
## 来源
[书名 / 文章名 + 具体章节或段落]
---
### 书籍页面格式（wiki/books/）
---
title: [书名]
author: [作者]
type: book
tags: [领域标签]
skill: [对应的 skill slug，如果有]
read-date: [完成日期]
---
## 核心主张
[这本书的中心论点，2-3 句话]
## 关键框架
[书中最重要的 2-3 个框架，各一句话说明]
## 最有价值的章节
[哪几章值得重读？]
## 关联书籍
[[ ]] [[ ]]
模块四：链接规则
是什么：
定义什么情况下建立 wikilinks，什么情况下不建立。
为什么需要：
这是 CLAUDE.md 里最容易被忽视但影响最大的一条规则。
没有链接规则，AI 会在任何两个概念"看起来有关系"的时候建立链接。
结果就是——每个页面都有十几条链接，全是浅层关联，打开 Graph View 看起来密密麻麻，但实际上没有任何真正有价值的洞见。
链接的价值，在于稀缺性。
只有真正重要的关联，才值得变成 wikilink。
怎么写：
Markdown
## 链接规则### 什么时候建立链接
只在满足以下条件之一时建立 [[wikilink]]：
1. 理解概念 A，改变了对概念 B 的理解
2. 两个概念在同一个决策场景中会同时被调用
3. 一个概念是另一个概念的前提或延伸
### 什么时候不建立链接
- 仅仅因为两个概念"都属于同一领域"
- 仅仅因为文章里提到了这个词
- 已经有超过 8 个链接的页面，不再新增
### 链接质量要求
每建立一个链接，在链接旁边用注释说明原因：
[[相关概念]] <!-- 原因：理解 X 的前提 -->
模块五：标签体系
是什么：
预定义你会用到的所有标签，每个标签的含义和使用条件。
为什么需要：
标签是你在 wiki 里做搜索、过滤、筛选的主要工具。
如果标签是 AI 自由发挥的，你最终会有几十个标签，每个用了一两次，没有任何过滤价值。
标签必须预定义，而且数量要少。
怎么写：
Markdown
## 标签体系### 内容类型标签（每个页面必须且只能有一个）
- #framework 可以指导决策的思维框架
- #principle 单条可操作的原则
- #case-study 真实案例或实例
- #concept 抽象概念，暂无直接操作性
- #tool 具体的工具或方法
### 状态标签（可选，描述完整程度）
- #seed 刚创建，只有基本定义
- #growing 有内容但还不完整
- #evergreen 相对稳定，经过多次使用验证
### 领域标签（根据你的领域选择，最多选用 5 个）
- #product-strategy
- #user-research
- #business-model
- #team-dynamics
- #decision-making
### 标签使用规则
- 每个页面：1个类型标签 + 0-1个状态标签 + 0-2个领域标签
- 不得创建预定义列表之外的标签
- 如果需要新标签，先更新 CLAUDE.md，再使用
3.3 动手：写你的第一版 CLAUDE.md
我们来写。
不是从空白开始，而是从一个模板开始——然后逐字理解，逐字修改成你自己的。
打开 ~/knowledge/vault/CLAUDE.md，替换成以下内容（用你自己的信息填充括号里的部分）：
Markdown
# CLAUDE.md
> 这是我的个人知识管理系统的操作说明。
> 每次开启新会话，请先完整阅读这个文件。---
## 系统身份
我是 [你的名字]，主要工作在 [你的领域]。
这个 Vault 服务于 [你的核心目标，一句话]。
在处理任何内容时，优先提取和 [你最关心的视角] 相关的框架和洞见。
---
## Vault 结构
- raw/ 原始输入，只读，永远不修改
- wiki/ AI 维护的知识库
- concepts/ 概念和框架页面
- cases/ 案例页面
- books/ 书籍页面
- inbox/ 零门槛输入，待处理碎片
- projects/ 项目文档，人主导，AI辅助
- .claude/ 系统配置，不处理为知识内容
---
## 页面格式规范
### 概念页面（wiki/concepts/）
必须包含字段：一句话定义、核心原则（3-5条）、适用场景、反模式、关联概念、来源
### 书籍页面（wiki/books/）
必须包含字段：核心主张（2-3句）、关键框架（最多3个）、最有价值章节、关联书籍
---
## 链接规则
建立 [[wikilink]] 的条件（必须满足其中一条）：
1. 理解 A 改变了对 B 的理解
2. A 和 B 在同一决策场景中同时被调用
3. A 是 B 的前提或延伸
不建立链接的情况：
- 仅因为"都属于同一领域"
- 仅因为文章里提到了这个词
- 单个页面链接已超过 8 个
---
## 标签体系
### 类型标签（必选其一）
#framework #principle #case-study #concept #tool
### 状态标签（可选）
#seed #growing #evergreen
### 领域标签（最多 2 个，从以下选择）
[填入你的 3-5 个核心领域标签]
### 规则
- 不创建预定义之外的标签
- 需要新标签，先更新此文件，再使用
---
## 处理规则
1. 新内容先进 raw/，通过 /wiki-ingest 处理
2. 不直接编辑 wiki/ 文件，除非有明确原因
3. 每次处理完内容，更新 wiki/log.md
4. 发现矛盾内容，在相关页面用 [!contradiction] 标注，不自动删除
---
## 可用 Skills
- /wiki-ingest 摄入新内容到知识库
- /process-inbox 处理 inbox 碎片
- /lint-wiki 知识库健康检查
- /daily-review 每日知识回顾
- /book-to-skill 将书转化为可调用 Skill
---
## CLAUDE.md 版本记录
### v1.0 - [日期]
初始版本，基础结构建立
保存。
这是你的 v1.0。
现在不要试图把它写得"完美"。
完美的 CLAUDE.md 不是想出来的，是用出来的。
3.4 CLAUDE.md 的迭代实验：故意找崩溃点
这一步是本讲最重要的实践环节。
我要你故意让系统崩溃。
然后从崩溃里学习。
准备工作
找三篇不同类型的内容放入 raw/：
一篇技术类文章（比如关于架构设计、编程范式之类） 一篇商业类文章（案例分析、商业模式之类） 一篇相对"杂"的内容（访谈记录、播客要点、或者一段演讲笔记）
运行摄入，观察结果
Bash
cd ~/knowledge/vault
claude
/wiki-ingest raw/article-1.md
/wiki-ingest raw/article-2.md
/wiki-ingest raw/article-3.md
每处理完一篇，先不要立刻看输出。
等三篇都处理完，然后逐一检查 wiki/ 里生成的文件。
带着这五个问题检查
问题一：格式一致吗？
三篇文章处理出来的 wiki 页面，结构是否统一？
如果某个页面缺少你在 CLAUDE.md 里定义的字段，或者多了一些你没定义的字段——说明你的格式规范不够精确。
问题二：标签用得对吗？
AI 使用的标签，是否都在你预定义的列表里？
如果出现了新标签，两种可能：
AI 没有严格遵守规则（需要在 CLAUDE.md 里加强约束语言） 你的标签列表确实有遗漏（需要更新标签体系）
问题三：链接建立得有意义吗？
打开任意一个有 wikilinks 的页面，逐一看每条链接。
每条链接你都能说出"为什么要建这个连接"吗？
如果有"完全不理解为什么要连"的链接——说明你的链接规则不够精确。
问题四：内容归类对吗？
三种不同类型的文章，AI 把概念分别放在了哪个子目录？
是否符合你的 Vault 结构定义？
问题五：有没有内容"不知道该怎么处理"就被扔掉了？
有些内容比较特殊，不完全符合你定义的任何类型。
AI 是怎么处理它的？
记录崩溃点，更新 CLAUDE.md
把你在上面五个问题里发现的每一个不满意之处，写下来：
Markdown
## 崩溃点记录### 崩溃点 1
现象：[AI 做了什么]
根本原因：[CLAUDE.md 缺少哪条规则]
修复方案：[在 CLAUDE.md 里加什么]
### 崩溃点 2
...
然后更新你的 CLAUDE.md，在版本记录里写：
Markdown
### v1.1 - [日期]
- 新增：[你加了什么规则，原因是什么崩溃点]
- 修改：[你修改了什么，为什么]
这个迭代循环的意义
我要解释一下，为什么这一步这么重要。
你在做的，是把你对"好的知识管理"的隐性认知，变成显性规则。
每一个崩溃点，都在告诉你：你心里其实有一个标准，但你从来没有把它说清楚。
当 AI 没有达到你的标准，你才意识到那个标准的存在。
然后你把它写进 CLAUDE.md。
下次，AI 就会按这个标准工作。
这是整个系统里最具价值的学习过程。
不是学 AI 怎么用，而是学清楚自己对知识管理的真实需求。
3.5 从模糊指令到精确约束
这一节讲一个实战技巧：
如何把模糊的感受，变成 AI 可以执行的精确规则。
一个常见的场景
你运行了 wiki-ingest，看到生成的页面，感觉"不太对，但说不清哪里不对"。
这个"说不清"，是需要解决的。
因为你说不清，就无法告诉 AI 该怎么改，下次它还是一样。
三步把感受变成规则
第一步：描述现象
不要说"不太对"，要说具体发生了什么。
❌ "这个页面感觉不够好" ✅ "这个页面的'一句话定义'写了三行，而且用了很多专业术语，我完全读不懂自己的知识库"
第二步：找到根本原因
这个现象，是 CLAUDE.md 缺少了哪条规则导致的？
"因为 CLAUDE.md 里没有规定'一句话定义'的长度上限，也没有要求必须用我能理解的语言写。"
第三步：写出精确规则
把根本原因翻转，就是规则。
"一句话定义：必须不超过 25 字，必须用我自己能直接说出来的话，不使用原文术语。"
精确约束 vs 模糊指令：对比实验
我来给你看两个版本的 CLAUDE.md 片段，以及它们的输出效果：
版本 A（模糊指令）：
Markdown
处理文章时，提取重要的概念，用清楚的语言写，
建立有意义的关联。
版本 B（精确约束）：
Markdown
处理文章时：
1. 每篇文章最多提取 3 个独立概念页面（不是越多越好）
2. 每个概念的定义必须：不超过 25 字，用我能直接说出口的语言
3. 只建立满足以下条件的链接：
理解 A 改变了对 B 的理解，且这两个概念我会在同一个工作场景中同时调用
4. 如果一个概念在 wiki/ 里已经存在，更新现有页面，不创建新页面
版本 A 的输出：每次不一样，质量飘忽，你不知道下次会得到什么。
版本 B 的输出：高度一致，你知道会得到什么，不满意的部分非常明确。
约束越精确，输出越可预测。
这不是在限制 AI。
这是在帮 AI 更好地服务你。
3.6 CLAUDE.md 的几个常见误区
在你自己迭代 CLAUDE.md 的过程中，有几个坑我见过最多。
提前说清楚，省得你踩一遍再回来改。
误区一：写太多废话，没有可执行的规则
Markdown
# ❌ 这样没有用
这个知识库是我的第二大脑，帮助我成长和学习。
我希望 AI 能够理解我的思维方式，帮我建立深度的知识关联，
让知识产生复合增长的效果……
这段话读起来很好，但 AI 无法从中提取任何具体的执行指令。
每一条规则，必须能被转化成一个"是/否"的判断或者一个具体的操作步骤。
误区二：规则之间有矛盾
Markdown
# ❌ 这样会让 AI 不知道怎么做
处理文章时，尽量多提取概念，确保不遗漏重要内容。
每篇文章最多提取 3 个概念页面。
第一条说尽量多，第二条说最多 3 个。矛盾。
AI 会选择最近看到的那条，或者随机选一条。
CLAUDE.md 里任何两条规则都不应该有冲突。
误区三：没有处理"边界情况"的规则
Markdown
# ❌ 这个缺失会导致问题
新内容先进 raw/，处理后进 wiki/。
如果来了一篇既有概念又有案例的文章，概念部分去 wiki/concepts/，案例部分去 wiki/cases/？
还是整篇文章按主类型归入一个地方？
如果你没定义，AI 会做出它认为合理的选择——但不一定符合你的预期。
每个"如果……那么……"，都应该在 CLAUDE.md 里有一个答案。
误区四：写完就不改
CLAUDE.md 不是一个写完就可以存档的文件。
它应该随着你的使用不断进化。
每个月回顾一次，问自己：
上个月有没有出现让我不满意的 AI 输出？ 那个不满意，是哪条规则缺失或不精确导致的？ 有没有我的使用习惯变了，但 CLAUDE.md 还是旧规则？
CLAUDE.md 的版本记录，就是你的知识管理系统进化史。
3.7 一个完整的 CLAUDE.md 实例
我来给你看一个相对完整的例子。
这是一个独立顾问、主要服务 B2B SaaS 产品团队的人的 CLAUDE.md。
你不是要复制它，而是用它来校准：
你自己的 CLAUDE.md，和这个相比，差了什么？
Markdown
# CLAUDE.md
> 版本 1.3 | 上次更新：2024-03-15---
## 系统身份
我是一名独立产品顾问，主要服务于 B2B SaaS 领域的早期和成长期公司。
这个知识库帮助我在产品策略咨询、用户研究设计和团队 Workshop 中调用积累的框架和案例。
优先提取：可以直接在 40 分钟 Workshop 内使用的框架；B2B 场景中的真实反模式；
以及能帮助非技术创始人做产品决策的原则。
---
## Vault 结构
- raw/ 只读，原始输入
- wiki/
- concepts/ 框架和概念（#framework #concept）
- cases/ 真实案例（#case-study）
- people/ 作者、创始人（#person）
- books/ 书籍页面（#book）
- synthesis/ 跨来源的综合分析（#synthesis）
- inbox/ 零门槛碎片
- projects/
- active/ 进行中的客户项目
- archive/ 已完成项目
- templates/ 可复用的模板
- .claude/
- commands/ 自定义 Slash Commands
---
## 页面格式规范
### 框架/概念页面（wiki/concepts/）
---
title:
type: concept | framework
tags: [类型] [领域]
source:
---
## 一句话定义
[不超过 25 字，用能直接说出口的语言]
## 核心原则
- [原则 1：必须是可操作的，"做X而不是Y"的形式]
- [原则 2]
- [最多 5 条]
## 何时用
[在什么具体场景下调用这个框架？]
## 何时不用
[这个框架的局限性在哪里？]
## 实际案例
[如果来源里有，摘一个最具体的例子]
## 相关框架
[[]] <!-- 原因：[一句话说明关联] -->
## 来源
[书名/文章名 + 章节/链接]
---
### 案例页面（wiki/cases/）
---
title:
type: case-study
tags: #case-study [领域]
company:
outcome: success | failure | mixed
---
## 情境
[背景：公司、阶段、面临的挑战]
## 关键决策
[做了什么，为什么这样做]
## 结果
[发生了什么]
## 可提取的模式
[这个案例支持或反对哪个框架？]
## 相关框架
[[]]
---
## 链接规则
### 建立链接的条件（必须满足其中一条）
1. 理解 A，改变了我对 B 的理解方式
2. A 和 B 在同一个决策场景中会被同时调用
3. A 是理解 B 的前提知识
### 不建立链接的情况
- 两个概念"都属于产品管理"这种宽泛关联
- 仅因为文章里提到了这个词
- 一个页面的外链已经超过 6 条
### 链接格式
[[页面名]] <!-- 原因：[一句话说明为什么建这个链接] -->
---
## 标签体系
### 内容类型（每页必须且只能选一个）
#framework 有名字的思维框架
#principle 单条可直接执行的原则
#concept 抽象概念，暂无操作性
#case-study 真实案例
#tool 具体的工具或方法
#synthesis 多来源综合分析
#book 书籍页面
#person 人物页面
### 状态（可选，最多一个）
#seed 刚创建，只有基本内容
#growing 有内容但还在发展
#evergreen 经过实际使用验证，相对稳定
### 领域（最多 2 个）
#product-strategy
#user-research
#b2b-saas
#team-dynamics
#decision-making
### 规则
- 不使用预定义之外的标签
- 需要新标签，先更新此文件的标签列表，再使用
- 每个页面：1个类型 + 0-1个状态 + 0-2个领域
---
## 处理规则
1. 摄入原则：每篇文章最多创建 3 个独立概念页面
2. 存在即更新：如果 wiki/ 里已有相关页面，更新现有，不创建重复页面
3. 矛盾标注：发现和现有内容矛盾时，在相关页面顶部加 [!contradiction] 标注，
列出矛盾点，不自动删除任何一方
4. 不确定时不处理：如果内容类型不清晰，放入 inbox/ 等待人工判断
5. 日志要求：每次摄入操作完成后，在 wiki/log.md 追加一条记录
---
## 可用 Skills
- /wiki-ingest [file] 摄入单个文件
- /process-inbox 处理 inbox/ 的所有内容
- /lint-wiki 知识库健康检查
- /daily-review 每日回顾
- /weekly-synthesis 每周综合分析
- /book-to-skill [pdf] 将书转为 Skill
---
## 版本记录
### v1.3 - 2024-03-15
- 修改：案例页面新增 outcome 字段（发现之前无法筛选成功/失败案例）
- 新增：链接格式要求加入注释原因（发现积累了很多不知道为什么建的链接）
### v1.2 - 2024-02-20
- 修改：类型标签从 10 个减少到 8 个，合并了重叠的标签
- 新增：处理规则第 4 条（发现 AI 会对格式不明确的内容乱归类）
### v1.1 - 2024-01-30
- 修改：一句话定义加入字数限制（发现总是写很长）
- 新增：链接数量上限规则（发现部分页面链接过多）
### v1.0 - 2024-01-15
初始版本
注意这个 CLAUDE.md 的几个特点：
每一条规则后面都有括号说明"为什么"。
不是给 AI 看的，是给你自己看的。
六个月后你回来看这个文件，你能知道每条规则是怎么来的。
版本记录写的不是"修改了什么"，而是"因为什么崩溃点做了这个修改"。
这让你的 CLAUDE.md 成为一份可学习的文档，不只是一份配置文件。
3.8 CLAUDE.md 和 Vault 里笔记的关系
有一个边界需要说清楚。
你的 Vault 是用来存你的知识的。CLAUDE.md 是用来定义系统规则的。
不要把两者混在一起。
一个容易犯的错误
有些人会把学到的内容直接写到 CLAUDE.md 里：
"我读了精益创业，学到了 MVP 的概念，以后 AI 处理内容的时候要注意……"
不对。
MVP 的概念应该在 wiki/concepts/mvp.md 里，通过 book-to-skill 或 wiki-ingest 生成。
CLAUDE.md 只放系统规则，不放知识内容。
另一个容易犯的错误
有些人会把 AI 的输出（计划、总结、建议）存回 Vault：
"让 AI 帮我写了一份项目计划，就存在 wiki/ 里吧。"
这也不对。
wiki/ 是你对外部世界的知识的提炼。
AI 基于你的知识生成的东西，如果不是真正的知识内化，存进去会污染你的知识库。
规则：只有经过你判断认可的内容，才能进入 wiki/。
AI 生成的草稿，先放 projects/ 或 inbox/，确认有价值再迁移。
模块作业
作业一：完成你的第一版 CLAUDE.md（必做）
基于本讲的五模块框架，写出你自己的第一版。
不求完美，但五个模块都要有内容：系统身份、Vault 结构、页面格式、链接规则、标签体系。
作业二：三篇内容摄入 + 找三个崩溃点（必做）
准备三篇不同类型的内容，运行 wiki-ingest，检查输出。
带着 3.4 节的五个问题，找出至少三个"不满意但能说清楚原因"的崩溃点。
把崩溃点转化为规则，更新到 CLAUDE.md v1.1。
在版本记录里，写清楚每个修改的原因。
作业三：写一份"规则背后的逻辑"（选做但推荐）
在 inbox/ 里创建一个文件：claude-md-decisions.md
针对你的 CLAUDE.md 里每一条主要规则，写一句话说明：
"这条规则是因为 [什么崩溃点] 加进来的，它解决的是 [什么问题]。"
这份文件，六个月后你会非常感谢自己写了它。
本讲总结
text
这一讲你做了什么：□ 写了你的第一版 CLAUDE.md
□ 运行了三次摄入，找到三个崩溃点
□ 把崩溃点转化为规则，完成了 v1.1
这一讲你应该建立的认知：
CLAUDE.md 不是配置文件，是你对知识管理需求的显性化。
每一个崩溃点，都是你的隐性标准在告诉你它的存在。
把它写下来，AI 才能按你的标准工作。
约束不是限制——
约束是让输出可预测的唯一方式。
可预测，才能信任。
能信任，这个系统才真的为你工作。
下一讲，我们开始讲 book-to-skill。
你刚刚建立的 CLAUDE.md，会在第一次真正喂书之后，再迭代一次。
因为只有当你第一次看到一本书被拆解成 Skill，你才会知道——你的 wiki 页面格式和 Skill 的格式，需不需要协调。
带着这个问题进入 Module 4。
**Module 3认知破点：约束是让 AI 输出可预测的唯一方式；CLAUDE.md 是你对知识管理需求的显性化，不是配置文件
我是【一只阿木木】——公开建造我的 AI 第二大脑。
普通人如何用 AI 搭建自己的知识操作系统？
一个程序员出身的知识工作者，公开记录自己如何用 AI 工具搭建个人知识系统、把读过的书和做过的项目变成可复用资产的全过程。
欢迎加入行动营👇获取更多Obsidian + AI数字大脑实践
我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统
欢迎关注【一只阿木木】🌊