Notes · 2026-06-21
Prompt 工程入门:写出高效提示词的 6 个原则
什么是 Prompt 工程?
Prompt 工程(Prompt Engineering) 是设计和优化发给模型的输入文本,让输出更接近你期望的结果。
它和「写代码」一样,需要迭代:第一版 Prompt 很少完美;改一个词、加一个示例,回答质量可能差很多。好的 Prompt 往往同时带来两件事:
- 质量更高:分类更准、格式更稳、胡编更少
- 更省 Token:指令更短、输出更可控(见同系列 降低 AI API 成本的 10 个实用技巧)
先认识几个词
| 术语 | 白话 |
|---|---|
| Prompt | 你发给模型的完整输入(系统提示 + 用户消息 + 示例等) |
| System Prompt | 每次请求都会带上的「角色与规则」 |
| Few-Shot | 在 Prompt 里给 2~3 个输入→输出示例 |
| Chain-of-Thought | 让模型先分步推理,再给最终答案 |
| 结构化输出 | 要求 JSON、表格等固定格式,方便程序解析 |
原则一:明确具体,拒绝模糊
模型不会读心。越模糊,它越按「平均用户」来猜——结果常常是又长又空。
❌ 模糊的 Prompt:
帮我写点关于 AI 的内容
✅ 具体的 Prompt:
请撰写一篇 300 字的科普短文,面向零基础读者介绍什么是大语言模型(LLM),
要求使用一个生活比喻帮助理解,语言通俗易懂,避免缩写词。
写具体时要回答四个问题
| 问题 | 示例 |
|---|---|
| 给谁看? | 零基础读者 / 后端工程师 / 老板 |
| 要什么形式? | 300 字 / 3 条 bullet / JSON |
| 什么语气? | 科普 / 正式 / 口语 |
| 怎样算合格? | 必须包含比喻、不得编造数据 |
自检清单
- 删掉头尾客套(「请你」「谢谢」对质量帮助不大,却占 Token)
- 数量可量化(字数、条数、字段名)
- 禁止项写清楚(「不要代码」「不要编造链接」)
原则二:角色扮演(Role Prompting)
给模型一个具体角色,相当于缩小它的「默认风格」范围:
你是一位有 10 年经验的后端架构师。请审查以下 API 设计方案,
从性能、安全性、可维护性三个维度各打 1~5 分,并给出改进建议。
每个维度先写结论,再写理由,各不超过 80 字。
常用角色示例
| 场景 | 角色表述 |
|---|---|
| 代码审查 | 资深 Python 开发者,重视类型标注与异常处理 |
| 数据分析 | 数据分析师,结论必须引用表格中的数字 |
| 文案润色 | 专业编辑,保留原意、只改语病和节奏 |
| 科普解释 | 大学教授,用简单例子解释复杂概念 |
注意
- 角色要和任务匹配,「你是诗人」却让它写 SQL,帮助有限
- 角色描述不宜过长——System Prompt 每次请求都计费
- 关键约束(「必须基于给定文档回答」)比华丽角色更重要
原则三:提供少样本示例(Few-Shot)
给 2~3 个 输入 → 输出 示例,往往比长篇描述格式更有效:
将以下用户评论分类为「正面」「负面」或「中性」。
示例:
评论:这个产品太好用了!→ 正面
评论:配送速度太慢了 → 负面
评论:包装还行 → 中性
请只输出分类标签,不要解释。
请分类:
评论:价格合理,功能够用 →
技巧
| 做法 | 说明 |
|---|---|
| 示例多样化 | 覆盖边界情况(讽刺、双关、中性偏正) |
| 2~3 个通常够用 | 再多增加 Token,收益递减 |
| 格式一致 | 示例输出格式 = 你期望的真实输出格式 |
| 负例可选 | 必要时加一个「不要这样输出」的反例 |
Few-Shot 示例若固定不变,可配合 Prompt Caching 降本(见控费技巧文)。
原则四:链式思维(Chain-of-Thought)
需要推理、计算、多条件判断时,让模型「先想再说」,准确率通常明显更好:
请一步步分析以下数学题:先列出已知条件,再写出计算过程,最后单独一行给出答案。
题目:一个水箱容量 500 升。进水管每分钟 15 升,排水管每分钟 8 升。
从空箱开始,多少分钟灌满?
常用触发语:
- 「请一步步思考」
- 「先分析,再结论」
- 「Let's think step by step」(英文任务仍常用)
何时用、何时不用
| 适合 CoT | 不必 CoT |
|---|---|
| 数学、逻辑、复杂规则 | 简单分类、翻译、格式化 |
| 需要可审计的推理过程 | 只要最终结果、且要极短输出 |
生产环境若不需要展示推理过程,可在 Prompt 里写:「内部一步步思考,最终回答只输出结论」——部分模型支持;也可拆成两次调用(先推理草稿,再摘要给用户)。
原则五:结构化输出
程序要接模型结果时,尽量要求 JSON / 固定字段,而不是自然段:
分析以下客户反馈,只输出 JSON,不要 markdown 代码块:
{
"sentiment": "正面|负面|中性",
"topics": ["主题1", "主题2"],
"urgency": "高|中|低",
"summary": "一句话摘要"
}
客户反馈:
「物流慢,但客服态度很好。」
好处
- 减少格式漂移和多余废话
- 后端
json.loads直接解析 - 配合 API 的 JSON mode / structured outputs(OpenAI、Anthropic 等)更稳
注意
- 字段类型、枚举值写清楚(用
|列出可选值) - 解析失败要有重试或 fallback
- 复杂 schema 可放 System Prompt,用户消息只放数据
原则六:迭代优化
Prompt 工程是实验,不是一次写定:
版本 1:总结这篇文章
→ 太长、太笼统
版本 2:用 3 个要点总结核心观点
→ 更好,但缺少依据
版本 3:用 3 个要点总结;每点必须引用原文中的一个短语
→ ✅ 可上线
建议工作流
- 固定测试集:10~30 条真实用户问题,改 Prompt 前后对比
- 一次只改一处:同时改角色、示例、格式,无法判断谁起作用
- 记录版本:Prompt v3 + 当时输出样例 + 失败 case
- 用 trace 工具:LangSmith 等看「模型实际收到了什么」(见 工作流一文)
进阶技巧速览
| 技巧 | 适用场景 | 说明 |
|---|---|---|
| Self-Consistency | 高准确率决策 | 同一 Prompt 采样多次,投票取众 |
| Tree-of-Thought | 复杂规划、博弈 | 探索多条推理分支再选优 |
| ReAct | 需要查资料、调工具 | 推理与工具调用交替(Agent 常用) |
| 逆向 Prompt | Debug | 「你为什么这样回答?哪句输入导致?」 |
入门阶段先把 6 个原则用熟,再碰进阶;否则容易 Prompt 很长、效果却不稳。
常见误解
| 误解 | 实际情况 |
|---|---|
| Prompt 越长越好 | 冗长指令浪费 Token,关键约束反而被淹没 |
| 角色越牛越好 | 「世界顶级专家」不如具体任务描述有用 |
| Few-Shot 越多越好 | 通常 2~3 个足够;多了贵且可能过拟合示例 |
| CoT 处处适用 | 简单任务反而更慢、更啰嗦 |
| 写好 Prompt 就不用测 | 必须用自己的测试集迭代 |
小结
| 原则 | 一句话 |
|---|---|
| 明确具体 | 受众、格式、长度、成功标准写清楚 |
| 角色扮演 | 缩小风格空间,别堆空话 |
| Few-Shot | 用示例教格式,2~3 个精选 |
| 链式思维 | 推理题先分步再想结论 |
| 结构化输出 | JSON 等固定格式,方便接程序 |
| 迭代优化 | 测试集 + 一次改一处 + 留版本 |
Prompt 不是玄学:把需求说清楚,用例子对齐格式,用数据验证迭代。 这和写接口文档、写单元测试是同一套工程思维。