提示词不是玄学，是工程
提示词不是玄学，是工程
提示词工程（Prompt Engineering）这个词被用烂了。从 2023 年 ChatGPT 爆火开始，各种「万能提示词模板」「一句话让 AI 效率翻倍」的内容铺天盖地，搞得很多人以为这就是个文字游戏。
但如果你真正在生产环境里用过大模型，你会知道：提示词设计是一门严肃的工程学科，它有明确的设计模式、可复现的效果差异、以及经过论文验证的理论基础。
今天不聊那些花里胡哨的「角色扮演」模板，而是拆解几个真正经典的、经过学术验证和工业实践检验的提示词范式。每一个都值得深入理解其背后的原理，而不只是复制粘贴。
案例一：Chain-of-Thought —— 一句话让推理准确率翻倍
2022 年 Google Brain 的 Jason Wei 等人发表了一篇论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》，这篇论文可以说是提示词工程的分水岭。
核心发现极其简单：在提示词末尾加上 "Let's think step by step" 这一句话，就能让模型在 GSM8K 数学推理基准测试上的准确率从 17.7% 飙升到 78.7%。
来看一个具体对比：
A: 11 ← 直接给答案，正确
Q: The cafeteria had 23 apples. If they used 20 to make lunch and bought 6 more, how many apples do they have?
A: 27 ← 错误！正确答案是 9
A: Roger started with 5 balls. 2 cans of 3 = 6. 5 + 6 = 11.
Q: The cafeteria had 23 apples...
A: Started with 23. Used 20, so 23 - 20 = 3. Bought 6 more, so 3 + 6 = 9. ✓
CoT 之所以有效，本质上是在利用 Transformer 的一个架构特性：模型的「思考深度」受限于生成的 token 数量。标准提示下，模型被迫在一次前向传播中完成所有推理；而 CoT 让模型把中间步骤外化为文本，相当于给了它更多的「计算步骤」。这不是什么魔法，而是在用生成长度换计算深度。
但要注意一个常见误区：CoT 对小模型（参数量低于 ~100B）效果很差，甚至会降低准确率。这是因为小模型的推理链本身就不可靠，「一本正经地胡说八道」反而比直接猜答案更危险。所以 CoT 是大模型时代的专属技巧。
来源：Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", NeurIPS 2022
案例二：Few-Shot Prompting —— 用例子代替说明书
Few-Shot Prompting 是 GPT-3 论文（Brown et al., 2020）的核心贡献之一。它的思路反直觉地简单：与其费劲描述你想要什么格式，不如直接给几个例子。
这个技巧在实际开发中的使用频率远超 CoT，因为它解决的是一个更普遍的问题——输出格式控制。
// Few-Shot 示例：情感分析任务 输入："这家餐厅的牛排太棒了，下次还来！" 输出：{"sentiment": "positive", "confidence": 0.95, "aspect": "food_quality"} 输入："等了四十分钟才上菜，服务态度也很差" 输出：{"sentiment": "negative", "confidence": 0.90, "aspect": "service"} 输入："环境一般，但价格还算公道" 输出：{"sentiment": "neutral", "confidence": 0.72, "aspect": "value"} // 现在处理新输入： 输入："甜品种类很多，但味道中规中矩" 输出：
这个例子展示了 Few-Shot 的精髓：三个示例同时定义了输出的 JSON 结构、字段命名规范、confidence 的取值范围、以及 aspect 的分类体系。如果你试图用自然语言把这些规则全部描述清楚，提示词长度至少翻三倍，而且模型的遵循率反而更低。
Few-Shot 的收益曲线是典型的边际递减。从 0 到 3 个示例，效果提升最显著；超过 5 个之后，增益几乎可以忽略，但 token 消耗线性增长。在生产环境中，3 个精心挑选的示例通常是性价比最高的选择。
选择示例时有个关键原则：示例要覆盖边界情况，而不是重复典型情况。三个都是「好评」的例子，不如一个好评、一个差评、一个中性评价。多样性比数量更重要。
来源：Brown et al., "Language Models are Few-Shot Learners", NeurIPS 2020
案例三：System Prompt 的结构化设计 —— 被低估的工程实践
如果说 CoT 和 Few-Shot 是学术界贡献的经典范式，那 System Prompt 的结构化设计就是工业界在实战中摸索出来的最佳实践。
OpenAI 在其官方 Prompt Engineering Guide 中给出了一个核心建议：用分隔符（delimiters）明确区分提示词的不同部分。这看起来是个小技巧，但在复杂系统中，它是防止 prompt injection 和保证输出稳定性的关键。
来看一个生产级 System Prompt 的结构：
# Role 你是一个专业的代码审查助手，专注于 Python 代码质量分析。 # Context 用户会提交 Python 代码片段，你需要从以下维度进行审查： - 代码风格（PEP 8 合规性） - 潜在 Bug - 性能问题 - 安全漏洞 # Output Format 以 JSON 格式返回审查结果： ```json { "issues": [ { "severity": "high|medium|low", "line": number, "category": "style|bug|performance|security", "description": "问题描述", "suggestion": "修复建议" } ], "summary": "总体评价", "score": 0-100 } ``` # Rules - 只关注代码本身，不要解释 Python 基础语法 - severity 为 high 的问题必须给出具体修复代码 - 如果代码没有问题，返回空的 issues 数组 - 不要编造不存在的问题 # Examples <example> 输入：def get_user(id): return db.query(f"SELECT * FROM users WHERE id={id}") 输出：{"issues":[{"severity":"high","line":1,"category":"security", "description":"SQL 注入漏洞","suggestion":"使用参数化查询"}], "summary":"存在严重安全漏洞","score":20} </example>
这个结构遵循了一个被广泛验证的模式：Role → Context → Format → Rules → Examples。每个部分用 Markdown 标题分隔，让模型能清晰地解析不同层次的指令。
Anthropic 在其官方文档中特别强调了一个原则："Put words in Claude's mouth"——在 Assistant 回复的开头预填内容，强制模型沿着你期望的方向生成。比如你想要 JSON 输出，可以在 assistant message 的开头预填一个 {，这比在 system prompt 里写十遍「请返回 JSON 格式」都有效。
另一个实战经验：Rules 部分用否定句式比肯定句式更有效。「不要编造不存在的问题」比「只报告真实存在的问题」更能降低幻觉率。这可能和模型训练时的 RLHF 数据分布有关——否定指令在安全训练中出现频率更高，模型对其更敏感。
案例四：Self-Consistency —— 用「投票」对抗不确定性
Self-Consistency（自洽性采样）是 Google 的 Xuezhi Wang 等人在 2023 年提出的方法，它解决了 CoT 的一个致命缺陷：单次推理链可能走偏，而你无法判断它是否走偏了。
方法很直觉：对同一个问题，用较高的 temperature（比如 0.7）生成多条推理路径，然后对最终答案做多数投票。
在 GSM8K 上，Self-Consistency + CoT 的组合将准确率从 CoT 单次采样的 78.7% 进一步提升到了 91.0%。
Self-Consistency 的代价是显而易见的：API 调用次数乘以采样数。5 次采样意味着 5 倍的成本和延迟。在生产环境中，这个方法更适合用在高价值、低频次的场景——比如医疗诊断辅助、法律文书分析、金融风控决策。对于聊天机器人的日常对话，这个成本完全不值得。
一个工程上的折中方案：先用低成本模型做初次推理，只在 confidence 低于阈值时才触发 Self-Consistency 采样。这样可以把平均成本控制在 1.3-1.5 倍，同时覆盖大部分不确定性场景。
来源：Wang et al., "Self-Consistency Improves Chain of Thought Reasoning in Language Models", ICLR 2023
案例五：ReAct —— 让模型学会「边想边做」
ReAct（Reasoning + Acting）是 Yao et al. 在 2023 年提出的框架，它解决了一个根本性问题：纯推理的模型无法获取实时信息，纯行动的模型不会规划。
ReAct 的提示词模式让模型在 Thought（思考）、Action（行动）、Observation（观察）三个状态之间交替：
Question: 《奥本海默》的导演还执导过哪部获得奥斯卡最佳影片的电影？ Thought 1: 我需要先确认《奥本海默》的导演是谁。 Action 1: Search["奥本海默 导演"] Observation 1: 《奥本海默》由克里斯托弗·诺兰执导... Thought 2: 导演是诺兰。我需要查他的其他获奥斯卡最佳影片的作品。 Action 2: Search["克里斯托弗·诺兰 奥斯卡最佳影片"] Observation 2: 《奥本海默》获得第96届奥斯卡最佳影片... Thought 3: 看起来诺兰只有《奥本海默》获得了最佳影片。 Action 3: Finish["《奥本海默》是诺兰唯一获得奥斯卡最佳影片的电影"]
这个模式直接催生了后来的 AI Agent 生态。LangChain、AutoGPT、OpenAI 的 Function Calling，