提示词工程介绍

1. 什么是提示词工程

提示词工程（Prompt Engineering）是指通过精心设计输入给大语言模型（LLM）的文字，引导模型输出准确、稳定、符合预期结果的工程实践。

一句话理解：用对话的方式给模型"写需求文档"。

它既不是玄学，也不是"咒语"，而是一套可以系统学习的方法论。本质上是把模糊的人类意图，翻译成模型能稳定执行的指令。

2. 为什么需要提示词工程

同一个模型，面对不同的提示词，输出质量可能差出 10 倍以上。

看一个例子：

❌ 模糊的提示词

帮我写一个登录接口

模型只能凭借猜测做出选择：用什么语言？什么框架？要不要校验？返回什么字段？……

✅ 清晰的提示词

用 Python FastAPI 写一个登录接口：

路由：POST /api/v1/login

请求体：{"email": str, "password": str}

验证：邮箱格式、密码长度（8-32）

成功返回 JWT，过期 24 小时

失败返回 401 + 错误信息

用 pydantic 做参数校验

后者输出的代码可以直接用，前者大概率要返工三轮。

提示词工程的价值就在于：把返工的成本前置到一次写清楚。

3. 提示词的基本结构

一个高质量提示词通常包含以下要素：

要素	作用	示例
角色（Role）	设定模型的视角	"你是一名资深 Python 工程师"
任务（Task）	明确要做什么	"审查下面这段代码"
上下文（Context）	提供背景信息	"这是一个支付系统的核心模块"
输入（Input）	待处理的内容	"`python\ndef pay(...)`"
约束（Constraints）	限制条件	"只关注安全性和并发问题"
输出格式（Format）	期望的输出结构	"按 markdown 表格输出问题列表"
示例（Example）	参考样例	"比如：[严重] 第 12 行..."

并非每次都需要全部，但缺得越多，输出越不稳定。

4. 核心原则

原则一：明确而具体

模型不会"读心"。任何模糊词都会被模型用最常见的解释填补。

❌ 模糊	✅ 具体
写得简洁一点	控制在 200 字以内
用现代化的方式	使用 ES2022 语法和 async/await
多举几个例子	给出 3 个不同复杂度的例子

原则二：分解任务

复杂任务拆成多步骤，比一次"全包"准确得多。

错误：帮我重构这个项目并写文档

正确：
1. 先列出当前代码的主要问题（不要改动）
2. 我确认后，按问题列表给出重构方案
3. 我同意方案后，再实际修改代码
4. 最后基于修改后的代码写文档

原则三：给示例（Few-shot）

让模型"看一眼想要什么样"，比解释一百句还有效：

请按以下格式生成 commit message：

输入：修改了登录验证逻辑，加了限流
输出：feat(auth): add rate limiting to login endpoint

输入：修复了支付页面的样式 bug
输出：fix(ui): correct alignment on payment page

输入：{你的描述}
输出：

原则四：结构化输出

需要程序处理的输出，明确指定 JSON / XML / Markdown 格式：

请提取以下文本中的人名、地名、时间，
按 JSON 输出，不要任何其他文字：

{
  "persons": [...],
  "places": [...],
  "times": [...]
}

原则五：让模型"思考"

复杂推理任务加一句"让我们一步一步思考"（Chain-of-Thought），准确率能显著提升：

计算公司明年的预期利润，要求：
1. 先列出所有收入来源和数字
2. 再列出所有成本项
3. 然后计算每项的同比变化
4. 最后给出预测结果

请逐步推理，不要直接给结论。

5. 常见技巧

Zero-shot：不给示例

模型基于训练知识直接完成。适合简单、常见的任务。

把下面这句英文翻译成中文：
"The quick brown fox jumps over the lazy dog."

Few-shot：给少量示例

模型从示例中"学"格式和风格。适合输出格式固定的任务。

判断情感：

"这家餐厅的菜真好吃" → 正面
"等了一个小时菜还没上" → 负面
"店员态度一般般" → 中性
"环境优雅，服务到位" →

Chain-of-Thought（CoT）：思维链

让模型展示推理过程，提高复杂推理的正确率。

问题：小明有 5 个苹果，吃了 2 个，又买了 3 个，最后送了一半给朋友，
他还剩几个？

请按以下步骤思考：
1. 初始：5 个
2. 吃掉后：5 - 2 = 3 个
3. 买入后：3 + 3 = 6 个
4. 送出一半：6 / 2 = 3 个
答案：3 个

Self-consistency：自一致性

同一个问题让模型答多次，取多数答案。适合数学、推理类任务。

ReAct：推理 + 行动

让模型在"思考 → 行动 → 观察"的循环中工作，是 Agent 工作的核心模式。

Question: 北京今天的天气怎么样？
Thought: 我需要查询实时天气
Action: search_weather("北京")
Observation: 25℃ 晴
Thought: 已经获取，可以回答
Answer: 北京今天 25℃，晴

6. 角色提示（Role Prompting）

给模型设定一个"身份"，让它的输出风格、深度更聚焦。

你是一名有 15 年经验的安全工程师，专注于 Web 应用渗透测试。
请审查下面这段登录接口代码，重点关注：
- 注入风险
- 时序攻击
- 权限绕过

代码：...

但要注意：角色不是越夸张越好。"你是世界上最好的程序员"这种没什么用，"你是熟悉 PostgreSQL 内核的 DBA"这种具体角色才能引导模型调用相关的知识。

7. 系统提示与用户提示

大多数 LLM API 都区分两类提示：

类型	作用	频率
System Prompt	设定 AI 的整体行为、规则	通常只设一次
User Prompt	具体一次对话的输入	每次都不同

[System]
你是一名英语口语老师。
- 只用英语回复
- 每次回复后纠正学生的语法错误
- 给出更地道的表达建议

[User]
I goes to school yesterday.

System Prompt 适合放：身份、风格、约束、禁止事项。User Prompt 放具体任务。

8. 提示词的"反模式"

反模式一：堆砌形容词

❌ 请写一篇非常优秀、极其专业、令人惊叹的文章
✅ 请写一篇 800 字的文章，结构包含引言、3 个论点、结论

反模式二：负面指令过多

模型容易"无视"否定句。"不要做 X"不如"请做 Y"。

❌ 不要写得太啰嗦，不要用复杂的词，不要堆砌形容词
✅ 用平实、简洁的语言，每句话不超过 30 字

反模式三：一次塞太多

❌ 帮我把这 5 个文件改了，再写测试，再写文档，再生成 PR 描述
✅ 一次一件事，按顺序来

反模式四：依赖模型"记住"

长对话中，模型可能"忘掉"前面的约束。重要约束在每次提示中重复一次比较保险。

9. 提示词调试

写出来的提示词不好用，怎么办？以下是排查顺序：

看输出错在哪：是格式错？还是内容错？还是答非所问？
检查指令是否模糊：把"差不多"、"最好"、"尽量"换成具体数值
加示例：给 1-3 个 input → output 对照
加约束：明确不要什么（"不要解释，只输出代码"）
拆任务：让模型先做 A，再基于 A 的结果做 B
换模型：有些任务小模型搞不定，需要更强的模型

调试小技巧

让模型自己评估自己的输出：

对你刚才的输出，请用以下标准打分（1-10）：
- 是否准确？
- 是否完整？
- 是否符合格式？

如果有不足，请指出并重新输出。

10. 提示词模板

实战中，提示词常常是模板化的。可以维护一个个人"提示词库"。

代码审查模板

角色：资深 {{language}} 工程师
任务：审查下面这段代码

代码：
```{{language}}
{{code}}

要求： - 按【严重】【重要】【建议】三级输出 - 每条问题给出：行号 + 问题描述 + 修改建议 - 只指出实际问题，不做无谓夸赞 - 不要解释代码本身

输出格式：markdown 表格

#### 翻译模板

请把下面的文本从{{src}}翻译成{{dst}}。

要求： - 保持原文语气和风格 - 专有名词不译，但首次出现时附原文 - 译文符合{{dst}}的表达习惯，不要直译 - 输出仅包含译文，不要解释

原文： {{text}}

#### 提取信息模板

从下面文本中提取信息，按 JSON 输出。

字段： - name: 人名（字符串） - age: 年龄（整数，无则 null） - city: 城市（字符串，无则 null）

要求： - 只输出 JSON，不要任何其他文字 - 字段缺失用 null，不要省略字段 - 多个结果用数组

文本： {{text}}

### 11. 模型差异

不同模型对提示词的"敏感度"不同：

| 模型 | 特点 | 提示词建议 |
|---|---|---|
| Claude | 善于理解长指令、结构化输入 | 用 XML 标签包裹各部分 |
| GPT | 跟随指令好，喜欢明确格式要求 | 用 markdown 标题分段 |
| 开源小模型 | 容易"跑题"，需要严格约束 | 多给示例（few-shot） |

Claude 推荐用 XML 标签：

```xml
<context>
你是公司内部的代码审查机器人。
</context>

<input>
def login(user, pwd):
    ...
</input>

<task>
找出代码中的安全问题。
</task>

12. 提示词工程 vs 微调

什么时候应该写提示词，什么时候应该微调模型？

维度	提示词工程	微调（Fine-tuning）
成本	低（写文字）	高（GPU + 数据）
速度	立刻生效	训练数小时到数天
适用场景	通用任务、原型、快速试错	大规模、固定风格、领域知识
灵活性	改提示词即可	改了就要重训

90% 的场景，提示词工程足够。当提示词反复优化仍达不到效果，或者需要稳定的输出风格、调用上千次 API 节省成本时，再考虑微调。

13. 一个完整的实战例子

需求：让模型把用户的自然语言描述转成 SQL 查询。

第一版（粗糙）

把下面的话转成 SQL：
"找出最近一个月销售额最高的 5 个商品"

输出：勉强能跑，但表名、字段名都是猜的。

第二版（加 Schema）

表结构：
- products(id, name, price)
- orders(id, product_id, quantity, created_at)

把下面这句转成 PostgreSQL：
"找出最近一个月销售额最高的 5 个商品"

输出：可以跑，但还会偶尔写错聚合。

第三版（加示例 + 约束）

你是 PostgreSQL 专家。

表结构：
- products(id, name, price)
- orders(id, product_id, quantity, created_at)

要求：
- 只输出 SQL，不要解释
- 用 CTE 让结构清晰
- 时间字段用 INTERVAL 表达式

例子：
输入："本周下单量最多的用户"
输出：
WITH weekly AS (
  SELECT user_id, COUNT(*) AS cnt
  FROM orders
  WHERE created_at >= NOW() - INTERVAL '7 days'
  GROUP BY user_id
)
SELECT * FROM weekly ORDER BY cnt DESC LIMIT 1;

现在的输入：
"找出最近一个月销售额最高的 5 个商品"

SQL：

输出：稳定、可读、可直接上线。

这就是提示词工程的价值——通过迭代设计，把"看运气"变成"靠工艺"。

14. 学习建议

先用，再学：先大量使用 Claude/ChatGPT，培养"模型感"，再回头看理论
写提示词日志：记录哪些有效、哪些无效，沉淀自己的模板库
对照阅读：看 Anthropic、OpenAI 官方的 Prompt 指南
学习官方 System Prompt：很多产品的 System Prompt 已被复刻在 GitHub 上，直接学
不要迷信"魔法咒语"：那些宣称"加上这句话效果暴涨"的，多半是过拟合到某个场景

总结

提示词工程 = 把人类意图翻译成模型能稳定执行的指令
核心要素：角色、任务、上下文、输入、约束、格式、示例
五大原则：明确具体、分解任务、给示例、结构化输出、让模型思考
主流技巧：Zero-shot、Few-shot、Chain-of-Thought、ReAct
调试方法：看错在哪 → 加约束 → 加示例 → 拆任务 → 换模型
维护自己的提示词模板库，是工程化使用 LLM 的基础
90% 场景下，写好提示词比微调模型更划算