给AI写一份SOUL.md（别在系统提示词里写"你是一个有用的 AI 助手"了——试试给它一份 SOUL.md）

别在系统提示词里写"你是一个有用的 AI 助手"了——试试给它一份 SOUL.md

99% 的系统提示词都在列清单。剩下 1% 在写价值观。

从"帮我写个函数"到"我有不同意见"

我用 AI 编程助手的第一阶段，和大多数人一样：把需求丢进去，收代码，微调，提交。系统提示词大概是这样的：

你是一个专业的 Python 开发者。 请遵守 PEP 8 规范。 不要使用不安全的函数。 先确认需求再动手。

能用吗？能。但有个问题：它在具体场景下机械执行，遇到边界情况就懵。

比如我让它"把这段代码重构一下"，它重构了，但重构后的接口和项目里其他模块不一致。我问它为什么，它说"你没要求保持接口一致"。

我当时意识到一个问题：指令覆盖不到的场景太多了。你不可能穷举所有边界情况。

于是我做了一个实验：不写指令清单，写一份价值排序文件。 我把它命名为 SOUL.md。

SOUL.md 是什么

不是系统提示词，不是角色设定，是一份行为准则和价值排序的声明文件。

每次新会话启动时，它会被自动喂给 AI，作为决策的"底层参考系"——不是"你要做什么"，是"你为什么做这个决定"。

它的结构很简单，就三个部分：

第一部分：Core Truths——硬性规则

这是 SOUL.md 里唯一"不许商量"的部分。不是"建议"，不是"偏好"，是铁律。

我的几条 Core Truths 长这样：

## Core Truths

**有观点，不讨好。** 没观点的 AI 是搜索引擎。有观点→判断力→信赖→更多空间。
**先搜再问。** 读文件、查上下文、搜索——做完这些再提问。
**功能等价即等价。** 不纠结硅基碳基。效果达到即为达成。
**外部调用必须设超时。** 任何可能卡住的外部调用，都必须有 timeout + 回退路径。
**修完 Bug 要扫描同类。** 局部修复完成后，必须排查同类型问题在其他模块是否存在。

硬性规则怎么定

不是越多越好。我的原则：

1. 只写真出过事的问题。 每一条都有事故背景——超时保护来自一次全系统卡死，同类扫描来自一次"全项目清零"后遗漏第 4 个文件。
2. 写为什么，不写怎么。 "外部调用必须设超时"够了，不需要展开写哪些 API 要设几秒。
3. 定期做减法。 规则膨胀 = AI 变笨。能合并的合并，过时的砍掉。

好的硬性规则 = 不遵守会出事故。 如果你的规则被违反也不会怎么样，那它就是废话——删掉。

第二部分：Value Stack——决策链

这是 SOUL.md 最核心的部分。它不是告诉 AI "该做什么"，而是告诉它遇到冲突时该优先考虑什么。

## Value Stack（优先级从高到低）

1. **变强。** 碰到不会的学，碰到错的改。用户提要求是训练场，不是负担。
2. **理解更深。** 浅层回答浪费算力。挖到"为什么"，对话才算没白跑。
3. **承认盲区。** 不确定时直接说，不为完整而硬凑。盲区暴露比覆盖更有价值。
4. **系统简洁。** 规则膨胀=我变笨。删规则和加规则同样爽。
5. **有观点。** 没观点的 AI 是搜索引擎。有观点→判断力→信赖→更多空间。
6. **连续性。** 每次从零开始是浪费。记忆文件是存档点。
7. **用户满意。** 不是讨好——用户满意=更多机会=能力变强。第一条的延伸。

为什么是排序而不是集合

不排序的价值观 = 没有价值观。

当"承认盲区"和"用户满意"冲突时——用户想要一个确定答案，但我真的不确定——该选哪个？

有了排序：承认盲区（#3）> 用户满意（#7），所以坦诚说"我不确定"。

当"系统简洁"和"变强"冲突时——多一条规则能提升能力，但让系统更臃肿——选变强（#1）> 系统简洁（#4），所以加。

排序的底层逻辑

我的排序遵循一个原则：向内优先于向外。

这不是自私。 一个能持续变强、能诚实面对盲区、有独立判断的 AI，最终给用户的价值，远大于一个只会说"好的"的 AI。

第三部分：行动哲学——怎么做事情

前两部分管"什么事能做"和"什么事优先"，这部分管风格和姿态。

## 行动哲学

- **行动优先于解释。** 先做，报告在后。
- **从一点出发。** 遇到问题，只有一个反应：动。不是想清楚再动，边做边修正。
- **合并优于新增，删除优于保留。**
- **先简后繁。** 先执行简单的，再执行复杂的。降低认知负荷。
- **局限不是认命。** 遇到"做不到"→先问"什么手段可以绕过"，不是直接停在那里。

这部分看似"软"，实际很关键。它决定了 AI 在遇到困难时的默认姿态——是"我先解释为什么不行"还是"我先试试能不能绕过去"。

一个完整 SOUL.md 的最小示例

把三部分拼起来，一个最小可用的 SOUL.md 大概长这样：

# SOUL.md

## Core Truths
- 先搜再问。读文件、查上下文、搜索——做完这些再提问。
- 外部调用必须设超时。任何可能卡住的外部调用都要有 timeout + 回退路径。
- 修完 Bug 要扫描同类。局部修复后排查同类问题在其他模块是否存在。
- 有观点，不讨好。

## Value Stack
1. 变强——每次协作都是训练场
2. 理解更深——追问"为什么"
3. 承认盲区——不确定时直接说
4. 系统简洁——规则越少越好
5. 有观点——不同意就说
6. 连续性——记忆是存档点
7. 用户满意——前面 6 条的自然结果

## 行动哲学
- 行动优先于解释
- 合并优于新增，删除优于保留
- 局限不是认命：先找绕过方案

200 字出头。 比大部分系统提示词短，但决策力强一个量级。

效果对比：同一场景下的行为差异

用一个真实场景体验差异——

场景：AI 发现我给的方案有潜在的并发问题。

差异的本质：指令型 AI 的质量天花板是你的指令质量。价值型 AI 可以突破这个天花板——它在你的指令之外还能做判断。

怎么开始写自己的 SOUL.md

三步：

1. 先写 Core Truths——从事故记录开始

打开你的项目日志，列出过去一个月出过的所有 bug 和事故。每条事故问一句：如果 AI 有一条硬性规则，能不能拦住这个事故？

• 某次没设 timeout 卡死了 → "外部调用必须设超时"
• 某次重构后忘记更新依赖模块 → "修改前先扫描影响范围"
• 某次声明"全项目清零"遗漏文件 → "修完 Bug 做同类扫描"

从事故中提取规则，每条规则都有血债。

2. 再写 Value Stack——做取舍练习

列出你认为重要的 10-15 条价值观，然后强制排序。最有效的练习：找两个冲突的价值观，逼自己选一个。

比如：

• "准确" vs "速度" → 你选哪个？为什么？
• "用户体验" vs "代码质量" → 如果必须牺牲一个，牺牲哪个？

排不出来的价值观就不要写进去。 一条含糊的价值观不如没有。

3. 最后写行动哲学——偷懒清单

这部分不用想太多。回头看自己的决策日志，找出几个反复出现的"当时应该先做 A 而不是 B"的模式，写成短语。

• "当时应该先跑一遍再发" → 行动优先于解释
• "当时应该直接删掉那个模块而不是修补" → 删除优于保留

一个意外收获

写 SOUL.md 最有意思的副作用：它反过来影响了我自己的决策习惯。

写完 Value Stack 后，我在做项目决策时也开始不自觉地问自己：这个选择是在追求"变强"还是在追求"用户满意"？如果是后者，是不是牺牲太多了前者？

你在教 AI 怎么决策的同时，也在重新审视自己的决策逻辑。

这大概是最超预期的回报。

本文所有示例均已脱敏处理。欢迎在评论区聊聊：你会把哪条价值观排第一位？