大模型时代提示工程减法思维：精简提示词与技能编排实战

1. 模型能力跃迁后的提示工程思路转变

1.1 从“堆料”到“精简”的认知拐点

过去两年里，我经手过不少基于大语言模型的应用项目，从早期的简单问答机器人到后来的复杂多步推理系统，有一个感受越来越强烈：模型本身的能力在快速提升，但很多人的提示词和技能编排方式还停留在“模型很笨”的假设上。这个错位带来的直接后果就是——系统越来越臃肿，维护成本越来越高，效果却没有同步变好。

我最早做提示工程的时候，习惯把能想到的约束、示例、格式要求全部塞进系统提示里。一个典型的系统提示动辄两三千字，里面包含了角色设定、输出格式、边界条件、异常处理、语气要求、示例对话等等。当时这么做是有道理的，因为早期模型确实容易跑偏，你不把话说死，它就给你自由发挥。但最近半年，我明显感觉到一个变化：当我把同样复杂的任务交给新一代模型时，那些曾经必不可少的“拐杖”反而成了累赘。

这个现象背后的逻辑其实不复杂。模型能力弱的时候，它像一个刚入职的实习生，你需要把每一步都写清楚，甚至要给它模板让它照着填。但当模型能力强到一定程度，它更像一个经验丰富的专业人士，你只需要告诉它目标和关键约束，它自己会选择合适的路径。这时候如果你还拿对待实习生的方式对待专业人士，不仅浪费了它的能力，还会因为过多的指令让它无所适从。

我印象很深的一次经历是做一个合同条款提取的项目。早期版本我写了将近一千字的提示词，详细规定了提取的字段、格式、异常情况的处理方式，还给了三个示例。后来模型升级后我重新测试，发现把提示词精简到两百字左右，只保留核心字段定义和输出格式要求，准确率反而从百分之八十七提升到了百分之九十四。多出来的那些约束和示例，实际上在干扰模型对核心任务的理解。

1.2 什么情况下该做减法

不是所有场景都适合做减法，这一点必须先说清楚。我总结下来，判断是否该精简提示词和技能编排，主要看三个信号。

第一个信号是模型升级后效果没有同步提升。如果你换了更强的模型，但任务表现和之前差不多，甚至在某些case上还变差了，那大概率是你的提示词太复杂，把模型的能力限制住了。模型在试图同时满足你所有的约束条件，反而忽略了任务的核心目标。

第二个信号是维护成本开始超过收益。当你发现每次调整需求都要花大量时间修改提示词，而且改了一处经常影响另一处，说明你的提示词已经过度耦合了。好的提示词应该是模块化的、职责清晰的，而不是一团互相纠缠的指令。

第三个信号是示例数量超过三个。少量高质量的示例确实能帮助模型理解任务，但如果你需要靠大量示例来“教”模型做事，说明要么任务定义本身不够清晰，要么模型能力不足以胜任这个任务。在后一种情况下，加示例不如换模型或者拆任务。

注意：做减法不等于什么都不写。核心的任务定义、输出格式、关键约束仍然需要明确。减掉的是那些模型已经能自己推断出来的冗余指令，以及为了弥补模型能力不足而添加的过度约束。

1.3 减法思维在技能编排上的体现

提示词的减法相对直观，技能编排的减法更隐蔽但也更重要。所谓技能编排，指的是你把一个复杂任务拆成多个步骤，每个步骤调用不同的提示词或工具，最后组合成完整的工作流。早期做这种编排时，我倾向于把步骤拆得很细，每个步骤都写详细的提示词，生怕模型在某个环节出错。

但模型能力提升后，这种细粒度拆分的必要性在下降。举个例子，我之前做一个数据分析报告生成的项目，流程拆成了数据清洗、指标计算、趋势分析、报告撰写四个步骤，每个步骤都有独立的提示词和输出格式要求。后来我发现，新一代模型完全可以在一个提示里完成从原始数据到分析报告的全过程，而且因为减少了中间环节的信息损失，最终报告的质量反而更好。

当然，这不是说所有多步编排都应该合并成一步。判断标准在于：中间步骤的输出是否真的需要被独立消费。如果中间结果只是过渡，最终用户只关心最终输出，那就可以考虑合并。如果中间结果需要被其他系统使用，或者需要人工审核，那保留拆分是有意义的。

2. 提示词精简的具体操作方法与实测对比

2.1 精简前的诊断：找出冗余指令

动手删之前，先得知道哪些该删。我通常用一个简单的方法做诊断：把提示词里的每一句话拿出来，问自己“如果删掉这句，模型还能不能正确完成任务”。如果答案是“能”，那这句话就是候选删除项。

按照这个标准过一遍，通常能发现几类典型的冗余指令。第一类是常识性约束，比如“请确保输出是合法的JSON格式”“请不要编造不存在的信息”。新一代模型对这类基本要求已经有很好的遵循能力，不需要反复强调。第二类是重复性强调，比如在系统提示里说了“输出用中文”，在用户提示里又说一遍“请用中文回答”。第三类是过度具体的示例，比如为了说明输出格式，给了一个包含具体业务数据的完整示例，模型很容易把示例里的具体内容当成任务的一部分。

我做过一个对比测试，用一个信息抽取任务来验证精简的效果。原始提示词有八百多字，包含角色设定、任务描述、字段定义、格式要求、三个完整示例、五条注意事项。精简后的提示词只有两百多字，保留了任务描述、字段定义和格式要求，删掉了角色设定、示例和注意事项。

这个结果让我更加确信，在模型能力足够的前提下，提示词的复杂度与任务效果之间并不是正相关，而是存在一个最优区间。超过这个区间后，每增加一条指令，带来的边际收益递减，甚至为负。

2.2 精简的核心原则：目标导向而非过程导向

精简提示词的核心思路，我总结为一句话：告诉模型要什么，而不是告诉它怎么做。早期提示词之所以冗长，是因为我们不相信模型能自己找到“怎么做”的路径，所以把过程也写进去了。但模型能力提升后，它完全有能力自己规划执行路径，你只需要把目标和约束说清楚。

举个具体的例子。假设你要做一个会议纪要生成的任务。过程导向的提示词会这样写：“请先提取会议中的每个议题，然后针对每个议题总结讨论要点，接着识别达成的决议，最后列出待办事项。每个议题的总结不超过三句话，待办事项需要包含负责人和截止时间。”而目标导向的提示词只需要写：“请从以下会议记录中生成一份结构化的会议纪要，包含议题、讨论要点、决议和待办事项。”

两种写法我都实测过。在早期模型上，过程导向的写法确实效果更好，因为模型需要手把手的引导。但在新一代模型上，目标导向的写法不仅效果不差，而且生成的纪要结构更灵活，能根据会议内容的实际情况调整详略，而不是机械地按照固定模板填充。

实操心得：精简提示词时，可以先写一版“理想情况下我希望模型输出什么”，然后只保留对这个输出的描述和必要的格式约束。任何关于“先做什么再做什么”的指令，都先删掉测试一下，如果效果没有明显下降，就说明模型已经能自己处理了。

2.3 保留什么：不可省略的三类要素

做减法不是把提示词删到只剩一句话。根据我的经验，有三类要素是必须保留的。

第一类是任务边界。模型需要知道什么该做、什么不该做。比如“只基于提供的文档内容回答，不要引入外部知识”这种约束，在需要严格依据给定材料的场景下仍然必要。但要注意表述方式，与其写“不要编造”，不如写“如果文档中没有相关信息，请明确说明”。

第二类是输出格式。如果下游系统需要解析模型的输出，格式约束就不能省。但格式定义可以更简洁，用JSON Schema或者简单的字段列表代替大段的文字描述。我现在的习惯是直接给一个空的JSON结构，让模型填充，比用文字描述格式要准确得多。

第三类是关键示例。示例不在多，在于精准。一个好的示例应该覆盖任务中最容易出错的环节，而不是展示一个完美的标准答案。我通常只保留一个示例，而且这个示例会故意包含一个边界情况的处理，让模型理解在复杂情况下该怎么应对。

2.4 精简后的效果验证方法

删完之后怎么知道有没有删过头？我通常用三个维度来验证。

第一个维度是核心指标的对比。在精简前后跑同一批测试用例，对比准确率、召回率、格式合规率等关键指标。如果核心指标没有显著下降（通常允许百分之三以内的波动），说明精简是安全的。

第二个维度是边界情况的测试。专门构造一些输入不完整、格式不规范、内容有歧义的测试用例，看模型在精简后的提示词下是否还能正确处理。这一步很关键，因为精简提示词最容易暴露的问题就是边界情况处理能力下降。

第三个维度是输出多样性的观察。精简提示词后，模型的输出可能会变得更灵活。这时候需要判断这种灵活性是好事还是坏事。如果任务需要标准化输出，灵活性就是风险；如果任务需要创造性，灵活性就是优势。我一般会人工审阅二十到三十条输出，感受一下整体风格是否符合预期。

3. 技能编排的简化策略与实操案例

3.1 识别可以合并的步骤

技能编排的简化，第一步是找出哪些步骤可以合并。我通常从两个角度来判断。

第一个角度是信息依赖度。如果步骤B完全依赖步骤A的输出，而且步骤A的输出除了给步骤B用之外没有其他用途，那这两个步骤就可以考虑合并。比如“提取关键词”和“基于关键词生成摘要”这两个步骤，如果关键词不需要单独展示给用户，那完全可以合并成一个“生成摘要”的步骤，让模型自己决定关注哪些关键词。

第二个角度是错误传播风险。多步编排的一个固有问题是错误会逐步累积。步骤A的小误差传到步骤B可能被放大，到步骤C就可能完全跑偏。如果两个步骤之间的接口很窄（比如只是传递一个分类标签），合并的风险其实很低。但如果接口很宽（比如传递一大段自由文本），合并反而可能减少信息损失。

我做过一个多轮对话意图识别的项目，最初拆成了“意图分类”和“槽位填充”两个步骤。后来发现，意图分类的错误有相当一部分是因为分类时没有考虑槽位信息，而槽位填充又依赖意图分类的结果，形成了一个死循环。合并成一个步骤后，模型可以同时考虑意图和槽位，整体准确率提升了将近十个百分点。

3.2 用模型能力替代硬编码逻辑

技能编排中另一个常见的冗余是用代码做模型能做的事。早期因为模型能力不足，很多逻辑需要用规则或代码来实现，比如日期格式的标准化、金额的提取和计算、简单的是非判断等等。但现在这些任务模型已经能做得很好，继续用代码处理反而增加了系统的复杂度和维护成本。

我遇到过一个典型案例。一个财务报销审核的辅助系统，最初的流程是：先用正则表达式提取发票号码和金额，然后用规则判断金额是否超过阈值，最后用模型生成审核意见。后来我把提取和判断都交给了模型，只在最后加了一个简单的校验步骤。结果是不仅代码量减少了百分之六十，而且因为模型能理解上下文，对一些格式不规范的发票处理得比正则表达式更好。

当然，这不是说所有逻辑都应该交给模型。涉及精确计算、合规校验、数据一致性检查的场景，仍然应该用确定性代码来处理。模型适合处理的是那些需要理解语义、容忍模糊性、依赖上下文的任务。

3.3 一个完整的简化案例：从五步到两步

我拿一个实际做过的项目来完整说明简化的过程。这个项目是自动生成产品周报，输入是各个团队提交的零散工作记录，输出是一份结构化的周报。

最初的五步编排是这样的：第一步，对每条工作记录进行分类（开发、测试、设计、运营等）；第二步，对每类记录进行摘要提取；第三步，按照周报模板组织内容；第四步，生成过渡语句和总结；第五步，格式检查和修正。

这个流程跑起来能用，但问题很多。分类步骤经常把跨类的工作记录分错，摘要提取有时会丢失关键信息，过渡语句生成得很生硬。而且整个流程跑一遍要调用五次模型，延迟很高。

后来我做了简化，合并成了两步：第一步，模型直接阅读所有工作记录，生成周报的各个板块内容；第二步，模型对生成的周报进行润色和格式调整。提示词也从原来的五个独立提示词变成了两个，总长度减少了约百分之七十。

这个案例让我意识到，很多多步编排其实是在用流程的复杂度来弥补模型能力的不足。当模型能力提升后，这些流程不仅没有必要，反而成了限制模型发挥的枷锁。

3.4 简化后的监控与回退机制

做减法之后，系统的可观测性会下降，因为中间步骤少了，出问题时定位更困难。所以简化必须配合监控和回退机制。

我的做法是在关键节点埋点，记录模型的输入输出。对于合并后的步骤，如果最终输出质量不达标，可以临时回退到拆分版本进行对比排查。同时，我会保留一个“最小可用提示词”的备份，当精简版出现问题时，可以快速切换回去。

另外，简化后的系统对模型版本的依赖更强。模型升级或降级都可能影响效果，所以需要在模型变更时重新跑一遍回归测试。我一般会准备一个包含五十到一百条测试用例的回归集，覆盖正常情况和边界情况，每次模型变更后自动跑一遍，对比关键指标的变化。

4. 常见问题与排查技巧实录

4.1 精简后效果反而变差的排查思路

精简提示词后效果变差，是最常见的问题。遇到这种情况，我通常按照以下顺序排查。

首先检查任务定义是否足够清晰。精简过程中最容易犯的错误是把任务描述也删得太狠，导致模型不知道到底要做什么。这时候需要补充的不是过程指令，而是更清晰的目标描述。比如“生成一份报告”太模糊，“生成一份包含销售数据、趋势分析和建议的报告”就更明确。

其次检查输出格式是否明确。如果下游系统需要解析输出，格式约束不能省。我遇到过好几次因为删掉了格式说明，导致模型输出了一段自然语言而不是结构化数据的情况。格式约束可以用简洁的方式表达，但不能没有。

然后检查是否删掉了必要的边界约束。有些约束看起来是常识，但在特定场景下仍然必要。比如在一个法律文档问答系统中，“只基于提供的文档回答”这个约束就不能删，因为模型默认会使用自己的知识。

最后检查模型是否真的有能力处理精简后的任务。有时候问题不在提示词，而在于任务本身超出了当前模型的能力范围。这时候需要做的是拆解任务或者换模型，而不是把提示词再加回去。

4.2 技能合并后的错误定位方法

技能合并后，错误定位变得更困难，因为中间步骤的黑盒变大了。我的应对方法是在合并后的提示词中要求模型输出中间结果。

比如把“分类+摘要”合并后，可以在输出格式中要求模型先输出分类结果，再输出摘要。这样既保留了合并带来的效率优势，又保留了排查问题的线索。如果最终结果有问题，可以看是分类错了还是摘要错了，定位问题的效率不比拆分版本差。

另一个方法是用少量样本做对比测试。当合并版本出现问题时，拿同样的输入跑一遍拆分版本，对比两个版本的中间输出和最终输出。如果拆分版本在某个中间步骤就错了，说明问题出在那个步骤对应的能力上；如果拆分版本正确但合并版本错误，说明是合并带来的信息损失或指令冲突。

4.3 模型升级后的回归测试要点

每次模型升级后，我都会跑一轮回归测试。测试的重点不是看效果有没有提升，而是看精简后的提示词和编排是否仍然适用。

具体来说，我会关注三个变化。第一是输出风格的变化。新模型可能会改变输出的语气、详略程度、格式习惯，这些变化可能影响下游系统的解析。第二是边界情况处理的变化。新模型可能对某些边界情况的处理方式不同，需要确认是否符合预期。第三是指令遵循度的变化。新模型可能对某些指令的理解更准确，也可能对某些指令更不敏感，需要重新校准。

我一般会维护一个测试用例库，包含正常案例、边界案例和对抗案例。每次模型变更后跑一遍，记录关键指标的变化。如果某个指标下降超过百分之五，就需要人工介入分析原因。

4.4 常见问题速查表

避坑技巧：精简提示词时，建议保留一个“完整版”的备份。当精简版在某个场景下效果不好时，可以快速对比完整版的表现，判断是精简导致的问题还是模型本身的能力边界。这个对比过程能帮你更准确地找到精简的合理边界。

4.5 我踩过的几个坑

第一个坑是一次性删太多。最开始做减法时，我兴奋地把一个提示词从一千字删到一百字，结果模型完全跑偏。后来我学乖了，每次只删一类指令，测试后再删下一类。这样虽然慢一点，但能准确知道哪类指令是必要的，哪类是可以删的。

第二个坑是忽略了输出格式的下游依赖。有一次我删掉了输出格式中的字段顺序要求，觉得模型自己会合理安排。结果下游的解析代码是按固定顺序写的，导致解析失败。这件事让我意识到，精简不能只看模型效果，还要考虑整个系统的依赖关系。

第三个坑是在错误的模型上做精简。有一次我在一个中等能力的模型上精简提示词，效果一直不好，我以为是精简方法有问题。后来换到最强模型上测试，同样的精简提示词效果很好。这说明精简的前提是模型能力足够，在能力不足的模型上做精简是徒劳的。

第四个坑是没有建立回归测试机制。早期我精简完提示词后，只手动测了几个case就上线了。结果在一些不常见的输入上出了问题，被用户反馈才发现。后来我建立了一个包含各种类型输入的测试集，每次修改提示词后都跑一遍，才避免了类似问题。

5. 减法思维的边界与适用条件

5.1 什么情况下不应该做减法

减法思维虽然好用，但不是万能的。有几种情况我建议不要轻易做减法。

第一种是任务本身需要严格的流程控制。比如涉及多级审批、合规检查、数据校验的场景，流程的每一步都有存在的必要性，不能因为模型能力强就随意合并。这类场景的复杂度是业务本身带来的，不是模型能力不足造成的。

第二种是模型能力还不够强的场景。如果你用的模型在基础任务上还经常出错，那提示词和编排的复杂度就是必要的补偿。这时候应该先考虑换模型，而不是强行做减法。

第三种是团队协作需要明确分工的场景。多步编排有时候是为了让不同的人负责不同的步骤，比如产品经理写分类提示词，算法工程师写摘要提示词。这种情况下，拆分是为了协作效率，合并反而会增加沟通成本。

第四种是需要精细监控和调试的场景。在系统上线初期或者问题排查阶段，保留更多的中间步骤有助于定位问题。等系统稳定后再考虑合并也不迟。

5.2 减法与可维护性的平衡

做减法的初衷之一是提升可维护性，但减法本身也需要维护。我的经验是，精简后的提示词和编排需要更完善的文档和测试来支撑。

因为精简后的系统更依赖模型的“默会知识”，这些知识不在代码里，也不在提示词里，而是在模型的训练数据里。新加入团队的成员可能不理解为什么某个约束被删掉了，容易在修改时又把冗余加回去。所以需要把精简的决策过程记录下来，说明每条被删掉的指令是因为什么原因删的，在什么条件下可能需要加回来。

另外，精简后的系统对输入的变化更敏感。因为模型需要自己处理更多的边缘情况，如果输入分布发生变化，效果波动可能比复杂系统更大。所以需要更频繁地监控线上效果，及时发现和应对变化。

5.3 建立持续精简的机制

减法不是一次性的工作，而应该是一个持续的过程。我的做法是每次模型升级后都做一轮精简评估，看看有没有新的冗余可以删掉。

具体来说，我会定期回顾现有的提示词和编排，问三个问题：第一，有没有哪条指令是上个模型版本需要但现在不需要的？第二，有没有哪个步骤是之前因为模型能力不足而拆分但现在可以合并的？第三，有没有哪个示例是之前为了教模型但现在模型已经掌握的？

这个回顾不需要很频繁，我一般每个季度做一次，或者在模型大版本升级后做一次。每次回顾可能只会删掉一两条指令或合并一个步骤，但积少成多，半年下来系统的简洁度会有明显提升。

个人体会：做减法的过程其实是对任务理解不断深化的过程。每删掉一条指令，你都需要更清楚地知道任务的核心是什么。这种思考反过来也会帮助你写出更好的提示词，即使是在需要复杂提示词的场景下。

5.4 减法思维对团队协作的影响

最后说一点团队层面的感受。减法思维不仅适用于提示词和技能编排，也适用于团队的工作方式。当模型能力提升后，很多之前需要多人协作的环节可以简化，比如数据标注、规则维护、流程监控等。

但这不意味着团队可以缩小，而是意味着团队的重心需要转移。从“教模型做事”转向“定义模型该做什么”和“验证模型做得对不对”。前者需要的是工程能力，后者需要的是领域知识和判断力。我在带团队时发现，那些对业务理解深的成员，在减法思维下反而能发挥更大的价值，因为他们能准确判断哪些约束是必要的，哪些是可以删掉的。

这个转变对个人成长也有启发。当工具越来越强时，人的价值不在于会使用工具，而在于知道该用工具做什么、做到什么程度、什么时候不该用工具。这个判断力，才是减法思维背后真正重要的东西。