Anthropic官方警告："再检查一遍"已成提示词反模式

一个让人措手不及的转变

最近 Anthropic 发布了一篇关于降低成本、提升 Claude 平台性能的博客，其中一个观点直接击中了大量长期使用者：那些我们习惯性写进提示词里、用来"逼"模型更努力工作的指令，如今正在起反作用。

Anthropic 由前 OpenAI 副总裁 Dario Amodei 和 Daniela Amodei 兄妹于 2021 年创立，公司的核心使命是构建安全、可解释的 AI 系统。Claude 是 Anthropic 推出的大语言模型系列，目前已迭代至 Claude 4 系列。与 OpenAI 的 GPT 系列不同，Anthropic 特别强调"Constitutional AI"（宪法 AI）的训练方法——通过一组预定义原则来指导模型的行为对齐，而非单纯依赖人类反馈的强化学习（RLHF）。传统的 RLHF 流程需要大量人类标注员对模型输出进行偏好排序，然后训练一个奖励模型来指导策略优化。而 Constitutional AI 则引入了"AI 反馈的强化学习"（RLAIF）这一创新环节：模型首先根据一套明确的行为准则（即"宪法"）对自身输出进行自我批评和修订，然后再用这些经过修订的样本来训练奖励模型。这套准则涵盖了有益性、无害性和诚实性等多个维度，使得模型在训练阶段就已经内化了大量关于"如何正确行事"的判断逻辑。这种训练理念使得 Claude 模型在遵循指令的同时保留了更强的自主判断能力，也正是本文讨论的核心背景：模型已经被训练得足够"懂事"，外部的过度指令反而会干扰其内建的行为逻辑。

"Double-check your work"（再检查一遍工作）、"Be maximally thorough"（尽可能彻底），这些短语几乎出现在每个人的配置文件里。它们曾经是必需品——老一代模型如果不明确要求，就会偷工减料、走捷径。但今天的模型早已默认执行这些行为。于是这些指令的效果，从"提醒"变成了"重复劳动"：模型被要求把已经做好的事情再做一遍，成本翻倍，答案反而更差。

发帖的开发者读完文章后做了一件事：数了数自己配置文件里的这类指令。结果是 66 处 "must"、54 处 "never"，总共 125 行。而他坦承，从来没有真正梳理过哪些是"真约束"，哪些只是"多余的督促"——并且怀疑后者占了大多数。

为什么"帮忙"的提示词反而添乱

这个问题的根源涉及新老模型在行为逻辑上的根本差异。理解这一点，是优化提示工程策略的前提。

提示工程（Prompt Engineering）作为一门实践学科，随 2022 年 ChatGPT 的爆发而进入主流视野。早期的提示工程更像是一门"玄学"——用户通过反复试错发现，在提示词中加入 "Let's think step by step" 这样的短语，能显著提升 GPT-3.5 等模型的推理准确率。这种被称为"链式思维提示"（Chain-of-Thought Prompting）的技术，由 Google Brain 团队的 Jason Wei 等人在 2022 年的论文中首次系统化。此后，提示工程迅速发展出 Few-shot（少样本提示，在提示词中提供若干示例来引导模型输出格式和风格）、Zero-shot（零样本提示，不提供示例直接发出指令）、角色扮演等多种范式。更高级的技术如 Self-Consistency（自洽性采样，生成多条推理路径后投票选出最优答案）和 Tree-of-Thought（思维树，让模型探索多个推理分支并进行评估回溯）进一步推高了提示工程的复杂度。这些技术甚至催生了"提示工程师"这一新兴职位，薪资一度高达六位数美元。但随着模型能力的迭代——特别是从 GPT-3.5 到 GPT-4、从 Claude 2 到 Claude 3.5 再到 Claude 4 的跃升——许多曾经有效的提示技巧正在被模型的原生能力所取代。例如，最新模型在零样本条件下的推理表现已经接近甚至超越了早期模型在精心设计的链式思维提示下的表现。这种"模型能力吞噬提示技巧"的趋势，正是当前争论的焦点。

老模型：你说什么，它做什么

早期模型只会严格执行你写下的每一步。如果你不明说"检查你的工作"，它就不会检查；如果你不列出"按这个顺序处理"，它可能跳步。因此，把每一个环节都写清楚、把每一个动作都强调到位，是那个时代提示工程的正确做法。这与早期模型的训练方式有直接关系——GPT-3 等模型主要基于大规模文本预测进行训练，其指令遵循能力相对薄弱。OpenAI 后来通过 InstructGPT 项目引入了指令微调（Instruction Fine-tuning）和 RLHF，才让模型具备了基本的指令理解能力。但即便如此，这些早期经过对齐的模型仍然严重依赖用户提供的详细步骤说明——它们更像是一个需要逐步指导的新员工，而非能够独立工作的资深专家。

新模型：它本来就会，你却打断了它

当前的 Claude 模型具备更强的自主判断能力，很多事情它本来就会主动做好。这种能力的提升来自多方面的技术进步：更大规模的预训练数据、更精细的对齐训练（包括前文提到的 Constitutional AI 方法）、以及模型架构本身的优化。新一代模型已经在训练过程中"见过"了海量的指令-响应对，内化了"检查工作""分步推理""全面考虑"等行为模式。问题在于——当你在它已有的能力之上再叠加一层"必须按这个顺序做"的硬性指令时，模型会停止执行它本来会做的合理动作，转而机械地服从你的指令。这种现象在 AI 研究中被称为"指令覆盖"（instruction override）——显式指令会压制模型在训练中习得的隐式行为策略，导致整体输出质量的下降。

Anthropic 给出的例子非常具体：

• "Be maximally thorough" 导致模型进行了数十次根本不必要的知识库检索。这里涉及当前企业 AI 应用中最流行的架构之一：检索增强生成（Retrieval-Augmented Generation，简称 RAG）。RAG 的工作原理是在模型生成回答之前，先从外部知识库（如向量数据库）中检索相关文档片段，然后将这些片段作为上下文注入提示词中。具体的技术流程包括：首先将用户查询转化为向量嵌入（embedding），然后在向量数据库（如 Pinecone、Weaviate 或 Chroma）中进行近似最近邻搜索（ANN），检索出语义相似度最高的若干文档片段，最后将这些片段拼接进提示词的上下文窗口。每一次检索操作都涉及嵌入模型的推理计算（将查询文本转为向量）、向量数据库的查询开销、以及检索结果注入后对上下文窗口的 token 占用。在 Claude 的 API 定价体系中，输入 token（包括系统提示词和注入的检索结果）按量计费——以 Claude 3.5 Sonnet 为例，输入 token 的价格为每百万 token 3 美元，输出 token 为 15 美元。这意味着每一次不必要的检索不仅增加了向量数据库的调用成本，还会因为将更多检索片段注入上下文而推高 token 消耗。当提示词中包含 "Be maximally thorough" 这类督促语时，模型可能会触发远超必要次数的检索调用——它会试图穷尽所有可能相关的知识源，即使前几次检索已经获得了足够的信息。在一个日调用量达到百万级的生产系统中，每次多检索 3-5 个文档片段，一天下来就可能多消耗数十亿 token，折合数千美元的额外支出。在按调用次数和 token 数量计费的商业模式下，这种过度检索直接转化为不必要的成本开支。

• "Double-check your work" 让模型把已经完成的工作重新做了一遍；

• 最刺痛人的是相互矛盾的规则：一条策略在某处允许某个行为，却在另一处禁止它，结果四笔本应通过的合法退款没有发出去。这种矛盾规则的危害远不止经济损失——在金融服务、医疗健康等受严格监管的行业中，系统未能执行应有操作可能构成合规违规，带来法律和声誉风险。

换句话说，你加进去帮忙的那句提示词，恰恰成了挡在路上的障碍。

该删什么，不该删什么：提示词清理指南

值得强调的是，Anthropic 的建议并不是让你把一切约束都剥离干净。这是很多人容易误读的地方。

区分"督促语"与"硬约束"

文章明确指出，要移除的是那些推动性的督促语（nudging），而不是硬性约束（hard constraints）。两者的区别在于：

• 督促语：试图让模型"更努力"，比如"要彻底"、"要仔细检查"。现代模型已默认具备这些行为，重复要求只会浪费算力、扰乱判断。从技术上理解，这些督促语之所以产生反效果，是因为它们改变了模型在解码阶段的注意力分配。Transformer 架构中的自注意力机制（Self-Attention）会根据上下文中所有 token 的相关性来分配"注意力权重"。当系统提示词中充斥大量督促性指令时，模型的注意力会被这些指令占用，相应地分配给实际任务内容（如用户查询和检索结果）的注意力资源就会减少，从而影响输出质量。
• 硬约束：定义了不可逾越的边界，比如"绝不要重复点击发布按钮"。这类规则应当保留——它们防止的是真实的、不可逆的错误。

发帖者举了自己的例子："Never click the publish button twice"（绝不要重复点发布）是一条真正的硬约束，理应留下。但他 125 行规则中的大多数，很可能只是无意义的督促。

单独控制模型的"努力程度"

Anthropic 还提到，模型"工作强度"有一个独立的控制维度：设得太低，模型会在证据不足时就仓促作答；设得太高，它又会在简单问题上过度纠结。

具体来说，Claude 的扩展思维（Extended Thinking）功能允许开发者通过设置 budget_tokens 参数来控制模型在生成最终回答前进行内部推理的 token 数量。这一功能的底层机制是让模型在输出最终答案之前，先生成一段"思维链"（thinking tokens），这些中间推理步骤对用户不可见但会影响最终输出的质量。较低的预算意味着模型会快速给出答案，适合简单查询；较高的预算则让模型进行更深入的推理，适合复杂任务。这类似于 OpenAI 在 o1/o3 系列模型中引入的 reasoning_effort 参数（low/medium/high），以及 Google DeepMind 在 Gemini 2.5 中引入的 "thinking budget" 概念。值得注意的是，这种参数化控制代表了 AI 工程领域的一个重要趋势：将原本依赖自然语言的模糊指令转化为可量化、可调节的结构化参数。这种参数化设计的核心理念是：模型的"认真程度"应该由结构化的技术参数来调控，而不是依赖自然语言中模糊的督促性表述。前者可量化、可复现、可优化——你可以通过 A/B 测试精确找到特定任务的最优 budget_tokens 值；后者则不稳定且可能产生意想不到的副作用——同样一句 "be thorough" 在不同上下文中可能触发截然不同的模型行为。

这意味着调节模型的努力程度应该通过专门的参数，而不是靠在提示词里堆砌"要努力"之类的口号。

给长期使用者的配置文件审计建议

对于任何维护着长期运行配置的团队和个人来说，这篇文章抛出了一个值得立即行动的问题：你审计过自己的提示词规则文件吗？

文中提到的"配置文件"，本质上就是系统提示词（System Prompt）——在用户对话之前注入模型的一段隐藏指令，用于定义模型的行为边界、角色设定和响应风格。在 API 调用中，系统提示词通常以 system 角色的消息形式传入，它的优先级高于用户消息，但低于 Anthropic 自身注入的安全层指令。对于企业级应用，系统提示词往往长达数千 token，包含业务规则、合规要求、输出格式规范等大量条目。随着时间推移，这些配置文件会像代码库一样不断膨胀——新规则被追加进来，旧规则却很少被清理。这种"只增不减"的维护模式，在软件工程中被称为"配置腐化"（configuration rot），与代码库中的技术债务如出一辙。造成这种现象的原因也相似：删除一条规则的风险（可能导致未知的行为变化）总是显得大于保留它的成本（多消耗一些 token），于是团队倾向于"宁可多留也不敢删"。这正是导致文中开发者积累 125 行冗余规则的典型原因。更重要的是，在 Token 即成本的大模型经济学中，每多一个 token 的系统提示词，都会在每次 API 调用中被重复计费。以一个日均处理 10 万次对话的客服系统为例，如果系统提示词中有 2000 个 token 的冗余内容，按 Claude 3.5 Sonnet 的输入定价（每百万 token 3 美元），一天的额外成本约为 0.6 美元——看似微不足道，但一年下来就是 219 美元，如果是更大规模的部署或使用更昂贵的模型（如 Claude 3.5 Opus），这个数字会成倍增长。

如果你的配置文件也积累了几十上百条 must / never，不妨按以下思路做一次清理：

1. 列出所有强制性指令，统计 must、never、always 等关键词的出现次数，先建立全局认知。可以编写一个简单的脚本来自动化这一过程——用正则表达式匹配这些关键词并统计频率，同时标记出它们所在的具体行和上下文。
2. 逐条判断类型：这条规则是防止真实错误的硬约束，还是只在督促模型"更努力"？一个有效的判断标准是问自己：如果删掉这条规则，模型输出中最坏的情况是什么？如果最坏情况是"回答不够详细"，那它很可能只是督促语；如果最坏情况是"执行了一个不可逆的危险操作"，那它就是硬约束。
3. 删除冗余督促：凡是现代模型已默认执行的行为（检查、彻底、认真），大胆删掉。
4. 排查矛盾规则：重点检查同一行为在不同位置是否有冲突的规定，这类矛盾最容易造成隐性故障，比如那四笔没发出的退款。建议将所有规则按主题分组（如"退款策略""数据处理""输出格式"），在每个组内逐一比对，检查是否存在逻辑冲突。
5. 保留并明确硬约束：真正的边界规则要保留，且表述清晰、不留歧义。

结语：提示工程的范式正在迁移

这次讨论之所以引发广泛共鸣，是因为它触及了一个更深层的转变：随着模型能力的跃升，昨天的最佳实践正在变成今天的反模式。

我们曾经相信"提示词指令越详尽越好"，因为那是驯服不可靠模型的必要手段。但当模型本身变得足够聪明、足够主动时，过度指令反而成了束缚。提示工程的重心，正从"事无巨细地告诉模型怎么做"，转向"只设定必要边界，把判断权交还给模型"。这一转变与软件工程中的管理理念演化颇为相似：从瀑布式开发中事无巨细的需求文档，到敏捷开发中只定义验收标准、把实现细节交给工程师自主判断。管理学中的"任务型领导"（Task-oriented Leadership）与"授权型领导"（Delegative Leadership）理论也印证了这一规律——当团队成员的能力和主动性达到较高水平时，领导者应当从详细的任务分配转向目标设定和边界把控，否则过度管控反而会降低团队效能。在 AI 领域，这种转变还有一个更具前瞻性的含义：随着 AI Agent（智能体）架构的兴起，模型正在从"被动回答者"进化为"主动执行者"，它们需要的不再是步步指引的操作手册，而是明确的目标函数和不可逾越的安全护栏。

对于每一个还在用老思路维护配置的人来说，这或许是时候回头看看那些积攒已久的规则——它们中有多少还在真正干活，又有多少只是在悄悄拖后腿。