Opus 5.5的官方提示词指南放出来那几天我扫了一圈技术群和社区讨论发现一个很有意思的现象没人晒超长提示词模板也没人纠结结构化prompt怎么写大家转得最多的一句话是——最该学的居然是删。顺着这句话我重新把官方指南读了一遍又拿手头的几个真实项目试了试发现删这个字确实戳中了这两年提示词工程的命门。过去我见过太多几千字的角色扮演任务说明输出规范示例大全式提示词也有很多朋友跑来问我为什么提示词写得越长模型越呆其实答案就藏在这次官方指南反复强调的一个词里简洁。这篇文章我会从官方指南的底层逻辑讲起拆解删为什么有效再结合Claude Code实际使用场景CLAUDE.md、MCP servers、本地模型接入这些天天有人踩坑的地方最后给出一套可参考的删减判断标准和一次完整的实操案例。不管你是刚接触提示词的新手还是已经被长提示词折磨过的老手这篇都能给你一些可以直接抄的作业。1. 为什么这份官方指南最该学的居然是删1.1 长提示词时代的集体惯性过去两三年提示词圈子里有一种很普遍的心态提示词写得越长越详细模型就越懂我。于是各种模板应运而生——几百字的角色设定、几十条输出规范、一整套few-shot示例、加上一堆请务必你要知道非常重要的强调性前缀。我也写过这种东西最夸张的时候给一个内容生成任务写了800多字的提示词恨不得把每个标点符号的用法都规定好。但用下来的真实体感是提示词越长模型越容易在某个角落跑偏。要么是我最关心的那个要求被淹没在一堆次要信息里要么是几个要求之间出现逻辑矛盾模型自己也很困惑。这就像给一个聪明但记忆力有限的实习生布置任务你把20条注意事项一口气全倒给他他大概率只记得住前三条和后两条。官方指南这次的做法恰恰相反。它通篇在用一种能做减法就绝不做加法的思路讲提示词指令要直接背景信息要少不要反复强调同一件事不要堆砌同义词。看完之后我最大的感受是官方对模型能力的态度已经变了——默认模型能理解你的核心意图你要做的是把意图表达清楚而不是通过反复轰炸来保证它理解。1.2 官方指南里那些看似简单、其实反直觉的原则我把官方指南传达出来的几个关键原则归纳了一下单看每一条都很朴素但放在当下的提示词社区环境里每一条都挺反直觉的指令要短能一句话说清楚的事情不要用三句话绕。多出来的话不是帮助是噪音。背景要给够用的别给全部的模型只需要了解与任务直接相关的背景你项目的十年发展史它用不上。重复是负资产同一个要求换了三种说法模型反而要花注意力去判断这三句话是不是同一个意思。示例优于描述与其花50个字描述你想要什么风格不如给一个具体示例既省token又更精准。尤其是重复是负资产这条真的很反直觉。很多人写提示词的时候觉得我多强调几遍它总该重视了吧实际上模型处理的是token序列你每重复一遍都是在把注意力从核心指令上分走一部分。说得极端一点你写请务必一定要非常认真的审查安全漏洞跟写重点检查安全漏洞在模型那边得到的权重差异并没有你想象中那么大但前者白白占掉了四五个词的token预算。1.3 删的本质是信任模型我觉得这次社区能对删产生这么大的共鸣背后其实是一个认知转变过去大家写长提示词本质上是防御性写作——因为不信任模型的理解能力所以什么都要多说几句怕它听不懂。但到了Opus 5.5这个量级模型本身的理解能力已经很强了你那些防御性的补充说明大部分时候都是多余的。删的背后是信任信任模型能抓住核心信任少而精确的指令比多而杂乱的指令更有效。这不是让你什么都不写而是让你把每一句话都放在删掉它会怎样的拷问下过一遍。删掉之后任务依然清晰那就删删掉之后模型可能产生歧义那才是必须留下的。2. 机制层面为什么提示词越短模型反而越听话2.1 注意力是账户里唯一的钱如果不聊机制只聊现象总觉得有点玄学。其实删之所以有效是可以从模型的工作原理上找到解释的。Transformer模型在处理你的提示词时核心机制是注意力——模型会在所有输入token之间分配注意力权重。你可以把注意力理解成账户里的一笔钱你写进去的每一个字都在花这笔钱。问题是这笔钱不是均匀花的。模型会优先把注意力分配给那些看起来更重要的信息而判断重要性的方式之一是位置和显著性。如果你在前面铺垫了一大段背景故事再插入几个强调词最后才说真正的任务模型很可能已经把钱花得差不多了。更麻烦的是那些冗余的修饰词、同义反复的句子会真实地分走一部分注意力——哪怕只有一点点累积起来也会让核心指令的信号强度下降。我在实际测试中有一个很直观的感受把一段300字的提示词删到80字之后模型对核心要求的遵循度反而是上升的。比如我让模型生成JSON输出长版本总会在某个字段上出格式问题精简版本就稳定很多。因为冗余信息少了模型的注意力能更集中地在格式约束上。2.2 上下文窗口的中部遗忘大语言模型领域有一个被反复验证的现象叫lost in the middle——模型对长上下文的开头和结尾部分记忆更牢对中间部分的内容则容易遗忘。这个现象对提示词工程的影响非常直接你的提示词越长你想强调的核心指令就越容易被推挤到上下文的中间位置变成一个模型扫过但没注意的信息。这也能解释为什么很多人写长提示词时喜欢在开头和结尾反复强调同一个要求——其实你已经无意中在对抗中部遗忘了。但靠重复来对抗遗忘是笨办法真正有效的做法是缩短总长度让核心指令始终处于上下文中更靠前或更靠后的显著位置。删减提示词的过程本质上就是把关键信息搬运到模型更容易注意到的位置。2.3 指令内部的隐性冲突提示词越长另一个风险也在悄悄增加内部逻辑冲突。人写长文本的时候很容易前后措辞不一致提示词也一样。举个我见过的真实案例有人在提示词里写请给出简洁的回答另一段又写请详细说明每个步骤还有一段写回答需要全面覆盖所有方面。这三句话单独看都合理放在一起模型就懵了——到底要简洁还是要详细它最后往往给出一个不上不下、两头都不满意的输出。删除的过程天然就是一次指令一致性检查你每删掉一句话都在迫使自己重新审视剩下的指令之间是否冲突。这也是为什么我建议所有长提示词用户都认真做一次删减练习——不是为了省token而是为了发现那些你从来没注意过的自相矛盾。2.4 Token预算只有一次花在提示词上就是花在任务上最后一点非常现实一次请求里模型能处理的上下文是有限的。提示词占用的token越多留给推理和输出的空间就越少。在Claude Code这类工具型产品里这个矛盾更突出。系统提示词、工具描述、对话历史、你的项目指令、当前代码内容……每一样都在竞争上下文窗口。如果你在提示词里塞了一大堆废话式预防针真正留给代码分析和生成的推理空间就被压缩了。实测中我能明显感觉到提示词精简之后模型给出的代码补全更长、更完整因为它有更多施展空间。3. Claude Code场景里的删从CLAUDE.md到MCP servers3.1 CLAUDE.md从项目百科全书到一行行动摘要Claude Code的CLAUDE.md是项目级指令文件每次会话都会自动加载相当于模型的长期记忆。很多人刚接触时容易犯一个错误把CLAUDE.md当成团队Wiki来写把代码规范、技术栈介绍、目录结构全塞进去动辄几十上百行。这个问题的伤害是隐性的。CLAUDE.md每次会话都占用上下文你写进去的每一个字都在燃烧token预算。更关键的是信息太多之后模型反而不清楚在这个项目里到底什么是最重要的约束。我见过一个CLAUDE.md写了几百行的项目模型每次都会把一些无关紧要的规范当重点真正关键的业务规则反而被忽略。我现在的写法是CLAUDE.md只保留这个项目特有的、模型不可能自己知道的东西。比如特定的命令别名、禁止修改的文件列表、核心架构约束。能用三句话说明白的绝不用十句。每次添加内容之前我都会问自己这段如果删掉模型在什么情况下会犯错如果想不到具体场景那就不写。3.2 MCP servers接入越多模型越选择困难Claude Code里大家最近讨论很多的是MCP servers通过npx或者本地配置接入各种工具让模型能直接调用外部能力。这确实强大但实践中我踩了一个很典型的坑MCP servers接入得越多模型反而越容易选错工具。原因不复杂。每个MCP server都有一串工具描述这些描述都会占用上下文窗口而且每次模型要决定调用哪个工具时需要在所有可用工具里做选择。你接了10个server、每个server带5个工具模型面对的就是50个工具的选择题——它经常选到那个名字相似但不是你现在想要的工具。后来我做了一轮大清洗把不常用的server全部停用只保留两三个真正在项目里高频使用的。效果立竿见影工具调用准确率高了很多。这件事本质上也是删——从上下文里删掉了大量无关的工具描述让模型的注意力能集中在真正有用的那几个工具上。3.3 跨模型切换时精简提示词的迁移优势最近不少人喜欢在Claude Code里接入本地模型或者第三方模型来试——比如通过LM Studio跑本地模型或者配置DeepSeek、Qwen、GLM这些。我试过之后最大的体会是精简过的提示词在换模型时的迁移成本极低。原因很简单不同模型的口味差异很大。有的模型对角色扮演式的长提示词反应很好有的模型则更吃简洁直接的指令。一套充斥着你是XX专家请务必你拥有XX年经验的长提示词在一个模型上跑得好换一个模型可能完全变味。反而是那种只包含核心任务、关键约束、输出格式的短提示词在不同模型之间都比较稳。如果你有跨模型测试的需求比如把同一个任务在Claude和本地模型之间对比我强烈建议你把提示词删到骨架状态再拿去迁移。删得越干净你在新模型上要做的适配调整就越少。3.4 一次真实的CLAUDE.md删减从70行到7行我自己的一个项目里有件事印象很深。那是一个中型的Web服务仓库起初我给CLAUDE.md写了一大堆内容包括完整的目录结构、所有技术栈信息、十几种编码规范、测试要求整整70行。用起来总觉得Claude Code很笨——它总是婆婆妈妈地复述规范或者在一个我不希望它动的目录里瞎改文件。后来我痛下决心把70行删到7行。只保留了核心命令、禁止修改的目录、一条架构红线、数据模型修改时必须同步更新迁移文件。删完再跑同样的任务它的行为明显变了——不再反复念叨那些规范直接干正事。出错率反而下降了。那次之后我意识到一个道理Claude Code不是你的下属不需要你事无巨细地交代它更像一个能力很强的同事你只需要把这件事里跟其他项目不一样的约束告诉它剩下的它自己能搞定。4. 提示词里的三删三不删我的取舍清单4.1 这三类内容删掉基本都是加分先说我经验里最该删的三类内容你对照一下自己的提示词大概率能找出不少。第一类是纯强调词。请务必非常重要一定要仔细这类修饰性前缀模型并不会因为它们而提高对任务的重视程度。它们占据的是token空间但几乎不提供信息量。删掉它们核心指令一点都不会变模糊。第二类是重复指令。同一个要求换着说法写了好几遍比如注意安全性要小心安全问题不要忽略安全隐患——这三句话在模型眼里可能是同一个意思也可能是三个矛盾的意思。保留其中最具体的那一句其他删掉。第三类是无关背景信息。模型完成任务所需要的背景比你想的要少得多。你给一个代码审查任务写上一大段这个项目是公司的核心系统用户量很大出了事故会很严重对审查结果几乎没有任何正面影响。项目背景除非会直接影响任务的执行方式否则都属于噪音。4.2 这三类内容删了你就等着哭吧与上面对应我有三类内容是从不删的也建议你保留。第一类是核心任务描述。就是你到底要让模型干什么审查以下代码生成一组单元测试把下面这段文本改写为技术博客。这句话是整个提示词的地基任何情况下都不能含糊。第二类是输出格式约束。要不要JSON、字段名是什么、按什么顺序排列、长度限制是多少——这些直接影响你能不能拿到能直接用的结果。格式约束删掉之后模型往往会以字面意思完成任务但给出一个你需要二次处理的输出格式反而更费劲。第三类是硬性边界。比如不要修改代码只输出审查意见禁止使用第三方库如果信息不足直接说不知道不要编造。这类内容是模型犯错的拦网删掉之后它可能不知不觉就越界了。4.3 一张随时对照的取舍表格我把该删和不该删的内容放在一起对比方便你下次写提示词时快速判断该删不该删判断标准请务必非常重要等空洞强调词明确的任务动词审查、生成、改写删掉后任务会不会变模糊同一要求的多种说法唯一确定的输出格式/结构删掉后输出还能不能直接用与任务无关的背景故事直接影响执行方式的硬性约束漏掉它会不会导致模型越界堆砌的同义形容词一条清晰的示例删掉后模型还有没有参照物过度的角色设定安全红线禁止做的事删掉后会不会引入风险4.4 判断删不删的两把尺子如果你不想背清单也可以用两把通用尺子来卡每句话。第一把尺子删掉这句话之后模型还会不会理解任务如果答案是不会留着如果还是会删。第二把尺子删掉之后模型的输出质量会不会下降如果不会删如果会留着。我自己的操作习惯是先写全、再删半、最后再删半。第一版提示词怎么想就怎么写不做任何约束先把思路理顺第二版开始删掉所有修饰词和重复句把每个要求压成一句话第三版再审视一次看看哪些背景信息其实是自己写high了塞进去的继续删。三轮下来一个800字的初稿通常能压到150字以内而且效果明显更好。5. 一次完整的删减示范从105行到19行5.1 原始版本一份典型的防御性写作产物空谈判断标准不够直观我拿一个真实的代码审查任务来做一次完整删减。以下是我仿照网上很常见的长提示词风格写出来的原始版本105行收集了几乎所有常见的冗余写法你是一位拥有二十年经验的资深软件架构师同时也是一位精通代码审查的专家 曾经主导过多个大型项目的代码评审工作在业界享有盛誉。 我接下来会给你一段代码请你务必仔细、认真、全面地审查这段代码。 注意这不是一段普通的代码它来自我们的核心支付系统这段代码一旦出现问题 可能会导致严重的资金损失所以请你务必高度重视认真对待每一个细节。 首先请你重点关注代码中可能存在的安全问题包括但不限于SQL注入、 XSS攻击、CSRF攻击、敏感信息泄露、权限绕过、不安全的反序列化等等 总之任何可能的安全漏洞都不能放过安全问题是最重要的。 除了安全问题之外请你也要关注代码的性能问题 比如是否有不必要的循环、是否有效率低下的数据库查询、 是否有可以优化的算法等等性能问题同样重要因为它会影响用户体验。 另外代码的可读性也很重要比如变量命名是否清晰、 函数是否过长、是否有重复代码、注释是否充分等等 这些虽然不影响功能但会影响团队的长期维护效率。 最后还要检查代码中是否存在隐藏的bug 比如边界条件处理不当、空指针异常、并发问题、资源泄漏等等 这些都是运行时最容易出问题的地方。 请在审查时按照以下几个维度逐一检查安全、性能、可读性、bug隐患、架构合理性。 每个维度都不能遗漏。 在输出时请按照严重程度从高到低排列所有发现的问题 每个问题需要说明 1. 问题出现的具体位置文件、行号 2. 问题的具体描述 3. 问题的严重程度严重/中等/轻微 4. 可能的修复建议 请注意输出格式一定要规范每个问题之间要有清晰的分隔 不要混在一起不然我看起来会很吃力。 请确保你的审查是全面的、深入的、细致的不要有任何遗漏。 我信任你的判断力你一定能给出高质量的审查结果。读一遍你会发现角色设定、强调词、背景警告、重复列举、格式要求、信任表达——几乎每个该踩的雷都踩了。5.2 三步删减法的完整过程第一步先删所有无效修饰。主要是拥有二十年经验的资深务必重要细致的深入的这类词。删完之后文字会变得很干但信息量一点没少。第二步合并重复指令。原始版本里安全这个主题出现了至少三处性能也出现了两次可读性的概念被反复提及。我把这些散落的点合并成一组清单式的关注项。第三步压缩输出格式描述。原始版本用了5段来说明输出格式其实一句话就能说清一条问题占一条包含四个字段。这里的关键是给字段例子而不是描述字段长什么样让模型直接模仿结构。5.3 最终版本19行信息密度反而更高删完之后的版本长这样审查以下代码。按严重程度从高到低列出发现的问题。 每列出一个问题需要包含 1. 位置文件路径和行号 2. 问题具体描述 3. 级别严重 / 中等 / 轻微 4. 建议修复方案用一句话说明 检查重点 - 安全注入、越权、敏感信息泄露 - 性能明显低效的循环或查询 - 隐患边界条件、空指针、并发、资源泄漏 - 可读性命名混乱或过长函数 注意 - 不要修改代码只输出审查结果 - 某方面确实没有问题就跳过不要强行列问题19行对比105行删掉了82%的内容。但对比一下两条版本的关注点原始版本里的安全、性能、可读性、bug、输出格式全都在最终版里保留着删掉的只是那些看起来在强调、实际上没信息量的部分。5.4 删完之后我实测到的三个变化用精简版本跑同一段代码我观察到的变化有三个。第一是输出结构更稳定了每条问题都规规矩矩按照四个字段来不会再出现原始版本偶尔忘了写行号的情况。第二是问题质量更聚焦模型不会再因为背景警告里那句核心支付系统而过度紧张把无关紧要的小毛病都拉高到严重级别。第三是token开销明显下降一次审查请求省出来的token可以覆盖更多的代码内容等于变相拉长了单次能审查的代码量。我后来把同样的思路用在很多场景上生成单元测试、写提交信息、分析报错日志都可以先写一版长的再删到骨架状态。每次删完输出基本都会变好一点点——不夸张这已经成了我固定的工作流。5.5 最后一个小提醒删减之后的维护习惯还有一点想提醒你。提示词删完不是一劳永逸的模型升级之后可能对某些指令的理解方式会变。我习惯在每次版本升级之后把之前跑得很顺的短提示词重新用一个测试样本跑一遍确认输出质量没有退化。如果发现某个之前删掉的内容现在又开始影响输出质量了那就把它加回来然后继续做删减测试。好提示词不是写出来的是删出来的——这句话我越用越觉得是真的。