第一章 提示词工程导论
如果你在 2025 年仍然觉得“Prompt 就是问个问题“，那你大概率是在 LLM 上做应用，而不是用 LLM 做工程。这一章先建立共识：我们到底在为什么编程，以及为什么提示词工程仍然是一门手艺而不是一个指令。
为什么 2025 年还要谈提示词工程
模型变强 ≠ 写提示词变得不重要。模型变强带来的真实变化是：坏提示词的可接受区间变宽了，但好提示词和坏提示词之间的差距并没有消失。 在生产环境里，你面对的是：
- 边界场景（edge case）而不是教科书示例
- 长上下文、跨文档、跨工具调用
- 失败成本不是一次重试，而是品牌、隐私、法律风险
- 评测要可重复、可回归、不能用“体感“
所以提示词工程的本质变化是：从“让模型输出正确的示例“变成“让模型在长尾分布上仍然稳定“。 这就是为什么它仍然是一门工程学科。
提示词工程到底是什么
一种最简洁的定义：通过自然语言对模型进行编程。 你写的不是代码，而是对模型的“行为契约“：
- 你是谁（persona / role）
- 你要做什么（task）
- 你掌握什么信息（context / tools）
- 必须遵守什么（constraints）
- 用什么形式输出（format）
这五个要素基本可以覆盖一切 prompt，从聊天机器人到 Agent 到结构化抽取。后面章节会一个一个拆。
LLM 骨架速回顾
读这书不需要模型训练背景，但有几个术语会反复出现：
- Token：模型真正吃下去的“字“。中英文比例不一样（一个汉字约 1.5–2 个 token），算成本和上下文时不要按字符算。
- Context Window：单次调用最多能塞多少 token。窗口大不等于任何时候都该塞满，详见第七章。
- Temperature / Top-p：控制“创造性“。摘要、抽取、结构化输出用低（≤0.2）；开放写作可以高。
- System / User / Assistant Messages：不同厂商在这套三分法上的具体语义略有差别，但概念通用。
- Stop Sequences：模型的硬截止符，可以用来切分多段输出。
一个提示词的完整生命周期
工程化的提示词不是一行字符串，而是 版本控制的资产：
- 意图澄清：这段 prompt 解决什么业务问题？失败长什么样？
- 草稿与样例：先写 5–10 个真实输入，让模型出 5–10 个真实输出，肉眼挑刺。
- 结构化：把直觉沉淀成模板，固化变量、分隔符、输出格式。
- 评测：把样例固化成评测集，建立自动评分（详见第九章）。
- 上线与监控：灰度、A/B、收集 bad case。
- 回归：模型升级、API 变更、上下文结构变化时，重跑评测。
- 废弃：当一段 prompt 开始“叠 buff“（补丁套补丁），就重写。
几个常见心智误区
- “提示词越长越好”：错。相关长度比绝对长度重要。噪声会稀释指令。
- “换个说法试试”：可以，但请只改一个变量。单变量改动是评测的前提。
- “示例给得越多越好”：错。3 个高质量例子 > 30 个低质量例子。
- “系统提示 = 安全护栏”：错。安全护栏来自结构化校验、工具白名单，而不是“请不要输出密码“。
- “调试靠肉眼”：可以，但只要一个 prompt 进入产品，它就要能跑评测。
本书怎么读
后面九章大致按这个顺序展开：
- 提示词的基本结构（第二章）
- 不同任务用什么技巧：零样本/少样本（第三章）、CoT（第四章）
- 行为控制：角色与系统提示（第五章）、结构化输出（第六章）
- 系统级问题：多轮与上下文（第七章）、注入与防御（第八章）
- 工程闭环：评测与优化（第九章）、工具与 Agent（第十章）
你可以顺序读，也可以当手册按章节查阅。
本章回顾
- 提示词工程在 2025 年的意义不是“让弱模型变强“，而是让强模型在长尾上稳定。
- 一个提示词是五要素的契约：role / task / context / constraints / format。
- 一个提示词是资产：版本化、可评测、可回归。
- 调试提示词的第一原则是单变量改动。
延伸阅读
- Anthropic: Prompt Engineering Overview (docs.anthropic.com)
- OpenAI: Prompt engineering guide (platform.openai.com/docs/guides/prompt-engineering)
- Google: Prompting guide 101 (developers.google.com)