企业官网建设流程全解析

遇到同样一条Prompt，上一步还输出结构完整的JSON，下一步就给你夹带一句“好的，以下是……”，把整个解析流程直接带崩。这种“忽好忽坏”的体验，是做大模型应用开发时最折磨人的一个问题。哪怕换更强的模型，也照样会出现措辞漂移、格式跑偏、逻辑跳变。

这篇文章不聊大道理，就分享我在实际项目里反复试过、确认有效的8种Prompt优化技巧，主要用来解决“输出不稳定”这个痛点，比如格式时好时坏、内容时而完整时而缺失、任务边界偶尔失守。适用的场景包括数据抽取、信息分类、客服答疑、代码生成、结构化工具调用等对输出质量有硬要求的任务，也适合刚入门的开发者和大模型应用开发者参考。

1. 先搞清楚：大模型输出为什么“忽好忽坏”

1.1 输出不稳定的典型表现与影响

先描述现象。我遇到过的“不稳定”基本可以归成三类：

第一类是格式不稳定。要求返回JSON，大部分时候都正常，偶尔一次在前面加“好的”，或者键名从user_name变成username，或者少了个逗号，解析直接报错。这类问题在纯文本聊天里看不出什么，但一旦接入自动化流程，就是致命的。

第二类是逻辑不稳定。同样的问题换一次提问，答案的侧重点变了，甚至结论都可能反转。比如让模型判断一段客服工单是否涉及退款诉求，有时判“是”，有时判“否”，没有明显的规律。这类问题在做文本分类和意图识别时格外明显。

第三类是内容完整度不稳定。要求输出五个要点，有时候给四点，有时候给六点，有时候把两个要点合并成一个，导致下游统计口径混乱。

这些问题的共同后果是：人没法信任输出结果，自动化流程得在旁边加一堆“清洁”逻辑，开发效率大打折扣。如果拿这样的Prompt直接上线，早晚会出事故。

1.2 背后机制：随机性与模糊地带

不要把这些现象简单归结为“模型笨”或“运气差”。底层机制其实可解释。

大模型的解码过程本质是概率采样。模型每生成一个token，都会计算一个候选词的概率分布，然后按一定规则从中挑一个。当temperature和top_p不为零时，挑选过程带随机性——即使同一个输入，两次生成也不会完全一致。这是输出不稳定的第一层来源。

第二层来源是Prompt本身存在“模糊地带”。如果你只写“请提取信息”，模型需要靠自己的理解去脑补你要提取的字段、格式、边界、空值策略。不同脑补方向对应不同概率通道，一旦概率分布接近，随机采样就可能把输出推往不同方向。所以很多不稳定问题，本质是Prompt的表达不足以约束模型走向单一路径。

第三层是上下文干扰。输入文本越长，模型越容易受无关信息影响，注意力分散后，Prompt末尾的要求可能会“衰减”。这也是长文档任务里格式特别容易崩的原因。

理解了这三层来源，再看下面8个技巧，思路会清晰很多：要么用确定性替换随机性，要么把模糊地带压缩到最小，要么在Prompt之外再用代码兜底。

2. 8种Prompt优化技巧详解

2.1 技巧一：用“硬格式”锁定输出边界

适用场景：数据抽取、实体识别、结构化信息返回。思路是把“模型自己决定输出什么”变成“模型往我给的模板里填空”。

先说一个常见误区。很多人会写“请以JSON格式返回”，以为加了这半句就够了。实际是不够的——JSON的键名是什么？值的类型是字符串还是数组？没有键时要不要填空数组？字段缺失怎么处理？这些都没说明，模型只能猜。

我的做法是直接在Prompt里给出一个合法JSON骨架，并让模型按骨架填空。比如要做电商订单信息抽取，Prompt里会写：

请从以下文本中抽取订单信息，严格按下面JSON结构返回： { "order_id": "字符串，缺失时填N/A", "user_name": "字符串，缺失时填N/A", "items": ["字符串数组，每个元素是一个商品名"], "total_amount": "数字或null，缺失时填null" } 只输出JSON本身，不要写任何解释。

这段描述里最关键的不是“用JSON”，而是“缺失时填什么”。这类兜底说明，能有效避免模型在字段信息不足时空着不写、自己编一个值、或者用“暂无”这种模棱两可的文本，把解析器的类型校验全部打乱。

除了JSON，XML标签、Markdown表格、纯枚举值这些格式都适用，原则是一致的：把自由发挥的空间收窄。格式模板越接近“代码世界里可验证的结构”，输出就越稳定。

实际测试中，这个方法通常能把格式通过率从70%左右提到95%以上。剩下的零星失败，再用第8个技巧去兜底。

2.2 技巧二：Few-shot示例不仅要“给对”，还要“给错”

适用场景：分类、抽取、改写，尤其是那些“凭一句话说不清边界”的任务。

假如你想让模型区分“售后问题”和“产品咨询”，只写一句“请判断用户意图”是不够的。“七天无理由退换货”算售后还是咨询？“这个型号有白色吗”呢？模型在语义边界上只要稍微挪一点，分类结果就会跟着漂移。

Few-shot是最好的边界标注工具。但我的经验是：不光要给正例，还要给反例。给“什么是对”的示例，模型会模仿；给“什么不是”的示例，模型才知道划分边界在哪里。举个例子：

判断以下用户消息属于"售后问题"还是"产品咨询"。 示例1（售后问题）："我的订单三天了还没发货，能催一下吗？" 示例2（产品咨询）："这款手机支持无线充电吗？" 示例3（售后问题）："收到的耳机有一只没声音，怎么处理？" 示例4（不是售后问题，而是产品咨询）："耳机支持蓝牙5.3吗？" 用户消息：{message} 只输出"售后问题"或"产品咨询"。

示例4存在的意义，是明确告诉模型“询问参数”不是售后。很多人省略这一步，结果就是模型把带“耳机”“订单”这些词的消息一股脑归成售后。

示例数量不用多，每个类别2~3个就够，关键是示例之间要有区分度，覆盖那些模棱两可的边界情况。另一点容易被忽略：示例要和真实请求保持相似的写法和长度，不要拿精炼过的示范文本去指导满是语气词的真实对话。

2.3 技巧三：角色设定要从“身份”走向“边界”

“你是一名资深数据分析师”“你是一个贴心的客服助手”——这类角色设定不是没用，而是只解决一半问题。它能让模型在语气和专业度上靠拢，但没法稳定输出结构。真正影响稳定性的是“能力边界”。

如果角色设定里没有边界，模型会自作主张。比如让它做客服回复，它可能顺手给出“可以退货”这种未经确认的承诺；让它做信息抽取，它可能对超出范围的字段也展开解释。要避免这种情况，角色设定里需要补充四类信息：任务范围、输出形式、禁止事项、越界时怎么办。

一个更可靠的写法：

你是一个负责售后工单分类的助手。 你的任务范围：只把用户消息分类为A/B/C三类。 你不可以做的事：不要回答分类之外的任何问题，不要评价用户情绪，不要给出处理建议。 如果用户消息与售后无关，输出"不在处理范围"。 输出要求：只输出一个类别名。

对比一下“你是一个售后助手，请对消息分类”，后者在用户消息里夹杂“差评！我要投诉”时，很可能顺便输出一句安抚话术，导致下游解析失败。

边界设定还有一个额外好处：它能让“拒答”也变成稳定输出。与其让模型在边界外自由发挥，不如给它一个固定的出口——输出“不在处理范围”。这既保护了流程，也保护了用户体验。

2.4 技巧四：把复杂任务拆成“单步指令”

适用场景：分析、总结、多步骤推理、生成结果需要引用依据的任务。

模型在抽象层面的“发散”空间，比在具体步骤层面的发散空间大得多。让模型“一步到位”地综合回答一个问题，它往往会先决定“回答的姿势”，比如先感慨一句、再分几个自然段、最后来个总结。这个姿态一变化，输出结构就跟着变。

我常用的解决办法是把任务改成显式步骤，通常叫“Step-by-Step”。但要注意，不是简单加一句“请一步步思考”，而是把每一步的输出目标都在Prompt里写清楚：

请按以下三步处理用户反馈，并在最终输出中按步骤标注： 步骤1：提取用户反馈中提到的具体问题点，用列表列出。 步骤2：判断每个问题点的紧急程度，输出"高"或"低"。 步骤3：基于问题点，生成一句不超过50字的初步回复。 输出格式： 问题点：... 紧急程度：... 初步回复：...

这样的好处是，模型在每一步只解决一个小目标，输出空间的多个自由度被收缩了。每步的结果又能作为下一步的上下文，逻辑链条更可控。

复杂任务还有一个常见依赖——长文本。如果输入文本特别长，建议加一句“基于上文中包含的信息回答，不要回忆外部知识”，防止模型跑到训练记忆里找内容。实测下来，这能明显减少幻觉和答非所问。

2.5 技巧五：温度与采样参数：把“运气”变成“可控”

Prompt优化不是只改文本，参数也要跟着调。很多人拿到大模型接口，temperature就懒得动了，默认值可能偏创意。对输出稳定性要求高的业务，这是问题所在。

我个人的参数策略很简单：

关于temperature，有一个值得记住的直觉：它调节的是概率分布曲线的“锐度”。温度越低，高概率token被选中的可能越大，输出越保守、越确定；温度越高，低概率token也有机会出现，输出更花哨但也更随机。所以当你的任务要求“一定不能跑偏”时，温度就别往高了放。

有的平台还提供seed参数，配合固定值可以让部分采样过程可复现。但注意，这并不保证跨版本模型的结果完全一致，只能当作缩放随机性的辅助手段。真正的稳定性还得靠Prompt文本本身。

2.6 技巧六：用“自校验指令”让模型自己检查

适用场景：格式要求复杂、字段多、对准确性要求高的输出任务，比如一份十几个字段的JSON，或一条必须包含指定环节的客服话术。

模型输出完之后，我们再让它在同一轮上下文里对结果做一次检查，这叫自校验。原理很简单：第二次生成时，模型面对的是“成品”，不需要从头组织结构，注意力可以集中在“哪里不对”上。格式遗漏和字段缺失在成品面前更容易被识别。

一个常见写法是两阶段Prompt——注意，是要在一条Prompt里分两步写，而不是分两次接口调用：

第一步：根据用户需求生成结果。 第二步：检查第一步生成的结果。如果发现字段缺失、格式错误、或与用户要求不符，输出修正后的完整结果；如果没有问题，原样输出。

这样写，模型会先产出初稿，再以修正者的视角复核整个内容，稳定性比单次生成高很多。缺点是多消耗一些token，但相比亲自动手清洗脏输出，这点成本值得。

自校验也有副作用，后面第4章会专门讲一个“改错”的坑。这里先记住一个原则：校验指令要限制“只修正格式和缺失字段”，不要给它放开权限重写内容。

2.7 技巧七：设置“拒绝回答”与“兜底回复”

适用场景：信息抽取、工单分类、知识库问答，凡是“输入里可能没有答案”的任务。

模型天生倾向于“答非所问宁可信其有”。你问它某订单是否存在，它判断不了的时候可能编一个订单号；你让它从文章里抽取手机型号，文章没提，它可能返回“未知型号”而不是空值。这种自动补全的行为对工程系统非常不友好。

对策是给模型一个明确的“无法回答”出口，并且给它默认值的填写规则：

从以下文本中抽取品牌和型号。 - 如果文本中没有提到，输出"未知"。 - 不要猜测，不要使用训练知识补充。 - 只输出JSON：{"brand": "品牌或未知", "model": "型号或未知"}

注意“不要使用训练知识补充”这句。模型在做抽取时经常会拿着训练阶段见过的手机型号来“填空”，有了这句明确禁令，幻觉大幅减少。同理，在分类任务中可以加“如果无法判断，输出‘无法判断’”的选项，而不是硬选一个类别。

让“不知道”也成为合法输出，带来的另一个好处是下游可以接人工兜底。模型输出“未知”时自动转人工，比让模型硬着头皮给答案稳妥得多。

2.8 技巧八：外部兜底：用代码断言与重试机制

无论Prompt写得多么完善，概率采样决定了它不可能100%稳定。所以工程上的最后一道防线，必须放在Prompt之外。

我把这层防护分为三件事：输出校验、失败重试、结果清洗。

输出校验是硬性的。拿到模型输出后，先做合法性判断：JSON能不能解析？字段缺不缺？类型对不对？枚举值是否在允许范围内？一段简单的Python示例就能说清思路：

import json def validate_response(raw_text: str) -> dict: # 去掉可能存在的首尾噪音 text = raw_text.strip() if not text.startswith("{"): # 常见噪音：模型自带的"好的，以下是……" start = text.find("{") end = text.rfind("}") if start == -1 or end == -1: raise ValueError("no json found") text = text[start:end+1] data = json.loads(text) assert "order_id" in data, "missing order_id" assert isinstance(data.get("items"), list), "items should be list" return data

失败重试的要点是“带变化地重试”。单纯把同一个Prompt再发一遍，很可能得到一模一样的结果，浪费调用次数却没有新信息。我更推荐的做法是：第一次失败后，把报错信息附在原文后面，让模型据此修正：

上一次输出解析失败，错误信息为：{error_message}。 请严格按照指定JSON格式重新输出，不要增加任何前后缀内容。

这种“错误反馈式重试”，成功率比静默重发高很多，因为模型能看到自己的错误点在哪里。

结果清洗可以作为最后手段，例如用正则把多余的描述性文字去掉、把全角符号转成半角、去掉Markdown代码块标记。前面几个手段都失效时，清洗至少能让内容具备解析的可能性。

3. 如何验证你的Prompt稳不稳：评估方法

3.1 以“最小回归集”替代逐个试

很多人在调Prompt时，用的是“同一句话试几次”的方法。如果连续几次结果都正常，就认为稳定了。这个方法有陷阱：单条样本通过，不代表换一类表达还能通过。

我习惯为每个任务准备一个“最小回归集”，通常5到10条输入，覆盖正常情形、边界情形、异常情形。以客服工单分类为例，回归集应包括：明确的售后问题、明确的产品咨询、既像售后又像咨询的模糊表达、与任务完全无关的消息、特别长的消息、包含多个问题的消息。每类各一两条。

每次调整Prompt后，拿这个回归集整体跑一遍，看整体通过率，而不是盯着某一条看效果。这样才有可对比的基线。

3.2 稳定性指标怎么看

单跑一遍并不够。为了衡量“稳定”，最好让每个用例连续跑5到10次，并统计三个指标：

格式通过率：输出能否被解析器成功解析，字段是否齐全。这直接决定自动化流程能不能跑通。

内容一致率：多次输出中，核心结果相同的比例。以JSON为例，可以比较关键字段值是否一致。比如order_id每次都相同，但user_name偶尔被抽成别名，后者就是不稳定点。

失败重试恢复率：第一次校验失败后，经过重试成功恢复的比例。这个指标决定了你的兜底代码能不能兜住。

记录建议用一张简单的表：

这份记录的价值在于：当模型版本升级或者线上出现诡异故障时，你能迅速定位是Prompt问题、参数问题还是模型行为漂移。

3.3 Prompt版本管理：别让“上一步调好”变成“下一步失效”

Prompt迭代过程中，一个非常常见的翻车点是：你调好了A场景，结果发现B场景挂了；你把B补好，A又开始不稳定。如果对Prompt前后版本没有记录，这种问题排查起来极其耗时。

我通常在每次调整后顺手记下：改动点是什么、为什么改、当前回归集过不过、哪个用例有回归。这不需要复杂工具，一个清单表格就足够。等积累多了，你会发现自己对“哪些表述容易引发模型发散”的判断会准很多。

更重要的是，模型服务商更新底层模型版本时，线上Prompt很可能突发性变差。有版本记录在，就能快速做前后对比，判断是“提示词退化”还是“模型升级连带漂移”，而不是对着屏幕怀疑人生。

4. 实际踩坑记录与排查心得

4.1 踩坑实录：看起来要求了格式，结果还是乱

有一段时间我在做客服对话摘要，Prompt里写得很清楚“请输出JSON”，结果模型一句话回复末尾偶尔还会带上“希望以上回答对您有帮助”。一开始怀疑是模型问题，后来把Prompt从头读到尾，发现问题出在“顺序”上。

我写的Prompt结构是：先一段场景描述，再给要处理的对话，最后写“以JSON格式输出摘要”。这个顺序让模型在处理完整段对话后，注意力已经漂移，格式要求被“稀释”了。

调整方式是把格式模板和最终指令移动到Prompt末尾，并且用“严格按以下结构”“只输出JSON”这类短促强约束的句式。改完后，同一批样本的格式通过率立刻提升了不少。后来我总结出一个经验：不要在Prompt开头长篇大论写格式要求，越靠近任务指令末端的部分，对输出的锚定作用越强。

4.2 踩坑实录：示例太多反而更不稳定

有一次做意图分类，为了让模型判断得更准，我在Prompt里塞了十几个示例，各种边界情况都覆盖到了。结果跑出来的结果时好时坏，有的示例之间互相冲突，模型反而学糊涂了。

问题不在“示例数量”，而在“示例一致性”。比如示例A说“询问退货政策”是售后，示例B又说“询问七天无理由”是产品咨询，这两个边界在模型看来就是矛盾的，输出自然摇摆。删掉冲突示例、统一标注口径之后，分类稳定性立刻恢复了。

示例选择还有一个原则：要选“划边界”的示例，不要只是堆砌相似表达。那些一眼就能判断的例子放得再多也只是冗余，反而占用上下文空间。

4.3 踩坑实录：temperature调低了还是不稳，问题出在上下文

有一阵子某项目的抽取任务连续出现字段遗漏，我把temperature调到0，结果问题依旧。排查到最后，发现是系统把用户原文截断后拼接了一段历史对话，上下文总长度到了四千多token。模型处理长上下文时，注意力分布在大量内容上，对Prompt末尾的字段要求自然就“看不清”了。

解决办法是精简上游输入：把无关闲聊过滤掉，只保留与任务相关的段落；必要时单独提取重点段落再传给模型。此外，把格式要求放在Prompt末尾，并加一句“严格按照最新指令执行，忽略与任务无关的历史内容”，多多少少能缓解上下文干扰。这类问题提醒我：稳定性不单是Prompt文本的事，输入的质量和长度同样影响最终输出。

4.4 踩坑实录：自校验把正确结果改错了

自校验是个好用的技巧，但也别把它当万能药。我在一个实体抽取任务里发现，让模型“检查并修正”之后，它把原本抽对的信息改成另一个语义相近但错误的实体，甚至把正确JSON的字段顺序改得鸡飞狗跳。

后来把第二阶段指令限制成：不要重写内容，只检查JSON结构和必填字段，发现问题时输出缺失字段名即可。实际执行改为“必须在第一阶段结果基础上修改，不允许重新生成全文”。限定越窄，模型改动幅度越小，副作用越少。这个教训也让我明白：所有让模型“自由校验”的技巧，都要明确“不允许做什么”，不然它会把校验变成一次重新创作。

5. 一点个人体会

做了这么多大模型应用的调优，我最深的感受是：输出稳定不是某一条Prompt文本的功劳，而是一条链条的共同结果——任务拆分合理、格式约束到位、参数设置匹配、代码兜底完整，以及一个能帮你发现问题的评估流程。

如果你现在正被“输出不稳定”折磨，我的建议是不要凭感觉一遍遍改Prompt。先挑一两条最常出错的输入，回看它是在什么环节处理的，再根据问题类型选择对应的优化方式：格式问题靠硬模板，分类问题靠边界示例，越界问题靠角色边界，长文问题靠缩短上下文和加强校验。改完一个点，跑一轮回归，再改下一个点。你很快会发现，大模型虽然本质是个概率系统，但工程上的稳定性是可以一点一点设计出来的。希望这篇文章能帮你少走几段弯路。