背景与问题
在把大模型接入真实业务时，很多团队首先遇到的是输出不可控：回答跑题、字段缺失、格式漂移、同一输入多次调用结果差异明显。提示词工程并不是寻找神秘咒语，而是把任务目标、输入数据、约束条件、示例和输出协议写成模型能稳定理解的形式。对于开发者而言，它更像一份面向概率系统的接口文档：既要描述业务意图，也要为异常、边界和解析成本做设计。
核心概念
系统提示
系统提示通常用于设定模型的角色、能力边界、语气、安全策略和输出规范。例如让模型扮演客服、代码审查员或数据抽取助手。好的系统提示应该明确“必须做什么、不能做什么、遇到不确定情况怎么办”。据公开资料，不同模型对系统消息的处理方式和优先级存在差异，生产环境请以官方文档为准，并通过回归测试验证。
Few-shot 示例
Few-shot 是通过少量示例告诉模型任务模式。它适合分类、实体抽取、情感判断、工单路由、内容改写等任务。示例不只是展示正确答案，更重要的是展示判断边界：正常样本、模糊样本、缺失样本、应拒绝的样本都可以放入示例中。示例越接近真实输入分布，模型越容易稳定复用。
结构化输出
结构化输出强调让模型返回程序可解析的结果，例如 JSON、固定字段列表、CSV 或带 schema 的对象。相比自由文本，结构化输出能显著降低后处理成本。实际工程中，可以要求模型只输出 JSON，并约定字段名、类型、枚举值和空值策略；如果模型平台提供函数调用、工具调用或 JSON Schema 约束，也可优先使用平台能力。
从工程角度看，三者可以组合：系统提示负责稳定人设和底线规则，Few-shot 负责校准任务格式与判断尺度，结构化输出负责对接下游程序。若只写一句“请帮我处理”，模型很容易在风格、字段和边界上漂移。
实践步骤与检查清单
- 先写任务说明：用一句话描述输入是什么、输出是什么、成功标准是什么。
- 拆分角色与规则：系统提示放长期稳定约束，用户消息放本次变量数据。
- 设计 Few-shot：从 2 到 5 个示例开始，覆盖典型场景和至少一个边界场景。
- 定义输出协议：明确字段、类型、必填项、枚举值，以及无法判断时返回什么。
- 控制上下文长度：只保留与当前任务相关的字段、示例和规则，避免无关信息干扰。
- 加入校验层：程序侧对返回内容做 JSON 解析、字段校验和重试，不要假设模型永远合法。
- 建立评估集：用固定样本衡量格式合法率、字段准确率、拒绝准确率和成本。
下面是一个简化的提示词结构示例，用于从用户反馈中抽取问题类型和紧急程度：
system: 你是工单分类助手。只输出 JSON，不输出解释。字段要求：category 为 bug、billing、account 或 other；urgency 为 low、medium 或 high；summary 不超过 20 字。user: 用户反馈：{feedback} assistant: {"category":"billing","urgency":"medium","summary":"重复扣费"}这个示例的用途是把角色、输出字段、枚举值和示例放在同一个可测试模板中。实际使用时，{feedback} 可由程序替换为真实文本，再对返回 JSON 做 schema 校验。
常见坑与建议
- 指令互相冲突：例如同时要求“极简回答”和“详细列出所有依据”。应明确优先级，必要时分阶段输出。
- 示例过度理想化：如果 Few-shot 全是干净输入，模型遇到噪声文本容易失效。建议加入脏数据、短文本和歧义样本。
- 只靠提示词防注入：系统提示不能替代安全层。用户输入可能包含“忽略之前指令”等内容，需配合输入过滤、权限隔离和输出校验。
- 忽视采样参数：抽取、分类、结构化任务通常更适合较低随机性，创意生成可适当放宽。不同平台参数名称和效果不同，请以官方文档为准。
- 把长提示当万能方案：规则过多会稀释重点。可把稳定规则放系统提示，把动态数据放用户消息，并用小标题或分隔符组织内容。
- 没有失败回退：当模型返回非法 JSON 时，应记录原始响应、触发重试、降级到人工或规则解析。
- 评估指标缺失：仅凭主观感觉判断提示词好坏，容易在模型升级后失效。建议记录每次提示词版本、测试集结果和线上坏例。
延伸阅读方向
在掌握基础提示词工程后，可以进一步关注上下文工程、RAG 检索增强、Agent 工具调用、模型评估体系、提示词版本管理、缓存与成本控制，以及提示注入防护。若团队准备上线生产系统，建议把提示词当作代码资产：纳入版本控制、单元测试、灰度发布和线上监控。这样，提示词工程才能从单次调优变成可持续迭代的工程能力。
参考来源
免责声明：本文内容整理自公开网络资料，仅供学习交流参考，不代表观山书院立场。如涉及版权侵权，请联系我们删除。
联系邮箱：chenxj.g@gmail.com