1. 提示词越写越长这件事到底哪里出了问题如果你最近半年一直在用Claude做开发或者写内容大概率经历过这样一个阶段一开始随便说两句就能出结果后来发现效果不稳定于是开始加约束、加示例、加格式要求、加边界条件提示词从几十个字膨胀到几百字再膨胀到上千字。每次改完都觉得“这下应该稳了”结果跑起来还是时好时坏。Opus 5.5发布之后官方放出了一份提示词指南我第一时间逐条读完最反直觉的一个结论是这份指南里最有价值的部分不是教你怎么写而是教你什么时候该删。这个结论乍看有点标题党但如果你真的在Agent开发或者日常编码辅助里踩过坑就会明白它说的是什么。我们习惯性地认为“信息越充分模型表现越好”但实际使用中过长的提示词会带来三个非常具体的问题注意力稀释、指令冲突、以及维护成本失控。这三个问题在短对话里不明显一旦进入多轮Agent循环或者复杂任务编排就会集中爆发。这篇文章面向的是已经在用Claude做实际开发、或者正在搭建Agent工作流的从业者。我会把官方指南里关于“删”的逻辑拆开讲清楚同时结合我自己在项目里踩过的坑给出可以直接抄的提示词精简方法和验证流程。如果你还在“提示词越长越安心”的阶段这篇内容可能会帮你省下不少调试时间。2. 为什么“加约束”这个直觉在Opus 5.5上开始失效2.1 注意力机制下的指令权重稀释先讲一个基础但容易被忽略的事实模型在处理提示词时并不是把每一句话都同等对待。你可以把它想象成一个会议室提示词里的每一条指令都是一个人在发言。人越多每个人的声音就越容易被淹没。当你的提示词里塞了二十条约束模型在生成每一个token时需要在所有约束之间做权衡结果就是某些约束被“听到”了某些被忽略了。这不是模型能力不够而是注意力分配的物理限制。Opus 5.5在长上下文处理上确实比前代强了很多但“能处理长上下文”和“在长上下文里保持每条指令的权重”是两回事。官方指南里有一句话我印象很深大意是当提示词超过某个长度后新增的约束带来的收益会迅速递减而副作用会迅速上升。我自己的实测数据是在代码生成任务里提示词从300字增加到800字时首次通过率确实有提升但从800字增加到1500字时首次通过率反而下降了大约12%。这个拐点因任务类型而异但趋势是一致的。2.2 指令冲突你以为的补充其实是打架比注意力稀释更隐蔽的问题是指令冲突。举个例子很多人在写代码生成提示词时会同时写上这两条“请严格按照我提供的接口定义生成代码不要自行修改任何函数签名。”“如果发现接口定义中有不合理的地方请优化后给出更合理的实现。”这两条单独看都没问题放在一起就是矛盾的。模型在面对冲突指令时行为是不确定的——有时候它会选择遵守第一条有时候会选择第二条取决于上下文里哪条指令离生成位置更近。这种不确定性在单次调用里可能看不出来但在Agent的多轮循环里会被放大导致行为漂移。官方指南里专门提到了这一点提示词里的每一条指令都应该是可独立验证的如果两条指令在某些场景下会给出相反的行为预期那它们就不应该同时存在。2.3 维护成本改一处崩三处的连锁反应还有一个很少被讨论但实际项目里最致命的问题长提示词的维护成本。当你的提示词有1500字、包含十几个约束和五六个示例时你想调整其中一个行为会发现牵一发而动全身。改了一个示例另一个场景的输出格式就变了加了一条约束之前稳定的case开始报错。我在一个Agent项目里遇到过这种情况提示词迭代到第四版时已经没人敢动了因为每次改动都会引入新的回归问题。最后我们的做法是把提示词拆成三层——核心指令层、任务模板层、示例层——每层独立维护才把这个问题控制住。而这个思路和官方指南里“删”的逻辑是一致的。3. 官方指南里“删”的三条具体操作线3.1 删冗余示例一个够用的示例胜过三个相似的官方指南里关于示例的部分核心观点是示例的作用是锚定输出格式和风格不是穷举所有情况。很多人写提示词时习惯放三四个示例觉得这样模型能学得更准。但实际上如果这几个示例在结构上是同质的那第二个和第三个带来的边际收益非常低反而会占用宝贵的上下文空间。我现在的做法是每个任务类型只保留一个“最小完整示例”这个示例必须覆盖输出格式的所有关键字段但不包含任何边界情况。边界情况用文字描述不用示例。这样做的效果是提示词长度减少了大约40%而输出格式的稳定性反而提升了。具体操作上你可以这样判断一个示例是否该删判断维度该保留该删除结构覆盖覆盖所有必填字段与另一个示例结构重复场景差异代表一类独立场景只是换了个变量值长度占比占提示词总长15%以内单个示例超过200字可替代性文字描述无法替代用一句话就能说清楚3.2 删防御性指令不要为小概率事件写大段约束防御性指令是提示词膨胀的重灾区。什么叫防御性指令就是那些“为了防止模型做某件不太可能做的事”而写的约束。比如“请不要在代码中使用任何已废弃的API。”“请确保不要生成任何可能引起歧义的解释。”“如果遇到不确定的情况请不要随意猜测。”这些指令的问题在于它们描述的是“不要做什么”而模型对否定式指令的遵循能力天然弱于肯定式指令。更关键的是这些约束针对的是小概率事件但它们的成本是每条都在稀释核心指令的权重。官方指南的建议是只保留那些在测试中真实出现过的失败模式对应的约束。如果某个问题你从来没在实际输出里见过那这条约束就不该存在。我按照这个原则清理了一轮提示词删掉了大约三分之一的防御性指令实测输出质量没有下降反而因为核心指令更突出稳定性有所提升。3.3 删格式赘述用结构化标记替代自然语言描述第三个该删的是格式赘述。很多人用自然语言描述输出格式比如“请先输出一个标题然后换行接着输出三个要点每个要点用短横线开头要点之间空一行……”这种描述方式又长又容易产生歧义。Opus 5.5对结构化标记的理解能力很强你完全可以用更紧凑的方式表达同样的要求。比如上面的例子可以写成输出格式 ## 标题 - 要点1 - 要点2 - 要点3这样不仅更短而且模型对格式的遵循准确率更高。官方指南里明确提到对于格式要求结构化示例比自然语言描述更有效且占用token更少。我在实际项目里把格式描述从自然语言改成结构化标记后格式错误率从大约8%降到了2%以下。4. 精简之后怎么保证该有的约束一个不少4.1 建立失败模式清单而不是约束清单删完之后最大的担心是“万一漏了怎么办”。我的解法是不维护约束清单维护失败模式清单。具体做法是每次在实际运行中发现一个失败case就记录下它的失败模式然后判断这个失败模式是否值得用一条约束来防御。如果值得就加一条如果不值得就接受这个失败率。这个思路的转变很关键。约束清单是“我猜模型可能会犯什么错”失败模式清单是“模型实际犯了什么错”。前者会无限膨胀后者有明确的边界。我现在的失败模式清单里只有七条对应七条核心约束提示词总长度控制在400字以内覆盖了之前1500字提示词90%以上的场景。4.2 用分层结构替代平铺约束另一个保证不遗漏的方法是分层。我把提示词分成三层第一层角色与目标。用两三句话定义模型在这个任务里的角色和最终目标。这一层不涉及具体约束只定方向。第二层硬约束。只放那些违反了一定会出问题的规则通常不超过五条。每条约束都必须对应一个真实的失败模式。第三层任务模板。具体任务的输入输出格式和示例按任务类型组织不同任务之间互不干扰。这样分层之后每层的内容都是内聚的修改一层不会影响另一层。而且当你要检查“有没有漏掉什么”时只需要逐层对照失败模式清单不用在长文本里大海捞针。4.3 用回归测试代替人工检查人工检查提示词是否完整在提示词超过500字后基本不可靠。我的做法是建一个小的回归测试集包含10到15个代表性case每次修改提示词后跑一遍看通过率有没有下降。这个测试集不需要很复杂用脚本调用API批量跑就行。关键是这个测试集要覆盖你实际业务里的主要场景而不是追求数量。我见过有人建了几百个case的测试集结果每次跑完要半小时最后根本没人跑。10到15个case两分钟跑完才能真的用起来。5. 在Agent循环里提示词精简的收益会被放大5.1 多轮调用下的token成本与延迟Agent和单次对话最大的区别是提示词会在每一轮循环里被重复发送。如果你的系统提示词是1500字一个任务跑了20轮那就是30000字的重复开销。这不仅是成本问题更是延迟问题——每多1000字提示词首token延迟大概增加几十到上百毫秒20轮累积下来就是秒级的差异。我把系统提示词从1200字精简到350字之后一个典型Agent任务的端到端时间从平均14秒降到了9秒左右。这个提升在单次调用里不明显但在Agent场景里是实打实的用户体验差异。5.2 行为漂移长提示词在多轮里的累积误差比成本更严重的是行为漂移。长提示词里的指令冲突和注意力稀释问题在单轮里可能只是偶尔出现但在多轮循环里会累积。第一轮模型可能忽略了某条次要约束第二轮基于第一轮的输出继续生成偏差就被放大了到第五轮、第十轮输出可能已经完全偏离了预期。精简提示词的一个隐性收益是核心指令的权重更集中模型在每一轮里都更可能稳定地遵循这些指令从而减少累积误差。我在一个代码重构Agent里对比过1500字提示词在第8轮左右开始出现明显的格式漂移而350字提示词跑到第15轮仍然稳定。5.3 工具调用场景下的指令优先级Agent通常涉及工具调用这时候提示词里还需要包含工具使用说明。如果提示词本身已经很长再加上工具说明很容易出现“模型不知道该先遵循哪条指令”的情况。官方指南里提到在工具调用场景下工具说明应该和核心指令分离放在独立的系统消息或工具定义里而不是混在提示词正文中。这样做的好处是模型在处理工具调用时注意力集中在工具定义上不会被提示词正文里的其他约束干扰。我现在的做法是系统提示词只保留角色、目标和硬约束工具说明全部放在工具定义里任务模板按需注入。这样系统提示词可以稳定控制在300字左右工具调用的准确率反而比之前混在一起时更高。6. 我自己的精简实操从1200字到350字的完整过程6.1 第一步标记每句话的存在理由我把自己用了三个月的1200字提示词打印出来逐句标记这句话是为了解决什么问题如果删掉它哪个具体场景会出问题标记完之后发现大约40%的句子找不到明确的对应场景它们要么是“以防万一”加的要么是从别的提示词里抄来的要么是早期调试时加的但后来问题已经不存在了。这一步的关键是诚实。如果你发现某句话的理由是“感觉应该有”那它大概率就该删。6.2 第二步合并同类约束消除冲突标记完之后我把剩下的句子按主题分组发现有几组约束其实在说同一件事只是表述不同。比如“输出要简洁”和“不要写冗长的解释”就是同一件事。合并之后约束数量从23条降到了9条。然后检查冲突。我发现有两组约束在特定场景下会打架一组要求“严格按模板输出”另一组要求“根据内容灵活调整结构”。这两条不可能同时满足必须选一个。我选择了前者因为模板输出的稳定性对下游处理更重要。6.3 第三步用结构化格式重写压缩到350字合并和消除冲突之后内容已经少了很多但还是自然语言散落着。我用结构化格式重写了一遍角色资深代码审查助手 目标对给定代码进行审查输出结构化审查报告 硬约束 1. 只审查代码逻辑和潜在缺陷不评价代码风格 2. 每个问题必须给出具体行号和修复建议 3. 不确定的问题标记为“待确认”不猜测 输出格式 ## 审查摘要 ## 问题列表 - 行号 | 严重程度 | 问题描述 | 修复建议 ## 待确认项这样重写之后字数从1200降到了350左右而且每条约束都是可验证的。6.4 第四步跑回归测试确认没有引入新问题精简完成后我用之前建的15个回归case跑了一遍通过率从精简前的86%提升到了91%。有2个之前偶尔失败的case现在稳定通过了原因是之前的长提示词里存在指令冲突精简后冲突消失了。没有出现新的失败case。这个结果验证了一个判断在大多数场景下提示词的问题不是不够长而是太长导致了指令之间的相互干扰。7. 精简提示词时最容易踩的三个坑7.1 删过头把必要的边界约束也删了精简的第一个坑是删过头。有些约束看起来像是防御性的但实际上对应着真实的高频失败模式。比如在代码生成任务里“不要生成测试代码”这条约束如果你删了模型有相当概率会在输出里附带测试用例导致下游解析失败。判断标准是如果这个失败模式在你的实际运行中出现频率超过5%那对应的约束就不该删。5%这个阈值可以根据业务容忍度调整但关键是要有数据支撑不能凭感觉。7.2 格式压缩导致可读性下降第二个坑是为了压缩字数把提示词写成了一团乱麻自己都看不懂。提示词是给人维护的可读性很重要。我的原则是宁可多花50个字把结构写清楚也不要为了省字数把三条约束挤成一行。结构化标记本身就有压缩效果不需要再额外牺牲可读性。7.3 忽略了模型版本差异第三个坑是拿旧版本的提示词直接套用到Opus 5.5上。不同版本对提示词的敏感度不同有些在旧版本上必要的约束在新版本上可能已经不需要了因为模型本身的能力提升了。官方指南里也提到每次大版本更新后都应该重新审视提示词删掉那些因为模型能力提升而变得多余的约束。我的做法是每次模型版本更新后先跑一遍回归测试然后逐条检查约束问自己这条约束在旧版本上是为了解决什么问题新版本还需要吗通常能再删掉10%到20%的内容。8. 把“删”变成习惯之后我的工作流发生了什么变化最直接的变化是调试时间大幅缩短。以前改提示词要反复跑case、对比输出、调整措辞一轮下来半小时起步。现在提示词短了改一条约束的影响范围清晰可见通常十分钟内就能完成一轮迭代。另一个变化是Agent的稳定性明显提升。之前跑长任务时总要盯着怕它中途跑偏现在系统提示词精简到350字以内核心指令权重集中跑十几轮基本不用干预。这让我能把更多精力放在任务编排和工具设计上而不是整天跟提示词较劲。还有一个意外收获是精简提示词的过程逼着我重新思考每个任务的核心目标是什么。很多时候提示词膨胀是因为任务定义本身就不清晰想用约束来弥补定义的模糊。当你被迫删掉那些“以防万一”的约束时反而会倒逼你把任务目标想清楚。这个思考过程的价值可能比提示词本身更大。如果你现在手里的提示词超过800字我建议你今天就做一件事把它打印出来逐句标记存在理由然后删掉那些找不到明确对应场景的句子。不用追求一步到位先删20%试试跑一遍你的核心case看看效果是变好还是变差。根据我的经验大概率会变好。