Qwen结构化Prompt实战：信息抽取格式稳定与输出可控指南

把同一个任务分别用一段话交代的“自然语言 Prompt”和带格式标记的“结构化 Prompt”跑在不同 Qwen 模型上，效果能差出多少？我一开始也觉得不会差太多，直到一次线上事故让我彻底改变看法。那次我负责一个模拟项目的客服工单信息抽取，模型用的是 Qwen 系列，Prompt 写得像给同事发消息一样自然，结果输出格式三天两头变，解析脚本跟着改到崩溃。后来把 Prompt 改成分节的 JSON 模板，同一个模型、同一批数据，输出稳定得可怕。这篇文章就把我这段时间反复对比的结构化 vs 自然语言两种 Prompt 风格，拆开揉碎讲清楚：为什么 Qwen 对结构这么敏感，什么场景该用哪种，以及那些让结构化 Prompt 翻车的典型案例。

如果你正在用 Qwen 系列模型做文本抽取、分类、格式化输出，或者被模型“不听话”的格式问题折磨过，这篇文章应该能给你一些直接能用的思路。我会先复盘那次事故，再从模型机制层面推测结构差异的根源，然后用一套可控的对比实验给出分任务的数据结论，最后把我踩过坑之后的 Prompt 工程套路完整拿出来。

1. 一次让我开始较真 Prompt 结构的线上事故

先说事故背景。当时系统要从用户的售后留言里抽三个字段：问题类型、涉及商品 SKU、用户期望的处理方式。最初版本我写的 Prompt 基本是这么个风格：用一大段自然语言告诉模型“请你阅读下面的用户留言，然后帮我判断这是售后哪个类型的问题，如果提到了商品编号就提取出来，最后总结一下用户想要我们怎么做”。听起来没毛病，人完全能听懂，但 Qwen 的实际输出五花八门。

有时候模型规规矩矩返回三段文字；有时候自作主张加一句“根据您的要求，我进行了分析”；还有时候把字段名改了，比如我让它输出“expectation”，它偏要写“用户期待”。最要命的是偶尔它会输出一段 Markdown 表格，或者对整个留言做一段总结。我这边负责解析的同事天天问“到底还有多少种格式”，那段时间光写正则和异常分支就花了一个迭代。

后来我被逼着重新读了一遍模型文档和社区里的 Prompt 经验，一时兴起把 Prompt 改成了结构化版本。核心思路是：把角色设定、输入数据、输出格式、注意事项分别用 XML 标签隔开，输出部分直接给出 JSON 骨架，字段名写死，甚至把期望输出的样例也放进去。改完之后第一轮测试，50 条样本 49 条输出都是合法 JSON，字段名一个没跑偏，解析代码几乎不用动。

这个反差让我开始认真思考一个问题：同样一个模型，为什么换了下 Prompt 的外壳，表现就差这么多？为了不被“碰巧”骗了，我后面专门腾出时间做了系统性对比实验。先把当时事故里的几个关键观察列出来：

• 自然语言 Prompt 下，Qwen 会把“格式要求”和“语义内容”混在一起处理，一旦源文本里有类似结构的内容（比如留言里也有 JSON 片段），模型容易跟着跑偏。
• 结构化 Prompt 下，模型能更清楚地区分“这是指令”“这是数据”“这是输出样式”，格式指令对生成过程的影响更稳定。
• 只要输出模板里稍微给一个具体示例，模型往示例格式上靠的倾向非常明显，几乎不需要再写什么“不要输出别的内容”这类强约束。

先说清楚我理解的两个概念，免得后面混淆。自然语言 Prompt 就是用完整的句子、段落向模型描述需求，像和真人沟通；结构化 Prompt 则借助 JSON、XML、Markdown 标题、编号列表等格式元素，把提示词拆成职责明确的区块。我后面所有实验都基于这个定义展开。

那段事故经历最让我意外的是：我原本以为“说的越清楚越好”，但人类的“清楚”和模型的“清楚”不是一回事。人喜欢连贯的段落，模型却更适应边界分明的块状信息。后面我仔细看了输出 token 的分布才隐约感觉到，模型在处理自然语言大段落时，注意力很难稳定落在“输出格式”这几个句子上；而结构化格式标记就像给它沿途插了路标，每一步生成都更知道当前该走到哪个位置。

2. 结构化与自然语言到底差在哪：Qwen 的指令跟随路径拆解

要理解 Prompt 结构对 Qwen 的影响，不能只停留在“结构化更好用”这种经验层面。我试着从模型处理文本的机制角度拆一下，虽然不能保证完全准确，但对调 Prompt 的指导意义很大。

模型读入 Prompt 时，本质上是在把整段文本切成 token 序列，然后通过自注意力机制让每个位置的 token 都能“看到”其他位置的 token。但这不代表所有位置的约束作用一样。实践中我发现，Qwen 对靠后的指令内容往往跟随得更紧密，对开头部分的角色设定更多作为背景信息来参考。这也符合很多大模型共有的“近因偏差”。自然语言 Prompt 喜欢把输出格式要求放在末尾的大段文字里，虽然位置靠后，但这段要求混在语气词、补充说明、边界情况描述里，约束信号被稀释；结构化 Prompt 则会把输出格式单独拎出来，用代码块或者 JSON 骨架放在最后，格外显眼。

再往细里说，Qwen 系列的指令跟随有一个特点：它对“形态完整”的格式约束特别敏感。注意我用的词是“形态完整”，不是“语义完整”。什么意思呢？假设你在 Prompt 里放了一个 JSON 对象骨架：

json复制{
  "category": "",
  "sku": "",
  "expectation": ""
}

模型在生成时看到的是一个完整的、闭合的 JSON 形态，即使值为空，它也能推断出接下来应该填什么类型的值。它后续生成的 token 会顺着这个形态走，不太容易突然跳到“好的，我帮你分析一下”这种自然语言上去。反过来，如果在 Prompt 里只写“请输出一个 JSON”，没有给形态，模型就需要在生成过程中自行脑补 JSON 长什么样，脑补出来的结构自然容易跟你想要的不一致。

另一种合理的推测与 Qwen 的分词和特殊 token 机制有关。现代指令模型的对话模板里其实有不少隐藏的特殊 token，用来标记系统、用户、助手这些角色边界。Qwen 对这类“边界信号”是有专门建模的。结构化 Prompt 等于在用户消息内部又套了一层层显式边界，相当于把角色边界放大到内容层面。模型在处理时更容易把“这是输入数据”和“这是输出要求”当成两个不同的处理对象，而不是揉在一起的一段话。

我用一个生活化的类比。自然语言 Prompt 像是口头交代别人干活：“你去把仓库收拾一下，顺便看看有几个纸箱，注意别弄坏了，纸箱要数清楚，回头告诉我。”人听了知道重点是数纸箱，但理解过程要绕一下。结构化 Prompt 像是给了一张表单，上面写着“仓库物品：；纸箱数量：；损坏情况：____”。表单一递过去，对方不用猜你重点在哪，填就行。Qwen 也是更吃表单这一套。

不过，这里必须泼一盆冷水：结构化并不是在所有情况下都更好。它让格式更稳定，但也可能压缩模型的自由发挥空间。遇到开放式任务，比如写摘要、写文案、头脑风暴，过于强硬的 JSON 结构反而可能让内容变得僵硬、漏重点，甚至和指令冲突。我后面实验里的数据也验证了这一点。

为了直观对比，我把两种 Prompt 在几个维度上的差异整理成了表格：

这张表基本概括了我要表达的核心差异。但理论归理论，我很好奇这些差异在真实任务上到底能拉开多大差距，于是设计了后面那套对比实验。

3. 同题对比实测：我的实验设置与完整复现步骤

光靠事故里的观察下结论不科学，我决定把实验做得可控一点。我选了五类常见任务，每一类分别写自然语言和结构化两版 Prompt，在同一个 Qwen 模型上跑同样的输入，比较输出效果。

实验用到的模型是 Qwen 系列里的一个开源 instruct 版本，具体到部署方案是之前团队搭好的内部推理服务，温度固定 0.3，top_p 0.9，最大输出长度 1024，其他采样参数保持默认。需要说明的是，这是一个基于常见实践的实验配置，不是唯一标准；温度低一点是为了减少随机性，让对比更公平。

五类任务分别是：

1. 意图分类：给一句用户输入，判断是“咨询”“投诉”“表扬”还是“无关”。
2. 信息抽取：从一段人物介绍里抽取姓名、公司、职位、城市。
3. 摘要生成：把一段产品功能描述压缩成三句话。
4. 多选项问答：给一个问题带四个选项，输出正确答案的字母。
5. 代码生成：用自然语言描述需求，让模型生成一段 Python 函数。

每种任务我都准备 50 条测试样本，用规则脚本加人工复核的方式评估。指标主要看四个：输出格式合规率、关键字段准确率、语义准确率（由人工判断内容对不对）、平均输出 token 数。

两类 Prompt 的构造逻辑必须说清楚。自然语言版我尽量写得像真实工程师会写的那种“口语化清楚指令”，不刻意写得差，也不过度优化；结构化版则用清晰的区块和模板，典型骨架是：system 段给角色、user 段开头用 XML 标签包住输入数据、最后放 JSON 输出骨架和一条示例。

为了方便你复现，我放一个简化版的信息抽取 Prompt 示例，语言是 Python 里的 f-string 写法，但用不到任何具体 SDK 函数，只展示字符串构造逻辑：

python复制natural_prompt = f"""
请阅读下面的用户介绍，提取出这个人的姓名、公司、职位和所在城市。
如果某个信息没有提到，就不要填。
介绍内容：{source_text}
输出格式：请用JSON格式输出，包含name, company, title, city四个字段。
"""

structured_prompt = f"""
<task>
你是信息抽取助手。从<source>中提取实体字段。
</task>

<source>
{source_text}
</source>

<output>
请严格按以下结构输出JSON，未提到的字段填null，不要编造。

{{
  "name": "",
  "company": "",
  "title": "",
  "city": ""
}}
</output>

<example>
输入："张三在杭州的某科技公司担任算法工程师。"
输出：{{"name": "张三", "company": "某科技公司", "title": "算法工程师", "city": "杭州"}}
</example>
"""

这里有个细节：示例放在 output 区块之后，也就是整段 Prompt 的最末尾。我这样安排是有意的，因为前面提过模型对靠后的格式示例更敏感，让它最后“看一眼”正确输出形态，再开始生成，格式跟随会明显变好。

完整实验流程分成三步。第一步，把 50 条样本和两种 Prompt 模板分别组合，批量调用推理服务，保存原始输出。第二步，写一个校验脚本，对输出做 JSON 解析检查格式合规率，并提取关键字段；解析失败的样本自动标记为格式违规，不参与字段准确率统计。第三步，让我和另一位同事分别抽 20 条做人工语义判断，两人独立打分，有分歧再讨论。

跑完之后统计结果的范围，我每个任务至少重复了三轮，发现结论方向稳定，具体的百分比有轻微浮动，所以下面所有数字我给的是多次测试的平均范围，不追求实验室级别的精确。

如果你想把这套实验复现到自己的场景里，有几个容易忽略的注意点。第一，Prompt 模板里的示例要和真实测试样本的难度一致，示例太简单会高估模型能力，示例太难会让模型被带偏。第二，两个版本的 Prompt 都要写到自己认为“已经够用”的程度，不要刻意把自然语言版写得很烂，那样对比出来的结论没有参考价值。第三，固定除 Prompt 结构外的所有变量，包括温度、输入顺序、模型版本。第四，别只看格式合规率，一定要加人工语义评估，因为可能出现模型输出了标准 JSON 但内容全错的情况。

4. 分任务拆结果：什么时候结构化完胜，什么时候自然语言更稳

实验数据跑完，我把各任务的对比结果整理成一张表。先看整体，再逐个拆。

数字本身已经说明很多问题，我逐个解读一下。

信息抽取和意图分类是结构化 Prompt 的绝对主场。信息抽取任务里，自然语言版本格式合规率只有 72%，也就是说 100 条输出里有 28 条需要人工修复或重新请求；结构化版本直接把合规率拉到 99%，字段准确率也从 70% 提到 94%。这个提升幅度在工程上是质变，意味着解析管道可以大幅简化，不需要处理几十种异常格式。意图分类影响稍小，是因为输出本身可以限定在几个枚举值里，即使格式乱一点，语义还容易识别。

摘要生成出现了一个有意思的反转：结构化版本的格式合规率更高，但语义准确率反而低了。我看了具体输出，发现问题出在结构化约束太“压榨”内容空间。模型为了硬凑 JSON 里的三个字段，把摘要拆成三个独立句子，每句只讲一个点，结果重要细节经常被漏掉。自然语言版本没有字段束缚，模型反而能组织出更流畅、重点更全的摘要。这个发现很重要：结构化不能无脑用，它更适合“字段型”任务，不适合“内容型”任务。

多选项问答两种 Prompt 表现几乎持平，语义准确率都是 90%。原因也好理解：这类任务输出空间极小，本来就接近“选字母”的封闭式问题，格式要求简单，结构化的优势体现不出来。代码生成任务更是彻底翻转，结构化版本编译通过率和功能正确率都低于自然语言版本。我猜测是因为结构化 Prompt 把代码需求拆碎后，模型容易把需求当成数据字段去“填充”，而不是当成一个整体目标去“设计”，生成的代码变得机械甚至残缺。

这组结果让我形成了一个比较清晰的判断框架。判断一个任务适不适合上结构化 Prompt，核心问题就两个：输出形态是否需要字段化？格式一致性是否比内容自由度更重要？如果两个答案都是“是”，果断用结构化；如果输出天然是一段文本、需要模型发挥理解和重组能力，继续保持自然语言的写法可能更稳妥。

实验里我还发现一个混合策略值得推荐。最稳定的做法不是二选一，而是“自然语言指令 + 结构化输出约束”。具体来说，用自然语言段落把任务目标、背景、注意事项讲清楚，让模型充分理解上下文；然后在输出阶段强制给一个 JSON 或 XML 模板。这样既避免了纯结构化带来的语义损失，又保住了格式合规性。后续我在信息抽取以外的不少任务里都用这个组合，效果好于只用其中任何一种。

5. 三种典型翻车现场：结构化 Prompt 不是万能药

实验结论清晰之后，我以为自己再也不会被 Prompt 坑到了，结果很快就被现实教育了。结构化 Prompt 在落地过程中遇到的新问题，比自然语言版的“格式乱”更隐蔽，也更难排查。我把三种最典型的翻车情况拆开讲，每个都带上完整的排查链路。

第一种是“字段强行填充”问题。我给抽取任务设计了一个 JSON 模板，里面包含五个字段，但源文本经常只涉及其中三个。模型明明没找到对应信息，还是大笔一挥填了个“未知”或者“无”，而不是按我预期填 null。看起来格式合规了，字段值却污染了后续统计。排查时我先拿了 10 条 badcase，发现凡是源文本里缺字段的输出，模型都倾向于补一个词进来，原因是我在 Prompt 里写了“请包含以下字段”，这让它认为每个字段必须有非空值。修复方法是在输出说明里加一句明确规则：字段缺失时只允许填 null，禁止写解释。改完再跑，字段准确率立刻回到正常水平。

第二种是“示例反噬”问题。我当时为了提升效果，在结构化模板里塞了五个 few-shot 示例，每个示例都是长篇的输入输出对。结果模型非但没学好，反而被最后那条示例的细节带偏，大量输出模仿示例的用词风格，甚至出现了示例里才有的实体名称。排查时我逐步减少示例数量，从五个减到三个再到一个，发现从三个降到两个时效果就明显改善了。最后我确定：示例不需要多，但要精准。保留一条和当前输入最接近的示例，放在 Prompt 的最末尾，比堆五条乱七八糟的示例有效得多。

第三种是“嵌套过深导致截断”问题。为了应对一个稍微复杂的业务，我把输出结构设计成了三层 JSON 嵌套，内部还放了一个数组。模型前两条输出正常，后面开始频繁截断，不是少个右括号，就是数组只输出一半。一开始我怀疑是上下文长度不够，检查后发现输入明明很短，问题出在嵌套层级高，生成时模型要维持的内部状态太多，越到后面的括号越容易“迷路”。修复方案是打平结构：把三层 JSON 改成两层，数组拆成独立字段，并在 Prompt 末尾加上“输出必须是一个完整 JSON 对象”的提示。效果立竿见影，截断率明显下降。

从这三个翻车案例里，我提炼了一条通用排查链路。拿到 badcase 后，不要急着改措辞，先做三件事：第一，单条复现，确认是不是随机性问题；第二，逐步删减结构化片段，每删一个区块就重新跑一次，定位是哪个区块引发了问题；第三，针对定位结果做修复，通常不是加强约束就是解除约束。如果删到只剩纯文本 Prompt 时问题依然存在，那说明问题根本不在结构，可能出在模型能力、输入数据质量或者预算设置上。

结构化 Prompt 的常见翻车可以被归纳成一句话：结构是给模型划的边界，但边界太多太密，模型也会被绊倒。合理的结构层级一般不超过三层，关键约束数量保持在五条以内，示例控制在两条左右。过度设计结构化 Prompt，和写自然语言 Prompt 时啰嗦半天，本质上是同一个错误。

6. 落到日常工程里：我给 Qwen 配 Prompt 的几个固定套路

经历完前面所有折腾，我最终沉淀出一套固定的 Prompt 配置方法。没有放之四海而皆准的模板，但有几个通用套路可以分享。

第一，人机职责先分清楚。System 消息里固定放角色、工作背景、全局性约束，不要在 System 里塞具体输入数据；User 消息里放任务区块和输入数据。Qwen 对 System 和 User 的边界建得很明确，混乱放会削弱指令效力。

第二，核心结构用“任务块 + 数据块 + 输出块”三明治布局。任务块用自然语言写清楚要做什么，允许补充背景；数据块用 XML 标签或 Markdown 引用块包住，避免和任务指令混在一起；输出块放格式化骨架和示例。最早事故里的信息抽取需求，我用这套布局后基本没再翻过车。我给一个通用模板，你可以直接抄走改成自己的：

text复制<task>
你是{角色}。你的任务是{todo}。
注意：{关键注意事项，不超过3条}
</task>

<data>
{输入文本或结构化数据}
</data>

<output>
请按照以下结构输出，缺失信息写null，不要编造：
{{JSON骨架}}
</output>

<example>
{一条最接近真实场景的示例}
</example>

第三，对不同的 Qwen 模型规模要区别对待。我是从实际使用中发现的：小尺寸模型（比如 7B 级别）对结构的依赖明显更强，结构化 Prompt 带来的格式合规收益更大，但同时它对嵌套结构也更脆弱，层级一定要压扁；大尺寸模型对自然语言的理解更充分，可以适当减少结构占比，多给一点语义自由度，但输出骨架依然是保底利器。这个规律在实验里反复出现过，建议你也按自己用的模型尺寸做一轮小验证。

第四，把“两步式”技巧用起来。遇到复杂任务，我会让模型先输出一个简短的思考草稿，再按结构化模板生成最终结果。这个做法本质上是在一个请求里完成“理解”和“格式化”两件事。对 Qwen 系列模型来说，草稿部分写在最终输出之前，既不影响格式合规，又能明显提升字段内容的准确性。代价是多消耗一点输出 token，但换来的是稳定性和质量，我觉得值得。

第五，也是最重要的，建立自己的 Prompt 回归集。不要每改一版 Prompt 就手动试几条，而是攒一批有代表性的输入，每次调整后统一跑一遍，自动检查格式合规率和关键字段命中率。这套回归集让我后续改 Prompt 的胆子大了很多，不用担心改一处崩一片。哪怕一开始只有二十条样本，也好过全凭感觉。

我常用的结构化 Prompt 版本在实际业务里服务的并不是高深任务，大部分就是信息抽取、字段补齐、意图判断这些活儿。把这些基础任务的结构定死，工程上的稳定性自然就来了。如果你正在给 Qwen 系列模型写 Prompt，我建议先把我前面那个三明治模板跑一遍，观察格式合规率的变化，再根据你自己的任务特点迭代。

最后再分享一个实际操作中的体会。Prompt 结构不是非黑即白的选择题，而是一条频谱：一端是纯自然语言，一端是强 JSON 模板，中间有无数种混合方式。我会根据任务对“内容自由度”和“格式一致性”的需求，在频谱上挑一个合适的点。这个判断能力来自大量 badcase 的积累，没有捷径，但前面说的回归集能帮你把判断周期从几天压缩到几小时。