Opus 5.5提示词精简指南：删掉冗余，成功率提升15%

1. 那份官方指南里最反常识的一句话

Anthropic 给 Opus 5.5 出的那份提示词指南，我前后翻了三遍。第一遍看的时候觉得平平无奇，第二遍开始有点不对劲，第三遍才反应过来——整份文档里信息密度最高的部分，不是教你怎么"加"，而是教你怎么"删"。

这个结论乍一听很反直觉。过去两年大家做提示词工程，习惯性动作都是往上堆：加角色设定、加输出格式约束、加 few-shot 示例、加思维链引导、加各种"你必须""你一定要""绝对不要"。一份提示词从 200 字膨胀到 2000 字，感觉每加一句都更安心。但 Opus 5.5 这一代模型的能力分布变了，很多过去必须显式写出来的东西，现在写出来反而是负收益。

我拿自己手上一个跑了半年的 Agent 项目做了对照实验。同一个任务，旧版提示词 1400 字左右，新版精简到 380 字，任务成功率从 82% 提到了 91%，平均 token 消耗降了六成多，单次响应延迟从 4.2 秒压到 2.6 秒。这个结果让我重新审视了自己过去积累的那套"提示词越详细越好"的方法论。

这篇东西不是官方文档的翻译，也不是泛泛而谈的"提示词技巧合集"。我想做的是把这份指南里真正有价值的那部分拆开，讲清楚三件事：为什么这一代模型对冗余提示词这么敏感、哪些内容属于"该删的"、以及删完之后怎么保证不翻车。如果你正在用 Claude 做 API 调用、Agent 开发，或者单纯想让日常对话质量更高，下面这些内容应该能直接用上。

2. Opus 5.5 为什么开始"嫌弃"啰嗦的提示词

2.1 指令遵循能力的跃升带来的副作用

要理解"删"这件事，得先理解这一代模型在指令遵循上发生了什么变化。

早期的模型，你给它一句"帮我写个爬虫"，它可能给你返回一段伪代码，或者干脆反问你想要爬什么。所以那时候大家养成了习惯：把任务拆到极细，把约束写到极致，把边界情况全部枚举出来。提示词写得像一份需求规格说明书，本质上是在替模型做它当时做不了的推理。

Opus 5.5 这一代不一样了。它在指令遵循上的提升不是线性的，而是跨了一个台阶。你给它一个相对模糊的高层目标，它能自己补全中间的执行路径。这时候问题就来了：你写的那一大堆细节约束，和模型自己推理出来的执行路径之间，会产生冲突。

举个我实际遇到的例子。我有个提示词里写着"先分析用户意图，再决定调用哪个工具，最后组织回复"。这句话在旧模型上是必要的引导，但在 Opus 5.5 上，模型本来就会做这三步，而且它判断"什么时候该跳过意图分析直接调工具"的能力比我的硬编码规则更准。我那句引导反而把它锁死在固定流程里，遇到简单请求也要走完三步，白白浪费一轮推理。

核心逻辑：当模型的默认行为已经优于你手写的规则时，任何显式约束都是在给它戴镣铐。

2.2 上下文注意力被稀释的真实机制

另一个更技术性的原因是注意力稀释。

Transformer 架构在处理长上下文时，注意力权重是会被平摊的。你的提示词里塞了 1500 字，其中真正决定任务成败的可能只有 200 字，剩下 1300 字是背景铺垫、格式说明、重复强调。这些内容不会消失，它们会持续占用注意力预算，让模型在关键指令上的聚焦度下降。

我做过一个粗糙但有效的测试：把同一份提示词里的"背景介绍"段落全部删掉，只保留任务描述和输出要求，在 50 个测试用例上跑对比。结果是精简版的输出质量在 43 个用例上持平或更好，只有 7 个用例变差，而那 7 个变差的用例，问题都出在我删掉的那段背景里其实藏了一个关键的领域术语定义。

这个测试说明什么？说明大部分背景铺垫是无效的，真正有用的信息往往集中在少数几个具体定义和约束上。删的时候要精准，不能一刀切。

2.3 从"填鸭"到"对话"的范式转移

还有一个容易被忽略的点：Opus 5.5 在多轮对话中的状态保持能力变强了。

过去我们写提示词，习惯把所有信息塞进 system prompt，因为模型在多轮里容易"忘事"。现在这个假设不成立了。模型能在多轮交互中稳定记住前面确立的规则和上下文，这意味着很多信息不需要在开头一次性灌进去，可以在需要的时候再补充。

这个变化对 Agent 开发影响特别大。以前我写 Agent 的 system prompt，恨不得把工具说明、输出格式、错误处理、边界情况全部写死。现在我更倾向于把 system prompt 压到最小，把具体的工具使用说明放到工具定义里，把格式要求放到需要格式化的那一步再给。整体提示词体积下来了，灵活性反而上去了。

3. 该删什么：四类典型的冗余提示词

3.1 重复强调型：说一遍和说十遍效果一样

最常见也最该删的，是重复强调。

我见过太多提示词是这样的结构：开头说"你是一个专业的代码助手"，中间说"作为专业代码助手，你需要……"，结尾又说"记住你是专业代码助手"。三遍。模型不是金鱼，说一遍它就记住了。重复强调不但没用，还会让模型误以为这件事特别重要，从而在其他方面过度保守。

判断标准很简单：同一件事，如果你在提示词里说了超过一遍，删到只剩一遍。如果删完之后你觉得不放心，那说明你对模型的信任度还没调整过来，这是心态问题不是技术问题。

3.2 常识兜底型：模型早就知道的事不用教

第二类该删的是常识兜底。

比如"输出要准确""不要编造事实""保持礼貌""注意代码规范"这类话。这些是模型的默认行为，写出来等于没说。更糟的是，有些兜底语句会触发模型的过度防御。你写一句"不要编造事实"，模型可能会变得过度谨慎，遇到不确定的地方就反复声明"我不确定"，把本来能答的问题答得畏畏缩缩。

我实测过一个案例：一个信息抽取任务，提示词里加了"如果信息不存在请明确说明，不要编造"。结果模型在 30% 的用例里把明明存在的信息也标成了"未找到"，因为它把"谨慎"的优先级调得太高了。删掉这句话之后，准确率反而回升。

经验：负面约束（不要做什么）比正面约束（要做什么）更容易引发副作用，能删就删。

3.3 流程硬编码型：把推理权还给模型

第三类是最隐蔽的，流程硬编码。

前面提过那个"先分析意图再调工具"的例子就属于这类。我们习惯把任务的执行步骤写死，因为旧模型需要这种引导。但 Opus 5.5 的推理能力已经能自己规划路径，你写死的流程反而限制了它的发挥。

这类内容的特点是：读起来像一份 SOP，有明确的步骤编号，有"首先""然后""最后"这样的连接词。删的时候要小心，因为有些流程确实是业务必需的（比如合规检查必须放在输出之前），这种不能删。判断标准是：这个步骤是业务规则要求的，还是你为了让模型能跑通而加的？前者保留，后者删掉。

3.4 格式过度约束型：留白比填满更难

第四类该删的是过度的格式约束。

"输出必须是 JSON""必须包含以下字段""字段名必须用下划线""时间格式必须是 ISO 8601"……这些约束在需要结构化输出的场景下是必要的，但很多人会把格式约束写得过细，细到模型为了满足格式而牺牲内容质量。

我的做法是：能用 API 层面的结构化输出（比如 tool use、JSON mode）解决的，就不要在提示词里用自然语言描述格式。API 层面的约束是硬约束，模型不会违反；提示词里的格式描述是软约束，模型会为了内容而妥协。两者混用的时候，模型经常顾此失彼。

4. 删完之后怎么保证不翻车

4.1 建立最小可用提示词的基线

删不是目的，找到那个"刚好够用"的平衡点才是。

我的方法是先建立一个最小基线：只保留任务描述和输出要求，其他全部删掉，然后跑测试。如果基线表现可接受，就在此基础上按需添加；如果基线表现不行，再逐条加回被删的内容，每加一条测一次，看哪条真正带来了提升。

这个过程听起来繁琐，但做一次之后你对"什么内容真正有用"的判断会准很多。我做完这个基线测试之后，发现自己过去提示词里大概有 60% 的内容是可以删的，而且删掉之后没有任何损失。

4.2 用测试集而不是感觉来判断

这里必须强调测试集的重要性。

很多人删提示词是靠感觉的：删完跑两个 case 觉得还行，就上线了。这种做法风险很大，因为提示词的改动往往在边缘 case 上才暴露问题。

我的做法是维护一个 30 到 50 条的测试集，覆盖正常 case、边缘 case、对抗 case 三类。每次改提示词都跑一遍，记录成功率、平均 token、平均延迟三个指标。只有三个指标都不退化，才认为这次改动是有效的。

测试集的构建不需要很复杂，从线上真实请求里采样就行。关键是覆盖度要够，特别是那些"看起来不会出问题"的简单 case，往往最能暴露提示词精简后的副作用。

4.3 分层管理：system、tool、turn 各管各的

删完之后，剩下的内容怎么组织也有讲究。

我现在习惯把提示词分三层管理：

这样分层的好处是，改一层不影响其他层，测试的时候也能定位问题出在哪一层。过去我把所有东西塞在 system prompt 里，改一个格式要求要动整个提示词，测试成本很高。

5. 一个真实项目的精简全过程

5.1 项目背景与原始提示词

说个具体案例。我手上有个客服工单自动分类的 Agent，输入是用户的一段自然语言描述，输出是分类标签加处理建议。原始提示词 1200 字左右，结构大概是：角色设定 200 字、任务说明 300 字、分类体系说明 400 字、输出格式 200 字、注意事项 100 字。

这个提示词跑了两周，分类准确率 79%，处理建议的质量参差不齐，平均响应延迟 3.8 秒。我决定按"删"的思路重构一遍。

5.2 逐段拆解与删除决策

角色设定那 200 字，写的是"你是一个经验丰富的客服专家，熟悉各类工单处理流程，能够准确判断工单类型并给出专业建议"。这段删掉，因为分类任务不需要角色扮演，模型的能力不依赖于这个设定。

任务说明 300 字，核心信息是"根据用户描述判断工单类型，并给出处理建议"。保留，但压缩到 50 字。

分类体系说明 400 字，这部分是业务知识，不能删，但可以优化。原来的写法是把每个分类的定义、示例、边界情况全部写出来。我改成只写分类名称和一句话定义，示例和边界情况交给模型自己推理。压缩到 150 字。

输出格式 200 字，原来用自然语言描述 JSON 结构。改成用 tool use 定义输出 schema，提示词里只写"按 schema 输出"。这部分直接归零。

注意事项 100 字，写的是"如果无法判断请选择'其他'分类""建议要具体可执行"这类。删掉，因为模型默认就会这么做。

5.3 精简后的效果对比

重构后的提示词大概 250 字，加上 tool schema 定义，总体积比原来小了七成。

跑测试集的结果：分类准确率从 79% 提到 86%，处理建议的质量评分从 3.2 提到 4.1（5 分制），平均延迟从 3.8 秒降到 2.1 秒，平均 token 消耗从 1800 降到 620。

这个提升幅度超出我的预期。我原本以为精简主要是省成本，没想到质量也上去了。后来想明白了：原来的提示词里那些冗余内容，其实是在干扰模型对核心任务的判断。删掉之后，模型的注意力全部集中在"分类"和"建议"这两件事上，自然做得更好。

5.4 精简过程中踩的两个坑

过程不是一帆风顺的，我踩了两个坑。

第一个坑是删得太狠。我一开始把分类体系说明也删了，只留了分类名称。结果模型对几个边界模糊的分类判断不准，准确率掉到 71%。后来加回一句话定义，才恢复到 86%。这说明业务知识类的信息不能省，省的是那些"教模型怎么思考"的内容。

第二个坑是格式约束迁移到 tool schema 之后，模型偶尔会输出 schema 之外的字段。原因是 tool schema 里我用了additionalProperties: false，但模型在某些情况下会忽略这个约束。解决办法是在提示词里补一句"严格按 schema 输出，不要添加额外字段"，一句话解决。

6. 删提示词这件事的边界在哪里

6.1 什么情况下不能删

"删"不是万能药，有些内容是不能删的。

业务规则类的信息不能删。比如"退款工单必须标记为高优先级""涉及账户安全的工单要转人工"，这些是业务逻辑，模型不可能自己推理出来。

领域术语的定义不能删。如果你的业务里有特殊术语，比如"活跃用户"在你的系统里定义为"7 天内有过登录行为的用户"，这个定义必须写清楚，否则模型会按通用理解来处理。

合规和安全约束不能删。涉及敏感信息处理、输出内容审核的场景，相关的约束必须显式写出，这是底线。

6.2 什么情况下反而要加

有些场景下，提示词不但不能删，还要加。

多步骤复杂任务，需要显式引导。虽然 Opus 5.5 的规划能力很强，但对于步骤之间有严格依赖关系的任务，显式写出步骤顺序能减少出错。

需要特定输出风格的场景，需要示例。如果你要求输出必须符合某种特定的语气或格式，给一两个示例比用自然语言描述更有效。

对抗性场景，需要防御性约束。如果你的应用会收到恶意输入，相关的防御约束不能省。

6.3 一个判断标准：模型能不能自己推出来

我总结了一个简单的判断标准：这条信息，模型能不能从任务描述和上下文里自己推出来？

能推出来的，删。推不出来的，留。

这个标准听起来简单，但实际用的时候需要你对模型的能力边界有准确的认知。我的建议是，拿不准的时候就做 A/B 测试，用数据说话，别靠直觉。

7. 把"删"变成一种习惯

7.1 每次改提示词先问三个问题

我现在改提示词之前会先问自己三个问题：

这句话删掉，模型还能完成任务吗？如果能，删。

这句话是在教模型怎么思考，还是在提供模型不知道的信息？如果是前者，删。

这句话是为了让模型做得更好，还是为了让我自己更安心？如果是后者，删。

这三个问题能过滤掉大部分冗余内容。特别是第三个问题，很多时候我们加约束不是因为模型需要，而是因为我们不放心。这种"心理安慰型"的提示词，是精简的主要对象。

7.2 建立提示词的版本管理

精简提示词是个迭代过程，需要版本管理。

我用的是最土的办法：每次改动都存一个版本，记录改动内容、测试结果、上线时间。这样出问题的时候能快速回滚，也能追溯是哪次改动引入的问题。

版本管理不需要很复杂，一个表格就够了。关键是要坚持记录，特别是那些"看起来没什么影响"的小改动，往往就是它们埋下了隐患。

7.3 定期做提示词体检

提示词会随着业务变化而腐化。半年前写的提示词，可能有一半内容已经过时了。

我现在的习惯是每个月做一次提示词体检：把线上提示词拿出来，逐句问"这句话现在还有用吗"。大部分时候能删掉 10% 到 20% 的内容，偶尔能发现一些因为业务变化而变得有害的约束。

这个习惯坚持了半年，我的提示词平均体积缩小了 60%，而任务成功率提升了 15 个百分点。这个投入产出比，比任何提示词技巧都高。

8. 关于 Opus 5.5 提示词的一点个人体会

用了几个月 Opus 5.5，我最大的感受是：这一代模型对提示词的"品味"变高了。它不喜欢啰嗦的、重复的、把它当傻子教的提示词。你给它一个清晰的目标，它能把事情办得很漂亮；你给它一堆细碎的约束，它反而束手束脚。

这个变化对做 Agent 开发的人影响尤其大。过去我们花大量时间在提示词工程上，试图用文字把模型的行为框死。现在这个思路要调整了：把精力放在任务定义、工具设计、测试验证上，提示词本身反而应该越简洁越好。

当然，简洁不等于简陋。该有的业务信息、领域知识、格式约束一个都不能少，少的是那些"教模型怎么做事"的内容。这个边界需要在实际项目里反复摸索，没有一刀切的标准。

最后分享一个我最近在用的技巧：写完提示词之后，把它读一遍，如果读起来像一份给新员工的培训手册，那大概率太长了；如果读起来像一张便签纸上的任务清单，那长度就差不多了。模型不需要培训，它需要的是清晰的任务和必要的信息。