1. 当模型能力溢出时为什么堆砌式提示词反而成了累赘过去两年里我经手过不下三十个基于大语言模型的应用项目从客服对话机器人到代码审查助手从合同条款抽取到多轮任务规划。有一个现象反复出现而且越来越明显模型每升级一次原先那套精心设计的复杂提示词和技能编排就会有一部分变成负资产。这个感受在最近半年尤其强烈。早期做对话系统的时候大家习惯把提示词写成一份“操作手册”——角色设定、输出格式约束、边界条件、示例对话、异常处理分支恨不得把能想到的情况全部塞进去。那时候模型的理解力和指令遵循能力确实有限你不写清楚它就真的会跑偏。但现在的模型不一样了你写一句“用简洁的中文回答不要编造事实”它就能稳定执行你给一个输出结构的示例它就能举一反三。这时候如果还保留着三页纸的角色设定和二十条格式规则结果往往是模型被过多的约束绑住了手脚回答变得僵硬、冗长甚至因为规则之间互相冲突而出现莫名其妙的输出。所谓“做减法”不是让你把提示词砍到只剩一句话而是要有意识地识别哪些内容是模型已经内化的能力哪些是真正需要你额外指定的业务逻辑。前者应该果断删掉后者才值得保留和强化。同样Skill技能模块的编排也需要重新审视——以前可能需要拆成五步的链式调用现在模型一次就能完成那中间那些胶水层和格式转换就可以拿掉了。这篇文章适合两类人看一类是正在维护线上提示词系统的开发者发现模型升级后效果反而波动了另一类是刚开始接触大模型应用的新手想少走一些“把提示词写成论文”的弯路。我会从实际案例出发拆解哪些东西该减、为什么该减、减完之后怎么验证效果以及在做减法过程中容易踩的坑。2. 识别提示词中的“冗余脂肪”与“核心肌肉”2.1 三类典型的冗余内容及其识别方法做减法的第一步是分类。我把提示词里的内容大致分成三类模型已内化的通用能力、业务专属的硬约束、以及为了弥补旧模型缺陷而加的补丁。第一类和第三类都是减法的重点目标。先说第一类。典型的例子包括“你是一个专业的助手”“请用礼貌的语气回答”“不要输出有害内容”“保持回答准确”。这些指令在早期模型上确实能起到一定作用但现在的模型经过对齐训练后这些行为已经是默认配置了。你反复强调反而会占用注意力资源让模型在真正重要的业务规则上分配不足。我做过一个对比测试同一个客服场景A版本提示词有八百字包含大量通用行为规范B版本只有两百字只保留业务相关的退换货政策和语气要求。结果B版本的回答质量在人工评估中反而略高而且平均响应长度缩短了百分之三十。第二类是业务硬约束比如“退款金额超过五百元必须转人工”“只能使用我们产品文档里的信息回答”“输出必须符合给定的JSON Schema”。这些是模型无法自己知道的必须保留而且应该放在提示词的显眼位置。第三类最隐蔽也最值得警惕。它们往往以“为了防止模型犯错”的名义存在比如“如果用户问的是A你就回答B如果问的是C你就回答D”这种穷举式的分支逻辑。在旧模型上这种写法确实能提高准确率因为模型自己不会推理。但新模型具备了一定的意图理解和推理能力你给它两三个示例它就能归纳出规则。继续保留穷举分支不仅让提示词变得难以维护还会导致模型在面对未列举的情况时表现僵硬。识别方法很简单把提示词里的每一条规则拿出来问自己“如果删掉这条模型在典型输入上会犯错吗”如果答案是否定的或者只是“可能会稍微不一样但不影响任务完成”那就可以考虑删掉。更严谨的做法是做A/B测试用一批真实用户输入分别跑删减前后的版本对比任务完成率和输出质量。2.2 用“最小可行提示词”思路重建基线识别出冗余之后下一步是重建一个最小可行提示词作为基线。我的做法是只保留任务定义、输出格式如果下游系统需要解析、以及无法从训练数据中获得的业务规则。其他全部删掉然后在这个基线上逐步添加每次只加一条观察效果变化。举个例子。假设你在做一个会议纪要生成功能。旧版提示词可能是这样的你是一个专业的会议纪要助手请仔细阅读以下对话记录提取关键讨论点、决策事项和待办任务按照以下格式输出……注意不要遗漏任何重要信息不要编造内容保持客观中立如果信息不完整请标注……最小可行版本可以简化为从以下对话中提取决策事项和待办任务用JSON输出字段包括decision和action。其他全部交给模型。实测下来新模型在大多数情况下都能很好地完成任务而且因为约束少了它对对话中隐含信息的捕捉反而更准确。当然最小可行提示词不是终点而是起点。你需要根据实际bad case逐步添加约束。关键是每次添加都要有明确的理由和验证数据而不是凭感觉“多写点总没坏处”。这个思路和软件工程里的YAGNI原则You Aren‘t Gonna Need It是一样的——不要预先添加你猜测可能需要的东西。2.3 减法不是一刀切哪些内容必须保留甚至加强需要强调的是做减法不等于所有东西都砍。有几类内容在新模型上反而应该加强。第一是输出格式的精确约束。如果你的下游系统需要解析模型输出那JSON Schema、字段类型、必填项这些必须写清楚。新模型虽然聪明但它不会读心术不知道你的解析器期待什么格式。我见过太多因为格式约束不明确导致线上解析失败的案例。第二是业务规则的优先级和冲突处理。比如“当用户要求退款且金额超过五百元时优先转人工而不是直接回答”。这种规则模型自己推不出来必须明确写。第三是安全边界和合规要求。虽然模型本身有安全对齐但每个业务场景的具体红线不同这部分需要明确传达。第四是少样本示例的质量。做减法的时候很多人会把示例也一起删掉。但高质量的示例往往比大段规则描述更有效。我的经验是保留两到三个覆盖典型场景的示例删掉那些为了穷举边界情况而加的示例。示例的作用是让模型理解任务的“风格”和“粒度”而不是覆盖所有可能性。3. Skill编排的瘦身从链式调用到单次推理3.1 旧架构下Skill拆分的逻辑与历史包袱在模型能力还不够强的时期把一个复杂任务拆成多个Skill、用链式调用串联起来是非常合理的工程选择。比如做一个“根据用户需求生成周报”的功能旧架构可能是这样的第一步用一个Skill提取用户输入中的关键信息项目名称、时间范围、主要进展第二步用另一个Skill查询数据库获取相关数据第三步再用一个Skill把信息组织成周报格式第四步用一个Skill做语言润色。每个Skill有独立的提示词中间结果通过代码做格式转换和传递。这套架构的好处是每一步可控、可调试、可替换。但代价也很明显延迟高、成本高、错误会累积。第一步提取错了后面全错。而且中间格式转换的代码往往很脆弱模型输出稍微变个格式就解析失败。现在的情况变了。新模型在一次推理中就能完成信息提取、数据理解、格式组织和语言润色。你只需要把原始输入和必要的业务数据一起给它加上清晰的输出要求它就能直接产出可用的周报。这意味着中间那些Skill和胶水代码都可以拿掉。3.2 判断哪些Skill可以合并的四个信号不是所有Skill都能合并但有以下信号出现时就值得考虑瘦身信号一相邻Skill之间只是做格式转换没有引入新信息。比如Skill A输出一段文字Skill B把这段文字转成JSON。这种转换完全可以合并到一次推理里让模型直接输出JSON。信号二某个Skill的提示词里大量在描述“上一步的输出长什么样”。这说明这个Skill的存在只是为了适配上一个Skill的输出格式而不是因为它有独立的业务逻辑。信号三Skill的输入输出可以用一个更简单的Schema描述。如果两个Skill之间的接口很复杂往往意味着拆分过细。信号四合并后的提示词长度在模型上下文窗口的舒适区内。新模型的上下文窗口普遍很大但提示词太长仍然会影响效果和成本。如果合并后提示词超过两千字可能需要重新考虑。我自己的经验是一个任务如果需要超过三个Skill串联就应该重新审视是否有合并空间。大多数业务场景下两到三个Skill足够了一个负责理解和规划一个负责执行和生成最多再加一个负责校验。3.3 合并后的验证怎么确认瘦身没有引入回归合并Skill之后必须做回归验证。我的做法是建立一个黄金测试集从真实用户请求中挑选五十到一百条覆盖典型场景和边界情况人工标注期望的输出要点。每次修改Skill编排后跑一遍测试集对比关键要点的覆盖率和错误率。这里有个细节不要只看最终输出的整体质量要拆解到具体维度。比如周报生成任务可以拆成“信息完整性”“格式正确性”“语言流畅度”三个维度分别打分。合并Skill后可能整体质量没降但某个维度出现了波动这能帮你定位问题。另外合并后要特别关注错误传播模式的变化。以前链式调用时错误是逐步累积的合并后错误可能变成“全有或全无”——要么一次做对要么整体跑偏。所以测试集里要包含一些容易让模型困惑的输入观察它的失败模式是否可接受。4. 实测案例一次完整的提示词与Skill瘦身过程4.1 案例背景与瘦身前的系统状态去年下半年我参与优化过一个内部使用的“技术文档问答助手”。这个助手的功能是用户用自然语言提问系统从一堆技术文档中检索相关段落然后生成回答。瘦身前的架构是这样的Skill 1意图分类。判断用户问题属于“概念解释”“操作步骤”“故障排查”还是“参数查询”。Skill 2查询改写。根据意图分类结果把用户问题改写成更适合检索的形式。Skill 3答案生成。把检索到的文档段落和用户问题一起给模型生成回答。Skill 4格式校验。检查回答是否包含引用来源、是否超过字数限制、是否包含禁止出现的表述。每个Skill都有独立的提示词加起来大概一千五百字。整个流程走下来平均延迟在四秒左右而且经常出现意图分类错误导致后续全错的情况。4.2 瘦身决策删了什么、合并了什么、保留了什么我们做的第一件事是砍掉Skill 1和Skill 2。理由很简单新模型完全有能力在一次推理中同时完成意图理解和查询改写。我们把这两个Skill的提示词合并成一段简短的指令“根据用户问题从以下文档片段中找到最相关的信息并回答。如果问题涉及操作步骤请按顺序列出如果涉及概念请用通俗语言解释。”就这么一句话替代了原来四百多字的分类和改写逻辑。Skill 4的格式校验也大部分删掉了。原来有十几条格式规则我们只保留了三条硬性的必须标注引用来源、回答不超过三百字、不能出现“根据文档”这种废话开头。其他关于语气、句式、段落结构的规则全部删除。Skill 3的提示词从原来的六百字压缩到两百字左右。删掉的主要是那些“请仔细阅读”“注意不要遗漏”“保持客观”之类的通用指令以及五个少样本示例中的三个。保留的两个示例分别覆盖“操作步骤”和“概念解释”两个最典型的场景。4.3 瘦身后的效果对比与意外发现瘦身完成后我们跑了一轮对比测试。结果有些出乎意料指标瘦身前瘦身后变化平均延迟4.2秒1.8秒下降57%意图理解准确率87%94%提升7个百分点回答可用率人工评估82%89%提升7个百分点平均回答长度210字165字缩短21%引用来源标注率96%98%略升延迟下降是预期之中的但准确率和可用率同时提升说明原来的复杂编排确实在拖后腿。我分析下来主要原因是意图分类Skill的错误会传播到后续所有环节而合并后模型可以在一次推理中综合判断反而更稳。另外删掉大量格式约束后模型的回答变得更直接、更聚焦用户反馈也更好。一个意外发现是瘦身后模型在面对模糊问题时更倾向于主动询问澄清而不是强行回答。这在旧架构下很少发生因为意图分类Skill会强行给问题贴一个标签然后后续Skill就沿着这个标签走。合并后模型有了更大的灵活度反而表现出了更好的“知道自己不知道”的能力。5. 做减法时最容易踩的三个坑5.1 坑一把“减法”做成“一刀切”最常见的错误是走向另一个极端把所有约束都删掉只留一句“帮我处理这个任务”。这种做法在简单任务上可能没问题但在需要精确输出格式或严格业务规则的场景下会直接导致系统不可用。我见过一个团队听说“新模型不需要太多提示词”就把一个合同信息抽取系统的提示词从八百字砍到五十字。结果模型输出的字段名和格式完全不固定下游解析器直接崩溃。后来他们重新加回了字段定义和两个示例才恢复正常。正确的做法是有减有留减的是通用能力相关的冗余留的是业务专属的硬约束。判断标准很简单这条信息是模型能从训练数据里学到的还是只有你知道的前者可以减后者必须留。5.2 坑二忽略下游系统的格式依赖做减法的时候很多人只关注模型输出“好不好”忽略了“下游能不能用”。如果你的系统需要解析模型输出那格式约束就是硬需求不能因为“模型应该能理解”就删掉。我的建议是在删减任何格式相关的内容之前先确认下游解析器的容错能力。如果解析器很脆弱那就保留精确的Schema定义如果解析器有较强的容错能力比如能处理字段顺序变化、能忽略多余字段那可以适当放宽。另外格式约束的写法也有讲究。与其写“请用JSON输出包含name、age、city三个字段”不如直接给一个示例{name: ..., age: 0, city: ...}。示例比描述更精确也更简洁。5.3 坑三没有建立回归测试就上线这是最危险的坑。做减法本质上是在改变系统行为没有测试就上线等于在赌博。而且减法的效果往往不是线性的——删掉一条规则可能在百分之九十的情况下没影响但在那百分之十的边缘情况下就是灾难。我的做法是任何提示词或Skill编排的修改都必须通过黄金测试集验证。测试集不需要很大五十到一百条就够但必须覆盖典型场景和已知的边界情况。每次修改后跑一遍对比关键指标。如果指标下降超过可接受范围就回滚或者调整。还有一点测试集要定期更新。用户的问题分布会变化新的边缘情况会不断出现。我一般每个月会从线上日志里抽一批新的bad case补充到测试集里保持它的代表性。6. 建立持续做减法的机制而不是一次性运动做减法不是一锤子买卖。模型在持续升级业务需求也在变化今天合理的提示词明天可能就冗余了。所以更重要的是建立一套机制让减法成为日常。我的做法是每次模型版本升级后强制做一轮提示词审查。具体流程是先用现有提示词在新模型上跑一遍黄金测试集记录指标变化然后尝试删减百分之二十到三十的提示词内容再跑一遍如果指标没有明显下降就采用精简版本。这个流程听起来简单但坚持下来能省掉大量维护成本。另外我习惯在提示词文件里加注释标记每条规则的添加原因和添加时间。这样过几个月回头看就能快速判断哪些规则已经过时了。比如一条规则写着“2024年3月添加因为模型当时无法正确处理否定句”那现在就可以测试一下新模型是否还需要这条规则。Skill编排也一样。我会定期检查每个Skill的调用频率和错误率如果某个Skill的错误率很低而且功能可以被相邻Skill吸收就考虑合并。反过来如果某个Skill经常出错就要分析是提示词问题还是拆分逻辑问题。说到底做减法的底气来自于对模型能力的信任而信任来自于持续的测试和观察。不要凭感觉删也不要凭感觉留。用数据说话用测试集验证这样才能在模型变强的同时让系统变得更轻、更快、更稳。