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