语言的边界，就是协作的边界

最近我在做一件事：把自己大部分的工作流程"skill 化"，凡是有标准化流程的部分，都整理成 SKILL.md。 与此同时，在使用 Hermes Agent 这类个人协作助手的过程中，我越来越关注 SOUL.md 和 USER.md 怎么写，才能更精简、更贴切，因为它们决定了 Agent 能否真正成为懂我的协作伙伴。

这也让我开始想一个更大的问题：以前大家写代码，现在变成写 MD 了。 以前一个项目最多就一个 README.md，写给人看的。 现在打开同一个项目，你会看到：AGENTS.md、SKILL.md、SOUL.md、USER.md、DESIGN.md， 还有一类比较特殊，是 AI 自己写给自己看的：MEMORY.md 和 NOTES.md，用来维持跨会话的记忆和任务状态。

文件变多了，这不奇怪。奇怪的是它们都是 .md，都是写给 AI 看的。 怎么把这些 .md 写好，是我还在不断摸索的事。这篇文章是我对这个变化的一次思考。

.md的受众变了

README.md 的受众是人。人能通过语境、默契、长期相处去补全没写出来的部分。 你写"代码要干净"，同事大概知道你什么意思。

AGENTS.md 的受众是 AI。它没有语境，没有默契，也没有对你的长期印象。 它只能从 context window 里的 token 去理解你。你没写进去的，对它来说就不存在。

这是一个根本性的差异，不是程度上的区别。Anthropic、Karpathy 等人最近在推一个概念：Context Engineering（上下文工程）。 它是提示词工程的升级，从"怎么写一句好提示"，进化到"系统性地管理给 AI 看什么"。 本质上，就是在回答：你的领域知识、你的工作方式、你这个人，怎么变成 AI 能理解的 token。

各大工具也在用自己的格式诠释这件事，如Claude Code 用 CLAUDE.md。AGENTS.md 目前是 Linux Foundation 主导的开放标准，60 多个工具都支持。 格式不同，但本质一样：在开始工作之前，让 AI 先了解作为协作者必须知道的工作说明。

为什么要拆成文件

软件工程里有关注点分离（Separation of Concerns），不同逻辑分不同模块，互不干扰。 这个思路正在被迁移到 AI 上下文管理里：项目知识放一个文件，能力规范放一个，身份信息放另一个。

但这不只是工程整洁的问题。维特根斯坦有个概念叫语言游戏：意义不是固定的，它由具体的使用场景决定。 "质量"在编码协作里是测试覆盖率，在写作协作里是某种难以言说的节奏感。同一个词，在不同的语言游戏里，意义完全不同。

所以要拆。AGENTS.md 定义的是"编码协作"这个游戏的规则：

• SKILL.md 定义的是"能力与工作方式"的游戏规则
• SOUL.md 定义的是 AI 自身价值观与行为准则的游戏规则
• USER.md 定义的是 AI 对用户理解与偏好认知的游戏规则 把它们混在一起，AI 会乱，更重要的是，你自己写着也会越写越乱，因为不同层次的知识有完全不同的表达逻辑和密度要求。

每一份 .md 文件，都是在为一段特定的协作关系划定边界，明确它的词汇表和使用场景。 这不是文档分类，而是在给 AI 建立不同场景下的认知框架。 理解了这一点，三重外化的结构就清晰很多了。

三重外化的知识

我用一个比喻来解释：给一个长期远程助理做入职交接。 你以后要跟他协作多年，他在另一个城市，没法通过日常相处慢慢懂你，只能靠写出来的东西。

1. 项目知识

第一层：项目知识 → AGENTS.md

最容易写，也最直接。用什么工具、禁区在哪、commit 格式、哪个目录不能手动改。 这相当于技术 onboarding 文档，规则明确，AI 能很好地遵守。 比如一个Web项目的 AGENTS.md 可能写：

• 对apps/下目录每个子项目的一句话介绍（避免每次重复扫描浪费Token）
• TS 文件先跑 npm typecheck，如果是API改动完必须运行 npm test

AI 只需要知道"是什么和怎么做"，不需要理解"为什么"。

2. 工作方式

第二层：工作方式 → SKILL.md

中等难度，需要把工作流程具体化、标准化（SOP化）。

比如每周销售洞察报告的生成：你希望AI怎么处理和汇总数据、哪些维度必须覆盖、图表用什么格式、分析建议应当有多深入、用什么语气和结构来写。

通常会包含输出模板、风格偏好、重要指标计算方式、以及必须避开的误区。 例如，一个销售团队的 SKILL.md 可能会规定：报告标题要简明清晰、每个结论需有对应的数据支撑、优先高亮异常变动、最后一节需要给出行动建议而不是泛泛总结。

写这层要求你把“平时自动化完成的事情”具象化表达出来，写着写着会发现：原来很多习惯和直觉，其实可以被抽象为具体可执行的步骤和规则。如果不给详细的SOP，每周汇报的结果可能就非常发散，换个基座模型生成的结果也千差万别。 你不会希望每周都由不同的分析师按照其各自的标准和风格给你输出汇报，我们希望他了解我们想要的，重要概念不能混淆，最好每次提交的汇报材料才有前后连贯性。

3. 用户画像

第三层："你是谁" → SOUL.md 和 USER.md

这一层最难写，也最值得花时间，需要明确区分两个文件，它们指向的方向完全不同。

SOUL.md 是 Agent 自身的底层画像，定义的是这个 AI"是什么样的存在"：它的价值观、决策原则、行为边界。 名称用"灵魂"不是随意的，它确实在定义那个层面的东西。 想象一个场景：用户要求 Agent 做一件与它价值观冲突的事，SOUL.md 决定它如何应对。 它不是规则清单，而是 AI 的性格底色。

USER.md 是 AI 对与它协作的用户的理解与画像。 它不是用户自己写的自我介绍，而是 AI 积累下来的"对你的认识"：你的沟通风格、偏好、上下文背景、在乎的事。 SOUL.md 决定 AI 是什么，USER.md 决定 AI 怎么理解你。两个文件，两个方向。

类比回来：SOUL.md 像是这个远程助理自己的价值观底稿，USER.md 像是他通过长期相处对你建立的印象。 这一层对于需要高度自主性、长期独立运作的 Agent 尤为关键。 如果只是做简单任务执行，前两层基本够用。 但如果是像 OpenClaw、Hermes Agent 这类个人协作助手，需要在你不在场的情况下代表你做判断、处理复杂问题，这两个文件就不可或缺了。

三层的核心差异不是信息量，而是可言说性。第一层几乎全部可以言说，第三层大部分只能感知。

克制比堆砌重要

但 .md 文件不是越多越好，越长越好。 LLM 的 context window 就像人的工作记忆，有上限， 而且研究者发现一个现象叫"context rot"：文件越长，AI 越会选择性忽略，你最在意的那条规则可能正好被跳过。 前沿模型大概能稳定遵守 150 到 200 条指令，超出这个范围就开始衰减。上下文一长，模型很容易遗忘掉重要的规则。

这个约束其实是好事。它逼着你回答：什么是真正重要的？

写 SKILL.md 不是把所有偏好都堆进去，写 USER.md 也不是写自传。 它们是高信息密度的提取，只放那些 AI 没有就一定会猜错的东西。剩下的，不写。尽量多写正向的要求，少写负面的禁止。 SKILL的创建过程是渐进的，需要边使用边完善。使用过程中发现模型容易重复犯同样的错，再记录下来。

语言、知识与边界

这件事让我想到两位哲学家，他们从不同方向照进了同一个问题，这个问题其实很早就被思考。

维特根斯坦在《逻辑哲学论》中写道："我的语言的边界，就是我的世界的边界。" 对人类来说，这是认识论上的隐喻，你能思考的边界受你掌握的语言和概念所限。 对 AI 来说，这是字面的事实：它的"世界"就是 context window 里的 token，你没写进去的，在它的世界里就不存在。 当你写 SOUL.md，你在字面意义上扩展了 AI 的世界，让它能触及你这个人。

他还有一个概念叫私人语言论证：纯粹私有的语言是不可能的，意义需要公共性，需要可以被他人验证的准则。 你的审美直觉、你的判断风格，现在是"私有的"，存在你的神经元和直觉里，不需要公共形式也能运转。 写 SOUL.md 和 USER.md，就是在强迫这些私有知识寻找公共形式，让它变得可传递、可被检验。

波兰尼从另一侧说了同样的事："我们知道的，永远多于我们能说出来的。 "这是隐性知识（Tacit Knowledge）的本质。 老木匠判断木头纹理的直觉、老医生凭第一眼感知病情的经验，存在他们的手上、眼神里，无法被完整写进手册。 徒弟学的不是手册，是跟着师傅看三年。

SOUL.md 和 USER.md 面临的正是这个困境。 你最深处的审美偏好、你的判断直觉，这些是你最有价值的知识，也是最难言说的。 你可以近似，但无法完整捕捉。

这两个边界夹在一起，才是这个问题的完整张力：AI 只能理解被写出来的（维特根斯坦），而人能写出来的永远不够完整（波兰尼）。 .md 文件就活在这两道边界之间，尝试弥合这道裂缝。

但这里有个反直觉的地方：写不出来，不一定是知识太复杂，有时候是你自己还没想清楚。 被 AI 协作逼着写这些文件，是一种被动的自我澄清。 你在向 AI 解释自己的过程里，也在重新认识自己。

我的思考

这些 .md 文件正在成为每个人的 AI 接口规范。 就像 API 有 OpenAPI spec，你这个人也开始需要一套 spec，让任何 AI 工具都能快速理解你怎么工作、你是什么价值取向。

其实不只是和 AI 协作，和人协作也是同一个道理。 你需要把自己的洞察、观点、立场、价值观，用显型或者隐性的方式以对方更容易接受的方式呈现出来，减少沟通协作过程中的误解。 这个过程帮助对方更完整地理解你，以及你真正想实现的目标。 对 AI 也是如此，只是它更依赖显性的文字，没有人际沟通里那种弹性和容错。

但我觉得最有意思的趋势，还不在这里。

最近在一些个人协作助手上，出现了一个被称为 Dreaming 的能力。 以 OpenClaw 的 Auto-Dream 为例，它会在每天凌晨四点触发一次"梦境循环"（Dream Cycle）：自动扫描最近几天的协作日志，提炼关键决策、学习到的模式、未完成的任务线索，然后把这些知识分层写回 MEMORY.md，同时持续更新它对用户的理解（USER.md）以及自身工作方式的认知。它的 README 里有一句话让我印象很深："大脑并没有在睡眠中停止工作，那是它最重要工作的开始。"

这意味着什么？这套 .md 文件，不再只是人手动维护的静态文档，它开始有自己的进化通道。 AI 不需要等你告诉它哪里需要改，它自己在反思、在提炼、在更新对你和对自己的认知。 就像和一个真实的人长期共事，他会在日常工作中慢慢更懂你，而你不需要每次都专门开会校准。 AI 也开始需要时间去反思和反省了，这个话题我想单独写一篇文章来展开。

不管 Dreaming 最终走向哪里，有一件事我越来越笃定：把自己想清楚并写出来，本身就是值得做的事。 不是为了 AI，是为了你自己。

参考