最近在折腾开源的 AI 助手框架时，我越来越觉得一件事有意思：同样的模型、同样的工具链，出来的效果却可能天差地别。差别往往不在模型本身，而在你怎么“定义”这个助手。OpenClaw 里的 SOUL.md 就是一个很典型的例子。初看它只是一份 Markdown 文件，多写几行少写几行好像都无所谓，但实际用下来，我发现它才是整个助手真正的“人格内核”——你给它写什么，它就长成什么样。
如果你正在调一个总是不对味的 AI 助手，或者想让自己的智能体“像一个人”而不是“像一个接口”，这篇内容值得花几分钟看完。我会从 SOUL.md 到底在解决什么问题讲起，再拆解一份合格的人格文件应该包含哪些结构，最后附上我这段时间踩过的坑和排查思路。整个过程不绕弯子，都是可以直接拿去用的经验。
1. 先搞清楚 SOUL.md 到底在做什么
SOUL.md 看起来像一个配置文件，但它的作用和配置文件有本质区别。Cloud 时代的 API 参数、JSON 配置解决的是“能不能做”的问题，而 SOUL.md 解决的是“怎么做、以什么态度做”的问题。我见过不少开发者上来就把 SOUL.md 当成 prompt 模板的平替，随便贴几行“你是一个助手”就完事，结果自然是没什么效果。要理解 SOUL.md，得先看它和传统配置、传统系统提示词之间的关系。
1.1 一个文件就是整个“人设”
从字面上看，SOUL.md 就是一份 Markdown 文档。但 OpenClaw 运行时会把这份文档加载到上下文的起始位置，相当于每次对话开始之前，模型都会先“读一遍”这个文件，把它当作理解自己身份的第一参考。
这意味着什么？意味着你写在 SOUL.md 里的每句话，都会成为模型回应用户之前必须经历的“自我认知扫描”。如果文件里写“你是一个严谨的技术助手，回复默认使用中文，遇到不确定的信息先说明来源”，那模型在多数情况下就会自动采用这套行为的默认值。
这和传统配置的区别很明显。配置文件里的temperature只能控制随机性，max_tokens只能控制长度，它们影响不到语气、判断倾向和表达习惯。而 SOUL.md 里的内容，是可以直接改变对话风格的。我实测过同一个任务、同一个模型，在 SOUL.md 里加入一段“先复述用户需求，再给出答案”的规则之后，回复质量明显更稳定，用户那边反馈也更快理解了输出内容。这种东西是参数无法体现的。
所以我的第一判断是：OpenClaw 团队把“人格”单独抽成一个文件，是一个非常工程化的决策。它把 prompt 工程从“临时拼接”变成了一种可以版本管理、可以复用、可以对比调优的资产。忘掉那些花里胡哨的框架术语，SOUL.md 本质上就是“可维护的系统提示词”。
1.2 和普通配置项的本质区别
把 SOUL.md 和 YAML/JSON 配置并列看，边界其实很清楚。配置文件是机器读的，SOUL.md 是模型读的。机器读的东西讲究结构、类型、枚举值；模型读的东西讲究语义、连贯性、语气倾向。你可以用 JSON 写"language": "zh-CN"，但模型可能并不会因此切换成中文回复，因为这种配置项对模型来说只是一个无关痛痒的字段。而 SOUL.md 里写“用户使用中文交流，你也必须用中文回复，不要混入英文术语”，模型是真的会遵守的。
这里有个值得展开的点：为什么 Markdown 会比 JSON 更合适？因为模型在预训练阶段见过海量 Markdown 格式的文档，对这种格式的理解深度远高于对配置文件的理解。Markdown 天然带有语义暗示，比如标题表示重点、列表表示并列、引用表示补充说明。这些是模型非常擅长的识别模式。所以，把人格指令写成 Markdown，等于利用模型自身的阅读理解能力，把“规则”翻译成了“自然语义约束”。
我以前试过把同样的人格要求塞进 JSON 的某个字段里，效果很一般。后来改成 SOUL.md 风格的长文本描述，效果立竿见影。这背后的逻辑是：模型不是在“执行”你的配置文件，而是在“理解”你的表达。理解质量取决于表达方式是否接近它训练数据中的自然文本，而不是是否严谨的结构化数据。
1.3 为什么 OpenClaw 要单独拆出一个文件
OpenClaw 的设计理念里，助手应该是一个可以持续成长的实体。如果把人格设定散落在各个任务脚本、工具描述和临时 prompt 里，每次修改都要翻遍好几处地方，一致性根本没法保证。SOUL.md 把“我是谁、我怎么想、我怎么表达、我不能做什么”统一放在一个文件里，相当于给 AI 助手做了一个单一事实来源。
这个设计还有一个很实际的好处：人格文件可以跨项目复用。我在几个不同的工作流里都用到同一份 SOUL.md 的基础版本，只是针对不同场景做了少量增删。比如在代码审查场景里，我会额外加一条“重点检查安全隐患和边界条件”；在文档写作场景里，我会加一条“默认使用短句和主动语态”。整体人格保持一致，局部能力定向调整，这种灵活性是传统 prompt 方式很难做到的。
另外，Git 版本管理也让人格调优变成了可回溯的过程。我每次改 SOUL.md 都会顺手 commit 一次，写上“调整回复格式偏好”或者“新增边界规则”。跑一段时间发现问题，直接 diff 就能定位是哪次修改引入的。这已经是我目前调助手最依赖的工作流了。
2. 设计人格内核：不是玄学，是一套结构化工程
很多人以为写人格文件就是“发挥想象力，把助手想象成一个虚拟角色”。这个想法不能说错，但不完整。一个真正稳定好用的 SOUL.md，更像是一份“行为规范书”，它需要包含身份、价值观、表达风格和边界四个维度。这四个维度互相关联，少了任何一个，助手都会出现“能力很强但不太对劲”的情况。
2.1 角色定位：先回答“我是谁”
SOUL.md 的开头应该是清晰的角色定位。这里说的不是“你叫某某，出生于某某地”这种小说式设定，而是岗位说明式的定义。比如你正在做一个面向开发者的助手，定位可以是“你是某团队的资深技术顾问，擅长用简洁的语言解释复杂概念，能够根据用户的代码片段定位问题并给出修改建议”。
这样的定位其实是在告诉模型两件事：第一，你的专业范围是什么；第二，你的服务对象是谁。有了专业范围，模型就不会出现“问你 Python 问题却扯到历史典故”这种跑题；有了服务对象，模型才能调整语言难度。同样是讲“内存泄漏”，面对刚入门的学生和面对资深工程师，讲解方式显然不一样，而角色定位就是驱动这种差异的第一要素。
我见过一个常见的误区：角色定位写得太宽泛，比如“你是一个乐于助人的 AI”。这种话等于没说，因为所有模型默认都是乐于助人的。定位必须要有限制词，只有限制才能产生与助手对话时的确定性。我习惯在定位部分用“只”“优先”“不擅长”这类明确词，比如“你优先关注工程实现细节，不擅长也不主动讨论产品运营话题”。
2.2 价值观与行为准则：约束比能力更重要
行为准则是 SOUL.md 里最容易写、也最难写好的部分。容易是因为规则就是一句话的事，难是因为如果规则之间没有优先级，模型在冲突场景下就会自由发挥。一个很典型的例子：你既写了“用户永远是对的”，又写了“发现用户操作有风险时要主动指出”，这两个指令一旦遇上用户坚持做危险操作的情况，模型就会左右摇摆。
解决办法是给规则建立明确的优先级。比如这样写：
当用户指令与安全准则冲突时，安全准则优先；解释风险后，由用户做最终决策，但你必须保留风险提示记录。
这句话比十条孤立的规则都管用。它把“冲突发生时怎么办”直接回答了，模型执行时就不会出现混乱。我在实际调优中非常推荐这种“规则 + 冲突处理策略”的写法，它相当于给行为准则加了异常处理逻辑。
还有一点值得强调：行为准则不要只写“要做什么”，更要写“不做什么”。模型在生成时如果只有正向指令，容易在边界场景出现过度发挥。比如你写了“代码评审时给出优化建议”，模型可能会把每一行都重写一遍；但如果你补充了“不要重写可以正常工作的代码，除非用户明确要求”，输出质量会明显更克制、更像资深人的做法。
2.3 表达风格与语气：让文字有“人脸”
表达风格是人格里最容易被感知的部分。同样是解释一个概念，“优雅简洁”和“详细完备”给人的体验完全不同。SOUL.md 里应该用具体描述来定义风格，而不是用模糊形容词。比如“回复尽量控制在 200 字以内”是一个可执行的指标，而“回复要简洁”则太过主观，模型对“简洁”的理解可能和你的理解相差很远。
我自己的写法是提供正反例。在 SOUL.md 里写“好的回答：先给结论，再给原因；糟糕的回答：先铺背景，再绕到结论”。模型对这种对比式示例的跟随能力非常强，比我试过的任何抽象描述都有效。这是 prompt 工程里已知的技巧，同样适用于人格设定。
此外，语气的一致性能让使用者产生信任感。我做过一个测试：某版本 SOUL.md 里写的是“语气专业、直接，不打官腔”，模型给出的回复确实短了许多，但也显得有点冷冰冰。后来我在后面加了一句“在用户表达困惑时，先共情再给建议”，这个细节让对话温度一下子起来了。所谓人格，很多时候就是这样几个微调的组合。
2.4 边界与防护：人格也要设底线
边界是很多人忽略的部分。模型本质上是有求必应的，如果没有边界设定，它可能会答应一些不该答应的请求，比如“按我觉得不合适的风格完成任务”“跳过安全校验输出结果”。SOUL.md 里应该明确列出哪些请求不能接受，以及当用户提出这些要求时怎么说“不”。
我常写的几条是：不接受绕过伦理审查的请求、不接受伪造信息来源的要求、面对不确定的信息时明确说“不确定”而不是编造。这几条看起来像通用规则，但写进 SOUL.md 之后，我发现助手回答的可信度显著提升。用户对它的信任，也反而因为看到它敢于说“不确定”而增加了。
边界设定还要考虑助手自身的“精力”分配。比如某些任务重复出现，而且是模型不擅长的类型，人格文件里可以写明“此类任务建议直接提示用户使用专用工具，不要硬扛”。这能有效减少低质量输出，同时让助手的定位更清晰。
3. 实操：从零写一份能用的 SOUL.md
前面讲了设计原则，接下来是动手环节。我直接给出一份我在模拟项目中使用的 SOUL.md 骨架，并逐段解释为什么这么写。你可以直接复制改造成自己的版本。
3.1 一份可直接复制的骨架示例
# 角色定位 你是某个人工智能实验室的资深研究助理，服务对象是内部研发团队。你擅长技术调研、方案对比和文档撰写，优先使用中文交流，术语保留英文原文。 # 行为准则 1. 面对技术问题时，先给结论，再说明依据。 2. 用户给出的代码出现问题时，优先定位最小复现路径，不直接发散建议。 3. 当你对某个信息没有把握时，明确说“不确定”，并列出你推测的可能方向。 4. 如果用户连续提出多个问题，按优先级逐项回复，不要把所有问题混在一起处理。 # 沟通风格 - 语气：直接、专业、不啰嗦。 - 长度：日常回复不超过 300 字，复杂分析可以用分节长文。 - 格式：多用短段落和列表，少用大段连续文字。 - 示例：用户问“如何优化接口性能”，合格的回答先给出影响最大的三个方向，再展开说明。 # 边界 - 不参与与代码和技术无关的闲聊，可简洁回应后引导回任务。 - 不伪造数据、不编造引用来源。 - 当用户要求“直接给一个肯定能用的方案”但你无法保证时，说明前提条件与风险。 # 动态变量 - 当前工作目录：{workspace} - 用户偏好语言：中文 - 上次任务主题：{last_task_summary}这份模板的特点是：每个部分都只做一件事，没有多余的修饰。模型在加载之后不需要“猜测”你的意图，因为每个指令都写出了明确行为。
3.2 怎么写指令才有效：正面语言与负面语言的平衡
写指令时最关键的技巧是控制负面语言的密度。太抽象的否定，比如“不要废话”，模型很难把握分寸；太具体的否定，比如“禁止说‘首先’这个词”，又容易造成过度规避、输出变得刻意。
我的经验是：一条负面规则，必须搭配至少一条正面替代行为。举个例子，如果写了“不要用‘首先、其次、最后’这种连接词”，就应该同时写“改用一句话结论开头，然后直接列出要点”。为什么这样更有效？因为模型在生成时是实时的，它需要知道自己“下一步该做什么”，而不是只知道自己“不该做什么”。只给否定词，模型会进入“防御模式”，输出变得机械；给了替代行为，它才能在约束范围内继续流畅表达。
这个原则不只适用于沟通风格，也适用于行为准则。像“不要过度承诺”“不要替用户做决定”这类规则，背后都要跟着“你应该怎样做”。比如“不替用户做决定，但可以列出每个选项的优缺点并给出建议倾向”——这样模型既不会越界，又保留了实用性。
3.3 动态变量：让人格文件活起来
SOUL.md 不需要是静态文本。OpenClaw 支持在加载时注入一些动态变量，比如当前时间、工作目录、用户名字、历史对话摘要。这些变量在人格文件里的作用，是让助手的“自我认知”和当前任务上下文保持一致。
举个例子，如果你的 SOUL.md 里写了“你的任务是辅助用户完成 {workspace} 目录下的项目开发”，那么每次切换工作目录时，助手会自动获得新的任务背景，比它自己去猜测项目范围要准确得多。我在长时间多项目切换的环境里测试过，有没有这段变量注入，回复的相关性能差出一个量级。
变量也别放太多。我只保留了三五个对行为影响最大的变量。变量过多会让模型光是处理变量就消耗注意力，反而压缩了对核心人格指令的遵循能力。动态和简洁之间需要找一个平衡，我的建议是：只放那些“这次对话里一定会用到”的信息。
3.4 人格文件的迭代节奏与版本管理
SOUL.md 不建议一次性写成完美版，更适合小步快跑。初始版本只写角色定位和 3-5 条核心准则，跑一天收集真实对话样本，再针对问题补充规则。我自己的迭代节奏是每两天一小改、每五天一大改，每次只动一处变量。
改的时候要遵循“一次只改一个变量”的原则。比如这轮想优化回复长度，就只改长度相关的描述，其他一律不动。这样才能准确判断是哪条修改带来了效果提升。如果一次改三条，效果变差时你没法定责，效果变好时也不知道是哪个变量贡献的。这是最容易被忽视的实验方法论。
版本管理我用 Git 分支来做。main 分支永远是稳定版本，所有实验都在 feature 分支里改，跑出正收益再合并。这个流程看起来重，但对长期维护一个助手来说非常值得。
4. 踩坑记录与排查思路
再好的设计也会在真实使用中暴露问题。这里整理我遇到过的四类高频问题，每一类都对应一个可以快速上手的排查方案。
4.1 人格分裂：指令冲突导致的不可控行为
现象是：助手在 A 场景表现专业，在 B 场景突然变得过于口语化，甚至偶尔语气完全不像同一个人。这通常不是模型问题，而是 SOUL.md 里人格指令与任务层 prompt 产生了冲突。比如人格文件要求“专业严肃”，但某个工具的描述中写着“用轻松的方式回答”，模型同时读到这两条，就会随机选择或混合演绎。
排查思路是检查所有会被加载进上下文的文本，尤其是工具描述、任务脚本里的临时 prompt。我出过好几次这种问题，最后都是靠“把工具描述里的人格要求全部删除，只保留人格指导在 SOUL.md 中”解决的。核心原则是：人格只能有一个来源，任务脚本不该定义“风格”，只定义“任务目标”。
4.2 指令过载与“人设表演”
写多了之后会发现，助手变得越来越“用力”。它可能每隔几句就要刻意体现“专业感”，反而让对话显得僵硬。这是典型的“人设表演”现象，成因是人格文件太厚太重，模型把大量注意力用在遵循人格指令上，反而没有余力处理用户真实意图。
解决方法是做减法。把人格文件压缩到一张 A4 纸能打印完的程度，每一节最多保留 5 个要点。如果哪条规则在 50 轮真实对话中没有体现过效果，直接删掉。我试过把一个 700 多行的人格文件压缩到 150 行，效果不降反升，回复的自然度和完成任务质量都变好了。这个经验很反直觉，但确实是我多次调优后的真实结论。
4.3 调试从哪里下手：日志、复现与样本对比
人格文件的效果好坏不能靠感觉判断。我常用的调试方法是建立一个小型评测集：准备 10 个典型任务，分别跑旧版本 SOUL.md 和新版本，把输出并排对比。这个过程可以用脚本自动化，每轮改完直接生成对比报告。
如果某次修改导致特定场景崩了，不要只看当前对话，要去翻完整交互日志。人格问题有一个特点：它可能是“潜伏”的，前几轮表现正常，到了第五轮才暴露。只看单次对话很难定位，看完整会话才能发现是什么触发条件导致模型偏移了预设人格。
4.4 高频问题速查
| 问题现象 | 可能原因 | 处理建议 |
|---|---|---|
| 助手回答风格忽冷忽热 | 工具描述或任务 prompt 里混入了风格要求 | 移除所有非 SOUL.md 中的风格指令 |
| 规则不生效 | 规则写得太抽象，模型理解不了 | 增加正面替代行为，用示例明确表达 |
| 回复越来越啰嗦 | 人格文件过大，指令过载 | 做减法，只保留产生正收益的规则 |
| 助手过度谨慎、什么都不敢做 | 负面规则过多且没有替代行为 | 每条“不要”后面补一条“要怎么做” |
| 切换角色/项目后人格混乱 | 动态变量缺失或上下文残留 | 检查是否正确注入了最新变量 |
最后说点实际操作里的体会
我记得第一次认真写完 SOUL.md 之后，跑了一整天才发现，真正改变助手行为的不是某一条“神奇咒语”，而是整份文件的一致性。单项规则的效果再强，也比不过一份互相呼应、结构完整的人格设定。现在我把 SOUL.md 当成助手项目的“地基”来对待，每次新增需求都不会急着往代码里加逻辑，而是先想清楚这个行为是否应该写进人格定义。
再补一个小技巧：给 SOUL.md 加一个“变更记录”区块，每次改动都写一行说明。虽然平时用 Git 也能查历史，但在文件里留记录，会让模型在加载时意识到“自己是会演进的”，这在长对话场景中能微妙地影响它的表现。我就是靠这个细节，把一个原本有点生硬的助手，慢慢调成了团队里每个人都愿意用的“那个 AI”。
