提示词即规格：如何把大模型抽取系统做成可控工程

在大语言模型（LLM）驱动的结构化信息抽取项目中，一个反直觉但至关重要的事实是：提示词的质量，往往比模型本身更能决定项目的成败上限。

很多人把精力放在选更强的模型、堆更多的算力、写更复杂的后处理逻辑上，却忽略了最根本的问题：你是否清晰地定义了任务？

如果你的任务边界模糊、规则抽象、示例不足，那么无论用 GPT-4 还是 Claude 3.5，结果都会在“看似合理”和“完全错误”之间随机游走——这正是许多 LLM 抽取项目难以落地的核心原因。

本文基于一个典型的多任务自由文本结构化项目（从非结构化段落中提取多个预定义字段），系统总结我们在提示词设计上的三次关键演进，并提炼出一套可复用于各类“文本 → 结构化数据”场景的工程实践。全文不涉及任何具体行业、业务或敏感信息，只谈方法论。

---

一、为什么提示词决定了系统上限？

自由文本天然具有以下挑战：

• 事件杂糅：一段话可能同时包含背景、计划、否定、已发生动作等多个语义层；
• 时间密集但归属模糊：大量时间短语并不属于目标事件，而是描述其他上下文；
• 语气复杂：否定（“未执行”）、建议（“可考虑”）、停用（“已停用”）、推测（“可能为”）等会直接影响“是否应抽取”；
• 表达不规范：省略主语、跨句指代、插入单位/频次/括号等，干扰字段边界判断。

在这些情况下，模型的理解能力不是瓶颈——真正决定成败的是你是否把任务转化成了一个足够清晰、可执行、可模仿的约束系统。而这个系统的载体，就是提示词。

换句话说：

不是模型能不能理解文本，而是你有没有把“理解什么、忽略什么、怎么输出”讲清楚。

---

二、提示词的三阶段演进

我们经历了从“规则完整”到“边界可执行”，再到“判例驱动”的三次关键迭代。

V1：基础规则版 —— “知道要做什么”，但“不知道怎么做”

特点：

• 字段定义完整，输出格式明确；
• 禁止项以清单形式列出（如“不要提取背景时间”）；
• few-shot 示例较少，且偏向干净、理想化的输入。

问题：

• 对边界情况仅做原则性描述（如“时间必须属于目标事件”），但未提供可操作的判断标准；
• 模型在遇到模糊输入时，会用自己的“常识”补全逻辑，导致行为不一致；
• 输出常夹带解释文字、漏括号、字段错位，导致 JSON 解析失败，结果“蒸发”。

典型表现：看到“2023-10 停用 X”，仍把“2023-10”填入时间字段；看到“未执行 Y”，仍输出一条空字段记录。

V2：边界规则强化版 —— 把“原则”转化为“硬性触发条件”

核心思想：让规则可执行，而非可解释。

典型做法：

• 时间归属：明确“时间必须直接修饰目标动作动词（如‘执行’‘采用’‘实施’），否则不提取”；
• 停用/停止：规定“出现‘停用’‘终止’等词时，时间字段必须为空”；
• 否定语义：定义否定触发词集合（如“未”“拒绝”“未予”），并规定“整条记录跳过，不输出”；
• 中心词约束：强调“若所有核心字段均为空，则返回空数组”。

效果：

• 误报率显著下降（precision ↑）；
• 行为一致性大幅提升；
• JSON 可解析率提高（减少因格式错误导致的“静默丢失”）。

代价：

• 少量边缘案例可能被过滤（recall ↓），但在强一致性要求的场景中，这是值得的权衡。

V3：示例增强版 —— 用“判例”定标，让模型“照着做”

最大发现：few-shot 的影响力经常大于规则文本。

原因在于：

• 规则是抽象的“法律条文”，模型需自行映射到具体行为；
• few-shot 是“输入 → 输出”的直接映射，模型更倾向于模仿其格式、拆分策略和决策边界。

V3 的关键实践：

• few-shot 覆盖真实线上分布：更长、更杂、包含多重嵌套、模糊指代、混合语义；
• 明确展示拆分逻辑（何时多行、何时合并）、留空策略（哪些字段可空）、跳过条件（否定/无核心信息）；
• 正例 + 反例结合：例如，专门设置一个“背景时间 + 目标动作”但时间字段为空的反例。

重要原则：当规则与示例冲突时，模型更信示例。因此，示例必须高精度、无歧义、与规则严格一致。

---

三、高频错误的工程化解法

以下是三类典型错误及其在提示词中的“硬编码”解决方案：

错误类型	问题表现	工程化修复
时间错挂	背景事件的时间被误挂到目标动作上	明确“时间必须紧邻或直接修饰目标谓词”，并在 few-shot 中展示反例（时间存在但输出为空）
停用误提	“停用方案X”被当作一次有效执行，时间被提取	写死规则：“停用/终止 → 时间字段必须为空”，并在示例中体现
否定误报	“未执行方案Y”仍输出一条记录（部分字段为空）	定义否定触发词集，规定“出现即整条跳过”，并在示例中展示空数组输出

这些修复不是靠“更聪明的模型”，而是靠更精确的任务定义。

---

四、通用输入/输出伪例（模拟真实复杂场景）

【输入文本】

6个月前客户反馈系统响应慢（背景事件）。随后于2023-11-15部署了新缓存模块。上线后运行稳定，但因兼容性问题，于2024-01停用该模块。另记录：团队未按计划实施数据库迁移，故性能未达预期。

【期望输出】

[
  {
    "执行日期": ["2023-11-15"],
    "方案名称": ["新缓存模块部署"],
    "状态评估": ["运行稳定"]
  },
  {
    "执行日期": [],
    "方案名称": ["新缓存模块"],
    "状态评估": []
  }
]

解释：

• “6个月前”是问题反馈时间，非部署时间，不提取；
• “停用该模块”只保留方案名称，执行日期为空（因停用时间 ≠ 执行时间）；
• “未按计划实施数据库迁移”含否定词“未”，整条跳过；
• 同一段落包含多个独立事件，按中心词拆分为多行。

注：字段名（如“执行日期”“方案名称”）仅为示意，实际项目中可根据业务自定义。

---

五、提示词即“可测试的规格说明”

为了可持续迭代，我们建议将提示词当作工程规格文档来维护：

1. 结构化写作模板

• 字段定义：简短、准确、可判定（避免“相关”“有关”等模糊词）；
• 字段关系：明确挂靠方向（如“时间 → 方案”）；
• 核心原则：如“核心字段不能为空”“无信息则空数组”；
• 输出格式：严格 JSON，字段顺序固定；
• 重要规则：拆分逻辑、独立性判断、边界语义；
• 禁止规则：用优先级列表，避免互相冲突；
• few-shot：覆盖典型 + 边界 + 反例。

2. 强约束表达技巧

• 使用绝对化措辞：“必须”“绝对不能”“整条跳过”；
• 采用“触发词集合 + 结论动作”模式：
  出现 {未, 拒绝, 未予} → 不输出记录

3. 迭代闭环机制

• 从质检中聚类错误模式（而非单字段错误）；
• 每次只修复 1–2 个模式，避免规则膨胀；
• 新规则必须配套正/反 few-shot；
• 建立示例回归审查：确保新示例与现有规则一致、边界清晰。

---

六、结语：核心资产是提示词与样例集

在这个项目中，我们最终意识到：

代码提供了可扩展的流水线（配置驱动、模块复用、导出与质检），但真正决定抽取质量的，是提示词的可执行性与 few-shot 的覆盖度与准确度。

当你把提示词和样例当成“可测试的规格”，持续迭代、持续回归，你就能把一个易漂移的 LLM 抽取系统，做成一个可控、可维护、可解释的工程系统。

在 LLM 应用落地的早期阶段，提示工程不是“调参技巧”，而是系统设计的核心环节。它值得被认真对待、规范管理、持续优化。

---

附：可复用的 few-shot 设计 Checklist

• 覆盖主要业务场景（典型输入）
• 包含边界案例（否定、停用、模糊时间）
• 包含反例（应跳过但易误提的情况）
• 输出格式严格一致（字段顺序、空列表表示）
• 避免使用歧义词或缩写（除非业务允许）
• 每个示例只聚焦 1–2 个关键规则