企业官网建设流程全解析

1. 当模型能力溢出时，为什么你的Skill和Prompt反而成了累赘

过去一年多，我经手过十几个基于大语言模型的应用项目，从客服对话到代码生成，从文档摘要到多轮任务编排。有一个现象反复出现，而且越来越明显：模型版本每升级一次，原先精心设计的Prompt模板和Skill编排就开始“拖后腿”。不是模型变笨了，恰恰相反，是模型变强了，强到我们之前为了弥补它能力不足而加的那些“拐杖”，现在变成了绊脚石。

这个标题说的就是这件事：模型变强之后，Skill和Prompt该做减法了。它不是一个纯理论探讨，而是一个在工程实践中反复被验证的规律。适合所有正在维护Prompt工程体系、Agent Skill编排、或者多步任务链的从业者参考。不管你是刚接触Prompt的新手，还是已经维护了几十版模板的老手，这篇文章都会帮你重新审视一个核心问题：你加的每一句指令、每一个Skill节点，到底是在帮模型，还是在帮倒忙？

我先把结论亮出来：模型能力越强，Prompt和Skill的设计哲学就越应该从“教它怎么做”转向“告诉它做什么”。这个转向不是审美偏好，而是有明确技术逻辑支撑的工程决策。下面我会从设计思路、核心细节、实操过程、问题排查四个维度，把这件事拆透。

2. 整体设计思路：从“补短板”到“划边界”的范式转移

2.1 旧范式：模型能力不足时的“脚手架思维”

早期做Prompt工程，大家的思路本质上是在给模型搭脚手架。模型推理能力弱，我们就写“请一步一步思考”；模型容易跑偏，我们就加“你必须严格按照以下格式输出”；模型知识不够，我们就往上下文里塞大量参考材料。这些做法在当时是完全合理的，因为模型确实需要这些辅助才能完成任务。

我印象很深的一个案例：某团队做一个合同条款提取工具，最初的Prompt写了将近800字，包含角色设定、输出格式约束、字段枚举、异常处理规则、示例演示。这套Prompt在当时的模型上跑得不错，准确率能到85%左右。但每次模型升级，他们都要重新调一遍，因为某些约束条件在新模型上反而导致了“过度拟合”——模型太听话了，把一些本该灵活处理的边界情况也硬塞进了预设格式里。

这就是脚手架思维的问题：你搭的架子越精细，模型自由发挥的空间就越小，而模型能力提升后，它本来可以自己处理好的事情，被你用规则框死了。

2.2 新范式：模型能力溢出后的“边界思维”

模型变强之后，正确的做法是反过来：你只需要划定边界，剩下的让模型自己决定。什么叫划定边界？就是告诉模型“你要解决什么问题”“输出给谁看”“有哪些绝对不能碰的红线”，而不是告诉它“第一步做什么、第二步做什么、第三步用什么句式”。

这个转变背后的逻辑其实很朴素。你可以把模型想象成一个员工：当它是个新手时，你需要给它写详细的操作手册，每一步都规定清楚；当它成长为资深专家后，你还拿操作手册去管它，它反而会觉得束手束脚，甚至因为手册里的某些过时规则而做出错误判断。

具体到Prompt设计上，这个范式转移体现在几个方面：

• 角色设定从“你是XX专家”变成“你的任务是XX”：前者是在暗示模型调用特定知识分布，后者是直接定义任务目标。新模型对任务目标的理解能力已经足够强，不需要靠角色扮演来激活能力。
• 步骤拆解从“必须按以下步骤”变成“你可以自行规划”：让模型自己决定推理路径，往往比人为规定的路径更优，因为模型能看到你没看到的关联。
• 格式约束从“严格按JSON输出”变成“输出结构化结果”：给模型留出选择合适结构的空间，同时用解析层做兼容，而不是把格式压力全压在Prompt上。
• 示例从“给3-5个few-shot”变成“给1个参考或不给”：新模型的指令遵循能力大幅提升，过多示例反而会限制它的泛化能力。

2.3 为什么“减法”比“加法”更难做

道理讲起来简单，但实际操作中，做减法比做加法难得多。原因有三个：

第一，心理惯性。你花了大量时间调出来的Prompt，每一句都是心血，删掉任何一句都会产生“万一出问题怎么办”的焦虑。我见过不少团队，模型升级后明明旧Prompt已经拖后腿了，但没人敢动，因为“它至少能跑通”。

第二，缺乏评估手段。做加法时，你可以通过对比测试看到某句话带来的提升；做减法时，你很难判断删掉某句话后，模型是真的变差了，还是只是输出风格变了。没有细粒度的评估体系，减法就无从下手。

第三，Skill编排的耦合性。很多Agent系统里，Skill之间是有依赖关系的。你删掉一个Skill节点，可能影响下游好几个节点的输入。这种耦合性让减法变得危险。

但正因为难，才值得做。接下来我会把做减法的具体方法和实操细节讲清楚。

3. 核心细节解析：哪些该减、哪些该留、怎么判断

3.1 Prompt中优先删除的四类内容

根据我自己的实践和观察，模型升级后，Prompt里最先应该考虑删除的是以下四类内容：

第一类：推理引导语。比如“让我们一步一步思考”“首先分析问题，然后制定方案，最后给出结论”这类话。新模型在大多数任务上已经具备自发推理能力，你强行规定推理路径，反而可能打断它更高效的内部推理。我实测过一个数学应用题场景，去掉“step by step”引导后，新模型的准确率没有下降，但输出长度缩短了约30%，推理速度提升了近20%。

第二类：冗余的格式约束。比如同时规定“用Markdown输出”“用二级标题”“每个标题下不少于三点”“每点不超过50字”。这些约束在旧模型上是必要的，因为不写它就乱输出。但新模型对“结构化输出”的理解已经很好，你只需要说“输出结构化的分析报告”，它就能给出合理格式。过多的格式约束会让模型把注意力从内容质量转移到格式合规上。

第三类：过度具体的示例。Few-shot示例在旧模型时代是利器，但新模型对指令的泛化能力很强。如果你给的示例太具体，模型可能会过度模仿示例的表面特征，而忽略任务本质。我的经验是：如果零样本效果已经达到或接近少样本效果，就果断删掉示例。

第四类：防御性指令。比如“不要编造信息”“不要输出无关内容”“如果不知道就说不知道”。这些在旧模型上确实需要反复强调，但新模型在指令遵循和事实性上都有明显提升。当然，这不是说完全不要防御，而是说防御的粒度可以更粗——从“逐条禁止”变成“总体原则”。

3.2 Skill编排中优先简化的三个方向

Skill层面的减法，核心是减少不必要的编排节点和过度设计的状态传递。

方向一：合并同类Skill。很多系统里存在多个功能相近的Skill，比如“提取关键词”“提取实体”“提取摘要”被拆成三个独立节点。在新模型上，这些完全可以合并成一个“信息提取”Skill，让模型一次性输出所有需要的信息。合并后不仅减少了调用次数，还避免了多节点之间信息丢失的问题。

方向二：去掉中间状态传递。有些Agent设计会把上一步的输出经过格式化、清洗、再包装后传给下一步。在新模型上，你可以直接把原始输出传给下一步，让模型自己理解上下文。中间状态传递越多，信息损耗越大，而且每个传递环节都可能引入错误。

方向三：用Prompt替代简单Skill。如果一个Skill的逻辑可以用一段清晰的Prompt描述清楚，而且不需要外部工具调用，那它就不应该被做成独立Skill。比如“判断用户意图是否属于售后范畴”这种任务，直接写在主Prompt里让模型判断即可，没必要单独做一个分类Skill。

3.3 判断“该不该减”的三个实用标准

减法不能凭感觉，我总结了三條可操作的判断标准：

这三条标准里，边际贡献测试是最核心的。但很多团队没有建立评估集，这是做减法的最大障碍。我的建议是：哪怕只有50条标注数据，也比没有强。有了评估集，你才敢做减法。

4. 实操过程：一次完整的Prompt瘦身记录

4.1 瘦身前的Prompt现状

我拿一个真实项目做例子（已做脱敏处理）。这是一个技术文档问答系统，用户提问后，系统需要从文档库中检索相关内容并生成回答。最初的Prompt大约600字，结构如下：

你是一个资深技术文档助手，擅长从技术文档中提取信息并回答用户问题。 你的工作流程如下： 1. 仔细阅读用户问题，判断问题类型（概念解释、操作步骤、故障排查、参数说明） 2. 根据问题类型，从提供的文档片段中定位相关信息 3. 如果文档片段中包含答案，用简洁的语言组织回答 4. 如果文档片段中不包含答案，回复“抱歉，当前文档中没有找到相关信息” 5. 回答时请引用文档来源，格式为[文档编号] 输出格式要求： - 使用Markdown格式 - 如果涉及步骤，用有序列表 - 如果涉及多个要点，用无序列表 - 回答长度控制在200字以内 - 不要编造文档中没有的信息 示例： 用户问：如何配置超时时间？ 文档片段：[文档1] 超时时间配置方法：在配置文件中找到timeout字段，设置为需要的秒数。 回答：根据文档[1]，配置超时时间的方法是在配置文件中找到timeout字段，将其设置为需要的秒数。 现在请回答用户问题。

这套Prompt在旧模型上表现稳定，但升级到新模型后，出现了两个问题：一是回答过于模板化，缺乏对用户问题意图的深入理解；二是遇到文档片段不完整时，模型会机械地回复“没有找到”，而不是尝试结合上下文给出部分回答。

4.2 瘦身后的Prompt版本

经过三轮删减和测试，最终版本缩减到约200字：

你是一个技术文档助手。根据提供的文档片段回答用户问题。 要求： - 回答基于文档内容，不编造信息 - 如果文档片段不足以完整回答，说明哪些部分有依据、哪些部分缺失 - 引用文档编号 - 输出结构化结果 文档片段： {context} 用户问题：{question}

删掉的内容包括：角色描述中的“资深”、五步工作流程、详细的输出格式约束、示例、防御性指令。保留的只有：任务定义、核心原则、引用要求、结构化输出要求。

4.3 瘦身效果对比

在同一个评估集（120条问题）上，新旧Prompt的表现对比如下：

准确率和完整性不降反升，输出长度大幅缩短，格式合规率略有下降但在可接受范围内。用户满意度提升明显，主要原因是回答更自然、更聚焦问题本身。

这个结果验证了一个判断：旧Prompt里的很多约束，在新模型上不仅没有帮助，反而干扰了模型对任务本质的理解。

4.4 Skill编排的同步简化

Prompt瘦身的同时，我也对Skill编排做了简化。原来的流程是：

用户提问 → 意图分类Skill → 检索Skill → 文档过滤Skill → 回答生成Skill → 格式校验Skill

简化后变成：

用户提问 → 检索Skill → 回答生成Skill

意图分类被合并进回答生成Prompt里，让模型自己判断问题类型；文档过滤被去掉，因为新模型对无关文档片段的鲁棒性已经足够强；格式校验被移到输出后处理层，用代码做基础校验，而不是让模型自己保证格式。

简化后，整个链路的响应时间从平均2.3秒降到1.4秒，错误率没有上升。这个收益主要来自减少了两次模型调用和一次状态传递。

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

5.1 减法做过头了怎么办

这是最常见的问题。删得太狠，模型开始跑偏。我的经验是：每次只删一类内容，删完立刻跑评估。不要一次性删掉推理引导、格式约束和示例，那样你根本不知道是哪个删错了。

如果发现删过头了，不要急着把整段加回去，而是先加一条最简原则。比如删掉格式约束后模型输出太随意，不要加回“用Markdown、用二级标题、每段不超过50字”，而是加一句“输出结构清晰、便于阅读”。让模型自己决定什么叫结构清晰。

5.2 不同模型版本的减法策略差异

不是所有模型升级都适合同一套减法策略。我的观察是：

• 推理能力提升明显的版本：优先删推理引导和步骤拆解
• 指令遵循提升明显的版本：优先删格式约束和防御性指令
• 知识广度提升明显的版本：优先删上下文参考材料和示例

判断方法很简单：看模型升级说明里重点强调了哪方面能力，就从那个方面开始做减法。

5.3 评估集不够用时的替代方案

如果没有标注评估集，可以用以下方法做快速验证：

1. A/B对比法：准备20个典型问题，分别用新旧Prompt跑，人工对比输出质量
2. 一致性检验：同一问题跑5次，看输出是否稳定。如果新旧Prompt的稳定性差不多，说明旧Prompt的约束是冗余的
3. 极端案例法：专门找边界情况测试，比如信息不完整、问题模糊、多意图混合的场景，看模型是否能合理处理

这些方法不如标注评估集严谨，但在资源有限时足够支撑决策。

5.4 减法后的监控与回滚机制

做减法一定要有回滚能力。我的做法是：

• 每次Prompt变更都记录版本号和变更内容
• 保留上一版Prompt至少两周
• 上线后监控关键指标（准确率、用户反馈、异常率）
• 如果指标下降超过阈值（我一般设5%），自动回滚

这套机制让我在做减法时没有后顾之忧，敢于尝试更激进的简化。

5.5 常见问题速查表

6. 个人经验总结与后续扩展方向

6.1 我踩过的三个坑

第一个坑是一次性删太多。有一次模型升级后，我兴奋地把Prompt从500字砍到100字，结果模型在边界案例上频繁出错，不得不花了两天时间逐步加回。教训是：减法要渐进，每次只动一个变量。

第二个坑是忽略了输出后处理。我以为删掉格式约束后，模型输出会自然结构化，但实际上模型输出的结构是不稳定的。后来我在输出层加了一个轻量解析器，兼容多种格式，问题才解决。Prompt做减法，工程层要做加法。

第三个坑是没有区分任务类型。有些任务确实需要详细约束，比如涉及合规审查的场景，你不能让模型自由发挥。减法不是一刀切，而是要根据任务的风险等级来决定减到什么程度。

6.2 后续可以尝试的扩展

这个方向还有很多可以探索的空间。比如动态Prompt：根据输入复杂度自动调整Prompt的详细程度，简单问题用极简Prompt，复杂问题适当增加引导。再比如Prompt自动压缩：用模型自己来精简Prompt，去掉冗余表达，保留核心语义。还有Skill编排的自适应简化：系统根据历史执行数据，自动识别哪些Skill节点是冗余的，给出简化建议。

这些方向我都在陆续尝试，有些已经有了初步效果。核心思路始终不变：模型越强，我们越应该把精力从“教模型怎么做”转移到“定义清楚要做什么”和“建好评估与回滚机制”上。做减法不是偷懒，而是把工程复杂度从Prompt层转移到系统层，让整个方案更健壮、更可维护。

最后分享一个我常用的判断方法：当你看着一段Prompt，心里想的是“万一模型不这么做怎么办”时，先别加约束，先跑十次看看模型到底会不会那么做。十有八九，它不会。