Notes · 2026-06-21

Prompt 工程入门:写出高效提示词的 6 个原则

什么是 Prompt 工程?

Prompt 工程(Prompt Engineering) 是设计和优化发给模型的输入文本,让输出更接近你期望的结果。

它和「写代码」一样,需要迭代:第一版 Prompt 很少完美;改一个词、加一个示例,回答质量可能差很多。好的 Prompt 往往同时带来两件事:

先认识几个词

术语白话
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 个要点总结;每点必须引用原文中的一个短语
  → ✅ 可上线

建议工作流

  1. 固定测试集:10~30 条真实用户问题,改 Prompt 前后对比
  2. 一次只改一处:同时改角色、示例、格式,无法判断谁起作用
  3. 记录版本:Prompt v3 + 当时输出样例 + 失败 case
  4. 用 trace 工具:LangSmith 等看「模型实际收到了什么」(见 工作流一文

进阶技巧速览

技巧适用场景说明
Self-Consistency高准确率决策同一 Prompt 采样多次,投票取众
Tree-of-Thought复杂规划、博弈探索多条推理分支再选优
ReAct需要查资料、调工具推理与工具调用交替(Agent 常用)
逆向 PromptDebug「你为什么这样回答?哪句输入导致?」

入门阶段先把 6 个原则用熟,再碰进阶;否则容易 Prompt 很长、效果却不稳。


常见误解

误解实际情况
Prompt 越长越好冗长指令浪费 Token,关键约束反而被淹没
角色越牛越好「世界顶级专家」不如具体任务描述有用
Few-Shot 越多越好通常 2~3 个足够;多了贵且可能过拟合示例
CoT 处处适用简单任务反而更慢、更啰嗦
写好 Prompt 就不用测必须用自己的测试集迭代

小结

原则一句话
明确具体受众、格式、长度、成功标准写清楚
角色扮演缩小风格空间,别堆空话
Few-Shot用示例教格式,2~3 个精选
链式思维推理题先分步再想结论
结构化输出JSON 等固定格式,方便接程序
迭代优化测试集 + 一次改一处 + 留版本

Prompt 不是玄学:把需求说清楚,用例子对齐格式,用数据验证迭代。 这和写接口文档、写单元测试是同一套工程思维。


延伸阅读