1. 从“删”字说起Opus 5.5 提示词指南到底在讲什么第一次看到“最该学的居然是删”这个说法我下意识以为是标题党。毕竟这两年提示词工程的主流叙事一直是“加”——加角色设定、加约束条件、加输出格式、加思维链、加少样本示例。大家比的是谁的提示词更长、更全、更像一份需求文档。结果官方指南反过来说核心动作是删这个反差本身就值得琢磨。我把这份指南反复读了几遍又拿手头的几个 Agent 项目做了对照实验结论是它讲的不是“提示词越短越好”这种偷懒逻辑而是在讲一个更本质的东西——上下文预算的分配权。模型能力越强它对冗余信息的容忍度反而越低因为强模型会认真对待你写的每一句话包括那些你随手加进去、其实并不需要的约束。你写“请务必保持专业”它就在输出里反复确认专业性你写“不要啰嗦”它可能连必要的解释都省掉。这些指令单看没问题叠在一起就互相打架最后模型在多个目标之间做妥协输出反而变得平庸。所以这篇东西适合谁看如果你只是偶尔用对话框问几个问题删不删影响不大。但如果你在做 Agent 开发、在写系统级提示词、在通过 API 批量调用模型或者你在用 Claude Code 这类工具做工程化的事情那这份指南里的取舍逻辑会直接影响你的 token 成本、响应稳定性和任务成功率。下面我按自己的理解把这份指南拆成几个可操作的层面来讲中间会穿插我实际踩过的坑和验证过的做法。2. 提示词膨胀是怎么发生的一个真实的失控过程2.1 从三行到三百行增量式堆叠的陷阱我拿自己半年前写的一个代码审查 Agent 举例。最初版本的系统提示词只有三行你是一个代码审查助手找出问题并给出修改建议用中文回复。跑得挺好。后来陆续遇到问题它有时候不区分严重程度我就加了一句“按严重程度分级”有时候漏掉安全类问题我加了“重点关注注入、越权、敏感信息泄露”有时候建议太笼统我加了“每条建议必须给出具体代码示例”有时候格式乱我加了输出模板。三个月后这份提示词变成了两百多行包含七个章节、四张表格、十几条禁止事项。问题出在哪出在我每次都是针对单个失败案例做加法从来没有回头删过。这就像给一个本来健康的系统不断打补丁每个补丁单独看都合理合在一起就成了意大利面条。最直接的后果是响应变慢、token 成本上升但更隐蔽的后果是模型开始在一些它以前能处理好的简单任务上出错。因为提示词里的约束太多它在做判断时要同时满足十几个条件注意力被稀释了。2.2 强模型对冗余更敏感而不是更宽容很多人有个误解觉得模型越强就越能“理解”冗长的提示词能自动过滤掉无关信息。实际观察下来恰恰相反。弱模型因为能力有限你给它一堆约束它可能只抓住最显眼的几个执行剩下的忽略掉反而“看起来”没受干扰。强模型会试图认真执行每一条于是约束之间的冲突就暴露出来了。举个具体的例子。我在提示词里同时写了“回答要简洁不要展开无关内容”和“对于复杂问题要给出充分的推理过程”。这两条在人类看来可以共存——简单问题简洁、复杂问题详细。但模型在判断“这个问题算简单还是复杂”时会产生摇摆有时候一个中等难度的问题它既想简洁又想充分推理最后输出一个四不像推理不完整结论也不干脆。删掉其中一条或者把判断标准写清楚问题立刻消失。2.3 官方指南里“删”的三个层次我把指南里关于删的部分归纳成三个层次从浅到深分别是删重复同一个要求用不同措辞写了好几遍。比如“不要编造”“不要虚构”“基于事实回答”“不确定就说不确定”这四句其实是一件事。留一句最明确的就行。删默认模型本来就会做的事你不需要专门交代。比如“请用通顺的中文回复”“请保持逻辑连贯”“请认真思考”这些是模型的默认行为写进去只是浪费 token。删冲突两条指令在特定场景下会互相矛盾但你没有给出优先级。这种最危险因为它不会报错只会让输出质量悄悄下降。前两个层次靠通读就能发现第三个层次需要你拿真实任务去测。我的做法是准备一组二十条左右的典型输入每次改完提示词就跑一遍对比输出差异。这个习惯帮我抓出了至少五处隐藏的指令冲突。3. 删之前先想清楚哪些东西是真正不能删的3.1 任务边界与输出契约删的前提是知道什么必须留。我的经验是无论怎么精简有两类信息必须保留任务边界和输出契约。任务边界回答的是“你负责什么、不负责什么”。比如一个客服 Agent你要明确它只处理售后咨询不处理售前比价遇到超出范围的问题要转人工。这条不写清楚模型会自作主张地扩展职责回答一些它不该回答的问题。输出契约回答的是“结果长什么样”包括格式、字段、长度范围、是否允许 Markdown 等。如果你要程序化解析输出这部分一个字都不能省。我见过有人为了精简把输出格式说明删了结果模型每次返回的结构都不一样下游解析代码天天报错。省下的那点 token远不够填解析失败的坑。3.2 关键约束的优先级排序约束之间如果可能冲突必须显式排出优先级。我的做法是在提示词里用一句话定调比如“当准确性和简洁性冲突时优先保证准确性”。这一句话的价值极高它相当于给模型一个冲突仲裁规则让它在两难时有据可依。排序的原则通常是安全合规 事实准确 任务完成 格式规范 风格偏好。越靠前的越不能妥协。你可以根据自己场景调整但一定要有这么一个顺序并且写进提示词。3.3 少样本示例的取舍标准示例是提示词里最占 token 的部分也是最容易被滥用的部分。我的取舍标准是只有当任务存在模型难以从指令中推断的隐含模式时才放示例。比如你要它按某种特定的、非标准的格式输出或者要它模仿某种特定的语气示例比文字描述有效得多。但如果任务本身很直白示例就是冗余。另外一个技巧是示例要放“边界案例”而不是“典型案例”。典型案例模型自己就能处理好放进去只是重复。边界案例才能教会模型在模糊地带怎么判断。我通常一个任务最多放两个示例一个正常情况一个边界情况再多就考虑是不是指令本身没写清楚。4. 实操一次完整的提示词瘦身过程4.1 准备阶段建立评测基线删之前必须先有基线否则你删完不知道是变好了还是变坏了。我的做法是收集 20 到 30 条真实任务输入覆盖简单、中等、困难三个难度以及至少 5 条边界情况。用当前提示词跑一遍把输出保存下来。定义评分维度比如任务完成度、格式正确率、事实准确率、平均 token 消耗、平均响应时间。人工或半自动地给每条输出打分形成基线数据。这一步看起来麻烦但它是后面所有优化的依据。没有基线你的“删”就是凭感觉很容易把有用的东西删掉。4.2 第一轮机械式去重第一轮不需要动脑子纯机械操作。把提示词里表达相同意思的句子合并把模型默认行为删掉。我通常能在这个阶段砍掉 20% 到 30% 的长度。具体做法是逐句问自己三个问题这句话和前面某句是不是一个意思这句话描述的是不是模型本来就会做的事这句话删掉之后任务还能不能完成三个问题有一个答案是“是”就删。这一轮结束后跑一次评测正常情况下指标应该持平或微升。如果明显下降说明你删掉了不该删的东西回滚重来。4.3 第二轮冲突检测与优先级重排第二轮是重点。把剩下的指令按主题分组比如“准确性相关”“格式相关”“风格相关”“安全相关”然后检查组内和组间有没有冲突。我常用的检测方法是构造“压力测试输入”——专门设计一些会让两条指令打架的输入。比如同时有“简洁”和“充分推理”两条指令时我就输入一个中等复杂度的技术问题看模型怎么处理。如果输出明显在两者之间摇摆就说明冲突存在。处理冲突的方式有两种要么删掉优先级低的那条要么加一句仲裁规则。我倾向于后者因为很多约束本身是有价值的只是需要明确什么时候适用。4.4 第三轮示例精简与结构化重写最后一轮处理示例和整体结构。示例按前面说的标准精简然后考虑把提示词重写成更结构化的形式。结构化不是指用 Markdown 标题分章节那么简单而是指按模型的处理顺序组织信息。我的经验顺序是角色与目标 → 任务边界 → 关键约束与优先级 → 输出契约 → 示例。这个顺序符合模型从“我是谁”到“做什么”到“怎么做”到“做成什么样”的认知流程比随意堆叠效果好很多。重写完之后再跑一次评测对比基线。我最近一次完整的瘦身把一份 280 行的提示词压到 95 行token 消耗降了约 60%任务完成度反而从 82% 提升到 89%。提升主要来自冲突消除后模型判断更稳定。5. 常见问题与排查技巧实录5.1 删完之后模型变“笨”了怎么办这是最常见的反馈。原因通常有三个一是删掉了任务边界模型开始乱扩展二是删掉了输出契约格式失控导致下游处理失败看起来像变笨三是删掉了必要的示例模型对隐含模式的理解出现偏差。排查顺序建议从输出契约开始查因为格式问题最容易被误判为能力问题。如果格式没问题再检查任务边界。最后才怀疑示例。我遇到过一次删了一个示例后模型在某个特定输入上总是答偏把示例加回去就好了。那个示例教的是“当信息不足时应该反问而不是猜测”这条规则用文字写模型理解得不好用示例就很清楚。5.2 不同模型对同一份提示词的敏感度差异同一个任务Opus 5.5 和更小的模型对提示词精简的反应完全不同。强模型在精简后往往表现更好因为干扰少了弱模型可能因为缺少明确引导而表现下降。所以如果你的系统里同时调用多个模型不要用同一份提示词要分别调优。我的做法是维护一个“基础提示词”加“模型适配层”。基础部分放任务边界和输出契约适配层放针对具体模型的补充说明。这样切换模型时只需要改适配层。5.3 提示词版本管理删改频繁的时候版本管理很重要。我用的是最简单的方案提示词存成独立文件用 Git 管理每次改动写清楚改了什么、为什么改、评测结果如何。文件名带上日期和版本号。这样出问题可以快速回滚也能看到优化轨迹。不要小看这个习惯。我有一次删了一条看起来没用的约束两周后才发现某个边缘场景出问题了靠 Git 历史五分钟就定位到了原因。5.4 常见问题速查表现象可能原因排查方向输出格式不稳定输出契约被删或模糊检查格式说明是否完整、是否有示例模型答非所问任务边界不清补充职责范围和转交规则简单任务也啰嗦缺少简洁性约束或与详细性冲突检查是否有冲突指令加优先级规则复杂任务推理不足推理引导被过度精简恢复关键推理步骤说明或加示例token 消耗没降删的是默认行为核心冗余还在重点查示例和重复约束响应变慢提示词结构混乱导致模型处理成本高按认知顺序重排结构6. Agent 场景下的特殊考量6.1 Agent 提示词和对话提示词的区别Agent 的系统提示词和普通对话提示词有本质区别。对话提示词主要管“这一轮怎么答”Agent 提示词还要管“多轮之间怎么保持状态”“什么时候调用工具”“工具返回结果怎么处理”“任务没完成怎么继续”。这些是 Agent 特有的不能简单套用对话提示词的精简逻辑。我的经验是Agent 提示词里最不能删的是工具调用规则和终止条件。工具调用规则决定它什么时候该用工具、什么时候不该用终止条件决定它什么时候停下来。这两块删了Agent 要么疯狂调用工具要么永远不结束。6.2 工具描述的精简策略Agent 的工具描述往往比系统提示词还长。每个工具的名称、用途、参数、返回值都要写清楚。这块的精简空间在于合并相似工具和用参数约束代替文字说明。比如你有三个工具分别用于查询用户、查询订单、查询商品如果它们的调用方式类似可以考虑合并成一个带类型参数的查询工具。这样工具描述从三份变成一份模型的选择负担也降低了。参数约束方面能用枚举值限制的就不要用文字描述能用必填/选填区分的就不要在描述里反复强调。6.3 多轮上下文的管理Agent 跑多轮之后上下文会越来越长。这时候提示词的精简不只是省 token还关系到模型能不能在长上下文里保持注意力。我的做法是系统提示词尽量精简把详细规则放到需要时才加载的知识库里历史对话做定期摘要压缩只保留关键决策和状态工具返回结果做截断和结构化不要把原始数据全塞进去。这套组合下来一个跑几十轮的 Agent 上下文能控制在合理范围内响应速度和稳定性都明显好于不做管理的版本。7. 我个人的几条实操心得关于“删”这件事我踩过的坑比成功的经验多。最开始我走极端觉得越短越好把提示词砍到只剩几行结果模型在边界情况上频繁出错。后来才明白删的目的是消除干扰不是追求最短。一份好的提示词应该像一份好的 API 文档没有废话但该有的信息一个不少。另一个体会是删的动作要配合评测。凭感觉删很容易删错尤其是那些看起来“理所当然”的约束往往在特定场景下有关键作用。我现在每次删改都会跑一遍评测集哪怕只是删一句话。这个习惯让我的提示词质量稳定上升而不是反复横跳。还有一点提示词精简不是一次性的工作。模型在更新业务在变化今天合适的提示词下个月可能就冗余了。我现在的做法是每个季度做一次全面审查平时遇到问题做局部调整。审查的时候重点看三件事有没有新的默认行为可以删、有没有新的冲突产生、示例是不是还覆盖当前的边界情况。最后分享一个判断标准如果你删掉某句话之后模型在评测集上的表现没有下降那这句话大概率就是冗余的。如果下降了说明它承载了某些模型无法从其他信息推断出来的东西那就留着。这个标准简单粗暴但实测很有效。