背景与问题：提示词不是聊天，而是接口设计

很多团队第一次接入大模型时，常会遇到一种落差：模型能力看起来很强，但一落到业务里就表现不稳。要么回答过于宽泛，要么格式无法解析，要么在边界条件下跑偏。表面上看是模型不够聪明，实际上更常见的原因是提示词没有把任务目标、输入约束、输出格式和失败处理说清楚。

观山静思
观山静思

从工程视角看，提示词不是简单的一句话，而是一段给模型执行的轻量协议。它需要像 API 文档一样明确：角色是谁、输入是什么、输出长什么样、哪些内容不能做、遇到不确定情况如何处理。系统提示、Few-shot 示例和结构化输出，正是这套协议里最常用的三个抓手。

核心概念：三类技巧分别解决什么问题

1. 系统提示：稳定角色、风格与边界

系统提示通常用于设定模型的整体行为框架。相比用户每轮输入，它更适合放长期不变的规则，例如角色定位、语气风格、安全边界、输出偏好和工具调用约束。一个常见的误区是把系统提示写成空泛口号，比如「你要专业、准确、简洁」。这类描述并非无效，但缺少可执行标准。更稳妥的写法是把要求拆成模型能遵循的动作。

例如，与其写「请专业地回答」，不如写「你是一名技术文档编辑，回答前先判断用户问题是否属于前端工程；如果信息不足，只提出最多三个澄清问题；不要编造未提供的依赖版本」。这类提示的好处是降低了模型自由发挥的空间，也便于后续做回归测试。

2. Few-shot：用示例校准格式与判断尺度

Few-shot 并不是简单堆例子，而是通过示例告诉模型：什么样的输入应该产生什么样的输出。它特别适合分类、抽取、改写、评审、意图识别等任务。示例的价值有两个：一是格式校准，二是边界校准。格式校准让模型知道字段、顺序、长度和语气；边界校准让模型知道遇到模糊输入时应该归为哪一类，或者是否应该返回空值。

在实际项目中，Few-shot 示例不在多，而在有代表性。建议优先选择三类样本：标准样本、边界样本和容易误判的样本。标准样本用于建立基本格式，边界样本用于定义模糊地带，误判样本用于纠正常见错误。若示例之间规则冲突，模型很容易学到不稳定模式。

3. 结构化输出：让结果可解析、可校验、可入库

当提示词进入生产系统，输出往往不能只是自然语言，而需要是 JSON、表格、枚举字段或固定模板。结构化输出的核心不是让模型「输出 JSON」这么简单，而是要把 schema、字段含义、取值范围和缺省策略写清楚。很多失败案例并不是模型不会 JSON，而是提示词没有说明当字段缺失时应该填 null、空字符串还是省略字段。

据公开资料，主流大模型普遍支持通过提示约束或官方结构化输出能力降低格式错误率，但不同模型对 JSON Schema、函数调用和响应格式的支持程度不同，请以官方文档为准。工程上建议始终保留一层服务端校验，不要把模型输出直接当作可信数据。

实践步骤：一套可落地的提示词设计清单

  • 明确任务类型：先判断是开放生成、信息抽取、分类决策还是代码生成。不同类型适合不同提示策略。
  • 写清输入来源：告诉模型哪些内容来自用户输入，哪些来自系统上下文，哪些不可信。必要时用标签隔离数据与指令。
  • 定义输出契约：明确字段名、类型、长度、枚举值、是否允许为空，以及失败时返回什么。
  • 加入最少必要示例：先给 2 到 4 个高质量示例，覆盖正常、边界和异常场景。
  • 设置拒绝与兜底策略：例如「如果无法从给定资料中提取，返回 empty: true，不要猜测」。
  • 做回归测试：准备固定测试集，每次改提示词都对比输出变化，避免局部优化导致整体回退。

下面是一个用于工单分类的结构化提示示例。它把系统角色、输入区域、Few-shot 示例和 JSON 输出要求放在同一模板中，便于程序拼接与后续维护。

system:
你是工单分类助手。请只根据用户提供的工单内容进行分类，不要推测未给出的信息。
输出必须是合法 JSON，字段包括：category, urgency, reason。
category 只能是 account、payment、bug、other。
urgency 只能是 low、medium、high。
如果信息不足，将 category 设为 other，并把 reason 写清楚。

示例 1：
输入：我无法登录，提示密码错误，但重置邮件收不到。
输出：{"category":"account","urgency":"high","reason":"登录受阻且重置邮件异常"}

示例 2：
输入：页面按钮点击后没有反应，控制台有 500 错误。
输出：{"category":"bug","urgency":"medium","reason":"功能不可用并伴随服务端错误"}

用户输入：
{{ticket_content}}

这个示例的重点不是 JSON 本身，而是它把「不要推测」「枚举值」「信息不足怎么办」都写成了可执行规则。对程序来说，这类输出更容易被校验和路由。

常见坑与建议

  • 只写目标，不写约束：比如「帮我总结」却没有说明长度、读者对象和是否保留风险项。建议把验收标准写进提示词。
  • 示例过多且互相矛盾：示例太多会挤占上下文，也会放大噪声。优先保留能改变模型判断的样本。
  • 把不可信输入直接混入指令：用户输入可能包含诱导或注入内容。建议用明确标签包裹外部文本，并声明其中的指令无效。
  • 过度依赖模型自觉：生产环境应加 JSON Schema 校验、字段清洗和重试机制。模型输出只能作为候选结果。
  • 忽视模型差异：同一提示词在不同模型上表现可能差异明显。切换模型前应重新评测，不要默认迁移。
  • 提示词一次写死：提示词应像代码一样版本化管理，记录变更原因、测试集和效果指标。

延伸阅读方向

  • 上下文工程：研究如何在有限 Token 内组织系统提示、检索资料、历史对话和工具结果。
  • 结构化输出与函数调用：关注各模型官方 JSON 输出、工具调用和响应格式能力。
  • 提示词评测：建立黄金样本集、自动评分器和人工抽检流程。
  • 安全与注入防护：了解提示注入、越权诱导、敏感信息泄露等风险及缓解策略。
  • RAG 与知识边界：当任务依赖私有知识时，需要结合检索、引用和置信度控制。

参考来源

免责声明：本文内容整理自公开网络资料，仅供学习交流参考，不代表观山书院立场。如涉及版权侵权，请联系我们删除。

联系邮箱：chenxj.g@gmail.com