别把系统提示词写成规则仓库

系统 prompt 是你能给 AI 模型的最强指令，但人们往里面塞的大多数内容，其实都不该放在那里。

这听起来有些反直觉。系统 prompt 的优先级高于其他所有消息，它会在整个对话中引导语气、格式和行为；当 Agent 表现异常时，它也是大多数开发者首先想到要调整的地方。因此，人们本能地不断往里面添加内容。Agent 忘记了一条规则，你就把这条规则加入系统 prompt；它使用了错误的风格，你就把风格要求也加进去。一个月后，你的系统 prompt 变成了一本长达 400 行的规则手册，而 Agent 依然会偏离预期。

问题不在于系统 prompt 不够强，而在于你一直把它当作文件柜，存放那些原本就不该存在于 prompt 里的东西。

系统 prompt 究竟是什么

系统 prompt 是一组常驻指令，会在语言模型看到用户消息之前提供给它。它定义了模型在整个会话期间应该如何行动，包括它的角色、语气、约束条件以及回答格式。NIST 的术语表给出了准确的定义：系统 prompt 是“由模型开发者或应用设计者在上下文中提供给 GenAI 系统的特定于应用的指令”。它是环境行为层。

你可以把它理解为职位描述与具体任务之间的区别。系统 prompt 是职位描述。它会说明：“你是一名高级代码审查人员；你使用平实易懂的语言回复；你绝不批准自己无法解释的代码。”用户 prompt 则是具体任务：“审查这个 pull request。”职位描述只设置一次，适用于所有工作；具体任务每次都会变化。

所有主流模型都提供了这一层。在 OpenAI、Anthropic 和 Google 的 API 中，你可以传入独立于用户轮次的 system role（或 system instruction）。在面向消费者的工具中，它通常表现为“自定义指令”或“个性”字段。在编程 Agent 中，它则表现为 Agent 启动时读取的文件：Claude Code 使用 CLAUDE.md，更广泛的生态系统使用 AGENTS.md。它们构成了环境上下文，在你输入任何内容之前，就开始影响 Agent 的每一次响应。

系统 prompt 与用户 prompt：真正重要的区别

理解系统 prompt 最清晰的方法，是先弄清它不是什么。用户 prompt 是某一轮对话中的单次请求；系统 prompt 则是承载这个请求的常驻上下文。

系统 prompt：“你是一名面向开发者读者的技术写作者。使用短段落写作。绝不使用营销话术。解释 API 时，始终提供一个具体的代码示例。”

用户 prompt：“解释一下我们的 webhook 签名机制是如何工作的。”

即使把用户 prompt 换成一百个不同的问题，系统 prompt 依然有效。这种持久性正是它存在的意义，同时也是一个陷阱。正因为系统 prompt 会持续生效，它看起来很适合存放所有你希望 Agent 记住的东西：你的 API 规范、数据库 schema，以及本周要发布功能的验收标准。

开发者正是在这里犯了错。能够在一段对话中持续存在，并不意味着它适合作为产品的持久记录。系统 prompt 存在于某个模型的一次会话上下文窗口中，除了你之外没有人能看到。把项目知识塞进去，等于创建了一份只能与当前对话共存的记录。

系统 prompt 不是产品的记忆

你需要换个角度来看这件事。开发者一次又一次付出高昂代价后才发现：模型上下文并不适合存储产品真正需要掌握的知识。

最近最清晰的例证来自一个 Claude Code 讨论帖。有人询问，是否真的有人把内置记忆功能当作项目记录使用。回答出奇地一致，而且没有一个是正面的。一名开发者正好尝试过这种做法，随后便后悔了：

我犯了一个错误，试图用它存储项目知识，现在这些内容已经渗透到其他项目里了，真是服了。别学我。

同一讨论中的其他人也从不同角度报告了相同的问题。有人认为记忆“完全不透明”，其中一条错误记录过了一个月才被发现。另一名开发者则直接禁用了它，因为“它很快就会过时”。最终形成的共识值得明确写下来：记忆应该用于保存用户偏好，而不是知识；应该保存行为，而不是事实。

这条规则同样适用于系统 prompt，因为系统 prompt 和 Agent 的记忆本质上属于同一类东西。两者都是环境上下文，都会影响行为，也都会悄无声息地过时，因为没有任何机制会根据现实情况检查它们。一旦你用其中任何一种方式保存产品需求，就等于创建了一份会相互污染、逐渐偏移，甚至在不发出任何警告的情况下提供错误信息的记录。

反驳意见也很合理，你应该认真思考：任何书面记录都会过时，包括保存在模型之外的记录。这确实没错。但你能看到、进行版本管理并据此验证的记录，与埋在一个你从不查看的上下文窗口中的记录，有着本质区别。另一篇讨论中的一名开发者总结了让书面记录长期有效所需的纪律：“wiki 必须 100% 反映当前状态。”对于一份三周前最后修改、现在又无法检查的系统 prompt，你无法执行这条原则；但对于一份由你掌控的计划，你可以做到。

什么应该放进系统 prompt，什么不应该

一条实用的界线是：区分 Agent 如何工作，以及它正在构建什么。

系统 prompt 应该描述“如何做”。你的规范、语气、格式规则、Agent 应该执行的命令，以及它上周犯过、后来被你转化为常驻指令的错误，这些都适用于每一个功能。它们天然属于环境信息，而系统 prompt 正是它们应该存在的地方。

“做什么”则完全不同。你正在发布的功能需求、定义完成状态的验收标准，以及代码必须呈现的具体行为，都不属于环境信息。它们具有明确的针对性，会随着功能变化，而且必须能够验证。如果把这些内容放进系统 prompt，它们就会与上下文窗口中的其他所有信息争夺注意力；随着会话不断增长，它们的效果还会逐渐减弱。最终，你甚至没有一份可用于检查成品的独立产物。

比较下面两种失败模式：

Agent 在一次会话中的行为不一致：它忘记了你的代码风格，无视命名规范，或者突然改变语气。这是系统 prompt 的问题。你应该在环境层修正“如何做”。

Agent 构建了错误的东西，或者构建出的东西看起来没问题，却在生产环境中崩溃。这根本不是 prompt 的问题，而是缺少 spec。对于一个系统 prompt 从未接触过的功能，它不可能定义什么叫“完成”。

BrainGrid 正是为了弥补这一缺口而构建的。Planning Agent 会接收你描述的功能，并将它转化为包含真正验收标准的需求，把“做什么”写成可以验证的陈述，而不是埋在 prompt 中。这份需求才是持久记录。当 Builder Agent 编写代码时，无论是在 BrainGrid Cloud 中，还是通过 MCP，在你自己的 GitHub 仓库中配合 Claude Code、Cursor 或 Codex 使用，最终工作都要根据这些验收标准进行检查。不能因为 Agent 停止运行了，就认为功能已经完成。只有当每一条标准都得到证据验证时，它才算真正完成。

系统 prompt 依然重要，它承载着 Agent 应该如何工作。但决定构建结果是否正确的内容，应该存在于计划里，因为在那里，你可以看到它、对它进行版本管理，并用它检查最终代码。模型是无状态的，你的产品不是。

实际应该怎么做

如果你正在调试一个总是表现异常的 Agent，最快的排查方式是先判断问题出现在哪一层。

如果 Agent 的行为有问题，比如语气、格式不对，或者无视某项规范，那么问题在于系统 prompt。收紧它，并保持简短。相比冗长的系统 prompt，较短的系统 prompt 更容易得到模型的充分关注。这与臃肿的上下文窗口会让 Agent 变笨而不是变聪明，是同一个道理。决定哪些内容有资格进入环境层，哪些内容应该放到可供模型对照检查的地方，正是 context engineering 的核心纪律。Claude Code 的构建者 Boris Cherny 发现，对这个工具本身而言，削减上下文比增加上下文更有效。

如果 Agent 构建了错误的东西，就不要再修改 prompt 了。无论添加多少环境指令，都无法定义一个从未提供给 Agent 的功能。把需求及其验收标准写在一个由你掌控、可用于验证的地方，然后让 Agent 根据它进行构建。

系统 prompt 负责搭建舞台，但它不会替你写剧本。

系统 prompt 是什么意思？

系统 prompt 是一组在任何用户消息之前提供给 AI 模型的常驻指令，它定义了模型在整个会话中的行为，包括角色、语气、约束条件和输出格式。它是应用于每次响应的环境行为层，与单次请求不同。大多数模型 API 都会将其作为独立的 system role 提供。

系统 prompt 和用户 prompt 有什么区别？

用户 prompt 是某一轮对话中的单次请求，例如“审查这个 pull request”。系统 prompt 则是承载这个请求的持久上下文，例如“你是一名使用平实语言回复的高级代码审查人员”。用户 prompt 每轮都会变化；系统 prompt 只设置一次，并持续影响所有用户 prompt。系统 prompt 是职位描述，用户 prompt 是具体任务。

我需要系统 prompt 吗？

如果只是问一个一次性问题，不需要。如果某个场景会被反复使用，就需要：优秀的系统 prompt 可以减少你在每条消息中重复说明的指令，降低 token 使用量，并让响应更可预测。但它应该只包含行为与规范，也就是“如何做”。不要用它存储产品需求或某个功能的验收标准；这些内容应该存在于一份可供验证的计划中，而不是环境上下文里。

ChatGPT 中的系统 prompt 是什么？

在 ChatGPT 中，系统级指令来自 OpenAI 自己隐藏的系统 prompt，以及你的“自定义指令”——你可以在这些字段中说明它应该如何在所有对话中回复。在 API 中，你可以通过 system role（或 developer role）显式设置它。无论采用哪种方式，它扮演的角色都相同：在处理你的实际消息之前，应用一组常驻行为规则。

系统 prompt 会过时吗？

会，而这正是把它当作知识存储时面临的主要风险。系统 prompt 是不可见的环境上下文，没有任何机制会根据现实情况检查它，因此过时的指令会一直留在那里，悄无声息地把模型引向错误方向。这就是为什么它应该保存持久的行为规则，而不是快速变化的项目事实。随功能变化的需求应该保存在一份可以检查并进行版本管理的记录中，而不是放在一份几周前最后编辑过的 prompt 里。

Agent 的行为属于系统 prompt。它正在构建的内容属于一份可供验证的计划。

BrainGrid 是一套能将创意转化为可信线上产品的系统。它会把你想构建的内容转化为带有验收标准的需求，使你的编程 Agent 能够据此接受验证。可在 braingrid.ai 试用。

最初发布于 BrainGrid 博客。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。