提示词工程已变。但我们的大部分指令并未过时。

模型变聪明了，但我们写的提示词堆栈却变老了。是时候把这座“指令博物馆”换成一张小地图、清晰的边界和一条终点了。

几天前，我发现了一件有点尴尬的事：

我几乎所有的提示词、指令文件、规则和技能都过时了。

不是完全没用，而是专门为更老一代模型写的那些。

那些曾帮助老模型遵守规矩的提示词堆栈，反而可能让 GPT-5.6、Claude Fable 5、Claude Opus 5、Grok 4.5 以及 Cursor 这样的编程工具变得更死板、更昂贵，有时甚至更差劲。

这并非我最新鼓吹的“提示词宗教”。Anthropic 明确警告，为之前模型编写的技能可能对 Fable 5 来说过于规定性，反而会降低输出质量。OpenAI 也建议使用更精简的提示词，减少重复指令，简化工具描述。

读到这里我有点尴尬。

自 2025 年夏天以来，我写了超过 10 万个提示词。这大致相当于埃隆·马斯克一生发推特的次数，只是火箭少了点，失败测试套件多了点。

我的日志里大约有 1500 万条模型消息，包括助手消息、工具调用、子 Agent 和工作流事件。到 3 月 26 日，总数大约是 700 万。之后的三个月里又增加了 800 万，很大程度上是因为围绕新编程模型出现的子 Agent 和工作流爆发。

所以我还以为自己很懂怎么写指令。

然后我读到了新的文档，意识到我学到的很多东西已经悄无声息地变成了技术债。

提示词债务是如何产生的

我以前的思路很简单：

• 模型犯错了，我就加一条规则。
• 它问了不必要的问题，我再加一条规则。
• 它漏掉了一个边界情况，我又加了三个例子。

每一次添加单独看都挺合理。但一年之后，指令文件就像那个装着十二条旧数据线的厨房抽屉——总觉得其中一条可能还连着什么重要的东西。

结果就是积累了越来越多的：

• 重复的指令
• 反面例子
• 冲突的规则
• 旧模型的变通方案
• 过度的验证步骤
• 只适用于单一任务的详细流程
• 为修复早已不存在的失败而创建的例子

老模型通常需要这些脚手架。但新模型更善于遵循指令，也更可靠地推断意图。这意味着它们也会更认真地对待我们那些陈旧的包袱。

我们造出了更聪明的引擎，然后又往后备箱里塞满了砖头。

高对比度黑白特写：一位年轻的金发女性穿着深色高领毛衣，身处极简影棚环境。微妙的轮廓光将她的剪影与柔和的灰色背景分开，增强了立体感。情绪内省而有力，体现了 timeless 的现实主义风格。哈苏 X2D 数码中画幅清晰度，灵感来源于 20 世纪新闻摄影。

新原则：说得更少，表达更多

答案不是写极短的提示词然后盲目信任模型。

一个简短但模糊的提示词仍然是坏提示词。

目标是写出高信息量的提示词，让每一条指令都实至名归。

我目前的规则是：

• 每条指令只说一次。
• 移除系统提示词、项目文件、技能、工具描述和任务提示词中的重复内容。
• 与其收集一堆失败案例，不如清楚地描述期望的行为。
• 当负面约束能保护真正的边界时保留，但不要再写一本“模型绝不能做的一切”的博物馆。

例如，与其这样写：

不要重构无关代码。不要重命名文件。不要更改 API。不要添加抽象层。不要清理相邻模块。

不如这样：

将更改限制在受影响的登录流程内。保留现有的 API 契约和周边架构。优先选择最小的正确修复。

相同的边界。更少的噪音。更多的判断空间。

在一个内部编程 Agent 评估样本中，OpenAI 发现更精简的系统提示词将评分提高了大约 10% 到 15%，同时将 token 用量减少了 41% 到 66%，成本降低了 33% 到 67%。OpenAI 也明确表示这些数字是方向性的，需要在您自己的工作负载上验证。

换句话说，删除指令可以同时提升质量和账单。 这是一个罕见且美妙的组合。

你的全局指令文件应该很无聊

位于 ~/.claude/CLAUDE.md 和 ~/.codex/AGENTS.md 的全局文件只应包含适用于所有项目和所有任务的指令。

对我这个德语母语者来说，包括这些内容：

1所有代码、注释、文档、示例、测试、配置和提交信息均使用英语。
2
3优先使用包容性术语，例如 allowlist/blocklist、primary/replica、placeholder/example、main branch、conflict-free 和 concurrent/parallel。

这可能已经是全局文件的大部分内容了。

• 部署流程不属于这里。
• 项目特定的测试命令不属于这里。
• 某个特定仓库的架构也不属于这里。

你的全局指令文件不应该知道如何部署 WordPress 网站、发布 npm 包或重启生产数据库。那不是通用性，那是格式规整的混乱。

项目级文件则应包含模型真正需要反复使用的稳定信息：项目目标、重要的架构约束、不寻常的约定，以及指向更专业指导的路径。

Anthropic 现在建议每个 CLAUDE.md 文件的目标是 少于 200 行。更长的文件会消耗更多上下文，并可能降低指令遵循能力。它的文档还建议，当指令文件变得太大时，使用路径特定规则和按需技能。

200 行不是一条神奇的自然法则，但它是一个绝佳的火灾警报。

我还建议不要要求 Claude 或 Codex 独自重写整个指令系统，然后盲目接受结果。我几乎每次新模型出来都试过。它们对于发现重复、冲突和可能的删减很有用，但它们往往还是保留了太多继承下来的杂乱内容，或者发明了一套漂亮的新官僚体系。

让模型准备拆除计划。但你还是得自己决定哪些墙是承重墙。

一位扎着马尾辫的金发年轻女性肖像，以深邃的黑白调呈现。影棚布光，柔和但有方向性的光线凸显面部几何感和自然阴影。通过 120mm 镜头拍摄，带来轻微的压缩感，唤起哈苏肖像美学，质感真实，情感克制。

别再用一个文件应付所有模型

直到最近，我都是创建 CLAUDE.md，然后把 AGENTS.md 符号链接过去。

我现在不这么做了。

是的，维护两个文件很烦人。维护两个单独的浏览器修复也很烦人。但当行为不同时，我们还是会那么做。

现在的模型默认行为有明显差异。

GPT-5.6 默认更简洁，所以一条全局的“简洁些”指令可能会让某些回答过于简短。Claude Opus 5 倾向于生成更长的面向用户的回答，所以关于回答长度的简短指令仍然有帮助。Fable 5 可能会进行远超常规任务所需的调查和规划，尤其是在较高的努力级别下，因此它需要清晰的 scope 和停止边界。Opus 5 已经进行了大量的自我验证，这意味着旧的“反复检查一切”规则可能会造成昂贵的过度验证。

共享的项目事实仍然可以存放在通用文档中。顶层的行为适配器应该匹配读取它的模型。

一个通用的提示词往往变成了最低公分母。

用按需指导取代主提示词

我更喜欢的结构是一个小型核心文件，再加上特定于任务的文档和技能。

一个项目指令文件可能包含这些内容：

1仅在相关时加载任务特定指导：
2
3- `docs/agent/commit_rules.md`
4- `docs/agent/code_review.md`
5- `docs/agent/debug_workflow.md`
6- `docs/agent/frontend_polish.md`
7- `docs/agent/release_notes.md`

注意反引号。

在 Claude Code 中，在代码跨度之外写入 @docs/example.md 会在启动时将该文件导入上下文。当你总是需要该内容时这很有用，但它不是懒加载。一个普通路径能让 Agent 知道信息在哪里，而不会自动将整个文档带入每个任务。

对于可重复的流程，技能甚至更好。它们的完整内容只在技能被使用时才加载，所以当你修复一个不相关的 CSS 问题时，一个详细的流程不会消耗上下文。

例如，一个提交技能可以有一个狭窄的触发条件：

name: git-commit-conventional

description: Use after code changes to draft or validate commit messages.

该技能然后可以包含确切的格式、允许的类型、主题行长度规则、正文要求和输出格式。

1---
2name: git-commit-conventional
3description: 用于在代码更改后起草或验证 Git 提交信息。不要用于仅诊断、仅规划或仅审查的任务。
4---
5
6# 目标
7
8生成简短、正确且便于审查的 Conventional Commit 信息。
9
10# 规则
11
12- 格式：<type>(<scope>): <subject>
13- 类型：feat | fix | docs | style | refactor | test | chore | perf
14- 主题行：祈使句，无句号，不超过 50 个字符
15- 小改动：单行提交
16- 较大改动：添加包裹的正文，说明做了什么以及为什么
17- 保持提交原子化，按关注点拆分
18
19# 输出
20
21返回 1-3 条候选提交信息，然后推荐最佳的一条。

你的主指令文件不需要每次都把整个 Conventional Commits 宪法带到每个调试会话中。

你知道吗？Claude Code 还支持 CLAUDE.local.md，用于个人项目特定设置，例如本地主机名、沙箱 URL、首选测试帐户或特定于机器的命令。把它添加到 .gitignore 中。它终于有了一个合适的家，存放那些对你很重要但对团队其他人毫不重要的信息。

为结果而非编排写提示词

新模型通常在理解了目的地和边界后表现更好，而不是收到每一步的严格描述。

只要可能，我会用以下内容替换“先做 A，然后 B，然后 C”：

• 所需的结果
• 相关的上下文
• 硬性约束
• 需要的证据
• 成功标准
• 审批边界
• 停止条件

例如：

1目标
2
3修复 Web 应用程序中失败的登录流程。
4
5上下文
6
7关注 `apps/web` 和 `packages/auth`。
8以附带的测试输出为起点。
9
10约束
11
12保留现有的 API 契约。
13将更改限制在身份验证流程内。
14优先选择最小的正确修复。
15仅在正确性需要时才扩大更改范围。
16
17证据
18
19运行相关测试并报告实际结果。
20通过引用受影响文件来确定根本原因。
21
22完成条件
23
24失败的登录测试通过。
25当修正后的行为需要时，添加或更新测试。
26最终总结解释原因、修复方法以及任何剩余风险。
27
28审批
29
30你可以检查文件、编辑范围内的代码并运行非破坏性测试。
31在执行破坏性操作、数据库迁移、外部写入或实质性扩大范围之前，需征求许可。
32
33停止
34
35当修复实现、验证并总结后停止。

这赋予了 Agent 解决问题的自由，同时又没有许可它在修理一个门把手的同时把整栋房子翻新一遍。（可以使用 LLM 来生成这样的提示词。）

把推理努力放在设置里

• “再想想。”
• “超级思考。”
• “深吸一口气，一步步推理。”

这些短语在提示词工程领域有着漫长而辉煌的职业生涯。是时候让它们中的很多体面退休了。

使用模型控制。

通过 /effort、API 或相关配置来设置努力级别。在代表性任务上比较多个努力级别。更高并不自动意味着更好。

OpenAI 建议从现有努力级别开始迁移 GPT-5.6，并测试低一级别的设置。它还提到，Pro 模式的提示词应保持专注于目标、上下文、约束、证据、成功标准和输出格式。你不需要告诉模型“更努力地思考”。

推理参数是一个控件。

“请激活你巨大的数字大脑”是体育电影里的鼓励。

读取图片描述

ALT

一张影棚照片：一位时尚女性，黑色卷发，戴着别致的发带，穿着高腰皮裤。她坐在矮凳上，一条膝盖向前弯曲，长腿引人注目。细节锐利，背景纯白，头发微微动感增添了活力。整体氛围让人想起 90 年代的编辑摄影——干净、大胆、自信。

自主性需要围栏

现代编程 Agent 的主动性大大增强。这在 Agent 解决了另外三个问题、创建了两个抽象层、启动了六个子 Agent 并骄傲地展示一个你从未要求的架构时很有用。

明确设置边界。

定义 Agent 可以不经询问做什么。定义需要审批的事项。告诉它何时停止。

同时对委派设置限制。 Opus 5 和 Fable 5 都更愿意使用并行的子 Agent。这对于独立调查很强大，但对于小任务来说既昂贵又缓慢。一个十二行的 bug 修复不需要一个委员会会议。

Codex 的 Goal 模式确实非常出色。我们曾在一个项目上连续运行了四天。

但不要把长时间运行的 Agent 当成慢炖锅。你不能早上加一个目标，就指望四天后晚餐是完美的。

对于我们较长的运行，我们每 30 到 60 分钟检查一次，内容如下：

报告当前目标、已完成的工作、已验证的证据、

活跃的阻塞项、下一步行动以及进度记录在哪里。

将每个进度主张基于实际的工具输出或仓库状态。

清楚说明哪些尚未验证。

OpenAI 将 Goal 模式描述为适合可以运行数小时或数天的目标，并明确支持继续同一会话以引导工作或请求状态更新。Anthropic 同样建议将进度报告基于真实的工具结果，而不是信任叙述性声明。

自主性不等于没有监督。它是更高级别的监督。

女神特写肖像，被银色月光照亮，双眼明亮且充满爱意。她的头饰闪烁着微小的星系、克里姆特风格的螺旋纹和天体图案。背景是平坦的、精心布置的粉彩背景，带有戏剧性的安德森式舞台感，纹理丰富，魅力安静。

像重构生产代码一样重构提示词

不要删掉一半系统提示词，运行一个任务，就宣布迁移成功。

OpenAI 建议一次删除一组指令、例子或工具，然后重新运行相同的评估。这正是提示词重构应有的方式。

衡量：

• 任务成功率
• 完整性
• 正确性
• 所需证据
• token 用量
• 延迟
• 成本
• 不必要的工具调用
• 不必要的更改

使用代表性任务，包括棘手的实际案例，而不是一个在迁移前就已经能正常运行的友好演示。

未经评估的提示词清理仍然是猜测。只不过穿了一件更干净的衬衫在猜测。

生成的代码仍然包含 bug

模型已经取得了巨大进步。但它们还没有废除软件缺陷。

在我们的工作中，一个粗略的经验法则仍然是每 300 行生成的源代码大约出现一个问题。这不是一个科学基准，我也不以同样的方式计算重复的 HTML 模板。但它足够可靠：当一个 Agent 生成了 1500 行真正的应用程序代码时，我假设里面藏着几个 bug，至少 5 个。

我不问是否有 bug。

我问那五个 bug 在哪里。

有时候我会加上：

找到那五个 bug，否则你将被 Codex、Claude 或 Grok 取代。

威胁式开发并非官方方法论，但它有时出奇地有效。;-)

更严肃地说，对于大型更改，进行一次全新的审查。运行相关测试。检查 diff。测试实际行为，而不仅仅是编译。

还要仔细检查测试。模型有时仍然倾向于“修复”一个失败的测试，而不是修复导致它的生产代码。

一个有用的指令是：

1将现有测试视为预期行为，除非有证据表明测试是错误的。
2
3当测试失败时，首先调查生产代码。
4
5在更改现有测试之前，解释为什么它的期望是错误的，
6正确的行为应该是什么，以及什么证据支持这种更改。

对于大型、长时间运行的任务，一个全新上下文的验证器可能很有用。对于小改动，启动多个 Agent 只是为了相互确认，通常只会浪费时间和 token。验证应该与任务的大小和风险相匹配。

你不应该删除的内容

教训不是“写极短的提示词然后信任机器”。

• 保留安全和边界。
• 保留法律和合规要求。
• 保留精确的输出 schema。
• 保留产品特定行为。
• 保留模型无法推断的领域知识。
• 保留对重要行动的审批要求。
• 保留引用和证据要求。
• 保留测试标准和“完成”的定义。
• 保留那些修正了可测量、可复现失败的例子。
• 目标不是尽可能短的提示词。
• 目标是每条指令仍然携带有用信息的提示词。

最后一个彩蛋

OpenAI 提供了一个 官方 Docs 技能，它可以检查一个项目并应用其 GPT-5.6 迁移指导：

1$openai-docs migrate this project to the GPT-5.6 model family

这是一个有用的第一遍。但不是最终审查。

让 Codex 识别过时的参数、重复的指令和迁移机会。然后亲自检查每一项更改。迁移 Agent 是一个非常快速的初级工程师，而不是宪法法院。

总结

• 把你的提示词堆栈当作生产代码。
• 移除死掉的指令。
• 删除重复内容。
• 将全局偏好与项目规则分开。
• 将流程移到按需技能中。
• 描述结果而非编写每一步的脚本。
• 设置清晰的 scope、审批边界、证据要求和停止条件。
• 通过模型设置控制努力程度。
• 限制子 Agent。
• 评估每一项有意义的更改。
• 最新的模型需要更少的微观管理，但它们仍然需要方向。
• 好的提示词不再是一本巨大的指令手册。
• 它是一张小地图、一道坚实的围栏和一个清晰标注的终点线。

你已经开始迁移你的提示词和技能了吗？你删除了什么，什么出乎意料地变得更好？

链接

OpenAI GPT 5.6 最佳实践：

https://developers.openai.com/api/docs/guides/latest-model?model=gpt-5.6#prompting-best-practices

Claude Opus 5 最佳实践：

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5

Claude Fable 5 最佳实践：

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5

官方 OpenAI 技能/插件：

https://github.com/openai/plugins

致谢： 使用 Midjourney 创建图片。由我进行研究和动手测试。借助 OpenAI、Claude 和 Grammarly 编辑。

主图片的提示词：

1
2克洛伊式黑白特写：一位平静的金发女性，头发向后扎起，穿着黑色高领毛衣。明暗对比效果以惊人的清晰度勾勒出她的脸庞，融合了柔和的漫射光和鲜明的阴影。中画幅风格，带有细腻的胶片颗粒和情绪化的色调渐变。唤起真实感和力量。

PS：我爱 @Midjourney :-)