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角色定位、核心任务、全局约束稳定改动频率低tool definition工具说明、参数格式、调用时机随工具变化独立维护turn prompt当前任务的具体要求、临时上下文每次请求都不同这样分层的好处是改一层不影响其他层测试的时候也能定位问题出在哪一层。过去我把所有东西塞在 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.15 分制平均延迟从 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 开发的人影响尤其大。过去我们花大量时间在提示词工程上试图用文字把模型的行为框死。现在这个思路要调整了把精力放在任务定义、工具设计、测试验证上提示词本身反而应该越简洁越好。当然简洁不等于简陋。该有的业务信息、领域知识、格式约束一个都不能少少的是那些教模型怎么做事的内容。这个边界需要在实际项目里反复摸索没有一刀切的标准。最后分享一个我最近在用的技巧写完提示词之后把它读一遍如果读起来像一份给新员工的培训手册那大概率太长了如果读起来像一张便签纸上的任务清单那长度就差不多了。模型不需要培训它需要的是清晰的任务和必要的信息。