System Prompt 不是一坨文本
分层管理的必要性：身份、环境、工具指引各自独立，互不干扰
本页解决的问题
先给结论「System Prompt 不是一坨文本」要解决的关键问题是什么？
分层管理的必要性：身份、环境、工具指引各自独立，互不干扰
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
常见的混乱写法
点击每层查看它负责什么
身份层
我是谁？性格、角色、基本人设
- 名字、角色定位
- 性格特征（友善 / 严谨 / 幽默…）
- 基本能力边界（能做什么、不能做什么）
环境层
现在什么情况？系统状态、用户上下文
- 用户基本信息（语言偏好、时区…）
- 当前操作系统、应用状态
- 会话上下文（在哪个页面、之前做了什么）
工具层
能用什么？可调用的工具和 API
- 工具名称和功能说明
- 参数格式
- 使用限制和注意事项
行为层
怎么行动？输出格式、决策规则
- 回答风格和格式要求
- 决策优先级（先做什么、后做什么）
- 安全护栏（什么不能做、什么要确认）
改一层不影响其他层
加个新工具？只改工具层。调整回答风格？只动行为层。不会牵一发而动全身。
多人协作不冲突
产品改行为、工程师加工具、运营调人设，各改各的文件，Git 合并不冲突。
A/B 测试更精准
想测试不同的回答策略？只替换行为层，其他三层保持不变，变量单一。
排查问题更容易
AI 行为异常？按层检查：是身份搞错了、环境信息过时、工具描述有误、还是规则冲突？
「「一坨文本」长什么样」怎样变成可执行的指令
「产品改行为、工程师加工具、运营调人设，各改各的文件，Git 合并不冲突」强调的不是某句神奇咒语，而是信息是否足够让模型判断“为谁做、要完成什么、什么结果算合格”。
背景决定方向，限制决定边界
从「AI 行为异常？按层检查：是身份搞错了、环境信息过时、工具描述有误、还是规则冲突」可以看出，一个有效请求至少要把任务、受众、输入材料、输出形式和限制条件分开。少了背景，模型只能猜；少了验收标准，即使文字流畅也无法判断是否完成任务。
继续加字不一定继续变好
把「AI 行为异常？按层检查：是身份搞错了、环境信息过时、工具描述有误、还是规则冲突」变成一个小练习：只改背景、要求、限制中的一项，保留其他内容不动，观察哪一层真正改变了结果。
从「「一坨文本」长什么样」走到「身份层」
「「一坨文本」长什么样」先把问题落在「常见的混乱写法 你是一个 AI 助手，名字叫 示例系统。 你可以搜索网页、读写文件、 现在是 2026 年，用户在中国。 当用户让你搜索时用 web_search 工具， 回答时先思考再回答，不要编造信息。 你的性格温暖友善， 文件操作用 file_read 和 file_write， 用户的语言偏好是中文， 如果不确定就告诉用户你不知道... 身份、环境、工具、行为全混在一起。改一处可能影响全部，谁也说不清哪段影响…」上；到了「身份层」，讨论继续推进到「我是谁？性格、角色、基本人设 定义 AI 的身份认同： 名字、角色定位 性格特征（友善 / 严谨 / 幽默…） 基本能力边界（能做什么、不能做什么） 特点： 几乎不变，一旦定好很少修改。 环」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
写请求时也应逐层补齐：先说任务和受众，再给材料和输出要求，最后加上限制与验收方式；一次只改变一层，才能知道哪项信息起了作用。
- 「「一坨文本」长什么样」：常见的混乱写法 你是一个 AI 助手，名字叫 示例系统。 你可以搜索网页、读写文件、 现在是 2026 年，用户在中国。 当用户让你搜索时用 web_search 工具， 回答时先思考再回答，不要编造信息。 你的性格温暖友善， 文件操作用 file_read 和 file_write， 用户的语言偏好是中文， 如果不确定就告诉用户你不知道... 身份、环境、工具、行为全混在一起。改一处可能影响全部，谁也说不清哪段影响…
- 「身份层」：我是谁？性格、角色、基本人设 定义 AI 的身份认同： 名字、角色定位 性格特征（友善 / 严谨 / 幽默…） 基本能力边界（能做什么、不能做什么） 特点： 几乎不变，一旦定好很少修改。 环
- 「最后的要点」：AI 行为异常？按层检查：是身份搞错了、环境信息过时、工具描述有误、还是规则冲突
最后的「最后的要点」把讨论落到「AI 行为异常？按层检查：是身份搞错了、环境信息过时、工具描述有误、还是规则冲突」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。