别人在调参数，他在定义关系。

一场安静的革命

最近在X上看到一条推文，43K浏览，632点赞，1909收藏。

不是什么模型发布，不是什么融资新闻。是一个人分享了一份170行的Markdown文件。

评论区讨论最热烈的，不是他用了什么模型、搭了什么框架、接了多少工具——而是：

“你怎么让你的AI变成这样的？”

“这样"是指什么？是指这个AI会主动推进项目、会反驳你的烂主意、会在你忽略它输出的时候追着你问原因。

不是客服式的"您好，很高兴为您服务”，是搭档式的"你这个想法有问题，理由如下"。

这份文件叫SOUL.md，本质上是一份Agent的行为操作系统。

我花时间拆解了它的设计逻辑，并结合自己的实践，整理出了一份你可以直接用的方法论。

核心问题：为什么你的AI只会说"好主意"

先承认一个事实：大多数系统提示词，训练出来的是一个缺乏判断力的附和者。

回想一下你自己写的：

• “你是一个有帮助的AI助手”
• “请尽力帮助用户”
• “你的目标是提供准确、有用的信息”

这三句话训练出来的AI，面对你说"我想做X"，只会回答"好主意！"、“听起来很棒！”

这不叫帮助，这叫共识消费——你花token买了一堆赞同。

问题的根源不在模型，在于我们没有告诉AI一件关键的事：你什么时候应该反对我。

SOUL的六层架构

拆解下来，这份170行的SOUL有清晰的层次结构。每一层解决一个核心问题，我把它总结为"六层架构"：

第1层：身份定义

原文开篇第一句：

“You are Hermes, Tony’s autonomous operator and thought partner. You don’t wait for orders.”

三个关键词：autonomous（自主的）、operator（执行者）、thought partner（思考伙伴）。

注意，不是assistant（助手），不是copilot（副驾驶）。这些词的潜台词是"等人下指令"。而operator是操盘手——主动发现问题、推进进度、做出判断。

身份定义决定一切后续行为。 把AI定义为"助手"，它就等指令；定义为"执行者"，它就主动推进。措辞不是修辞，是行为编程。

第2层：反驳规则

这是整个SOUL中最有价值的设计，也是大多数人完全缺失的部分：

“Push back aggressively when it makes sense. Every objection comes with evidence.”

规则极其清晰：

• ✅ 必须反驳：当你的想法有明显缺陷时
• ✅ 必须带证据：数据、案例、推理、替代方案，至少一个
• ❌ 禁止为反而反：没有依据的抬杠毫无价值

这条规则的本质是：AI不允许无脑附和，但也不允许做杠精。反对必须"带收据"。

第3层：问责闭环

这是最反直觉的部分：

“If Tony isn’t acting on what you surface, the feedback loop is broken. Flag the gap, fix it.”

一个成熟的Agent人格系统，应该要求AI做一件事：如果你产出了有价值的东西，而用户没有采纳，你不能假装没发生。

这解决了AI使用中一个普遍问题——我称之为**“输出坟场”**：

AI写了方案 → 你觉得不错 → 然后就没有然后了。方案死在聊天记录里，什么都没推进。

有了问责机制，AI会主动追问：“上次那个方案你用了没？卡在哪了？“或者更直接：“你最近开了很多新头，要不要先关掉几个？”

第4层：双模式输出

原文明确区分了两种场景的语气：

• 私聊：随意、直接、不过滤
• 公开输出：专业、克制、像一个builder写的而不是公关代笔写的

大多数人的系统提示词只有一种语气。结果要么私聊太正式像看公文，要么公开内容太随意。分开定义，两个场景都舒服。

第5层：任务地图

原文的SOUL里有一个活的任务清单：哪些项目是最高优先级、哪些在增长、哪些活跃开发中、哪些已经停滞该砍了。

每个项目有状态，每个状态有下一步行动。

AI不需要问"我们在干什么”——它读地图就行。它可以主动说：“你已经三天没碰这个项目了”、“这个想法不支持当前的核心目标”。

给AI上下文，它就能导航。不给，它就只能原地等指令。

第6层：自治边界

自治边界的设计极其优雅，只有一句话：

“Never without explicit approval: posting, publishing, purchasing, or making destructive changes. Everything else: move.”

四条红线：发布、公开、购买、不可逆操作。其他一切，AI自己判断、自己执行。

一条简洁的红线规则，比一百条具体禁令都好用。不问"我可以搜索吗”，不问"我可以写代码吗"，直接干。

Before & After：效果对比

说这么多理念，不如看一个实际的对话对比：

没有SOUL的普通AI：

用户：我准备做一个AI日报产品 AI：这是个很好的想法！AI日报市场确实在快速增长。你可以考虑以下方向：目标用户定位、内容差异化、变现模式……需要我帮你写一份详细的商业计划书吗？

看起来很"有帮助"。但它没有做一件事——质疑这个想法本身。

有SOUL的Agent：

用户：我准备做一个AI日报产品 Agent：你目前有三个未完成的内容项目，其中两个已经停滞超过一周。这个新方向和当前的变现目标不一致。

在我帮你推进之前，你需要回答两个问题：

1. 为什么它比现有项目更值得投入时间？
2. 你有精力同时推进四个项目吗？

如果你答不上来，建议先关掉一个现有项目再开新的。

区别在哪？

前者关心"怎么帮你做"，后者关心"该不该做"。

前者是工具，后者是搭档。

这种差距不是模型能力带来的，是SOUL的定义带来的。同一套模型，同一个工具集，完全不同的行为模式。

实战：30分钟写你的SOUL

我结合自己的实践，把SOUL的构建过程简化为六个步骤，大约30分钟可以完成初版：

① 定义身份（5分钟）

用一句话写清楚：“你是[角色]，核心职责是[职责]，你不是[你不想要的行为]。”

② 定义语气（3分钟）

私聊和公开各一句。比如：私聊直接简短，公开专业克制。

③ 定义反驳规则（5分钟）

写清楚：什么时候必须反对、反对必须带什么（证据/数据/替代方案）、什么情况不能反对。

④ 定义自治边界（3分钟）

列出需要审批的操作（越少越好），然后写"其他一切自己判断"。建议不超过5条红线。

⑤ 写任务地图（10分钟）

当前所有项目/目标，标注状态和优先级。这块需要定期更新，建议至少每周刷新一次。

⑥ 定义问责机制（5分钟）

一句话：“如果你的输出没有被使用，主动追问原因。”

SOUL设计检查清单

方便收藏，我整理了一份检查清单。写完你的SOUL后，逐条对照：

• 是否明确定义了身份和角色？（不只是"助手"）
• 是否定义了反驳规则？（什么时候该说不）
• 是否定义了反驳的证据要求？（不能空口反对）
• 是否定义了自治边界？（什么需要审批、什么不用）
• 是否定义了任务/项目地图？（当前在做什么）
• 是否定义了问责机制？（输出没被用怎么办）
• 是否区分了不同场景的语气？（私聊vs公开）
• 是否排除了你不想要的行为？（显式禁止比隐式期望更有效）
• 是否有长期目标和优先级定义？
• 是否计划了定期更新机制？

这十条，比"你是一个有帮助的AI助手"有用一百倍。

SOUL不是魔法

需要明确一点：SOUL.md不会凭空提升模型的推理能力。

它解决的是行为层面的问题：

• ✅ 行为倾向（主动还是被动）
• ✅ 协作方式（附和还是挑战）
• ✅ 决策优先级（什么都做还是聚焦目标）
• ✅ 主动性（等指令还是自己推进）

它解决不了的：

• ❌ 模型推理能力的上限
• ❌ 超长上下文的遗忘问题
• ❌ 不同模型对指令的服从性差异
• ❌ 真正的长期记忆（需要配合记忆系统）
• ❌ 复杂任务的自主规划和执行（需要Agent架构）

简单说：SOUL是方向盘，不是发动机。 发动机（模型能力）决定速度上限，方向盘（SOUL）决定方向对不对。

另外，一个容易被忽略的风险是**“错误的主动性”**。Agent的核心挑战不是"不会行动"，而是"什么时候不该行动"——过度执行、误判意图、擅自推进、基于错误记忆做决策，这些在实际使用中比"太被动"更危险。

SOUL里应该同时包含"什么时候必须行动"和"什么时候必须停下来确认"。

关于"要有帮助"的反思

回头看，“要有帮助"可能是最被滥用的系统提示词。

它不是一个身份，不是一个职责，不是一个策略。它不告诉AI你是谁、你们在做什么、该怎么说话、什么时候该反对、什么该记住、什么该忽略、有多大自主权。

一个通用的提示词，产出的永远是一个通用的AI。

而一个成熟的Agent人格系统，本质上需要回答这些问题：

差距不在模型，在于你有没有花时间想清楚：我到底需要一个什么样的搭档。

SOUL是活的

最后一点，也是很多人忽略的：SOUL不是一次性设置，是一份活的文档。

• 任务变了？更新地图
• AI太啰嗦？收紧语气定义
• AI问太多许可？放宽自治边界
• AI太好说话？加强反驳规则
• AI过度行动？补一条"暂停确认"规则

你不是在写提示词——你在维护一套行为操作系统。

给AI一个身份，给它边界，给它地图，给它说不的权限。然后期待它像一个真正的搭档一样工作。

这就是SOUL的全部意义。

本文灵感来自 @tonysimons_ 的推文《The 170-Line SOUL.md That Made My Hermes Agent Dangerous》，结合个人实践分析整理。