知识库的价值，只有在真实问题面前才能被感知
一只阿木木约 22 分钟Module 8｜项目实战
知识库的价值，只有在真实问题面前才能被感知
你已经建了系统，调好了节奏，通过了联调测试。但所有这些，只有在一个真实项目里被用起来，才算真正完成了这门课。这一讲，我们来做那件事。
写在前面
我想先问你一个问题。
你有没有过这种经历——
学完了一套方法论，觉得很有道理，然后回到工作里，完全没有用上。
不是因为方法论不好。
是因为你从来没有在真实的压力下用过它。
真实的压力是什么？
有截止日期，有真实的利益相关方，有你不得不交出去的产出物，有你自己会为结果负责的决策。
在这种压力下用过一次，比在"练习场景"里用十次，理解深十倍。
这一讲，我要让你用真实项目来验证整套系统。
不是一个"设计一个假想的产品"这种练习题。
是你现在真正在做的事，或者你下个月必须完成的事。
我知道这听起来有一点难。
因为你可能觉得："我的知识库还没够好，先再积累一段时间……"
停。
知识库永远不会"够好"才能用。
它是在用的过程中变好的，不是攒到某个程度才能用。
如果你等它"够好"，你会永远在等。
现在，带着你现在的知识库，进入这个项目。
8.1 项目选择：这是整讲最重要的一个决定
选什么项目，决定了这一讲的价值有多大。
我来说清楚选择标准。
三个必要条件
条件一：真实性
这个项目必须是你真正在做的，不是"为了练习设计的"。
真实项目有真实的约束：真实的信息缺口、真实的利益相关方、真实的不确定性。
这些约束，才能真正测试知识库能做什么、不能做什么。
假想项目没有这种约束，你会不自觉地"为知识库设计问题"，而不是"用知识库解决问题"。
条件二：跨领域性
这个项目最好需要你调用不止一个领域的知识。
比如：一个产品设计项目，需要同时调用用户研究、商业模式和技术可行性的知识。
跨领域性，能让你真正感受到知识库的关联价值——
单领域的问题，就算没有知识库，靠专业经验也能解决。
跨领域的问题，知识库里的连接才能发挥最大的作用。
条件三：有明确的交付物
这个项目必须产出一个具体的东西——文档、方案、分析报告、代码、演讲稿——
某个你可以拿出来、让别人评价的东西。
没有交付物，你无法判断"知识库帮了多少忙"。
有了交付物，你能做一个很直接的比较：这份东西，比我没有知识库的时候做的，有什么不同？
好的项目类型
text
✅ 产品 PRD 或功能设计文档
✅ 技术选型报告
✅ 商业计划或策略分析
✅ 研究综述或行业分析
✅ 课程大纲或培训方案
✅ 团队工作坊设计
✅ 个人年度复盘
✅ 一篇重要的长文
不好的项目类型
text
❌ "设计一个 AI 产品"（太宏大，边界不清）
❌ "学习某个技术"（过程没有交付物）
❌ "整理我的知识库"（这是系统维护，不是项目）
❌ 你三个月后才会真正做的事（太遥远，缺乏真实压力）
现在做这个选择
不要往下读，先停下来。
在你的 inbox/ 里创建一个文件：project-choice.md。
写下：
Markdown
# 我选择的项目## 项目名称
[一句话描述]
## 交付物
[具体要产出什么，什么格式]
## 截止时间
[真实的截止日期]
## 为什么选这个
- 真实性：[为什么它是真实的]
- 跨领域性：[需要哪几个领域的知识]
- 交付物：[交付物是什么]
## 我对知识库的预期
[我猜测知识库会在哪些地方帮到我，哪些地方帮不了]
写完之后再继续。
8.2 项目启动前：知识准备的四个步骤
你不能直接冲进去做项目。
在动手之前，有四个准备步骤——它们会决定你整个项目过程里，知识库能发挥多大的作用。
步骤一：绘制项目的知识地图
打开 Claudian，问一个问题：
text
我要做一个项目：[你的项目描述]
交付物是：[具体交付物]请帮我分析这个项目需要哪些领域的知识，
以及每个领域里最关键的几个核心问题。
生成一份"项目知识地图"。
你会得到一张列表：这个项目需要哪些知识，分别用来解决什么问题。
这张地图，是接下来所有步骤的导航。
步骤二：盘点知识库的覆盖情况
有了知识地图，接下来：
text
@wiki/
根据以上知识地图，
检查我的知识库里有哪些领域已有相关内容，
哪些领域是空白的。生成一份"知识覆盖报告"，格式如下：
## 已有覆盖
- [领域]：[[相关页面]] - 覆盖程度（高/中/低）
## 知识缺口
- [领域]：目前完全没有，需要补充
- [领域]：有一些但不够深，需要加强
这份报告会告诉你：
你现在的知识库，能覆盖这个项目的多少百分比。
哪些地方需要在项目开始前先补充知识。
步骤三：针对缺口做专项知识输入
看到知识缺口报告之后，根据重要程度，做专项知识补充。
如果缺口是一个核心领域，有几本关键书：
Bash
/book-to-skill ~/books/relevant-book.pdf project-skill
先把书转成 Skill，项目中随时调用。
如果缺口是某个特定问题，有几篇权威文章：
Bash
/wiki-ingest raw/key-article.md
快速摄入，加入知识库。
如果缺口是行业案例，需要研究：
用 Web Clipper 剪藏 3-5 篇最相关的案例文章，批量摄入：
Bash
/wiki-ingest raw/
一个重要的时间原则：
知识补充，不要无限延伸。
给自己设一个限制：项目启动前，最多花 2 天做知识补充。
2 天之后，不管知识库是否"完美"，开始项目。
知识缺口可以在项目进行中填补，但项目不能因为等待知识而无限推迟。
步骤四：运行 /project-brief
一切准备好之后，运行你在 Module 6 里设计的 /project-brief 命令（如果你还没有，现在创建一个）：
Bash
# 先打开你的项目主文件
# 然后在 Claudian 里运行
/project-brief
你会得到一份简报：
知识库里所有相关的概念和案例 可以调用的 Skills 知识缺口（已经在步骤三里处理了大部分） 建议的项目框架
这份简报，就是你进入项目执行的起跑线。
不是从零开始，而是从你已有积累的最前沿开始。
8.3 四轮执行：知识驱动的项目工作流
项目执行，分四轮。
每一轮有明确的目标，明确的工具，明确的输出。
第一轮：知识盘点与问题定义
目标： 把项目问题说清楚，同时盘清楚你的知识储备。
工具： Claudian + wiki/ + Skills
时间： 占项目总时间的 20%
在你的项目文件夹里创建 01-knowledge-inventory.md：
Bash
mkdir -p ~/knowledge/vault/projects/your-project/
touch ~/knowledge/vault/projects/your-project/01-knowledge-inventory.md
然后在 Claudian 里：
text
@projects/your-project/
@wiki/我正在启动这个项目：[项目描述]
请帮我完成知识盘点：
1. 这个项目最核心的 3 个问题是什么？
（不是"我需要做什么"，而是"要做好这个，我必须想清楚什么"）
2. 针对每个核心问题，我的知识库里有什么相关内容？
（引用具体的 wiki 页面或 Skill）
3. 每个核心问题，目前的知识覆盖还有哪些盲点？
把结果写入 projects/your-project/01-knowledge-inventory.md
这一轮最重要的产出不是文档，而是一个认知动作：
你第一次真正看清楚了这个项目在认知上的全貌——
哪些问题你有积累，可以快速推进。
哪些问题你缺乏积累，需要谨慎处理，或者临时补充。
这个全貌，让你的项目规划不是凭感觉，而是基于真实的知识储备。
第一轮结束的检查点：
text
□ 核心问题已经定义清楚（3-5个，不多不少）
□ 每个问题都有对应的知识库资源
□ 知识盲点已经列出
□ 知识清单文档已保存
第二轮：框架选择与分析
目标： 用知识库里的框架，深度分析项目的核心问题。
工具： Skills + wiki/concepts/ + Claudian 内联编辑
时间： 占项目总时间的 30%
在你的项目文件夹里创建 02-framework-analysis.md。
这一轮的工作方式，和你以前"做分析"的方式会有根本不同。
以前的方式：
凭经验和直觉做分析，偶尔 Google 找参考资料。
这一轮的方式：
用你积累的框架来结构化分析，每一个判断都有知识库里的依据。
具体怎么做：
针对第一轮里定义的每一个核心问题，在 Claudian 里运行：
text
问题：[你的核心问题]@wiki/concepts/[相关概念]
/[相关skill-slug]（如果有）
请用以上知识库内容，帮我分析这个问题：
1. 这个问题用什么框架来思考最合适？为什么？
2. 用这个框架分析，当前项目的情况是什么？
3. 框架指向的关键决策点是什么？
4. 需要补充哪些信息才能做出判断？
把分析结果写入 projects/your-project/02-framework-analysis.md
的"[问题名称]"部分
对每个核心问题都跑一遍。
这一轮的认知关键：
你会发现一件事——
当你明确告诉 AI"用我知识库里的框架来分析"，它给你的答案，和你不带知识库问同样的问题，完全不一样。
没有知识库：AI 给你一个通用框架，适合所有人，不特别适合你。
有知识库：AI 用的是你读过的书里的框架，你经历过的案例里的模式，你自己总结过的原则。
那个答案是"你的"，不是"人类通用的"。
处理框架冲突
有时候，两个框架对同一个问题给出了不同的建议。
这不是问题，这是最有价值的分析时刻。
text
框架 A（来自 [[wiki页面1]]）建议：[X]
框架 B（来自 /skill-slug）建议：[Y]两者有冲突。
请帮我分析：
1. 两个框架的核心假设分别是什么？
2. 我的项目情况更符合哪个框架的假设？
3. 有没有可能两者都对，只是适用于不同阶段或不同维度？
这种对话，会产生你在知识库里没有的洞见——
来自两个框架碰撞的新认知。
把这个新认知记录下来，事后摄入知识库。
第二轮结束的检查点：
text
□ 每个核心问题都有了框架支撑的分析
□ 框架的选择有明确的理由
□ 框架冲突已被分析和解决
□ 分析文档已保存，带有知识来源标注
第三轮：方案生成与交付物
目标： 基于第二轮的分析，生成真正的项目交付物。
工具： Claudian 内联编辑 + wiki/ + @提及
时间： 占项目总时间的 35%
这一轮，你要生成真实的交付物。
不是分析笔记，而是那个你要交给别人、或者用来指导行动的东西。
创建交付物主文件：
Bash
touch ~/knowledge/vault/projects/your-project/deliverable-main.md
在 Claudian 里：
text
@projects/your-project/01-knowledge-inventory.md
@projects/your-project/02-framework-analysis.md基于以上分析，帮我生成 [交付物类型]。
要求：
1. 每一个关键判断，标注知识来源
格式：[判断内容]（依据：[[wiki页面]] 或 /skill-slug）
2. 结构遵循 [你的格式要求]
3. 语言：[你的目标读者，相应的语言风格]
先生成目录结构，等我确认后再展开每一部分
为什么要"先目录后内容"
很多人直接让 AI"帮我写完"，然后得到一份东西，看起来不对，但不知道哪里不对，重新来又很费劲。
先生成目录，你可以在很低的成本下调整方向——
改一行目录，比改三页内容容易得多。
确认目录之后，再逐部分展开。
每展开一部分，立刻审阅，有问题立刻调整，然后进入下一部分。
不要等到全部完成再回头改。边做边调，是这一轮的关键节奏。
知识来源标注：为什么重要
我要求你让 AI 在每一个关键判断处标注知识来源。
这不只是为了"引用规范"。
这有三个实际的作用：
作用一：强制 AI 基于你的知识库工作，而不是给通用回答。
当 AI 需要标注来源，它必须真的去查你的知识库，找到对应的内容，而不是直接生成通用答案。
作用二：让你能验证判断的可靠性。
当你看到一个判断，来源是你六个月前读的一本书——你可以去翻那本书的 Skill，确认这个引用是否准确，判断是否恰当。
作用三：发现知识库的价值。
项目结束后，你数一数标注来源的条目——每一条，都是知识库为这个项目贡献的一次价值。
这不是虚的，是可以量化的贡献。
内联编辑的节奏
这一轮会大量使用 Claudian 的内联编辑功能。
正确的节奏是：
text
你写一段 → AI 扩展或改进 → 你审阅 diff view → 接受或拒绝 → 继续
不是：
text
让 AI 写完一大段 → 你再来改
你是导演，AI 是演员。
每一个镜头，你在场，你在控制方向。
不是把剧本扔给演员，叫他自己发挥完再给你看。
遇到知识缺口怎么办
第三轮执行过程中，你会遇到一些问题，知识库里没有答案。
两种处理方式：
方式 A：临时补充
如果这个缺口对交付物非常重要，停下来，找资料，摄入知识库，然后继续。
方式 B：标注待定
如果这个缺口不是核心的，用一个标注代替：
Markdown
> ⚠️ 知识缺口：[问题描述]
> 当前没有足够的依据做判断，建议在交付后补充研究
不要让知识缺口变成项目无法推进的理由。
承认不确定性，比用没有依据的内容填充，更诚实，也更有价值。
第三轮结束的检查点：
text
□ 交付物已完成第一稿
□ 关键判断都有知识来源标注
□ 知识缺口已标注（不是被忽略，是被承认）
□ 你对这份交付物的质量感到：基本满意（可以继续）
或者：还有明显的结构问题需要修改
如果是"明显的结构问题"——不要继续，先修结构。
结构错了，内容再好也是白费。
第四轮：复盘与知识沉淀
目标： 把这个项目的过程和洞见，永久沉淀进知识库。
工具： Claudian + /wiki-ingest + wiki/
时间： 占项目总时间的 15%
这一轮是大多数人最容易跳过的。
因为交付物已经做完了，有完成感，不想再做"后续工作"。
但这一轮，决定了这个项目的价值能不能持续复利。
创建项目复盘文档：
Bash
touch ~/knowledge/vault/projects/your-project/04-retrospective.md
在 Claudian 里：
text
@projects/your-project/请帮我做这个项目的知识复盘，提取以下内容：
1. 这个项目里，知识库真正帮到了哪些地方？
（具体列举，不是泛泛说"有帮助"）
2. 这个项目里，知识库明显不够用的地方是哪些？
（这是下一步需要补充的方向）
3. 这个项目让我学到了哪些以前不知道的东西？
（新的框架、新的原则、新的反模式）
4. 这个项目里有哪些决策过程值得记录？
（不是结论，是"为什么这样决策"的过程）
5. 如果下次做类似项目，有什么不同？
（可操作的改进建议，不是"要更努力"这种废话）
把结果写入 projects/your-project/04-retrospective.md
知识沉淀的三个层次
复盘文档生成之后，把值得进入知识库的内容分三个层次处理：
层次一：新概念或新框架
这个项目里，你学到了一个以前没有的框架或概念。
text
/wiki-ingest projects/your-project/04-retrospective.md
让 AI 把其中的新概念摄入 wiki/concepts/，按标准格式创建页面。
层次二：新案例
这个项目本身，是一个值得记录的案例——
不是"我做了什么"，而是"这个案例体现了什么规律"。
text
请把这个项目的关键决策过程，
整理成一个 wiki/cases/ 格式的案例页面。
重点是：情境是什么，做了什么决策，结果怎样，体现了什么模式。
层次三：更新现有页面
这个项目里，某些你已有的 wiki 页面，有了新的证据或反例。
text
这个项目里的 [具体经历]，
和我 wiki 里的 [[相关页面]] 有关。
请分析这个经历是支持、修正还是反驳了那个页面里的观点，
然后更新那个页面。
一个你现在就要做的决定
复盘做完，知识沉淀完成之后，打开那个你在 8.1 节创建的 project-choice.md 文件。
找到你写的"我对知识库的预期"那一段。
对照项目的实际过程：
你猜对了什么？
你猜错了什么？
你完全没有预料到的是什么？
把这个对比写下来。
这是这一讲最重要的一段文字。
不是给任何人看的，是给你自己留的一面镜子——
你对这套系统的认知，在做完这个项目之后，具体变化了什么。
第四轮结束的检查点：
text
□ 复盘文档已完成
□ 新概念/框架已摄入 wiki/
□ 项目案例页面已创建
□ 现有页面已用项目经验更新
□ "预期 vs 实际"对比已记录
8.4 A/B 测试：用数据说话
这一节，是整门课程里你需要最诚实面对的地方。
为什么需要做 A/B 测试
因为人有一种倾向——
当你投入了大量时间和精力建立一个系统，你会倾向于认为它"有用"，哪怕它实际上没有你想象的那么有用。
这叫沉没成本偏见。
A/B 测试，是对抗这种偏见的工具。
你需要一个客观的对比，才能真正知道知识库在这个项目里带来了多少实际的价值提升。
如何做 A/B 测试
在项目里找一个有明确答案的子任务——
比如："写一段对核心用户群体的分析"，或者"给出关于技术架构的建议"。
A 组：不用知识库
打开一个全新的对话（确保 AI 没有你知识库的上下文），输入：
text
[你的任务描述]
请给出你的分析和建议。
保存 A 组的完整回答。
B 组：用知识库
打开 Claudian，@ 相关的 wiki 页面和 Skill，输入完全相同的任务描述。
保存 B 组的完整回答。
对比维度
拿着 A 组和 B 组的回答，用以下五个维度对比：
维度一：具体性
哪个回答更具体、更有针对性？
A 组通常更通用——适合所有人的建议。
B 组应该更个性化——基于你的领域积累、你的项目背景、你的知识库里的案例。
打分：A（1-5分）vs B（1-5分）
维度二：框架准确性
B 组用的框架，是真实来自你知识库的，还是 AI 临时生成的通用框架？
如果你认不出那些框架，说明 B 组没有真正调用你的知识库。
这是需要检查的信号：是 CLAUDE.md 的规则不够强？还是相关 Skill 没有被加载？
打分：框架与知识库的匹配度（1-5分）
维度三：可直接使用性
哪个回答你可以拿去直接用，不需要大幅改写？
A 组通常需要你二次加工，把通用建议翻译成你的具体情况。
B 组应该直接适配你的项目，改动量更小。
打分：A（1-5分）vs B（1-5分）
维度四：洞见深度
哪个回答提供了你自己想不到的洞见？
注意：这个维度不一定是 B 组赢。
有时候 A 组会提供你的知识库里没有的新视角——那说明你的知识库在这个领域有缺口。
记录下来，这是下一步的补充方向。
打分：A（1-5分）vs B（1-5分）
维度五：知识溯源
B 组的回答里，有多少内容是可以溯源到你知识库里的具体页面或 Skill 的？
比例越高，说明知识库的贡献越实质。
打分：可溯源比例（0%-100%）
记录测试结果
Markdown
# A/B 测试记录## 测试任务
[任务描述]
## A 组（无知识库）
[粘贴 A 组完整回答]
## B 组（有知识库）
[粘贴 B 组完整回答]
## 对比评分
| 维度 | A 组 | B 组 |
|------|------|------|
| 具体性 | /5 | /5 |
| 框架准确性 | N/A | /5 |
| 可直接使用性 | /5 | /5 |
| 洞见深度 | /5 | /5 |
| 知识溯源 | N/A | % |
## 关键发现
[用 3 句话描述两者最核心的差别]
## 意外发现
[有没有任何让你感到意外的地方？]
## 结论
知识库对这类任务的价值：[高 / 中 / 低]
原因：
A/B 测试的几种结果，以及各自的意义
结果 A：B 组全面胜出
恭喜。知识库在这个领域真的在工作。
意义：这类任务以后继续用知识库驱动。
结果 B：A 组和 B 组差不多
这通常意味着两件事之一：
这个领域你的知识库积累不够多，还没有建立起优势 这类任务本身不需要深度的专业知识，通用回答就足够了
意义：判断是哪种情况。如果是第一种，加强这个领域的知识积累。
结果 C：A 组在某些维度胜出
不要慌。这是最有信息量的结果。
它告诉你：AI 本身的能力比你的知识库积累更强的地方在哪里。
意义：这是你的知识盲区，也是最值得去补充的方向。
结果 D：B 组的框架你认不出来
这是需要修复的问题。
说明 Claudian 没有真正调用你的知识库，而是在生成看起来像"来自知识库"的内容。
意义：检查 CLAUDE.md 里的工具协作规则，检查 @ 提及是否生效。
8.5 知识缺口发现与即时填补
整个项目过程中，你会不断遇到知识库无法覆盖的地方。
这不是失败，这是系统正常工作的一部分。
知识缺口的出现，是知识库告诉你它需要在哪里成长。
遇到缺口的三步处理
第一步：停下来，记录缺口
不要绕过去，不要用猜测填充。
在你的项目笔记里用标注记录：
Markdown
> ⚠️ 知识缺口
> 问题：[你遇到的具体问题]
> 为什么没有答案：[缺少哪个领域的知识]
> 重要程度：[高 / 中 / 低]
> 计划如何填补：[找什么资料]
第二步：评估对项目的影响
这个缺口，会阻碍项目推进吗？
如果会——立刻去找资料，摄入知识库，然后继续。
如果不会——继续项目，把这个缺口加入"项目后补充清单"。
第三步：填补之后，更新知识库
找到资料，摄入之后，让 AI 帮你更新之前标注的那个缺口：
text
我刚刚补充了关于 [缺口主题] 的知识。
请用新摄入的 wiki 页面，
回答之前标注的知识缺口问题，
并更新项目文档中对应的部分。
一个重要的观察
做完整个项目之后，把所有标注的 ⚠️ 知识缺口 收集起来。
你会发现它们集中在某几个方向。
这不是随机的。
这是你真实的知识结构告诉你，你在哪些领域的积累最薄弱。
把这些方向，加入你下一阶段的阅读计划。
不是根据"这本书很有名"来读，而是根据"这是我实际工作中的知识缺口"来读。
这是知识积累从"随机"变成"定向"的关键节点。
8.6 交付物回顾：系统给了什么，你贡献了什么
项目完成之后，做这最后一件事。
它很重要，但常常被跳过，因为你已经精疲力竭了。
拆解你的交付物
打开你的交付物主文件。
逐段逐页，给每一个部分打上标签：
text
[AI + 知识库] 这部分主要来自知识库的框架和案例
[AI 通用] 这部分来自 AI 的通用能力，和你的知识库关系不大
[你的判断] 这部分来自你自己的判断和经验，不是 AI 给的
[你的创造] 这部分是你的原创想法，知识库和 AI 都没有
统计比例
数一数四种标签各占多少。
把结果记录下来。
没有标准答案说哪个比例是"对的"。
但这个比例会告诉你一些重要的事：
如果 [AI + 知识库] 占比很高：
好事——知识库在工作。
但也要问：这些地方，你真正理解了知识库提供的内容，还是只是"接受了"？
如果 [AI 通用] 占比很高：
说明知识库在这个项目里没有真正发挥作用。
回去检查：是知识覆盖不够，还是调用方式不对？
如果 [你的判断] 占比很高：
这很好，说明知识库在支撑你的判断，而不是替代你的判断。
知识库的角色应该是"给你更多工具做判断"，而不是"替你做判断"。
如果 [你的创造] 占比很高：
这也很好，说明你的知识库在激发你的原创思维，而不是压制它。
一个诚实的问题
看完这个拆解之后，问你自己：
这份交付物，是我能做出来的最好版本吗？
还是说——我只是让 AI 填充了格式，没有真正深度思考？
这个问题没有标准答案。
但你心里知道答案。
如果你觉得"可以做得更好"——那个"更好"是什么，具体是哪部分？
把这个反思写进复盘文档。
这是这个项目留给你最重要的一份遗产。
8.7 实战中的常见状况处理
这一节，提前告诉你项目过程中最常见的几个卡点，以及怎么处理。
状况一：知识库找不到相关内容，AI 开始给通用答案
症状：你 @ 了 wiki/ 里的一堆页面，但 AI 的回答感觉和没有知识库一样——全是通用建议，没有基于你积累内容的特定分析。
原因：可能是：
你 @了的页面和问题的关联性不强 wiki 页面内容太薄，没有足够的实质内容 CLAUDE.md 里没有强制 AI 标注知识来源的规则
处理：
text
我刚才的问题，你的回答看起来像通用答案而不是基于我的知识库。
请重新回答，这次：
1. 只使用我 wiki/ 里有的内容，如果没有，明确说"知识库里没有覆盖"
2. 每个判断都要标注来自哪个页面
3. 如果知识库覆盖不够，告诉我需要补充什么
状况二：框架太多，不知道用哪个
症状：知识库里有好几个看起来都相关的框架，AI 把它们全都塞进了分析里，显得很臃肿，反而看不清楚。
原因：这其实是好事——说明你的知识库积累够了。
但框架太多，没有取舍，反而失去了分析的锋芒。
处理：
text
你给了我 [X] 个框架，但我需要在这个项目里聚焦。
请帮我从以上框架里选出最核心的 1-2 个，
说明为什么它们比其他框架更适合我的具体情况，
然后只用这 1-2 个框架来深化分析。
状况三：交付物第一稿很烂，你不知道从哪里改
症状：AI 生成了一份交付物，你觉得"哪哪都不对"，但说不清楚问题在哪里。
原因：大多数情况下，是结构的问题，不是内容的问题。
处理：
不要从内容入手，先从结构入手：
text
请扮演这份交付物的读者：[描述你的目标读者是谁]
读完这份文档，你的感受是什么？
你最困惑的地方是什么？
你认为最应该调整的结构问题是什么？
让 AI 从读者视角给你反馈，通常能快速找到最核心的问题。
状况四：你对 AI 生成的某个判断有疑虑，但不确定是自己错了还是 AI 错了
这是最微妙的状况。
处理：
text
你刚才做了这个判断：[具体判断]
来源是：[[wiki页面]] 或 /skill但我直觉上感觉有点不对。
请帮我：
1. 确认这个判断的原始依据是否被我知识库里的内容支持
2. 找出这个判断成立的前提条件
3. 找出这个判断可能不成立的情况
我不是要推翻它，我是要理解它什么时候对，什么时候不对。
这个处理方式，比"重新生成"更有价值。
你在做的是辨别，而不是让 AI 猜你想听什么。
状况五：项目中途发现整体方向可能有问题
症状：做到一半，你开始怀疑这个项目的整体方向——不是某个细节不对，是大方向可能偏了。
这是最痛苦的时刻，但也是最重要的时刻。
处理：
先停下来，不要继续往下做。
text
@projects/your-project/01-knowledge-inventory.md
@projects/your-project/02-framework-analysis.md我现在怀疑整个项目的方向有问题。
我的担忧是：[你的具体担忧]
请帮我回到最开始——
用我知识库里的内容，
重新验证我最初对这个项目的核心假设是否成立。
不要试图安慰我，诚实地告诉我哪里可能真的有问题。
早发现，早调整。
方向错了继续做，只是更用力地走向错误的地方。
8.8 项目结束：三件你必须做的事
交付物提交之后，项目没有结束。
有三件事必须做，才算真正结束。
第一件：知识清单文件归档
把 01-knowledge-inventory.md 移到 projects/archive/，但保留一个副本在 projects/your-project/ 里。
为什么？
因为这份文件记录了"进入这个项目之前，我的知识状态是什么"。
六个月后，做类似项目时，对比现在和那时的知识清单——你会看到你积累了多少。
第二件：更新你的个人 SOP
在 projects/templates/ 里创建或更新一个文件：project-sop.md。
把这个项目里，被验证有效的工作步骤沉淀进去：
Markdown
# 我的项目工作 SOP
（基于 [项目名称] 更新，日期：[日期]）## 项目启动
1. [你发现有效的具体步骤]
2. ...
## 执行阶段
1. ...
## 知识沉淀
1. ...
## 下次改进
- [这次发现的可以改进的地方]
这个 SOP，每次做完项目更新一次。
两年之后，它会是一份非常有价值的个人方法论文档。
第三件：给知识库写一封信
这听起来有点奇怪，但请认真做。
在 inbox/ 里创建一个文件：letter-to-kb-[项目名].md。
写给你的知识库：
Markdown
# 写给知识库的信## [项目名称] | [日期]
这个项目里，你帮了我什么：
[具体的，不是"很有帮助"这种废话]
这个项目里，你让我失望的地方：
[诚实的，不要为知识库辩护]
我给你带回来了什么：
[这个项目新增/更新了哪些 wiki 页面]
下次我希望你能做到的：
[对知识库的期望，也是下一步积累的方向]
这不是仪式。
这是一种强制你对知识库做诚实评估的方式。
写完之后，用 /wiki-ingest 把这封信摄入知识库。
是的，让 AI 读你对知识库的评估，然后更新 wiki/hot.md，让这份评估成为系统自我改进的输入。
模块作业
作业一：完成一个真实项目（必做，这是整门课程的毕业作业主体）
按照四轮执行框架，完成你在 8.1 节选择的真实项目。
产出：
项目交付物主文件（带知识来源标注） 知识清单文件（01-knowledge-inventory.md） 框架分析文件（02-framework-analysis.md） 复盘文档（04-retrospective.md） A/B 测试记录 知识溯源表（标注交付物里每个关键判断的知识来源）
作业二：完成 A/B 测试（必做）
在项目里找一个有明确答案的子任务，严格按照 8.4 节的框架完成 A/B 测试。
把完整的测试记录和结论保存在 projects/your-project/ab-test.md。
作业三：完成知识沉淀三件套（必做）
新概念/框架已摄入 wiki/ 项目案例页面已创建 现有页面已用项目经验更新
截图 /lint-wiki 的健康报告，确认系统状态正常。
作业四：写给知识库的信（必做）
按照 8.8 节的格式，认真写。
不要敷衍，不要说废话。
这封信，是这门课程你写的最重要的一份文档。
本讲总结
text
这一讲你做了什么：□ 选择了一个真实项目（不是练习）
□ 完成了四轮知识驱动的项目执行
□ 做了 A/B 测试，客观对比了知识库的贡献
□ 发现并处理了知识缺口
□ 拆解了交付物，分析了各部分的来源
□ 完成了知识沉淀三件套
□ 更新了个人 SOP
□ 写了给知识库的信
这一讲你应该建立的认知：
知识库的价值，不是"有了它就会更好"。
它是"在真实压力下，
当你需要一个比通用 AI 更了解你的协作者时，
它在不在"。
A/B 测试的意义，
不是证明知识库有用，
而是找到它在哪里有用、在哪里还不够用。
项目是知识库的验证场，
也是知识库生长的土壤。
你做的每一个项目，
都在让知识库更了解你的工作方式、
你的判断偏好、你的知识盲区。
这是一个正向循环——
你用知识库做项目，
项目回来喂知识库，
知识库在下一个项目里更懂你。
这个循环，没有终点。
这是好事。
下一讲，也是最后一讲。
我们不再讲新的工具，不再讲新的技巧。
我们讲一件更难的事：
怎么让这套系统在你的工作里，自己活下去、自己生长、自己进化。
一个系统建立容易，持续运转难。
Module 9 的全部，就是讲那个"持续"。
Module 8 完
认知破点：知识库的价值只有在真实问题面前才能被感知；
A/B 测试不是证明知识库有用，而是找到它在哪里真正有用；
项目是知识库最好的验证场，也是它生长的最好土壤
我是【一只阿木木】——公开建造我的 AI 第二大脑。
普通人如何用 AI 搭建自己的知识操作系统？
一个程序员出身的知识工作者，公开记录自己如何用 AI 工具搭建个人知识系统、把读过的书和做过的项目变成可复用资产的全过程。
欢迎加入行动营👇获取更多Obsidian + AI数字大脑实践
我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统
欢迎关注【一只阿木木】🌊