4、Prompt Engineering基础：零样本、少样本、思维链（CoT）、角色扮演、格式控制等核心技巧
聊到 Prompt Engineering，很多人觉得就是「跟 AI 说人话」。其实没那么简单。
我刚开始做大模型应用时，也踩过不少坑。明明问的是同一个问题，换了个说法，结果天差地别。后来我才明白——提示词不是聊天，是编程。你写的每一句话，都是在给模型「画边界」。
这一章，我把最核心的几种技巧拆开来讲。每个技巧我都用过，也翻过车。你跟着走一遍，基本就能应付 80% 的场景了。
4.1 零样本提示：最基础，也最容易翻车
零样本，就是不给例子，直接问。比如：
用户：请把这句话翻译成英文：「今天天气真好。」模型直接输出：Today's weather is really nice.
看起来挺顺，对吧？但我在项目中遇到过一个问题——零样本对「模糊指令」特别敏感。比如你问「写一封邮件」，模型可能给你写出一封商务函，也可能写成朋友间的闲聊。为什么？因为模型不知道你的「默认语境」是什么。
我曾经在客服系统里直接用零样本让模型总结用户投诉。结果模型把「用户骂人」总结成了「用户情绪稳定」。后来我加了一句「请保持客观，不要美化负面内容」，效果立刻好了。
零样本的核心要点：
- 指令要具体：别只说「总结一下」，要说「用 50 字以内总结核心问题」
- 明确输出格式：比如「输出 JSON 格式，包含 title 和 content 字段」
- 避免歧义：模型会脑补你没说的部分，所以尽量把边界说清楚
4.2 少样本提示：给模型「打个样」
少样本，就是给几个例子，让模型照着学。说白了，就是「你先做一遍，我再做」。
用户：请根据以下格式回答问题。
例子1：
问题：苹果是什么颜色？
答案：红色或绿色。
例子2：
问题：香蕉是什么形状？
答案：弯曲的。
问题：葡萄是什么颜色？
答案：模型输出：紫色或绿色。
你看，模型学会了「答案要简洁，且给出多种可能」。这就是少样本的力量。
我建议你注意三点：
- 例子要覆盖边界情况：比如做情感分析，别只给正面例子，也要给负面和中立的
- 例子数量 2-5 个最佳：太少学不会，太多模型会「过拟合」到例子上
- 例子顺序有影响：模型更关注最后几个例子，所以把最典型的放最后
我在做代码生成时，少样本帮我解决了一个大问题。模型默认生成的代码风格很乱，我给了 3 个「命名规范 + 注释风格」的例子后，输出质量直接提升了一个档次。
4.3 思维链（CoT）：让模型「边想边说」
思维链，英文叫 Chain-of-Thought。说白了，就是让模型把推理过程写出来，而不是直接给答案。
为什么会这样？因为模型直接输出答案时，容易「跳步」。比如你问「小明有 5 个苹果，给了小红 2 个，又买了 3 个，现在有几个？」模型可能直接输出 6，但它是怎么算的？不知道。如果让它一步步写：
用户：小明有 5 个苹果，给了小红 2 个，又买了 3 个，现在有几个？请一步步推理。
模型：
1. 初始有 5 个苹果。
2. 给了小红 2 个，剩余 5 - 2 = 3 个。
3. 又买了 3 个，现在有 3 + 3 = 6 个。
4. 所以答案是 6。嗯，这里要注意：思维链不是万能的。我遇到过一种情况——模型推理过程全对，但最后答案写错了。比如步骤里算出来是 6，最后写成了 5。所以，如果你用 CoT，最好再加一步「请检查你的推理过程」。
| 场景 | 是否推荐 CoT | 原因 |
|---|---|---|
| 数学计算 | ✅ 强烈推荐 | 减少跳步错误 |
| 逻辑推理 | ✅ 推荐 | 让模型「想清楚再说」 |
| 创意写作 | ❌ 不推荐 | 会限制想象力 |
| 简单问答 | ❌ 不推荐 | 浪费 token，且没必要 |
4.4 角色扮演：给模型「戴个帽子」
角色扮演，就是告诉模型「你现在是谁」。比如：
用户：你现在是一位资深律师。请帮我分析这份合同中的风险点。模型会立刻切换到「律师模式」——用词更严谨，逻辑更严密，甚至会用一些法律术语。你想想看，如果不加角色，模型可能用大白话给你分析，那就不够专业了。
我在项目中遇到过一个问题：角色扮演太宽泛，效果反而不好。比如只说「你是专家」，模型不知道该往哪个方向「专」。后来我改成「你是一位有 10 年经验的 Python 后端开发工程师，擅长 Django 和性能优化」，效果立刻好了。
角色扮演的几个技巧：
- 越具体越好：别说「老师」，说「高中数学老师，擅长讲导数」
- 可以叠加角色：比如「你既是医生，又是科普作家，请用通俗的语言解释」
- 注意角色冲突：别让模型同时扮演「法官」和「被告」，它会分裂
我曾经让模型扮演「心理咨询师」来安抚用户情绪。结果模型太「入戏」，开始分析用户的童年创伤。后来我加了限制：「只做情绪安抚，不做心理诊断」。
4.5 格式控制：让输出「听话」
格式控制，就是告诉模型「输出长什么样」。这是我最常用的技巧之一。为什么？因为大模型默认输出是「散文」——自由、随意、不结构化。但实际应用中，我们需要 JSON、表格、列表、Markdown 等格式。
用户：请输出以下格式的 JSON：
{
"name": "产品名称",
"price": 价格（数字）,
"stock": 库存数量（数字）
}
产品：iPhone 15，价格 5999，库存 200 台。模型输出：
{
"name": "iPhone 15",
"price": 5999,
"stock": 200
}嗯，这里要注意：模型对格式的「理解」有时会出错。比如你要求输出 JSON，它可能给你加个注释，或者把数字写成字符串。我建议你在格式控制后面加一句「请严格遵循格式，不要添加任何额外内容」。
格式控制的常见场景：
- JSON 输出：用于 API 对接，最常用
- Markdown 表格：用于数据展示
- 列表/编号：用于步骤说明
- 固定模板：比如「开头 + 正文 + 结尾」三段式
我在做数据清洗时，要求模型输出 CSV 格式。但模型总是把带逗号的内容搞乱。后来我改用「制表符分隔」，问题就解决了。所以，格式控制也要考虑数据的特殊性。
4.6 组合使用：技巧不是孤立的
你可能会问：这些技巧能不能一起用？当然可以。实际上，真正好用的 Prompt 都是组合拳。
举个例子，我在做一个「智能客服」项目时，用了这样的组合：
角色：你是一位资深客服专员，语气温和但专业。
格式：请输出 JSON，包含 "reply"（回复内容）和 "action"（下一步操作，可选值：escalate/close/follow_up）。
推理：请先分析用户情绪，再给出回复。分析过程写在 "reasoning" 字段中。
例子：
用户：你们的产品太差了，我要退货！
输出：
{
"reasoning": "用户情绪激动，有退货需求，需要先安抚再引导流程",
"reply": "非常抱歉给您带来不好的体验，我马上帮您处理退货事宜。",
"action": "escalate"
}你看，这里同时用了角色扮演、格式控制、思维链和少样本。效果比单独用任何一个都好。
4.7 避坑总结：我踩过的 3 个坑
最后，分享几个我实际踩过的坑，你遇到了可以绕开：
- 坑 1：过度依赖零样本。我曾经觉得「模型够聪明，不用给例子」。结果模型输出不稳定，每次都不一样。后来我养成了习惯——但凡任务有点复杂，至少给 1 个例子。
- 坑 2：思维链太长。有一次我让模型做多步推理，结果它写了 2000 字的推理过程，最后答案反而错了。后来我加了限制：「推理步骤不超过 5 步」。
- 坑 3：角色扮演太「戏精」。模型一旦进入角色，可能会过度发挥。比如扮演「老师」时，它开始出题考用户。所以，角色扮演一定要加边界，比如「只回答问题，不要主动提问」。
好了，这一章的内容就到这里。Prompt Engineering 说到底，就是「理解模型的思维方式，然后用它听得懂的语言跟它沟通」。你多练几次，慢慢就有感觉了。