id, title, type, domain, stack, tags, level, prerequisites, est_hours, related, week, order
| id |
title |
type |
domain |
stack |
tags |
level |
prerequisites |
est_hours |
related |
week |
order |
| ai.prompt-engineering.prompt-structured-output |
提示词结构、少样本、结构化输出和提示词版本管理 |
lesson |
ai |
|
| 提示词结构 |
| 少样本 |
| Few-shot |
| 思维链 |
| 结构化输出 |
| JSON Schema |
| 提示词版本 |
|
basic |
|
2.5 |
| ai.prompt-engineering.context-injection |
| ai.langchain.lcel-structured-agent |
| ai.prompt-engineering.interview |
|
|
1 |
提示词结构、少样本、结构化输出和提示词版本管理
解释说明
一个可维护的提示词结构
| 部分 |
写什么 |
| 角色和背景 |
你是谁、服务谁、业务背景 |
| 任务 |
要完成什么,成功的标准是什么 |
| 规则 / 约束 |
能做什么、不能做什么、资料不足时怎么办 |
| 输入数据 |
用标签(<documents>、<ticket>)包裹,和指令分开 |
| 示例(少样本) |
1~3 个典型的输入输出示例,覆盖边界情况 |
| 输出格式 |
JSON Schema 或明确的格式说明 |
写法要点:具体(“回答不超过 3 句话”而不是“简洁一点”);说明原因(模型理解了原因会处理得更好);正向描述要做什么,而不只是禁止什么;重要规则放在开头或结尾。
少样本(Few-shot)和思维链
- 少样本:给示例比写长篇规则更有效,尤其是格式和风格。示例要多样,避免模型只学会复制示例。
- 思维链:让模型先分析再给结论,对推理类任务有帮助;支持“推理 / 思考模式”的模型已内置这一过程,不需要在提示词里要求“一步步思考”。需要结构化输出时,可以设计
reasoning 字段放在 answer 字段之前。
结构化输出
| 方式 |
可靠性 |
| 提示词要求输出 JSON |
一般;可能多出说明文字、缺字段 |
| JSON 模式 |
保证是合法 JSON,不保证字段正确 |
| 原生结构化输出 / 严格模式(按 JSON Schema 约束生成) |
高;字段和类型符合 Schema(各厂商支持范围以官方文档为准) |
| 工具调用的参数 |
高;很多框架的结构化输出就是用它实现的 |
无论哪种,业务规则仍要自己校验(引用编号是否存在、金额是否合理),失败时把具体错误反馈给模型重试一次,仍失败就降级。
提示词版本管理
提示词是代码:放进 Git、有版本号、改动经过评审、上线前跑评测集;每次调用记录使用的提示词版本,方便定位问题和回滚。
案例
售后助手的提示词 v1 只有一句“你是客服,请回答用户问题”,经常编造政策。v3 改为结构化写法:明确只根据资料回答、资料不足时转人工、输出 JSON(答案、引用编号、是否转人工),并加入两个示例(一个能回答、一个应转人工)。评测集上编造率显著下降(具体数字以自己的评测为准)。
代码示例
模板和输出校验(完整版本 examples/prompt-kit/prompt_kit.py,带测试):
易错点
- 指令和数据混在一起,数据里的文字被当成指令。
- 示例过于单一,模型照抄示例内容。
- 只要求“输出 JSON”而不校验。
- 在提示词里写“不要编造”,却没有给“资料不足时怎么做”的明确出口。
- 提示词存在数据库里随时修改,没有版本和评测。
- 换模型后沿用旧提示词,不重新评测:不同模型对提示词的敏感点不同。
面试常问
- 你写提示词有什么方法?
- 怎么保证模型输出稳定的结构化数据?
- 提示词怎么管理和迭代?