为什么需要 Instruction Engineering
Role Prompting 解决了"谁来回答"，但没解决"怎么回答"。一个常见的失败模式：
用户："帮我写得好一点"
LLM：改了措辞，加了形容词
用户（不满）："不是这个意思，我要更有深度"
LLM：加了引用，扩展了篇幅
用户（仍不满）："太长了，要精炼"
问题不在模型，而在指令歧义："好"是什么？"深度"指什么？"精炼"到多少字？
Instruction Engineering 的核心目标：
让指令精准、无歧义、可验证，使 LLM 一次就能给出符合预期的输出。
指令的六要素
一个完整的指令应包含六个要素（缺一就可能跑偏）：
| 要素 | 作用 | 示例 |
|---|---|---|
| 角色 | 设定视角与风格 | "你是资深数据分析师" |
| 任务 | 明确要做什么 | "分析销售数据下降原因" |
| 输入 | 提供处理对象 | "（附数据）" |
| 输出格式 | 规定呈现方式 | "Markdown 表格，含 4 列" |
| 约束条件 | 划定边界 | "≤500 字，避免专业术语" |
| 验证标准 | 自检依据 | "每个结论必须有数据支撑" |
经验法则：六要素中，输出格式和约束条件最常被忽略，也最影响输出质量。
八条法则
法则 1：用动词开头
❌ "关于这个产品"（无动作）
✅ "分析这个产品的竞品优势"（动词"分析"明确）
❌ "用户反馈"（名词，无动作）
✅ "将用户反馈按主题分类"（动词"分类"）
常见动作动词：分析、总结、生成、转换、比较、评估、提取、分类、改写、审查。
法则 2：量化代替定性
❌ "简洁一些"（多短算简洁？）
✅ "控制在 200 字以内"
❌ "详细说明"（多详细算详细？）
✅ "每个要点展开 3-5 句话"
❌ "重点突出"（哪些是重点？）
✅ "前 3 点用加粗，其余正常"
量化维度：字数、段落数、要点数、时间范围、数据精度。
法则 3：正向指令优于负向
❌ "不要用专业术语"（模型需先想术语再避免，易出错）
✅ "用初中生能理解的语言"（直接给目标风格）
❌ "不要太长"（负向，边界模糊）
✅ "控制在 300 字以内"（正向，边界清晰）
原理：LLM 是生成模型，"不要做X"需先激活X的表示再抑制，不如直接引导到正确方向。
法则 4：一次一个指令
❌ "总结这篇文章并翻译成英文然后评价质量"
→ 模型可能漏掉某步或顺序混乱
✅ "请按顺序完成：
1. 总结这篇文章（200 字内）
2. 将总结翻译成英文
3. 评价翻译质量（1-5 分）"
复合指令需显式编号与顺序。
法则 5：给示例胜过讲规则
❌ "输出 JSON 格式，含 name 和 age 字段"
✅ "输出如下格式：
{"name": "张三", "age": 25}"
这是 Few-shot 的简化版：一个示例胜过十句描述。
法则 6：明确不确定时的行为
❌ （未说明，模型默认编造）
✅ "若信息不足，回答'根据现有信息无法确定'，不要编造"
✅ "若多个答案都合理，列出 Top 3 并标注置信度"
这是控制 幻觉 的关键指令。
法则 7：指定输出分隔符
❌ （输出与解释混在一起，难以解析）
✅ "将最终答案放在 <answer></answer> 标签内，推理过程放在 <thinking></thinking> 内"
这对程序化处理 LLM 输出至关重要。
法则 8：提供验证标准
✅ "完成后自检：
1. 字数是否 ≤500？
2. 是否包含 3 个数据点？
3. 是否有编造内容？
若不满足，修正后重新输出。"
让模型自我审查，相当于内置一轮 Self-Consistency 的验证。
常见歧义模式
模式 1：程度副词歧义
| 模糊 | 精确 |
|---|---|
| "简短" | "≤100 字" |
| "详细" | "每个要点 3-5 句" |
| "重要" | "影响营收的" |
| "近期" | "过去 7 天" |
| "多个" | "3-5 个" |
模式 2：指代歧义
❌ "把它改好"（"它"指什么？"好"是什么？）
✅ "把第二段的论据补充具体数据，每句至少一个数字"
模式 3：格式歧义
❌ "用表格"（几列？什么表头？）
✅ "用 3 列表格：维度 | 现状 | 建议"
模式 4：范围歧义
❌ "分析竞品"（哪些竞品？分析什么维度？）
✅ "分析 Notion 和 Obsidian 在'协作功能'和'价格'两个维度的差异"
模式 5：优先级歧义
❌ "要全面但要简洁"（矛盾）
✅ "优先保证关键信息完整，次要信息可省略，总字数 ≤500"
实战：从模糊到精准
优化前（模糊）
帮我写个产品介绍，要好一点，吸引人。
问题：无角色、无格式、无字数、"好"与"吸引人"无定义。
优化后（精准）
你是资深产品文案。请为以下产品写一段介绍：
产品：{{product_name}}
卖点：{{selling_points}}
目标用户：{{audience}}
要求：
1. 字数 150-200 字
2. 开头一句话点出核心价值
3. 包含 2-3 个具体卖点（用数据或场景）
4. 结尾一句行动号召
5. 语气：专业但不生硬，像朋友推荐
输出格式：
直接输出文案，不要加"以下是产品介绍"等前缀。
自检：
- 字数是否在 150-200？
- 是否有具体卖点？
- 是否有行动号召？
若不满足，修正后输出。
指令测试方法
方法 1：边界测试
故意给边缘输入，看指令是否hold住：
指令："提取姓名，输出 JSON"
测试输入：
- 正常："张三" → {"name":"张三"}
- 边界："张三李四" → {"name":["张三","李四"]} 还是 {"name":"张三李四"}？
- 异常："abc" → {"name":null} 还是报错？
若边缘行为不符合预期，需在指令中补充约束。
方法 2：反转测试
把指令给另一个人（或另一个 LLM），看他能否完全复述你的意图。若不能，说明指令有歧义。
方法 3：A/B 对比
同一任务写两个版本指令，对比输出质量：
版本 A："总结这篇文章"
版本 B："用 3 个要点总结这篇文章，每个要点 ≤50 字，标注原文段落号"
差异越大，说明指令优化的价值越大。
与其他 Prompt 技巧的关系
| 技巧 | 侧重 | 与指令工程的关系 |
|---|---|---|
| Role Prompting | 设定视角 | 指令工程的"角色"要素 |
| Few-shot | 给示例 | 指令工程的"示例"法则 |
| CoT | 推理过程 | 与指令工程互补 |
| Self-Consistency | 多次验证 | 指令工程的"验证标准"延伸 |
最佳实践：先写好指令（Instruction Engineering），再叠加角色（Role）与示例（Few-shot），最后按需加推理（CoT）与验证（SC）。
常见误区
- 误区 1：指令越长越好。冗长指令反而让模型抓不住重点，精准比详尽更重要。
- 误区 2：用 Markdown 就够清晰。格式≠指令，表格再好看，内容模糊仍会跑偏。
- 误区 3：模型够强就不需要精确指令。GPT-4o 也会因歧义跑偏，指令工程是所有模型的通用基本功。
- 误区 4：一次写完美。指令需要迭代，用边界测试发现问题再修正。
- 误区 5：约束越多越好。约束过多会相互冲突，抓核心 3-5 条即可。
- 误区 6：忽视验证标准。没有验证标准的指令等于"做完不算数"，模型可能草草了事。
进阶技巧
- 指令分层：复杂任务拆为"主指令 + 子指令"，降低单条复杂度
- 条件分支：
若 X 则 A，若 Y 则 B，让指令适配多种情况 - 优先级声明：
若约束冲突，优先满足字数 > 格式 > 语气 - 失败模式预判：
常见错误：...，请避免 - 元指令：
先复述你的理解，再执行，确保理解一致
小结
Instruction Engineering 是 Prompt 工程的地基：没有精准指令，再强的模型与再巧的技巧都发挥不出价值。八条法则的核心精神是——
把"我以为你懂"变成"我明明白白告诉你"。
当你发现 LLM 输出"差不多但不对"时，第一步不是换模型或加 CoT，而是检查指令是否有歧义。
Prompt 工程进阶系列下一篇将讲 Prompt 模板化与复用：如何把高频指令封装成可复用模板。