提示词工程：让 LLM 听你的

大模型很强，但「问法」不同，回答质量天差地别。提示词工程就是：用结构和技巧把需求说清楚，让模型稳定输出你想要的结果。下文用一张总览图、若干示例和检查清单，尽量写得能直接照着改 Prompt。

图：系统提示与用户消息共同构成上下文；模型据此预测续写，输出可以是纯文本、结构化 JSON 或工具调用。

为什么需要「好好写提示词」

模型本质上是在根据上下文猜「下一个词最可能是什么」——系统提示、用户话、历史轮次、Few-shot 示例，全部算上下文。上下文一乱，就容易格式漂移、漏条件、语气不对；写清楚了，角色、格式、边界才站得住。

---

核心结构：系统提示 + 用户输入

大多数 API 把对话拆成两种角色：

角色	常见名字	作用
系统	system	定义「你是谁、规则、格式」——模型会优先遵守，且用户通常看不见
用户	user	本次具体问题或任务

实用建议：把「身份、范围、格式、禁忌」放在 system；把「这一次要做什么」放在 user。例如：system 写「只做订单与产品咨询、中文回复」，user 写「订单 #123 何时发货」——模型一般会遵守 system 的硬约束来答 user。

---

技巧一：角色与任务说清楚

做法：在 system 里写清「你是谁」和「要完成什么类型的任务」。

反例（模糊）：

你是一个助手。

正例（具体）：

你是一个只处理「退款与换货」的客服助手。你只根据已知的退换货政策回答，不承诺政策外的内容。若用户问库存或新品，请回复「请咨询售前客服」。

效果：模型会主动拒绝政策外问题，减少瞎承诺。

---

技巧二：输出格式用示例约束

做法：在提示词里直接给「输入 → 输出」示例，或明确写出格式要求（列表、JSON、表格等）。

示例：要求固定 JSON 结构

请根据用户问题，输出一个 JSON，且只包含以下字段：
- intent: 用户意图（query / complaint / other）
- summary: 一句话摘要
- suggested_action: 建议的下一步

示例：
用户说：「我上周买的耳机坏了能换吗」
输出：{"intent":"complaint","summary":"用户反馈耳机损坏希望换货","suggested_action":"核实订单与保修后走换货流程"}

若要更稳，可配合 Structured Outputs（API 的 JSON Schema 约束），见本站 AI 能力体系：Function Call 与 Agent。

---

技巧三：Few-shot（少样本）示范

做法：在 system 或 user 里给 1～3 个「问题 + 理想答案」示例，模型会模仿风格和逻辑。

适合：代码解释、短摘要、分类、翻译等「风格固定」的任务。

---

技巧四：思维链（Chain-of-Thought，CoT）

做法：要求模型「先一步步推理，再给结论」，而不是直接给答案。适合数学、逻辑、多步判断。

简单触发方式：在问题末尾加一句引导语。

引导语示例	适用场景
请一步步思考，最后给出结论。	通用推理
先列出已知条件，再推导答案。	数学/逻辑题
先分析原因，再给出建议。	故障排查、决策

示例：

用户：小明有 20 元，买了 3 支笔每支 4 元，又买了 1 本本子 6 元，还剩多少？
请先一步步列式计算，再写出最终答案。

模型往往会先输出「3×4=12，12+6=18，20-18=2」，再写「还剩 2 元」，便于你检查过程是否正确。

---

技巧五：分步拆解复杂任务

做法：一个复杂需求拆成多条指令或子问题，让模型按步骤做，而不是一次塞进一段长话。

反例（一长段）：

帮我写一个 Python 函数：读当前目录下所有 csv，合并成一个 DataFrame，把第二列空值用 0 填上，再按第一列排序，最后返回前 10 行，还要写单元测试。

正例（分步）：

第一步：写一个 Python 函数 merge_csv(dir_path)，读取 dir_path 下所有 csv 并合并成一个 DataFrame。
第二步：在合并后把第二列空值填充为 0，按第一列排序。
第三步：函数返回排序后的前 10 行。
第四步：为 merge_csv 写 3 个 pytest 用例（空目录、单文件、多文件）。

这样模型更容易每步都做对，你也方便分步验收。

---

技巧六：负面约束（不要做什么）

做法：明确写出「不要做什么」「不要出现什么」，减少跑题和幻觉。

示例：

请根据下文写一段 200 字以内的产品简介。
要求：
- 只使用下文出现的信息，不要编造参数或功能。
- 不要出现「最好」「第一」等绝对化用语。
- 不要加标题和列表，只要一段连贯的段落。

---

一张实用检查清单

写完后可以快速过一遍：

检查项	说明
角色/身份	system 里是否写清了「你是谁」？
任务范围	是否说明了只做哪类事、不回答哪类问题？
输出格式	是否用示例或明确要求（JSON/列表/表格/长度）？
示例	复杂任务是否给了 1～2 个 Few-shot？
推理方式	需要推理时是否要求「先推理再结论」？
负面约束	是否有「不要编造 / 不要超出范围」等？
长度与语言	是否指定了字数、语言（如中文）？

---

和「工具」怎么配合

提示词管「说什么、怎么说」；Function Call / Agent 管「能否调接口、读文件、跑命令」。典型做法是：system 里写清角色与输出格式，同时列出可用工具；模型在没把握时先调工具拿事实，再组织回答。建议在 system 里明确一句：不确定就查工具，禁止瞎编。

更多机制见 Function Call 与 Agent。

---

小结

技巧	一句话	何时用
角色与任务	说清「你是谁、只做啥」	所有对话型应用
格式与示例	用示例或明确格式约束输出	需要结构化或统一风格时
Few-shot	给 1～3 个示例让模型模仿	分类、摘要、翻译等
思维链	要求先推理再给结论	数学、逻辑、多步判断
分步拆解	把大任务拆成小步骤	复杂编程或长文档任务
负面约束	明确「不要做什么」	防幻觉、防跑题

先从「系统提示写清角色 + 任务 + 格式」做起，再按需要加 Few-shot、CoT 和负面约束，就能在少改代码的前提下明显提升输出质量。