📑 本页目录（点开跳转）
03 · 提示词工程
⏱ 25 分钟 ｜ ⭐ 核心 ｜ 🔨 有可直接抄的模板
🎯 一句话
再高级的架构也救不了一个含糊的目标。 提示词工程 = 用最少的必要结构，可靠地达成目标——不是写得越长越玄乎越好。
🧱 一、五条基础功（占效果的 80%）
| # | 技巧 | ❌ 反例 | ✅ 正例 |
|---|---|---|---|
| 1 | 明确直白 | 「帮我看看这段代码」 | 「找出这段代码里所有可能抛异常的位置，逐个给出修复方案」 |
| 2 | 提供动机 | 「摘要控制在 100 字内」 | 「摘要控制在 100 字内，因为它会显示在手机推送里」 |
| 3 | 足够具体 | 「写一篇介绍」 | 「面向零基础读者，600 字，先讲是什么再讲为什么重要，结尾一个类比」 |
| 4 | 使用示例 | （靠形容词描述格式） | 直接贴一个输入→输出的完整例子 |
| 5 | 允许说不知道 | （默认） | 「如果资料里没有答案，直接说不知道，不要猜」 |
💡 为什么「动机」是五条里最被低估的
因果链
🔑 规则穷举不了边界情况，但目标可以泛化。 你不可能预见所有情况，但你可以让模型理解你想要什么。
💡 为什么「正面表述」有效
| ❌ 否定式 | 模型收到的信息 | ✅ 正面式 |
|---|---|---|
| 「不要用列表」 | 那用什么？段落？表格？代码块？ | 「用完整段落写流畅的散文」 |
| 「别写得太啰嗦」 | 多长算啰嗦？ | 「每个要点控制在两句话内」 |
| 「不要编造」 | （无法执行的指令） | 「只使用我提供的资料，资料没有的就说没有」 |
否定式还有个隐藏问题：它把那个概念放进了上下文。 说「不要提及竞争对手」，反而让"竞争对手"这个概念进入了模型的注意力。
📈 二、四条进阶技巧
① 预填响应（Prefill）—— 锁定格式最硬的手段
messages = [
{"role": "user", "content": "分析这段代码的问题"},
{"role": "assistant", "content": "{\n \"issues\": ["}, # ⭐ 替它开个头
]
# → 模型只能接着 JSON 往下写，不会先说"好的，我来分析一下……"
三个常用场景：
- 强制 JSON 输出：预填 {
- 跳过客套话：预填 根据代码，
- 强制某种立场：预填 这个方案的主要风险是
② 让它先想再答
结果对照
🔗 完整原理见第 4 章上下文工程——思考需要 token 作为载体。 ⚠️ 但现代模型很多已内建思考能力，不必总是手动加"一步步想"——先试不加。
③ 提示词链（拆成多次调用）
操作步骤
🔗 这就是第 6 章「顺序工作流」的雏形。
④ ⭐ 让模型面试你（大需求的杀手锏）
操作步骤
为什么有效：你脑子里的需求是模糊的，被追问的过程就是把它逼清楚的过程。 第 5 章有它在编码场景的完整用法。
🗑️ 三、两条已过时（2026 视角）
| 过时技巧 | 为什么过时 | 现在怎么做 |
|---|---|---|
| 满屏 XML 标签 | 现代模型对自然结构理解已经很好，过度标签化是噪声 | 适度分节即可；只在大段资料需要明确边界时用标签 |
| 重度角色扮演 | 「你是世界顶级的…」过重的角色定义反而限制有用性 | 简单说明场景和受众就够 |
⚠️ 注意「过时」是有条件的： 长文档场景下，用
<document>...</document>包住资料仍然有用—— 它解决的是"哪里是资料、哪里是指令"的边界问题，不是装饰。判断标准：这个标签在解决一个真实的歧义吗？ 是就留，不是就删。
🏗️ 四、系统提示词：Agent 的宪法
给 Agent 写系统提示词时，结构比文采重要。可直接抄的骨架：
要点
【角色与目标】
你是……。你的任务是……。成功的标准是……。
【环境】
你可以使用的工具：……
当前的约束：……（时间、权限、数据范围）
【流程建议】
通常先……再……，但你可以根据情况调整。
（用"建议"而非"必须"，给模型判断空间）
【硬规则】
- 永远不要……
- 必须……
（保持在 5 条以内！真正的硬规则用代码强制，见第 15 章）
【输出格式】
……
示例：……
⚙️ 三个工程细节
① 位置效应：关键指令放两头
⭐ 「先资料后问题」优于「先问题后资料」
② 规则越少越被遵守
流程图
③ 提示词是活文档，会过期
操作步骤
🔗 这和第 12 章 harness的核心命题同源： 你为模型缺陷写的每一段提示词，都编码了一个会过时的假设。
🔨 五、动手：提示词手术（五步）
拿你最近一个效果不好的提示词，按顺序做：
| 步骤 | 做什么 | 检查 |
|---|---|---|
| 1 | 圈出所有含糊词 | 「好一点」「优化」「合适的」「专业的」「详细」——每个替换成可验证的标准 |
| 2 | 补一句为什么 | 这个输出拿去干什么用？给谁看？ |
| 3 | 加一个例子 | 哪怕很短。示例比十行形容词管用 |
| 4 | 「不要 X」→「要 Y」 | 每个否定式都改写 |
| 5 | 数硬规则 | 超过 5 条？挑出能用代码强制的挪走 |
对比前后输出——差距通常肉眼可见。
🕳️ 六、五个常见坑
| 坑 | 症状 | 修 |
|---|---|---|
| 含糊的形容词 | 输出总是"差点意思"但说不清哪差 | 换成可验证标准（字数/结构/受众） |
| 规则太多互相打架 | 模型忽略某些指令 | 砍到 5 条以内，其余用代码强制 |
| 没给示例 | 格式每次不一样 | 给一个完整示例，比什么都管用 |
| 资料和指令混在一起 | 模型把资料里的话当指令执行 | 用标签明确边界（这是标签的正当用途）⚠️ 也是提示注入的入口，见第 15 章 |
| 一个提示词干四件事 | 每件都做得浅 | 拆成提示词链 |
📚 延伸阅读
- 2026 年提示词工程最佳实践
- Claude 5 时代的上下文工程新规则（"少即是多"部分）
✅ 检查点
- 五条基础功是什么？
- 为什么「提供动机」能让模型处理好你没预料到的情况？
- 「不要用列表」除了信息量低，还有什么隐藏问题？
- 预填响应能解决什么问题？举两个场景。
- 长文档场景下 XML 标签"过时"了吗？判断标准是什么？
- 关键指令该放在提示词的什么位置？为什么？
- 硬规则应该多还是少？装不下的怎么办？
👀 答案
- 明确直白、提供动机、足够具体、使用示例、允许说不知道。
- 规则穷举不了边界情况但目标可以泛化。模型理解了"为什么"，遇到你没预见的情况时能按你的意图行事，而不是机械执行规则。
- 它把那个概念放进了上下文——说「不要提竞争对手」反而让这个概念进入模型的注意力。
- 强制输出格式。场景：预填
{强制 JSON；预填根据代码，跳过客套话；预填某个开头强制特定立场。 - 没有完全过时。判断标准是「这个标签在解决一个真实的歧义吗」——长文档里标明"哪里是资料哪里是指令"是真实需求，装饰性标签才是噪声。
- 放开头和结尾，大段资料放中间。因为长上下文中间部分的注意力最弱（上下文腐烂）。「先资料后问题」优于反过来。
- 少，控制在 5 条以内。能用代码/hook/参数校验强制的就不要写进提示词——提示词是概率性的，代码是确定性的。
🛑 可以停在这里
⚡ 走神救援
先记住这几件事
- 说清目标、背景、约束和可观察的成功结果，必要时给具体示例。
- 需求还模糊时先澄清；复杂任务拆成可检查的中间结果。
- 提示词要随评测更新，不要不断堆叠已经失效或互相冲突的规则。
下一节 👉 04-上下文工程.md