企业官网建设流程全解析

“通义千问大模型prompt调试”这件事，我从最早的qwen-turbo一直跟到现在的plus、max几个档位，踩过的坑能写满一个笔记本。刚上手那会儿我也觉得Prompt调试是个玄学活儿——同样的意思换个说法，输出质量能差出一大截，改来改去全靠感觉。后来做的场景多了才明白，它其实更接近一门“沟通工程学”：你得知道模型的脾气、知道它哪里会误解、知道哪句话是有效的约束、哪句话纯粹是自我安慰。这篇东西不打算讲什么高深理论，就是把我在实际项目里反复验证过的调试路径、结构模板、参数取舍和翻车现场整理出来。

不管你是刚接触大模型API、还在纠结system和user该怎么分工的新手，还是已经能跑通demo、但一上真实数据就被格式漂移和字段漏抽折磨得没脾气的开发者，下面这些内容应该都能直接拿去用。我会从认知层面先掰扯清楚“调Prompt到底在调什么”，再给一套可复用的结构骨架，然后拿一个真实感很强的结构化抽取场景从头到尾走一遍迭代过程，最后把高频故障和工程化落地的东西摊开讲。全程只讲能复现的操作，不讲虚的。

1. Prompt调试到底在调什么，先把认知摆正

1.1 它不是搜索引擎，而是一台“条件续写机器”

很多人调Prompt调得痛苦，根子在于对模型的运作方式有误解。你输入一段文字，模型做的事情本质上是根据上文预测下一个token该是什么，一个接一个往外吐。它没有“查询数据库”这个动作，也没有“理解我的意图然后执行”这种中间环节。你觉得你在下指令，它觉得你在给它一个开头，它顺着往下写。这个认知差会直接导致两类典型错误：一是把需求写得像给同事发消息一样含糊，指望它“领会精神”；二是发现结果不对就不断加形容词，什么“非常重要”“务必严格”“绝对不能出错”，实际上这些词对模型来说只是普通的token，权重上并不会因为你加了感叹号就提高遵守概率。

真正有效的做法是把任务翻译成它擅长处理的形态：明确的输入边界、明确的输出结构、明确的判断规则。举个我常举的例子，你让实习生整理会议纪要，说“整理得清楚点”，他大概率给你一坨；你说“按议题分块，每块下面列结论、待办、负责人、截止时间，没提到的写未提及”，他就能交出能用的东西。模型比实习生好在它不知疲倦、不会抱怨，坏在它不会主动问你“这里我理解得对吗”，所以所有歧义都得你提前堵死。

1.2 通义千问的脾气：中文语感好，但也“爱发挥”

用通义千问系列做中文任务，最直观的感受是语感自然，长句处理不生硬，对中文里的省略、倒装、行业黑话的容忍度比不少同类模型要高。做客服话术改写、公文润色、中文摘要这类活儿，基础版本给出来的东西就已经能看了。但另一面是它在开放式任务上有比较明显的“补充欲”：你给的信息不全，它会自己脑补一段补上，而且补得还挺像那么回事，这就很危险。做信息抽取的时候我遇到过好几次，原文里根本没写的日期，它硬给填了一个合理的，如果不做校验直接入库，后面就是一堆脏数据。

所以调试策略要分场景：创意类、改写类任务，顺着它的发挥走，把temperature调高一点，让它多给几个版本；抽取类、判定类、格式敏感的任务，必须把它的发挥空间压到最小，温度压到0.1以下，约束写到没有歧义，输出格式卡死。这个“按任务类型定调试基调”的意识，比记住一百个prompt技巧都管用。我见过太多人拿一套万能模板到处套，做抽取和写文案用同一个温度、同一套措辞，结果两头都不满意。

1.3 为什么大部分调试是在做无用功

最常见的无用功是“单条样本调试”。拿一句话试，改一版Prompt，再试同一句话，发现好了，收工。上线之后发现另外三十种表达方式全崩。原因很简单，你调的是这一条样本，不是这个任务。正确的做法是先攒一个小评测集，哪怕只有三十到五十条，也要覆盖正常case、边界case、脏数据case、对抗case。每改一版Prompt，全量跑一遍，看整体通过率的变化，而不是盯着单条结果自我感动。

第二类无用功是“只调文字不调参数”。同样的Prompt内容，temperature从0.7降到0.1，输出稳定性可能是两个世界；max_tokens设小了，JSON会在末尾被硬截断，你以为是格式问题，其实是长度问题。还有top_p、seed这些，多数人从来不动。第三类无用功是“不做失败归因”，输出错了就笼统地认为“模型不行”，其实要分清楚到底是没理解任务、没看到关键信息、理解了但格式没对、还是原文本身就没有这个信息。这四种情况的修法完全不同，混在一起调，永远调不明白。

心得：每次改Prompt之前，先花两分钟给失败样本打个标签，是“理解错”“漏信息”“格式错”还是“原文缺”。标签分布会直接告诉你该改哪一段，比盲目重写高效得多。

2. 一套可复用的Prompt结构骨架

2.1 角色、任务、约束、示例的四段式

我把绝大多数生产环境在用的Prompt都收敛成四段：角色设定、任务描述、约束清单、示例。角色设定不是让你写小说，一句话交代清楚“你是谁、服务谁、擅长什么”就行，它的作用是给模型一个语言风格和知识范围的锚点，写太长反而稀释注意力。任务描述是核心，必须用动词开头，把输入是什么、要产出什么、产出物长什么样说清楚。约束清单是踩坑踩出来的，一条一条列，每条都必须是可判定的，像“语气要专业”这种就没法判定，得改成“不使用口语化的语气词，不使用感叹号”。

示例这块争议最大。有人认为few-shot万能，有人觉得示例会带偏模型。我的经验是：格式类的要求，示例比文字描述管用十倍；逻辑类的要求，示例要慎用，因为模型容易照抄示例里的内容而不是学规则。所以给示例的时候，格式示例可以多给，业务内容示例给一到两个足够，而且示例里的内容要跟真实数据的分布一致，别拿一个特别干净的例子糊弄它，上线遇到脏数据照样傻眼。

2.2 分隔符和结构化标记，别小看这几个符号

Prompt里混着指令和待处理文本，模型很容易分不清哪部分是“要求”、哪部分是“素材”。我习惯用明确的分隔符把素材框起来，比如三个井号、三个减号，或者直接用XML风格的标签包住。实测下来，标签形式的边界感最强，尤其是素材本身可能包含引号、括号、代码片段的时候，普通分隔符容易被素材内容干扰。还有一个细节：把最重要的约束放在Prompt的最末尾重复一遍，因为长Prompt里前半部分的指令权重会被稀释，末尾的内容对生成的影响更直接。

模板大概长这样，可以直接抄：

# 角色 你是一名严谨的信息抽取助手，只依据给定文本输出结构化结果。 # 任务 从 <text> 标签内的文本中抽取指定字段，输出一个JSON对象。 # 字段定义 - order_id：订单编号，字符串，找不到填 null - amount：金额，数字类型，单位元，找不到填 null - deadline：截止日期，格式 YYYY-MM-DD，找不到填 null # 约束 1. 只输出JSON，不要输出任何解释、前后缀、代码块标记 2. 所有字段值必须能在原文中找到依据，禁止推测 3. 金额若带“万”字需换算为数字，如 3.5万 输出 35000 4. 字段缺失一律填 null，不要填空字符串 # 示例 输入：订单A1023，金额两万三，本月30号前完成 输出：{"order_id":"A1023","amount":23000,"deadline":null} <text> {{待处理文本}} </text> 再次强调：只输出JSON对象本身，不要任何额外字符。

2.3 参数不是配角，几个关键项的实际取值

参数这块我整理了一张表，是这几个档位的模型在不同任务下我常用的起始值，实际项目里再微调。注意这不是标准答案，是起点，具体还得看你的数据。

max_tokens的估算有个简单办法：先不设上限跑一遍，看输出token数，取P95值再乘1.5，作为生产环境的上限。设太小是最隐蔽的坑，因为你看到的现象是“JSON解析失败”，很容易往格式方向排查，绕半天才发现是截断。

2.4 输出格式锁定的三种手段，按强度排序

第一层是文字约束，就是上面模板里那种“只输出JSON”。这层最弱，简单任务够用，复杂任务会漏。第二层是给schema，把字段类型、枚举值、嵌套结构写清楚，模型对结构化描述的理解力明显好于自然语言描述。第三层是用API层面的结构化输出能力，通义千问的部分接口支持指定返回格式，或者用它的函数调用能力把参数结构固定下来，这层最硬。我的习惯是三层叠加：文字约束保底，schema提准确率，接口能力兜底。三层都上还出错的情况，基本就是原文本身有问题了，得回到数据清洗环节。

还有个小技巧是“先想后答”。让模型在输出JSON之前，先用一小段话把关键信息摘出来，再输出最终结果，最后在代码里把这段思考内容切掉。这套做法对字段多、逻辑复杂的抽取任务提升很明显，代价是token消耗增加，得算成本账。

3. 实操：一个结构化抽取任务从零调通的全过程

3.1 需求拆解与基线建立

假设要做一个客服工单的自动分派系统，输入是一段用户口语化的描述，输出是工单类型、紧急程度、涉及产品、期望处理方式四个字段。第一步不是写Prompt，是先把字段的定义和判定规则写成人能看懂的文档。“紧急程度”这种字段最容易出问题，什么叫紧急？得给出可判定的标准：涉及资金损失、账号无法登录、服务已中断的算高；功能异常但有替代方案的算中；咨询类算低。规则不写清楚，模型就会各按各的理解来。

然后建基线。最朴素的Prompt就是一句话：“请判断以下工单的类型、紧急程度、涉及产品和期望处理方式”，不加任何约束，跑五十条样本，记录准确率。这个基线非常重要，它告诉你“不调”的水平在哪，后面每一版改动都要跟它比。我当时的基线大概是类型72%、紧急程度58%、产品65%、期望处理方式41%。期望处理方式这一项特别低，因为用户的表达太散了，模型抓不住。

3.2 第一版正式Prompt与失败复盘

第一版加了角色和字段定义，准确率提到了类型85%、紧急程度71%、产品78%、期望处理方式60%。进步明显，但离能用还差得远。把失败样本拉出来逐个看，问题集中在三类：一是用户一段话里说了好几件事，模型只抓了第一件；二是“期望处理方式”用户根本没明说，模型开始脑补；三是产品名用户用的是简称或者错别字，模型认不出来。

第二版针对这三点改：明确要求“逐条列出用户提到的所有诉求，再判断整体类型”；对没明说的字段强制填“未明确”；在产品字段后面附上常见简称和别名的对照。改完类型到了91%，紧急程度83%，产品89%，期望处理方式74%。这时候发现新问题：紧急程度的判断开始飘，同一个case跑三次有两次给高一次给中。这说明规则本身有交叉地带，得在Prompt里补一个优先级顺序：多个条件同时满足时取最高级别。

3.3 迭代到可用版本的关键几刀

真正让准确率上台阶的是三刀。第一刀是把输出改成“先分点摘录依据、再给结论”，让模型的推理过程显性化，摘录的原文如果跟结论对不上，我在代码层就能拦下来。第二刀是加了一个反向校验环节：让模型自己检查一遍“紧急程度判定为高，依据是否满足高优先级的三条规则之一”，不满足就重判。这一刀把紧急程度的准确率从83%推到了92%。第三刀是按工单类型拆了不同的Prompt变体，咨询类和故障类走不同的字段约束，整体准确率又涨了几个点。

这套做法听起来繁琐，但每一刀都是针对具体的失败标签下的，不是拍脑袋加内容。到最终版本，四个字段的准确率分别是95%、92%、94%、86%。期望处理方式这一项天花板就在这，因为很多用户确实没表达清楚，再怎么调模型也变不出来，这部分只能靠后续人工兜底。

3.4 代码层的调用与校验闭环

Prompt调得再好，代码层不做校验也是白搭。我的调用代码里固定有三段：调用前做长度检查和敏感内容过滤；调用后先做JSON解析，解析失败就带上错误信息重试一次；解析成功后做业务校验，字段类型、枚举值、必填项全过一遍，不通过就打回重跑。下面是个简化版的结构，可以直接改改用：

import json import dashscope def extract_ticket(text, retry=1): prompt = build_prompt(text) for i in range(retry + 1): resp = dashscope.Generation.call( model="qwen-plus", messages=[{"role": "user", "content": prompt}], temperature=0.05, top_p=0.8, max_tokens=800, result_format="message", ) raw = resp.output.choices[0].message.content.strip() raw = raw.removeprefix("```json").removesuffix("```").strip() try: data = json.loads(raw) except json.JSONDecodeError: continue if validate_schema(data): return data return {"error": "extract_failed", "raw": raw}

注意几个细节：temperature给到0.05而不是0，是因为绝对的0在某些版本上会导致输出过于机械、偶尔卡住不吐；raw处理那行是防模型自作主张加代码块标记，虽然Prompt里说了不要，但它有时候还是会加，代码里做一层清洗比在Prompt里反复强调更省事；重试的时候最好在Prompt里追加一句“上次输出不是合法JSON，请只输出JSON对象”，比原样重试成功率高不少。

4. 高频翻车场景与排查手册

4.1 格式漂移：说着只输出JSON，它偏要加两句话

这是最高频的问题，没有之一。表现是十条里有那么一两条，输出前面多了“好的，以下是抽取结果：”，或者后面补一句“如需进一步帮助请告诉我”。原因一般是Prompt里没有把话说死，或者示例给得不干净。修法有三层：Prompt末尾再强调一次；示例里的输出只放纯JSON，一个多余字符都不放；代码层做正则清洗，把第一个左花括号到最后一个右花括号之间的内容截出来。三层叠加基本能压到千分之几。

还有一种更隐蔽的漂移是字段名变了。你定义的是order_id，它输出orderId或者订单编号。这种情况通常是schema描述不够明确，或者示例里的字段名跟定义不一致导致的。检查方法很简单，把你自己的Prompt从头读一遍，看字段名有没有在不同地方用了不同写法，模型对不一致非常敏感。

4.2 长文本下的“指令遗忘”

输入超过几千字之后，模型对开头指令的遵守度会下降，中间的指令容易被忽略，靠后的内容理解反而更好。这是注意力分布的正常现象，不用觉得是模型坏了。应对办法有三个：一是把核心约束挪到末尾重复一次；二是分段处理，长文本先切块抽取，再用代码合并结果；三是先做一次摘要压缩，把无关内容剔掉再送进去。第三种最省token，但摘要本身有信息损失的风险，抽取类任务要谨慎。

实际项目里我做合同关键信息抽取，一份合同八千多字，直接送进去字段漏得厉害。改成先按章节切块，每块单独抽取，最后合并去重，准确率从六十几直接上到九十以上。代价是调用次数变多，成本和延迟都得重新算，这就是个典型的工程取舍。

4.3 过度发挥与幻觉，怎么把它摁住

幻觉这东西没法彻底消灭，只能降低概率加事后拦截。降低的手段包括：温度压低、明确写“仅依据原文回答，原文未提及的填未知”、要求输出依据片段、把开放问答改成封闭选择。事后拦截就是在代码里做一致性检查，比如抽取出来的金额必须能在原文里找到对应的数字串，找不到就标红人工复核。这套“生成加校验”的组合拳，比单纯在Prompt里写“不要编造”有用得多，因为后者本质上是句空话。

4.4 常见问题速查表

注意：排查顺序永远是先看原始输出（raw），再看Prompt，最后才怀疑模型。我见过太多人跳过第一步，直接改Prompt，结果问题出在代码里的字符串拼接上。

5. 把Prompt当代码管：工程化落地的几个习惯

5.1 版本管理与变更记录

Prompt一定要进版本库，跟代码一起管。每次改动写清楚改了什么、为什么改、评测集通过率变化多少。这事儿听起来麻烦，但出问题的时候能救命。我经历过一次线上准确率突然掉，查了半天发现是有人优化了Prompt的措辞，本地测着没问题，没走评测集，结果某个边缘case全崩了。有变更记录，五分钟就能定位；没有的话，只能全量回滚重来。

版本号我用日期加序号，比如ticket-v3.2-0412，同时在代码里把Prompt版本写进日志，这样线上每条结果都能追溯到当时用的是哪版。评测结果也跟版本绑定，形成一张表，谁想改动先看历史数据，心里有数。

5.2 评测集怎么建才不糊弄自己

评测集最容易犯的错是“只收正常样本”。正常样本模型闭着眼睛都能过，测出来的准确率虚高，一上线遇到各种脏数据就露馅。我的建法是四类样本按比例配：正常表达占一半，口语化、错别字、信息缺失的占三成，一个输入里包含多个意图的占一成半，故意对抗的占半成。每条样本都要有人工标注的正确答案，标注标准要写成文档，避免不同人标得不一样。

规模上，单个任务五十到一百条就能看出趋势了，不用一上来就搞几千条，先把迭代速度跑起来。等Prompt稳定了，再扩样本做回归测试。评测跑批的时候记得固定seed和温度，不然两次结果不可比，白测。

5.3 成本与延迟的现实取舍

通义千问的几个档位在价格和效果上差异明显，小模型跑简单任务完全够用，大模型留给复杂推理。我的做法是先全量用小模型跑，把置信度低的那部分（比如模型自己都给了模棱两可的答案）挑出来，再用大模型重跑，这叫级联。实测下来整体成本能降一大截，效果损失很小。延迟敏感的场景更要注意，大模型的响应时间可能是小模型的好几倍，用户等不起的话，宁可牺牲一点准确率。

还有一个省钱的细节是缓存。同样的输入重复调用的情况在真实业务里很常见，尤其是那些模板化的工单和固定格式的表单，做个输入哈希缓存，命中率能到两三成，成本直接下来一块。

5.4 什么情况下该放弃调Prompt

这话可能不太讨喜，但确实存在。当失败原因主要是“原文信息不足”或者“任务本身定义不清”的时候，再怎么调Prompt都是徒劳。我遇到过一个需求，要从用户的一句话里判断他的情绪倾向，但用户说的话本身就中性到极点，比如“我的订单什么时候到”，这根本没有情绪可言。这种时候正确的做法是改需求、加数据源或者接受一个较低的准确率并配人工兜底，而不是在Prompt里死磕。

还有一种该放弃的情况是任务需要精确计算或者严格逻辑推理。模型在这类任务上靠的是模式匹配，不是真算，数字一多就容易错。这种活儿交给代码或者工具调用，模型只负责把参数抽出来，各干各的擅长的事。

最后分享个我一直在用的小习惯：每调通一个场景，就把那个最终版Prompt和对应的失败案例整理成一个小卡片存起来，标注清楚适用场景和不适用场景。攒到二三十张之后你会发现，新场景来了基本能找到可复用的骨架，改改字段定义就能上手，不用每次都从零开始。踩过的坑不会白踩，前提是你得把它记下来。