4 月 6 日下午，我在阿里数字生态创新园的会议室，与客户开完线上会议后。偶然间刷到一条消息：Andrej Karpathy 在 GitHub 上传了一份 1200 行的 markdown 文档。
Karpathy 是前 OpenAI 的创始成员之一，前特斯拉 AI 总监，李飞飞的学生，最近刚加入 Anthropic。圈内人叫他「AI 领域的扫地僧」。
这一次他发的东西很简单：一段说明文档，告诉你怎么把 Obsidian 和 LLM 拼成一套个人 wiki 系统。他用一句话给自己的方案做了定义：Obsidian 是你的书房，LLM 是你的研究员，wiki 是你 20 年经验的百科全书。
二话没说，对于我这种零代码基础的人，最不缺的就是好奇心，马上让 Claude Code 给我重新创建了一个文件夹 LLM Viki（专门为了与 LLM Wiki 区分开来）。
这正是我两年来一直想做、但又始终没找到方法的事情，因为我收藏了好多电子书和文章，之前都放在 NotebookLM 里面，但总感觉差点意思。
两天后，我又挑了我手头服务的其中一个 B 端客户（后面统一叫他「客户 J」），把服务他公司近 20 个月、500 多份文件、60 多万字的文件夹，重新基于 LLM Wiki 的逻辑全部重新改造。
整个过程我没自己动手，全交给 Claude Code 去跑。不到 30 分钟时间，我看到 Obsidian 里面的关系图谱，几百个节点、3 位关键人物、3 条主线议题、跨会议的决策点，全部在屏幕上像星图一样连起来。
那一刻，我以为我找到了答案。
坦白讲，我错了。错的不是这个 LLM Wivi 系统，是我对自己业务的理解。
在 AI 的眼里，文件夹是这样分类的
对文件夹改造后让我震撼的，不是节点的数量，是节点和节点之间的连线方式。
Karpathy 的方法严格意义上来讲只有三件事。
第一，把所有的原始资料（PDF、网页剪藏、会议纪要、邮件、电子书）丢进 vault 里一个叫 raw 的文件夹。
第二，让 LLM 读完 raw 里的新内容，自己整理成 wiki 页面。这是整套系统最有意思的地方：不是你写笔记，是 AI 替你写。
第三，每周让 LLM 做一次「健康度检查」（/lint），找出 wiki 里的孤儿页、矛盾、过期信息、盲点。
我服务客户 J 已经 20 个月了。这 20 个月里我手动建过的文件夹，最多的时候有 78 个，按年度、按项目、按议题、按交付物各分一套。每次回头找一份会议纪要，我都得在三个目录里翻来翻去。要做新的方案时，我经常想不起来上一版的细节放在哪一层文件夹的第几个子目录里。
这是过去两年来我的常态，每次阶段交付完了都告诉自己说，等空一点一定要好好重新整理一下文件夹。结果呢？每次都给自己找借口，其实是一团浆糊，因为我既有本地文件，又有存到了飞书里的在线文件，实在工程量太大了。
那天看了 Obsidian 里的关系图谱后，我突然意识到：在 Claude Code 眼里，文件夹根本不是这样分类的。
它把客户 J 的业务负责人单独抽出来做成一个「人物画像」页，把过去 20 个月所有跟这位负责人相关的会议、邮件、决策片段都连到这一页上。它把「降本增效」识别成一条贯穿 14 次会议的主线议题，自动归类到一个叫 thread 的子目录里。它甚至把客户 J 在 2026 年 Q1 提到的，一个我自己都已经忘了的关于「区域代理商授权」的内容，标成了一条「待回访议题」，等我下次见面时打开就能看到。
我那些天在研究 Claude Code + Obsidian 的应用场景，一度晚上待在书房都有点走火入魔了。关于这些内容，没少发朋友圈，还专门配了我自己的知识库图谱的截图。然后就有好多朋友私信我，说自己也想搭一个。
我跟他们说：先等等，等我研究一下，因为我发现网上有一些博主教的方法其实是错的，根本就违背了 LLM Wiki 的初衷，文件夹越搞越多，越来越复杂。
接下来的一周，我开始不断尝试、失败、重来、再尝试，不断与 Claude Code 探讨怎样改造我的工作流，如果改造我的文件夹。
为什么我把建好的 Obsidian 仓库全部推倒重来
这一周里，我做的事情很简单：兴奋之下，我把所有其他东西也都拖进了这个 vault。
我把自己服务的 36 位 C 端学员——其中的 12 位伙伴与我的 1v1 咨询纪要放了进来（Obsidian）。然后我又把自己前面建好的 LLM Viki 知识库重新进行了整理，再把过去半年公众号写过的所有文章拖了进来。
接着又把我个人的方法论沉淀（韦斯的价值定价、沙因的过程咨询、Karpathy 的几篇论文，以及 Anthropic 官方发的资料）也都拖了进来。我以为我在搭一个属于「我」的 wiki。
我用 Claude Code 写一篇公众号文章草稿，主题是「为什么独立顾问的客户结构决定了交付质量」。文章写到一半，AI 引用了一段「学员 W 的真实经历」作为例证。我读了一遍，里面的细节非常生动：TA 从一家 500 强公司辞职，那是个百万年薪的岗位，转身做独立顾问 3 个月只赚了 5000 块，还是被邀请讲课的课酬。
问题是，这段细节我从来没有放进过公众号文章。这段是她在我们 1v1 咨询里告诉我的，我把它存在了学员档案里。AI 在不知道这两个文件夹之间该有边界的情况下，直接把私下对话当公开素材用了。
我把那段删掉的时候，有点顾虑了。
第二件事，我做了个测试，我问 AI，请基于客户 J 过去 20 个月在领导力发展上的所有沟通，给我提炼三条核心议题。它给我的报告里，第一条是「中层管理者的价值认知缺失」。我读到第三段，发现一段引用：「正如某位高管所说，最难的不是放下身段，是承认自己原来的方法已经不奏效了。」
这是学员 W 的原话。我从来没把她跟客户 J 联系过任何关系。AI 是从我的 vault 里自己把这两个完全不相关的人连接在一起的。如果这份报告我没仔细看就发给客户 J，它会出现在一个我服务 20 个月的 B 端客户的正式诊断报告里。
这一刻，我才意识到，如果把所有的输入、输出资料，一股脑的全放在一个 Obsidian 仓库里，将是巨大的灾难。尤其是对于像我这样的独立顾问而言，这是不可想象的。
这不是 Karpathy 的错，是我一开始用错了方式。Karpathy 的版本是给「一个人、一个 vault、搞定自己的知识管理」设计的，他自己是个科学家，他的所有素材彼此之间没有伦理风险。但独立顾问不是，独立顾问天然是多重身份的。
我手上服务的 B 端客户、我运营的 C 端独立顾问学员、我对外发表的公众号文章、我自己读书做的方法论笔记，这四类东西的敏感度完全不同。
B 端客户的合同金额是商业机密，C 端学员的 1v1 内容是伦理红线，公众号文章是对外创作必须脱敏，方法论笔记是我自己的私学。如果它们混在一个 vault 里，AI 在做任何一次 query 的时候，都可能跨越本来不该跨越的边界。
于是，我觉得应该做点什么。是时候把前面的框架推倒重来。
4 仓联邦：把「我」按身份切成 4 个独立仓库
接下来的一个多星期，我折腾了好几次，晚上在书房一度都坐椅子上睡着了。最早我试过 2 仓（输入仓 + 输出仓），失败。又试过 3 仓（私学仓 + 客户仓 + 创作仓），仍然不够。最后稳定下来的版本，叫 4 仓联邦（当然未来再决定把其它 B 端客户也改造一下）。
4 个仓库分别是：
LLM Viki（我把 Wiki 的 W 改成了 V，纯粹是为了在终端里跟客户仓做视觉区分）。在 ~/LLM Viki/，里面只有方法论、电子书摘要、行业文章剪藏。这是我自己的研发部，只输入不输出。
客户 J。在 ~/Desktop/咨询项目/<客户代号>/。后期每个 B 端客户一个单独的仓库。客户 J 在这里，未来如果再有新签的 B 端客户，会再单独开一个独立仓库，永远不放一起。
咨询 C 端。在 ~/Documents/咨询C端/。目前收录了 12 位 1v1 学员的资料（另外 24 位还没有录入）各占一个子目录，所有学员的会议纪要、诊断报告、都留在这里（他们的付费订单记录我是放在 Notion 搭建的 CRM 系统里，也是我自己研究做出来的）。
Danny’s 仓库。在 ~/Danny's 仓库/。这里是我的对外创作工厂。公众号文章、培训讲稿、正在写的书稿、还有一些学习复盘笔记，全部在这。
四个仓库的物理位置都不一样，对应的项目级 CLAUDE.md 也不一样。但只有它们之间有明确的「跨仓矩阵」和「脱敏契约」，这套架构才真的能跑起来。
跨仓矩阵规定了谁可以读谁、谁可以写谁。LLM Viki 仅自己可读可写，它是我的方法论 hub，永不接收客户库或学员库的自动数据流。B 端客户仓和 C 端学员仓都可以向上去读 LLM Viki（诊断时需要主动拉方法论），但仅自己可写。最关键的是 Danny’s 仓库，它可以读全 4 仓的内容（写作时需要客户案例 + 学员故事 + 方法论），但仅自己可写，并且写的时候强制脱敏。
脱敏契约有 4 条铁律，我把它写进了全局 CLAUDE.md，每次 Claude 帮我从客户库里取素材去写公众号草稿，都必须自动执行：
-
真名 → 代号（XXXX → 「客户 J」，学员 W → 「学员 W」）
-
合同金额 → 量级（50 万 → 「6 位数」）
-
行业细节 → 泛化（XX 行业 → 「电子电气产品」）
-
微信 / 电话 / 邮箱 → 永不出现
我见过太多独立顾问，包括过去的我自己，会觉得这是我自己的电脑、我自己的硬盘、我自己的客户素材，为什么需要这套契约？
我的理解是，这套契约保护的不是客户，是你自己。一个独立顾问最大的资产是「客户愿意把真心话告诉你」的那份信任。一旦你的素材库混乱到连 AI 都会把私下对话当公开素材用，那这份信任就被你自己的工具体系系统性地透支了。
这一条做不到的人，不适合做独立顾问，这是最基本的职业素养。
给你看一下客户 J 仓库现在的实际结构，这是我搭出来跑了一个月之后的版本：
客户 J/ （代号 J · 顶层目录）
├── raw/
│ ├── 客户原件/ （合同 · 政府文件 · 内部资料）
│ ├── 访谈与会议/ （每次纪要 · Fireflies 原文）
│ └── 出差速记/ （现场手记 · 飞机/高铁上写的笔记）
├── wiki/
│ ├── people/ （3 位关键人物画像 · 每人一页）
│ ├── threads/ （3 条跨会议主线议题）
│ └── 项目管理/ （里程碑 · 决策日志 · 任务看板）
├── outputs/
│ ├── 方案与交付物/ （每一版方案留档）
│ └── 培训与工作坊/ （Q2 AI 培训课件 + Demo 脚本）
└── CLAUDE.md （这个客户专属的项目级指令）
raw / wiki / outputs / CLAUDE.md 这四层，是这个客户仓库的所有内容。它从 2024 年 9 月开始累积到今天，500 多个文件、60 多万字，没有再往别的方向漫延。每周我会跑一次 /lint，让 Claude 检查里面有没有孤儿页、矛盾、过期信息。
每两周我会进 wiki 看一次「关键人物画像」有没有更新。每次客户开会之前 30 分钟，我直接打开 Claude Code 问一句「过去两个月我们讨论了哪些战略议题、各议题最新进展是什么、相关 wikilinks 给我列出来」，它会自动从 threads 子目录里把所有相关的会议、决策、悬而未决的点连起来给我看。
过去做同样的准备工作，我得手动翻 5 个不同的文件夹，前前后后折腾至少 1 个小时，现在 5 分钟搞定。
同时，对于很多人来讲，刚好借助 AI 改造自己的电脑文件夹时，可以顺便清理过去很多没有用的资料。
比如这是我用的第 12 台 Mac。换电脑那天，我打开旧 Mac 准备整理资料时，发现里面存着我 10 年前在阿里做销售时的客户跟进记录、方案模板、内部培训资料。我以前一直觉得那是「珍贵的回忆」，得留着。那天打开看了一眼，第一感觉是幼稚，第二感觉是这些东西现在打开也没用了。我咔咔一顿操作，删了 100 多个 G。
我那时候才意识到一件事：你大脑中真正重要的东西，从来不是文件，是结构。
一个独立顾问 5 年下来的文档，如果没有一套能让 AI 看懂、并且能让 AI 在不越界的前提下帮你调用的结构，那 5 年文档就只是 5 年硬盘占用。
4 仓联邦的本质，不是把文件夹切成 4 块。是把「我作为独立顾问的多重身份」按敏感度结构化地表达出来，让 AI 知道每次它在做什么动作的时候，自己站在哪一类身份的边界里。
这不是技术架构。是商业伦理的结构化表达。
一个月后，我开始有 3 块屏幕
写这篇文章的现在，是 2026 年 5 月 24 日下午。距离我第一次把 Karpathy 装到电脑里，正好过去了 7 个星期。
我的书房有 3 块屏幕。MacBook 屏幕在中间跑 Claude Code，左边一块三星屏幕跑 cowork 给我整理素材，右边一块 iMac 屏幕看个网综节目。这不是装样子，是我偶尔在家办公的真实样子。
4 月 25 号我临时定的客户 J 出差，4 月 26 号前要把行程与相关资料同步发给客户相关人。我跟客户（老板）及业务负责人、HR 负责人临时开了个电话会议，结束后我把会议纪要丢进客户 J 仓库的 raw 目录，然后直接对 Claude Code 说：「基于刚才这通电话和过去 2 个月的会议纪要，给我两天的行程安排和需要带的所有文档」。
而输入这段话，完全用不着五笔打字了，我只需要按下 Mac 上的 F5 按键，目测比微信输入法的语音转文字输入还好用。真的进入了能动嘴就不要亲自动手的时代。
大概 20 分钟左右（包含 Claude Code 与我用AskUserQuestion工具提问），两天的行程表、每一场会议要讲什么、需要客户哪些人列席、要带哪几份方案、提前要给老板看哪份资料，全部生成好了。我自己又花十来分钟调整了几个细节，整个出差准备工作就完成了。
过去做同样一件事，我需要花一整个晚上，写 PPT 和整理数据报表、翻历史记录、整理逻辑、排议程。现在 30 分钟足矣。
这是我自己的样本。我还想给你看另外一个朋友的样本，他叫老麦。是一位 22 年外贸实战专家，自己的外贸企业一年也有 3、4 个亿（已经交给合伙人在打理）。他还抽空写了本书：《外贸破局：拿回生意的主导权》，据说下一本正在路上了。同时，也是老麦外贸圈 —— 1000+ 外贸创始人付费社群的主理人。
他的公司分布在温州、杭州、深圳三地。深圳的公司在光明区，3 月份时我去过。4、5 百平米的办公室，只有合伙人+1 个助理，平常是接待客户、做社群伙伴交流活动的。
他在与我陆续交流了一阵子 Claude Cowork 与 Code 使用方法后，就开始动手实践了。两个星期之后他给我发了一条语音，大意是这样的：「我已经完全不需要助理了，她刚好也经常请假。我现在出海报、写文案、做提案，全部直接用 Claude Code，比助理输出质量高也更有效率，还能不受时间限制。」
说实话，我还是有点感慨的。我在朋友圈里看过太多人讲 AI 替代助理的故事，大多数都是故事。老麦不是讲故事的人，他从来不在朋友圈讲这些事，他是真的在践行中，如何让自己更高效、如何让自己跟上时代的步伐。
在微博时代，他在温州乃至浙江甚至全国的外贸圈中，就属于非常喜欢在社媒上分享的创业者。
到了 AI 时代，他完全没有老板的架子，极其务实与好学，跟我的每次沟通，非常有质量的问题及快速行动的能力，是我见到的外贸创业者中应用 AI 思考最深且最快见到成效的人，没有之一。
你可能会想，Danny，你这套不就是把简单的事情搞复杂了吗？我一个独立顾问，搞 4 个仓库、跨仓矩阵、脱敏契约，这些东西不应该是大公司的 IT 团队该干的吗？我自己一个人，一个文件夹不就够了？
我的理解是这样。一个文件夹够，前提是你的业务复杂度不高、客户敏感度不强、你也不写对外公开的东西。如果这三个条件你都满足，确实不需要 4 仓联邦，你甚至不需要 Claude Code。
但你只要满足这三个条件中任何一个的反面（你服务 B 端客户、你陪跑 C 端学员、你写公众号或者出书），你迟早会遇到我之前把输出、输入都放在一个大仓库中的情况。区别只是时间早晚而已。
当然，4 仓联邦也不是终点。我现在已经在想，未来如果再放 2-3 个 B 端客户，每个客户一个独立仓库会不会变成新的负担。说实话，我目前没有答案。但我相信随着 AI 的进化，这个肯定不是问题。
就像去年的这个时候，我还在报班学习如何写提示词。但今年却发现所谓的「提示词工程师」这个岗位已经消失了。
我想，任何架构都是阶段性的，重要的不是这个版本能用多久，是你下一次需要重构的时候，你能不能识别出「该重构了」那个效率进化的信号。
Karpathy 给的不是答案，是问题：他用一份 1200 行的文档逼着我重新看自己 5 年下来的所有文档，到底是资产，还是占用。
5 年下来的文档，想变成 24 小时复利的 wiki 系统，先要回答的不是怎么搭建，是我作为一个独立顾问，到底有几重身份。
你的身份清楚了，仓库搭建的逻辑自然就清楚了。
以上，与你共勉。
—— Danny 2026.05.25 11:28 于杭州
