不要用 AI 做这五件事：我用 Skill Stack 踩过的坑

by 一只阿木木

这篇文章是我最不想写，但最应该写的一篇。

不想写，是因为它会暴露我在过去一年里犯过的所有蠢。

应该写，是因为这些坑，几乎每个认真搭建 AI 知识系统的人都会踩到。

如果这篇文章能帮你省掉其中哪怕一个坑，它就值了。

写在前面：为什么是"不要用 AI 做"

我的公众号里，绝大多数内容都在讲"AI 能做什么"、"AI 怎么用"。

这篇文章反过来。

不是因为我对这套系统失去了信心——恰恰相反，我比一年前更相信它的价值。

而是因为我越来越意识到：

一套工具真正的成熟度，不在于它能做多少，而在于你清楚地知道它不该做什么。

一个只会说"AI 什么都能做"的人，大概率没有认真用过 AI。

一个知道"AI 在这五件事上会把你带进沟里"的人，才是真正用系统做过事情的人。

这五个坑，有的让我浪费了几个星期的时间，有的让我的知识库差点彻底废掉，有的让我意识到我在用一套精密的工具，做一件根本没有价值的事情。

每一个坑背后，都有一个我不太愿意回忆的具体故事。

我把它们全写下来了。

坑 1：把所有书都拆成 Skill

故事从一次"大扫除"开始

去年三月，我度过了一个非常"充实"的周末。

周六早上，我打开硬盘里存了几年的电子书文件夹，看着里面密密麻麻的 PDF，突然产生了一个念头：

"把它们全部拆成 Skill。"

这个念头让我兴奋了整整两天。

我开始一本一本地跑 book-to-skill 命令：

Bash

/book-to-skill ~/books/thinking-fast-and-slow.pdf
/book-to-skill ~/books/atomic-habits.pdf
/book-to-skill ~/books/deep-work.pdf
/book-to-skill ~/books/the-lean-startup.pdf
/book-to-skill ~/books/zero-to-one.pdf
/book-to-skill ~/books/sapiens.pdf
/book-to-skill ~/books/principles.pdf
...

终端里一行行的进度条往前跑，~/.claude/skills/ 文件夹一点一点变大，我感觉自己在做一件非常有意义的事。

到周日晚上，我一共拆了 23 本书。

我打开 skills 文件夹，看着整整齐齐的 23 个子目录，产生了一种近乎神圣的满足感。

然后，我关上了电脑，去睡觉了。

接下来发生的事，是这个坑的真正教训。

两个月后，我打开 ~/.claude/skills/，开始认真盘点：

这 23 个 Skill，我在过去两个月里，实际调用过的，有几个？

我数了数。

三个。

只有三个 Skill，被我真正使用过。

另外二十个，和我书架上那些买了就没怎么打开的书，本质上完全一样——只是从书架搬到了服务器，换了一种形式继续积灰。

问题出在哪里

我在那个周末犯的错误，不是技术层面的，是心理层面的。

我把"感觉在积累"误认成了"真正在积累"。

跑 book-to-skill 命令，看着进度条，看着文件生成，这个过程给了我一种强烈的"我在建设知识系统"的感觉。

但这种感觉是假的。

一个你不会用到的 Skill，和一本你不会打开的书，是同一种存在。

拆书不是目的，调用才是目的。一个永远不被调用的 Skill，只是在用存储空间制造一种虚假的勤奋感。

还有一个更深层的问题：

质量。

我在那个周末，用平均 15 分钟一本书的速度，"处理"了 23 本书。

这意味着我没有验证每本书的 Skill 质量，没有手动补充重要的使用场景，没有根据我自己的实际需求调整 SKILL.md 的结构。

这些 Skill 是机械生成的，没有经过我的判断和校准。

后来我发现，其中有好几个 Skill 的框架识别是有问题的——书的核心结构没有被准确抓住，生成的是一个看起来完整、实际上残缺的知识封装。

如果我真的调用了这些有问题的 Skill，AI 给我的建议会基于一个失真的框架，而我不一定能发现这个失真。

垃圾进，垃圾出。批量操作，批量垃圾。

这个坑的正确姿势

经历了这次之后，我给自己立了一条规则：

拆书之前，必须能回答这个问题："我在接下来两周内，有没有一个具体的场景会用到这个 Skill？"

如果答案是"有"——非常具体的"有"，比如"我在写一篇关于 PKM 的文章，需要用 Zettelkasten 的框架来组织结构"——那就拆。

如果答案是"以后可能会用"或者"总有一天会用"——不要拆。等到真正需要的时候再拆。

这条规则执行到今天，我的 Skill 库从 23 个缩减到了 9 个。

9 个，每一个我都能说出它上次被调用是在什么场景。

9 个，比 23 个更有价值。

这个坑的本质： 把工具的使用感，误认为是知识积累的结果。

判断标准： 不是你有多少 Skill，而是你的 Skill 调用率有多高。

健康的 Skill 库： 每一个 Skill，都应该有它被调用的真实记录。

坑 2：CLAUDE.md 写得越长越好

我的 CLAUDE.md 膨胀史

CLAUDE.md 是整个系统的核心文件——Claude Code 每次启动都会读取它，它是 AI 理解我的知识库和工作方式的依据。

道理我懂，所以我格外认真地对待它。

格外认真 到了一个不太对劲的程度。

我的 CLAUDE.md 的进化过程是这样的：

v1（第一周）： 大约 200 字，介绍了我是谁，Vault 的基本结构。

v2（第三周）： 扩展到 600 字，加了工作流说明，加了笔记命名规范。

v3（第六周）： 1500 字，加了连接规则，加了输出格式要求，加了我对每类笔记的具体定义。

v4（第十周）： 3200 字，加了读者画像，加了内容发布规范，加了我的个人品牌定位，加了各类项目的子目录说明，加了 Skill 的调用优先级说明……

v5（第十四周）： 5800 字。

是的。5800 字的 CLAUDE.md。

我当时觉得：CLAUDE.md 越完整，AI 对我的理解就越深，产出就越好。 这个逻辑听起来无懈可击。

然后我开始发现一些奇怪的事情。

Claudian 在处理一些简单任务的时候，开始变得不稳定。

比如我让它帮我整理 Inbox，它偶尔会漏掉一些应该处理的文件，或者用错了我在 v3 里指定的命名格式，明明在 v5 里也有说明，但它好像没有注意到。

更奇怪的是，有时候我问它一个和 CLAUDE.md 里明确写了规则相关的问题，它给的答案和我的规则是冲突的。

我以为是 Bug，重新提问了几次，还是一样。

问题的根源：上下文窗口不是无限的

后来我做了一个测试，才真正理解了问题所在。

我把我的 CLAUDE.md 的 token 用量算了一下：5800 字的中文文本，大概占了 7000-8000 tokens。

而 Claude 的一次对话，上下文窗口是有限的。

CLAUDE.md 要占 7000-8000 tokens，我当前正在编辑的笔记内容要占空间，我引用的其他文件要占空间，对话历史要占空间，我的提问和 AI 的回答要占空间……

当所有这些加在一起，系统实际上开始在做一件我不知道的事：丢弃信息。

它必须决定：在有限的上下文里，保留什么，丢弃什么。

而 CLAUDE.md 的后半段——那些我写得很认真的复杂规则，恰恰因为放在文件的末尾，经常是被优先丢弃的对象。

我写了 5800 字，告诉 AI 我要它做什么，但 AI 真正"读进去"的，可能只有前 2000 字。

后面那 3800 字，我写了，它没读。

更深的问题：复杂度本身是一个陷阱

上下文窗口是技术层面的问题，还有一个更根本的问题：

CLAUDE.md 越复杂，维护成本越高，系统越容易"腐烂"。

我的 v5 CLAUDE.md 写的是 14 周前的我的系统状态。

但系统一直在变。新的 Skill 加了进来，Vault 结构调整了，内容策略迭代了，项目增加了……

每次系统有变化，理论上 CLAUDE.md 都应该同步更新。

但 5800 字的文件，每次更新都是一个小工程。

于是我开始拖延更新，开始"先记下来以后再改"，开始让 CLAUDE.md 和实际系统越来越不一致。

最后的结果是：我有一份很长的 CLAUDE.md，但它描述的是一个不存在的系统。

AI 基于那份文件给我建议，建议是基于一个过时的、不准确的系统状态的。

CLAUDE.md 太长，让它变成了一个维护负担，而不是系统的核心资产。

这个坑的正确姿势

我现在的 CLAUDE.md，不超过 800 字。

这是我测试了多个长度之后，找到的甜点区间：足够告诉 AI 关于我和我的系统最关键的事，又不会挤占其他重要上下文的空间。

我遵循的原则是：CLAUDE.md 只写"宪法级别"的规则，不写"操作手册级别"的细节。

宪法级别：这是什么系统？谁在用？核心结构是什么？最重要的 3-5 条规则是什么？

操作手册级别：这个文件夹里的文件命名格式，那个子项目的具体工作流……这些细节，放在对应的子目录 CLAUDE.md 里，不要堆在根目录 CLAUDE.md。

同时，我给 CLAUDE.md 加了一条更新规则：

Markdown

## 更新原则
这份文件应该保持简短。
如果你想往里加东西，先问自己：
这条规则真的需要在每次会话里都加载吗？
还是只在特定项目里才需要用到？

这条规则写给未来的我，防止我又开始往里面堆东西。

这个坑的本质： 把"写得多"误认为"告诉 AI 的越多越好"。

反直觉的真相： 更短、更精准的 CLAUDE.md，比更长、更"完整"的 CLAUDE.md 效果更好。

健康的 CLAUDE.md： 你能在 2 分钟内读完它，你愿意每两周维护一次它。

坑 3：让 AI 帮我"思考"，而不只是帮我"处理"

一个我不太愿意承认的滑坡

这个坑，是三个坑里最隐蔽的，也是代价最大的。

它发生的方式很缓慢，几乎没有任何明显的"失误"时刻。只是某一天，我突然意识到：

我已经很久没有认真思考一个问题了。

不是没有在思考，而是我的思考方式变了。

变成了：打开 Claudian，输入问题，读输出，点头觉得有道理，然后执行。

这件事是怎么发生的，让我具体说一个场景。

大概在我开始用 Claudian 的第三个月，我在做一篇文章的内容规划。

以前，我会这样做：

打开笔记，把脑子里所有关于这个话题的想法先倒出来，然后看这些想法之间有什么关系，哪些是论点，哪些是例证，哪些是需要回答的问题，然后慢慢梳理出一个结构。

这个过程通常需要 30-40 分钟，有时候更长。但每次做完，我对这个话题的理解，都会比开始之前更深一层。

用了 Claudian 之后，我开始这样做：

打开 Claudian，输入"我想写一篇关于 X 的文章，帮我做内容规划"，然后 AI 给出了一个结构，我看了看，觉得不错，微调两处，开始写。

整个过程，7 分钟。

效率提升了 5 倍。

但有一天，我在写这篇文章的时候，意识到一件事：

我对这个话题，没有真正的观点。

我有 AI 整理的结构，有框架，有论点，但那些论点，是 AI 从我的 Vault 里提炼的，不是我坐下来想出来的。

当我试图在写作过程中去深化某个论点，去解释"为什么我认为这个是对的"，我发现我给不出一个真正有说服力的回答。

因为这个论点，从来没有真正经过我的思考。

它只是经过了我的"审阅"——我看了一眼 AI 给的结构，觉得听起来对，就接受了。

审阅，不是思考。

为什么这个坑很难发现

这个坑之所以隐蔽，是因为它不会立刻产生明显的"错误"。

AI 给你的内容规划，通常是有逻辑的，看起来是合理的，甚至有时候比你自己想的更系统化。

问题不在于 AI 给的是不是好答案，而在于：

当你习惯了接收答案，你就开始失去产生答案的能力。

我后来翻了翻自己半年前的文章和现在的文章，发现一个让我有点不安的变化：

半年前的文章，有很多个人化的、具体的、有时候甚至不太"正确"但很鲜活的观点。

最近的文章，逻辑更清晰，结构更完整，但读起来……

不太像我写的。

更像一个合理的 AI 输出，被我润色了一遍。

AI 能做什么，不能做什么

想清楚这件事，需要区分两种任务：

任务 A：处理型任务

整理 Inbox、归类笔记、格式化文件、检查连接是否断了、把一段文字翻译成另一种格式……

这类任务的特点是：正确答案是存在的，执行过程是机械的，你自己做也能做，只是慢而且无聊。

AI 在这类任务上的替代，是真正的效率提升，没有副作用。

任务 B：思考型任务

确定文章的核心观点、判断某个框架是否适用于我的具体情境、决定一个项目的方向、形成对一个问题的真实立场……

这类任务的特点是：没有唯一正确答案，过程本身就是价值的来源，你在做的过程中，你的理解在深化。

AI 在这类任务上的替代，短期看是效率提升，长期看是能力萎缩。

我踩的坑，就是把 B 类任务当成了 A 类任务来处理。

我让 AI 替我"做"内容规划，而不是让 AI 辅助我"做"内容规划。

这两件事，听起来差不多，实质上天差地别。

这个坑的正确姿势

我现在对 Claudian 的使用有一个先后顺序的硬性规定：

先自己想，再问 AI。

做内容规划的时候，我会先花 20 分钟，把自己对这个话题的所有想法倒进一个笔记里，不管乱不乱，先把脑子里的东西外化出来。

然后，我把这份乱七八糟的原始思考，连同相关 Skill，一起给 Claudian：

text

这是我对这个话题的原始思考（附笔记）
/zettelkasten-skill
/amumu-content-skill
帮我：
1. 找出我已有的论点里，哪些是真正有独特视角的
2. 找出我想说但说得不清楚的地方
3. 找出我可能遗漏的重要维度
不要给我一个新的完整结构，只帮我看清我已有的思考

这个用法和以前的区别是：

AI 是在放大我的思考，而不是替代我的思考。

我的观点还是我的，AI 帮我看得更清楚。

这个坑的本质： 把"效率工具"用成了"思考外包"。

警惕信号： 当你发现自己很少有"这是我的观点"的感觉，而是经常有"这是 AI 给我的输出，我觉得对"的感觉。

使用原则： AI 处理你的处理型任务，你自己完成你的思考型任务。先想，再问。

坑 4：用 AI 生成笔记，然后相信它们是"我的知识"

一个很诱人的工作流

这个坑，是从一个非常合理的需求开始的。

我有大量的阅读材料堆在 Inbox 里——读了一半的文章、看了书签但还没仔细看的链接、截图、语音备忘录的转录文本。

我发现 Claudian 可以做这件事：把这堆原始材料，自动整理成格式规范的笔记，带 frontmatter，带标签，带和已有笔记的 wikilink，存入 Concepts 文件夹。

我当时的想法是：太棒了，这正好解决了我 Inbox 积压的问题。

于是我跑了一次 Inbox 处理：

text

处理 Inbox 文件夹里的所有材料，
按照 CLAUDE.md 里的规范生成永久笔记，
存入 Concepts 对应子目录，
建立与现有笔记的连接。

十分钟后，我的 Concepts 文件夹新增了 17 篇笔记。

每篇都格式规范，连接完整，写得比我自己手动整理要好看得多。

我当时感觉，知识库在一夜之间"长大"了。

然后，差不多两个月后，一件尴尬的事发生了。

我在写一篇文章，需要引用一个关于"知识连接"的概念，我知道自己的 Vault 里有这个笔记——因为我记得 Claudian 生成过一篇相关的内容。

我找到了那篇笔记，读了读，然后想在文章里展开它。

我试图用自己的话解释这个概念。

然后我发现……我不会。

概念的定义我能读出来，但如果有人问我"你为什么认同这个观点"，或者"你能举一个你自己遇到过的例子来说明这个概念吗"，我说不出来。

因为这篇笔记，不是我消化之后写的，而是 AI 帮我整理的。

它描述的是别人理解的那个概念，不是我理解的那个概念。

笔记的本质是什么

《卡片笔记写作法》里有一段话我一直记得：

永久笔记的核心标准不是格式，不是标签，不是 wikilink，而是用你自己的话。

为什么是"用你自己的话"？

不是因为这是一条风格偏好，而是因为：把一个概念转化成你自己的语言，本身就是消化过程的一部分。

当你被迫用自己的话重述一个概念，你必须真正理解它，才能做到不扭曲它。

这个转化过程，会暴露你其实不明白的地方，会让你去追问"为什么"，会让你在写的时候想到自己遇到过的例子……

这个过程，才是知识真正进入你的系统的那一刻。

AI 生成的笔记，跳过了这一步。

笔记进了 Vault，但知识没有进你的脑子。

你有了一个更大的 Vault，但你没有变成一个更有能力的人。

这个坑特别具有欺骗性

这件事之所以这么难发现，是因为它在表面上完全"正确"。

• 笔记格式是对的
• 标签是准确的
• wikilink 是合理的
• 内容是准确的

但如果你用写博客的比喻来理解这件事就很清楚了：

一个用 AI 生成文章、自己只是校对一遍然后发布的博主，和一个自己认真写文章的博主，从读者视角来看，文章可能差不多。

但这两个人，写作能力的成长轨迹是完全不同的。

第一个人，做了多少期，写作能力不会有实质性提升。

第二个人，每写一篇，都在积累真实的能力。

用 AI 生成的笔记填充 Vault，就是第一种情况。

这个坑的正确姿势

我现在的 Inbox 处理流程，把"AI 负责的部分"和"我负责的部分"做了清晰的拆分：

AI 负责： 原始材料的分类、格式转换、初步的标签建议、识别与现有笔记可能存在的连接。

我负责： 真正的永久笔记写作。

具体操作是这样的：

第一步，让 Claudian 处理 Inbox，但输出的不是"永久笔记"，而是一份"值得写成永久笔记的材料清单"，每条材料附带：

• 核心概念是什么（一句话）
• 和我现有的哪些笔记可能相关
• 我是否已经有了自己对这个概念的理解，还是第一次接触

第二步，我拿着这份清单，坐下来，对于每个我认为值得写的概念，自己打开一个新文件，用自己的话，从零开始写一篇永久笔记。

AI 不参与这一步。这是我的工作。

第三步，写完之后，让 Claudian 帮我检查：连接是否完整？标签是否准确？有没有遗漏的相关内容？

这个流程比"让 AI 全自动处理 Inbox"慢了很多。

但慢下来的这部分时间，是知识真正入库的时间。

它不是我的效率损失，它是我的认知成本。

而这个认知成本，是不可被跳过的。

这个坑的本质： 把 Vault 的增长，误认为是自己知识的增长。

核心区别： AI 生成的笔记，是别人消化过的知识；你自己写的笔记，是你消化过的知识。

健康的工作流： AI 帮你处理，你来写作。处理和写作，是两件不同的事。

坑 5：系统越建越大，产出越来越少

这是最贵的一个坑

我把这个坑放在最后，因为它是代价最大的一个，也是我在这五个坑里，花了最长时间才意识到自己掉进去了的一个。

先说一组数据，是我自己统计的：

我在系统上投入的时间越来越多，产出越来越少。

它是怎么发生的

第一个月，我的系统确实帮我提升了效率。写作变快了，笔记整理变快了，我能做更多事情。

这个正反馈，让我产生了一个信念：

系统越完善，效率就越高。所以应该持续投入时间完善系统。

这个逻辑，在一定范围内是对的。

但我不知不觉越过了某个临界点，进入了一种新的状态：

建造系统，本身成了目的。

我开始花大量时间优化 Vault 的目录结构，为了"更整洁"重新整理了几十篇笔记的分类；花时间给 Skill 文件写更完善的元数据；花时间研究新的 Obsidian 插件，测试它们是否能改进某个环节；花时间设计新的 CLAUDE.md 结构……

每一件单独来看，都是"在改进系统"。

但整体来看，我在做的是：把越来越多的时间，花在系统的建造上，而不是系统应该服务的那件事上。

那件事，是写作。是思考。是创造真正有价值的内容。

建造者困境

我后来意识到，这是一个"建造者困境"——特别容易出现在像我这样的程序员背景的人身上。

程序员有一种深层的思维倾向：如果工具还不够好，先把工具做好，然后再用工具做事。

在写代码的时候，这个倾向有时候是对的——一个好的开发环境，确实能让你后续的工作更顺畅。

但把这个逻辑无限延伸，就会变成：工具永远不够好，所以永远在优化工具，永远没有真正开始做事。

这有一个更常见的名字：过度工程（Over-engineering）。

我用来管理知识的系统，被我过度工程化了。

一个让我清醒的问题

有一天我在看自己的周报，意识到那一周我花了 12 个小时在 Skill Stack 系统上，但没有产出任何一篇文章，没有完成任何一个真实项目。

我问了自己一个问题：

"如果我今天就停止改进系统，用现在的系统去做真正的工作，我能做到吗？"

答案是：可以。完全可以。

系统早在两个月前就已经"足够好了"。

后来那两个月，我做的所有"改进"，换来的效率提升，可能只有 5%-10%。

但我在那两个月里，本可以用那些时间写出 8-10 篇文章的。

我用 8-10 篇文章的时间，换了一个比以前好 5% 的系统。

这笔账，算出来让我有点后悔。

系统的真实目的

系统是手段，不是目的。

这句话说起来很简单，但在实际执行中，特别容易被遗忘。

因为"建造系统"会给你即时的满足感——你能看到文件变整齐，能看到 Skill 库增长，能看到 Vault 结构越来越清晰。

而"用系统做真正的工作"——写作、思考、创造——往往是困难的、缓慢的、有时候充满挫败感的。

当"容易的事"和"重要的事"产生竞争，人总是倾向于做容易的事。

建造系统，对我来说是容易的（我是程序员，这是我熟悉的事）。

写出一篇真正有价值的文章，对我来说是困难的。

所以我不知不觉地，用建造系统来替代了写文章。

这个坑的正确姿势

我后来给自己定了一个规则，叫做 "产出优先"原则：

每周，用于"建造系统"的时间，不能超过用于"使用系统产出内容"的时间的 20%。

如果我这周写作和做项目用了 10 小时，那我最多可以花 2 小时优化系统。

这个比例是硬性的。不是"争取达到"，是"必须遵守"。

违反这个规则的时候，我会在周报里标注出来，并且问自己："我在逃避什么？"

因为通常，当我想要过度优化系统的时候，背后有一个更真实的原因：我在逃避某篇文章的难度，逃避某个项目的不确定性，逃避需要真正思考的那件事。

系统优化，是一种生产力的幻觉。

让你感觉很忙，很有产出，但真正重要的事，一直在那里等你。

还有一个配套的规则，叫做 "够用就行"原则：

在决定要不要优化某个系统环节之前，先问：

"现在这个环节，够用吗？"

"够用"的标准不是"完美"，不是"最优"，而是：它能支撑我做我需要做的事，不会成为明显的瓶颈。

如果够用，就不动它。

精力留给产出。

这个坑的本质： 把"建造工具的感觉"当成了"用工具做事的替代品"。

警惕信号： 当你发现自己在系统上投入越来越多，但真实产出越来越少。

核心原则： 产出优先。系统服务于产出，不是产出服务于系统。

五个坑的共同根源

写完这五个坑，我意识到它们有一个共同的根源：

我们太容易把"感觉在做某件事"，和"真正在做某件事"混为一谈。

• 拆了很多书，感觉在积累知识
• CLAUDE.md 写得很长，感觉系统很完善
• 让 AI 替我思考，感觉思考变快了
• AI 生成了笔记，感觉知识库在增长
• 系统越建越大，感觉效率越来越高

每一个感觉，背后都有一个不太真实的现实。

这不是 AI 工具的问题，这是人类认知的问题。

我们天生擅长被即时反馈满足：一个填满的进度条、一个整洁的文件夹、一个越来越大的 Vault——这些都给我们即时的满足感，让我们以为在做对的事情。

真正有价值的事情——真实的理解、真实的能力提升、真实的内容产出——往往进展缓慢，没有那么多即时反馈，需要你在不确定中持续投入。

AI 工具放大了这个问题，因为它让"感觉在做某件事"变得更容易、更便宜、更有即时满足感。

所以我说"不要用 AI 做这五件事"，不是说这五件事完全不能碰。

而是说：

在你真正理解每件事背后的陷阱之前，请谨慎地碰它。

因为 AI 系统最大的风险，从来不是 AI 做错了什么，而是你感觉良好地走进了一个没有任何真实价值的方向，还以为自己在努力建造。

结尾

我公众号的 Slogan 是"公开建造我的 AI 第二大脑"。

"公开建造"这四个字，不只是说要公开那些进展顺利的部分，也意味着：要公开那些走弯路的部分。

这篇文章里的五个坑，每一个我都真实地踩过。

有些浪费了我几个星期，有些让我的系统走了很长的弯路，有些让我意识到自己在做一件本质上没有价值的事情。

但每一个坑，都让我对这套系统的理解深了一层。

让我知道：工具有边界，人的判断在边界之内才真正有价值。

这五件事，是我踩出来的教训，现在变成了这篇文章。

如果你在用 Skill Stack，或者任何类似的 AI 知识系统，希望这篇文章能帮你在走弯路之前，看清楚弯路的形状。

如果你也踩过类似的坑，欢迎在评论区告诉我。

我相信，每个认真搭建系统的人，都有自己的一套踩坑史。

那些坑，是比成功案例更有价值的东西。

附：五个坑的速查清单

存下来，下次想做这五件事之前，先看一遍。

text

坑1：把所有书都拆成 Skill
→ 先问：我在两周内有没有具体场景会用到这个 Skill？
坑2：CLAUDE.md 越写越长
→ 控制在 800 字以内，只写宪法级规则，不写操作手册细节。
坑3：让 AI 替我思考
→ 先自己想，再问 AI。AI 放大你的思考，不替代你的思考。
坑4：用 AI 生成笔记当作"自己的知识"
→ AI 帮你整理素材，你自己写永久笔记。
坑5：系统越建越大，产出越来越少
→ 建系统的时间，不超过产出时间的 20%。够用就行，产出优先。

我是【一只阿木木】——公开建造我的 AI 第二大脑。

普通人如何用 AI 搭建自己的知识操作系统？

一个程序员出身的知识工作者，公开记录自己如何用 AI 工具搭建个人知识系统、把读过的书和做过的项目变成可复用资产的全过程。

欢迎加入行动营👇获取更多Obsidian + AI数字大脑实践

我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统

欢迎关注【一只阿木木】🌊