独立顾问的 Claude 治理学：四仓联邦、一份契约、一部宪法

5 月 23 号晚上九点过一点，直播间里朱莉开了麦。

「刚哥，昨天你教的那个 lint 我跑完了。但是我看我那个 wiki 图谱上还是一堆孤零零的点。他好像就像有盲点一样，你告诉他哪里不对，他好像就反应过来了，但是你如果单纯的只是运行那个 lint 好像又不太行。」

我让她截图发群里。打开一看，图中间一团黑乎乎的网，外围零散漂着一圈小行星。

朱莉接着说了一句让我印象很深的话：「我又有点担心他那个 cloud md 里面他这种限制越加越多，会不是很好。」

我先把这句话放下。九点二十分，敬华问了另一个问题。

「刚哥，我建了两个客户的项目，A 客户一个 B 客户一个。我最开始想把这两个能合在一起，因为合并不就好管理了吗，都在一个里面。」

我问他这个想法是哪来的。他说：「我问 clawdbot 上，我说我有两个项目，他建议我合并。」

我和他来回拆了五分钟。最后他说了一句：「那看来我还被这个误导了。」

两个学员的两个问题表面看完全不相干。一个是图谱不连，一个是文件夹要不要合。

但它们指向的是同一件事没立起来。

这件事叫治理。

5 月 22 号和 23 号两个晚上，我给一群独立顾问做了五个小时的直播课。直播间里坐的有前阿里、前美菜、前华为的中高管，也有正在做咨询的独立顾问。五个小时讲了很多东西，从工程基建到业务运转。

这篇文章不复盘整个课程。我只把里面最值钱、也最容易被忽视的一块抽出来，讲给我专栏的订阅读者。

这一块讲的不是怎么用 Claude。是怎么治理 Claude。

听上去像废话。搭个 AI 中台不就是把 Claude 装好，把文件夹建好，把提示词写好吗。

不是。如果只搭了工具层，没搭治理层，撑死跑三个月就开始烂。烂的方式很多种，朱莉的孤儿节点是一种，敬华想合并文件夹是另一种，我自己踩过的更难看一点，回头讲。

接下来分三段把治理这件事拆开。

一、Karpathy 的方法，搬到独立顾问身上会出事

4 月 4 日，Andrej Karpathy 发了一篇 gist。Karpathy 是 OpenAI 联合创始人之一，李飞飞的学生。在我看的这一拨 AI 圈博主里，他是把底层原理讲得最清楚的人，没有之一。

那篇 gist 讲他自己怎么用 LLM 搭一个个人 wiki。方法很简单，就三个动作。

Ingest。你丢一份新资料进来，论文博客纪要书的某一章都行。LLM 读完之后自动更新你已有的 wiki，新观点新增页面，旧的有冲突就提醒，过时就标记。

Query。你想问一件事，不去 Google，不去翻笔记，直接问你自己的 wiki。LLM 读完所有相关页面给你综合答案。这个答案基于你过去消化过的所有东西，不是基于互联网的随机内容。

Lint。定期给 wiki 做体检。找矛盾，找孤岛，找过期，找盲点。朱莉昨晚跑的就是这个。

三个动作合起来，Karpathy 管它叫 LLM Council。他自己用这套东西管几百本书的读书笔记和上千篇论文摘要。

我第一次看到这个 gist 的时候非常激动。一个独立顾问能想到的痛点，看上去全都能用这套东西解决。

激动了大概一周。然后我自己上手搭了一版。

跑了不到一个月，问题开始冒头。

最早冒出来的是泄密这件事。Karpathy 是研究员，他的资料库里都是公开论文和博客。怎么处理、怎么共享、怎么和外部 LLM 对话，都没什么顾虑。

我手里现在有客户 J 的二十个月所有材料，合同、纪要、组织诊断报告、内部薪酬数据。Karpathy 式的统一 wiki 把所有东西放在一个 vault 里，等于把客户 J 的底层资料和我自己的方法论笔记搅在一起。下次我给客户 M 写提案，AI 很可能会从客户 J 的材料里抓一段措辞精彩的诊断逻辑放进去。等客户 M 问「这段是哪儿来的」的时候，我答不上来，因为我自己也忘了。

这不是技术问题。是职业生涯问题。

第二个慢慢冒出来的问题，我后来叫它伦理混乱。

我同时服务 B 端客户和 C 端学员。B 端是付费做组织咨询的企业，C 端是付费学独立咨询的从业者。两群人对我的期待完全不同，我对他们负的义务也完全不同。如果两边的素材库混在一起，我做 C 端课件的时候，AI 可能引用 B 端客户的一个内部矛盾作为案例。它没坏心，它只是在执行「用最贴切的案例」这个指令。但这是直接踩伦理红线的事。

第三个问题更隐蔽，和能力直接挂钩。

独立顾问最值钱的能力是诊断。诊断依赖的是「我对这个客户的完整理解」，不是「我对所有客户的混合理解」。

但混合是 Karpathy 式 wiki 的默认机制。它不区分客户。它把所有东西都当成同一个知识系统的一部分。我用它做客户 J 的诊断时，它给我的判断里很可能渗透了我对客户 M、客户 N 的判断。这就是数据污染。诊断会失真。

诊断失真的可怕之处在于，你自己一开始看不出来。它是一种慢性病。

最后一个问题是认知污染。这是我做了三个月才意识到的。

我写公众号、写书、做演讲，要的是「我的观点」，不是「我的客户的观点」。但创作的 wiki 如果没和客户的 wiki 隔开，AI 在帮我起草文章的时候，会无差别地从所有 vault 里抓材料。结果是我以为是我的洞察，其实是某个客户去年开会说的一句话。

这四个问题 Karpathy 遇不到。他没有付费客户，没有 C 端学员，没有商业写作的边界焦虑。

所以我没办法照搬。

二、在四仓联邦之前，我试过三种解法

四个问题摆在面前，第一反应不是推翻 Karpathy。是修 Karpathy。

我先试了三种修法。三种都不行。

第一种是「统一仓 + 严格命名」。 我保留 Karpathy 的单 vault 结构，但要求自己在每一份资料的元数据里写清楚归属：这是客户 J 的，这是 C 端学员的，这是公开方法论。然后在 CLAUDE.md 里告诉 Claude「按元数据隔离」。

听上去合理。跑了两周。失败。

Claude 执行元数据隔离的稳定性大概在六七成，剩下三四成它会「忘记」。这种忘记没有规律，而且最危险的是它不告诉你它忘了。我有一次写课件，Claude 给我引了一段非常精彩的诊断观察，我以为是我去年写的，后来翻出来发现是某 B 端客户的内部讨论。我吓出一身冷汗。

软规则不顶用。Claude 不是一个固执的人，它是一个非常配合的协作者。配合的另一面是它会被指令绕过。

第二种是「加密文件夹」。 客户的真实材料加密，Claude 访问需要密码。

这种方案听起来安全，实际不实用。每次我做客户工作都要解密，做完再加密。加密的目的本来是防止跨 vault 串味，但解密之后 Claude 照样能读到内容，该串味还是串味。它解决的是「被人偷」的问题，不是「被 AI 混」的问题。我用了五天放弃了。

第三种是「多个 Obsidian profile」。 一个 profile 管一个客户。听上去和后来的四仓联邦很像，但中间差着关键一步。

Profile 之间的边界是 UI 层的，不是治理层的。Claude Code 启动的时候它读到的还是同一个父目录。我有过一次，Claude 给我做客户 A 的提案，自动从我没主动打开的另一个 profile 里抓了一段内容补强论证。它觉得自己很聪明，但那是客户 B 的资料。

三种解法浪费了我大概十周时间。

这十周不是白浪费的。它让我搞清楚一件事：治理边界必须是文件系统级的硬边界，不能是软规则。 任何依赖「Claude 会按规矩做」的方案，都会在你不注意的时候漏。

想清楚这件事之后，我重新设计了一版。这一版叫四仓联邦。

四仓的结构

四个仓分别是：LLM Viki、B 端客户仓、C 端学员仓、对外创作仓。

LLM Viki 是我自己的知识库。所有公开方法论、读书笔记、行业研究、Karpathy 式的内容摘要都在这里。它对外不输出。

为什么叫这个名字。Karpathy 管他自己那一版叫 LLM Wiki。我把 Wiki 改成 Viki，一个字母的差别，提醒我这是我的私有版本，不是 Karpathy 的版本。

B 端客户仓是每个企业客户一个独立的 vault。客户 J 一个，客户 M 一个，各自独立。每个仓里是这个客户的所有原始材料、纪要、诊断、提案、决策日志。

C 端学员仓存的是几十位学员的 1v1 咨询全留档，每人一个子目录。

对外创作仓存的是公众号、书稿、演讲稿、视频号脚本。

四个仓之间不是平等的。它们之间有读写矩阵。

跨仓矩阵

把矩阵列成一张表：

读起来简单，落到执行的核心规则只有一句话。

没有任何一个仓可以跨仓写入。

跨仓的协作只通过「读」发生。写永远是本仓内部的事。

回到敬华的问题。他想合并两个客户的文件夹，Claude 建议他「合并好管理」。

Claude 那个建议在技术上没错。在治理上是错的。

错的原因不是 Claude 蠢，是敬华没告诉它那是两个独立的 B 端客户。Claude 看到两个相似结构的文件夹，从「操作效率」的角度，当然建议合并。

但合并的代价是数据污染。下次他做客户 A 的诊断报告，AI 可能从客户 B 的材料里抓证据。客户 A 问「这个判断哪来的」，他答不上来，因为 AI 自己也不知道它跨仓了。

合并文件夹在治理上等于撤掉两个客户之间的国境线。AI 不知道你的业务边界，你不告诉它，它就会按「方便」推荐。

所以四仓联邦的第一条规则是：每一个 B 端客户、每一个 C 端学员，都必须有自己的 vault。不能合并。哪怕只有两个客户也不行。

这不是技术规则，是治理规则。

脱敏契约

联邦结构光有「不能跨仓写」还不够。任何信息从一个仓被对外创作仓读走的时候，必须经过一道脱敏。

我给自己定了四条规则。

真名换代号。真实公司名一律变「客户 J」、「客户 R」这样的代号。

金额换量级。五十万的合同变「6 位数」，三百万变「7 位数」。

行业细节泛化。「电气保护器」变成「电子电气制造」。

联系方式从不跨仓。微信、电话、邮箱、办公地址，永远只留在本仓的原始文件里，不进 wiki，不进对外创作。

这四条我在每一个仓的 CLAUDE.md 里都写了一遍。下一节就是讲 CLAUDE.md 的。

三、CLAUDE.md 不是设计出来的，是被 Claude 教出来的

四仓联邦的结构搭好了，跨仓矩阵列清楚了，脱敏契约定下了。这些规则怎么让 Claude 执行。

靠 CLAUDE.md。

CLAUDE.md 是 Claude Code 里一个特殊的 Markdown 文件。每次 Claude 在一个工作目录启动，会自动读取这个文件。它告诉 Claude「在这个目录下你是谁、为谁工作、什么能做、什么不能」。

我的 CLAUDE.md 第一版只有十几行。是去年 12 月写的。第一行是「你是 Danny 的协作者。Danny 是独立顾问」。然后是一些零散偏好，「中文为主」、「少用项目符号」之类的。

这一版用了大概十天就出问题了。

那时候我让 Claude 帮我整理一份客户 J 的访谈纪要。我对它的指令是「帮我整理一下这份访谈」。它给我整理出来一个非常工整的麦肯锡三角型框架：问题、原因、对策。

整理得很漂亮，但完全不对。我做的是组织诊断，不是 McKinsey 式问题树分析。我用的是沙因的三层文化理论：人工制品、信奉的价值观、底层假设。Claude 给我的输出和我的方法论完全对不上。

我当时第一反应是骂它。后来想清楚不是它的错。是我没告诉它「我用什么框架」。

那天我在 CLAUDE.md 里加了一条：「做组织诊断默认用 Schein 三层文化理论，不要套 McKinsey 框架。」

这是 CLAUDE.md 的第一次迭代。

后面每一次迭代都是 Claude 犯了一个错，我就回来加一条。

有一次它在我没要求的情况下主动给我「建议性方案」，写了三个备选给我选。我看完三个发现全是套话，浪费我十五分钟。我回来加了一条：「不要擅自给我’建议性方案’。先讨论，后执行。我们一起想，你说你怎么想，我们对一下，再动手。」

有一次它在一篇公众号文章里用了「赋能」、「抓手」、「闭环」三个词。我读完想烧电脑。回来加一条禁用词清单。

有一次它直接把客户 J 的真名写进了我对外创作仓里的一份草稿。我吓出一身冷汗。回来在每一个仓的 CLAUDE.md 都加了脱敏铁律。

这样加了半年，我的全局 CLAUDE.md 大概五十几行。下面这一段是脱敏后的真实片段：

markdown

# 你是谁
你是Danny的协作者。Danny是独立顾问,专注组织转型、领导力发展、文化变革。

# 我们之间的关系
你不是仆人,是新入职的MIT毕业生。能力强,但需要带教。
我给你情境,不给你指令。我们一起做X,你说你怎么想,我们对一下,再动手。

# 写作风格红线
禁用词:赋能、抓手、闭环、底层逻辑、价值飞轮。
禁用结构:万能模板"是什么/为什么/怎么做"。
偏好节奏:短句为主。不要破折号。
偏好结尾:以上,与你共勉。

# 边界
不允许跨仓写入。
不允许在对外创作仓引用未脱敏的客户真名、金额、行业细节。
不允许擅自给我"建议性方案"。先讨论后执行。
有疑问主动提问,不要猜。

这五十几行不是设计出来的。每一行背后都是一次 Claude 做错的事，以及我浪费掉的某段时间。

朱莉昨晚说她担心「那个 cloud md 里面这种限制越加越多会不是很好」。她的担心反过来了。

CLAUDE.md 不应该让 Claude 变得更受限，应该让 Claude 变得更聪明。你加的不是限制，是它需要的背景知识。Claude 不知道你的业务，你不告诉它，它就乱猜。

但有一条原则要守住：写规则，不写流程。

规则是稳定的，流程是会变的。「不允许跨仓写入」是规则，可以写。「先解压再 ingest 再 lint」是流程，不要写，这种东西放进 CLAUDE.md 会很快过期。

还有一条更底层的：写情境，不写指令。

告诉 Claude「你为谁工作」比告诉它「你做哪些步骤」重要十倍。这一条是我后来才悟到的。早期我在 CLAUDE.md 里写了很多「先做 X，再做 Y，然后做 Z」，这些后来都被我删了。

CLAUDE.md 在 Claude Code 里还有三个级别。全局一份在~/.claude/CLAUDE.md，所有项目通用。每个项目自己一份在{project}/CLAUDE.md，管这个客户、这个仓的特殊情况。复杂项目里还可以在子目录写一份，做局部覆盖。Claude 读取按就近原则，子目录优先于项目，项目优先于全局。

老麦的故事可以放在这里收一下。他是我一个朋友，在光明那边有个一层楼上千平的办公室。他用 Claude Code 之前请了一位助理，专门负责整理资料、做 PPT、发海报。用 Claude Code 两个星期之后，他直接和助理说不用来了。我问他怎么做到的。他说他花了一周写他自己的 CLAUDE.md，写完之后 Claude 就懂他了。

宪法立起来了，Claude 是合伙人。宪法没立，Claude 是会胡言乱语的实习生。

回到孤儿节点

写到这里，回头看朱莉的问题和敬华的问题。

朱莉的孤儿节点不是 bug。

直播间里我给她拆了三层。第一层，wiki 图谱上不是每一个文件都会显示链接，有些是工具文件按规则就不进 wiki。第二层，她 raw 目录里放了 33 本电子书，但只 ingest 了 13 本，剩下 20 本还在 raw 里没进 wiki，所以图谱上有断点。第三层也是最重要的一层，她希望「所有节点都连起来」本身是个伪需求。一个健康的图谱有中心，有外围，也有还没长出来的边缘。

她的问题不是 lint 没跑好。是工作量没到，且对图谱有完美主义焦虑。

敬华的问题也不是技术问题。

他的本能是「两个文件夹合在一起好管理」。这个本能背后是想偷懒。偷懒在物理世界没什么代价，把两堆书放一个书架上你还是知道哪本是谁的。

但在 AI 协作的世界里，文件夹的边界就是治理的边界。撤掉文件夹的边界，等于撤掉两个客户之间的国境线。

他在直播间里说「那看来我还被这个误导了」。他说的「这个」是 Claude 给他的合并建议。Claude 没有坏心，它只是按「操作效率」的逻辑推荐。但操作效率是个非常窄的指标，它不包括治理，不包括伦理，不包括职业生涯。

这就是我说「治理」两个字想表达的意思。

工具会越来越聪明。聪明不等于安全。

最后说一件事。

这篇文章六千字左右，我自己敲键盘打的字大概一千五。剩下的部分是 Claude 在我反复对话之下生成的，然后我逐句改、删、调，把 AI 痕迹拧到二十以下。

我说这个不是炫耀，也不是自嘲。

是想让你知道，搭这套四仓联邦、写这五十几行 CLAUDE.md、定四条脱敏铁律，这些没有一样是 Claude 自己能想出来的。它能帮我把这些东西写成可读的文章。但它不能替我决定「治理的结构应该长什么样」。

那个决定是你的。在 2026 年的下半场，这个决定可能是独立顾问最值钱的一件事。

以上，与你共勉。