OpenClaw爆火引发入职提示词热潮，但静态文档注定崩解。本文提出CLAUDE.md路由器模式，用分布式上下文文件实现动态技能注入，让AI根据所在位置自适应行为，解决token效率与维护难题。
一只龙虾引发的AI界大地震
上周GitHub上有个项目直接炸裂，八万多颗星星在一周内疯狂点亮，整个科技圈都在为一只卡通龙虾疯狂打call。
如果你这几天刷过X平台，肯定被这只龙虾刷屏了。它叫Clawdbot，后来改名叫Moltbot，现在又叫OpenClaw，总之就是一个开源AI助手，能在你自己的电脑上跑，连上WhatsApp或者Telegram，然后神奇的事情发生了，它居然会主动干活，完全不用你开口吩咐。
早上自动给你播报日程，帮你整理收件箱，管理日历，甚至还能自动帮你办登机手续。这就是传说中的主动式AI，所有人都在等的东西终于来了。
但有个问题我观察了一整周，发现了一个特别要命的规律，这个坑会在几周后让所有人摔得鼻青脸肿。
那些真正从OpenClaw身上榨出价值的人，正在疯狂写一种叫"入职提示词"的东西。这些文档长得吓人，动辄几千字，详细解释他们是谁、怎么工作、 priorities是什么、哪些红线绝对不能碰。我亲眼看见一个哥们儿花了整个周六打磨他的入职文档，把自己的沟通偏好、工作时间表、饮食禁忌全都塞了进去。结果到了周二，这个AI就把一半内容忘得一干二净，居然开始在他专注工作的时间段推荐午餐会议。
这就是核心问题所在。入职提示词本质上是个临时补丁，注定会崩。
入职文档为什么会烂掉
入职提示词就是一大段静态上下文，你贴进去然后祈祷AI能记住。但它活在一个注定会被清空或压缩的对话里，而且完全没有结构，没有层级，没法表达"这个比那个更重要"。所有内容权重一样，结果就是所有内容都没权重。
更惨的是，它是块状的。你的偏好、你的边界、你的专业知识、你的沟通风格，全被塞进一大坨文本里，AI就算没在做相关的事也得全程扛着这些内存。这就是所有做AI代理的人都会遇到的上下文爆炸问题。Token窗口是有限的，就算窗口够大，内容太多也会让性能变差，因为模型会被无关信息搞晕，开始关注错误的东西。
解决方案不是写个更好的入职文档，而是换一种架构。
CLAUDE.md文件作为本地化技能
过去几个月我一直在为Claude Code搞一个东西，我觉得这个方案能解决问题。看着OpenClaw爆火，我意识到这个模式适用于任何会在文件系统里逛来逛去的代理，而OpenClaw开始在你电脑里翻箱倒柜的时候，本质上就是在做这件事。
我的做法不是搞一个巨型上下文文档，而是在文件系统里到处撒小上下文Context文件。每个文件住在特定目录里，告诉AI关于这个领域需要知道什么。关键就在这里，这些文件本质上就是本地化技能，根据AI在看哪里动态注入。
当AI导航进一个目录并读取那里的上下文文件时，它就在经历一次动态技能注入。进入食谱文件夹，烹饪上下文加载。进入财务文件夹，不同的上下文、不同的约束、不同的行为。AI根据它在哪里自适应，而不是只看对话开始时你告诉它什么。
这比入职文档强多了，因为它不需要一次性搞定所有事。它带AI到处逛。你可以调整特定领域的内容，不用碰其他东西。
路由器模式
这就是架构实际运作的方式，我觉得这对任何做主动式AI的人都重要。
你有一个根上下文文件，很详细，大概五百行，涵盖AI需要知道的关于整个系统的一切。把它当成通用导航。但其他所有上下文文件都很短，大概五十到一百行，任务就是告诉AI这个目录里有什么、什么时候该看这里、接下来去哪里。这些就是路由器。
看看路由器长什么样，
my-system/ |
当AI导航进食谱目录时，它读取这个文件，立刻知道这里有什么、这个目录什么时候相关、适用什么规则。这就是技能注入，AI现在拥有了之前没有的烹饪专用上下文，而且不需要加载你的整个人生故事就能得到。
这到底给你带来了什么
最明显的好处是token效率。AI在需要时根据工作地点加载上下文，离开时可以释放。导航进食谱文件夹？加载烹饪上下文。导航出去？释放。你不用在无关信息上烧token。
但我没想到的是维护变得多容易。当某个领域发生变化时，你更新那个目录的上下文文件就行，不用在一篇两千行的入职文档里疯狂翻找正确段落。上下文住在它描述的东西旁边，所以真的能保持更新。
行为真的会根据位置改变，这原来还挺重要的。在你的财务目录里工作的AI应该比帮你搞创意写作的AI更谨慎。有了分布式上下文文件，你可以本地编码这些约束。关于财务里绝对不能删除任何东西的偏执规则，不需要污染你的写作文件夹，在那里你可能希望AI更激进一些。
最让我惊讶的是系统如何引导导航。每个路由器不只是描述这里有什么，还告诉AI接下来去哪里找。"如果你需要X，检查这个目录。如果你需要Y，去那里。"AI跟着线索走，而不是盲目搜索。文件系统变成了可导航的图，而不是扁平的搜索空间。
哪里会崩
我得诚实说说这个模式在哪里会崩，因为它确实有崩的时候。
设置成本是真实的。你不可能一个下午就搞定，我迭代了好几周才让路由器结构感觉对，现在还在微调。如果你只是周末搞个小项目，简单的入职文档可能就够了。这是给长期使用的代理准备的基础设施。
它还需要AI真的去读上下文文件，这在每个设置里都不是自动的。Claude Code天然就会读CLAUDE.md文件，但如果你在做定制的东西或者用Moltbot，你可能需要自己把"进入目录时读取上下文文件"的行为接上线。模式是靠谱的，管道工程各有不同。
还有过度工程的真实风险。我发现自己给其实不需要的目录创建上下文文件，现在我有些文件只会说"这个文件夹是杂七杂八的东西"，这...没啥用。我定下的规则是，如果你在上下文文件里滚来滚去找相关部分，那它就太长了，应该拆分。但如果你创建上下文文件时绞尽脑汁也填不满有意义的内容，那你可能根本不需要在那里放一个。
怎么真正开始
你不需要一上来就建整个系统。从一个根上下文文件开始，描述你的整体设置，你是谁、主要领域是什么、全局约束有哪些。先用一周。
当你注意到AI在某个特定领域搞混时，那就是在那里创建上下文文件的时候。"哦，它老是搞砸我的 meal planning，让我给那个目录加点上下文。"系统从实际摩擦中自然生长，而不是试图提前预测一切。
当一个上下文文件太长时，拆分它。父节点变成路由器，指向有详细内容的子节点。层级随着复杂度需求自然加深。
这对OpenClaw意味着什么
那些为OpenClaw写详细入职提示词的人已经get到了正确的洞察，主动式AI需要深度上下文才能好好工作。但他们用静态文档解决这个问题，这些文档会随时间退化，而且不scale。
分布式上下文文件模式基本上是同一个想法的基础设施版本。上下文住在相关的地方，需要时加载，引导AI在你的文件系统里导航。本地化技能，而不是试图一次性搞定一切的块状简报。
我觉得接下来会这样发展，现在所有人都在从零建这些系统。
OpenClaw用户写入职提示词，Claude Code用户写CLAUDE.md文件，公司建内部知识库试图搞清楚怎么暴露给AI代理。但模式是一样的，你需要结构化的持久上下文来塑造AI的行为，它需要可维护、需要高效。
有人会把这个产品化。不是AI代理本身，而是让代理真正有用的上下文层。元框架，如果你想这么叫的话。现在我们都用markdown文件和目录结构做这件事，能用但感觉像1996年手写HTML。这个基础设施的版本要来了，它将区分感觉像助手的代理和感觉像需要你 babysit 的聊天机器人。
OpenClaw向所有人展示了主动式AI长什么样。上下文架构才是让它真正工作的关键。
如果你在用任何碰文件的代理，现在大部分都碰，这个模式值得理解。
入职文档让你起步。分布式上下文系统才是让它持续工作的保障。