高 进阶
Prompt工程最佳实践#
一句话答案#
Prompt 设计核心：角色设定 + 清晰指令 + 示例（Few-shot）+ 思维链（CoT）+ 结构化输出约束。
核心要点
Prompt 在 LLM 四阶段中的位置： 预训练（学语言）→ SFT（学指令）→ RLHF/DPO（学对齐）→ Prompt 工程（引导输出，不改权重，零成本迭代）
五大核心技巧：
| 技巧 | 作用 | 示例 |
|---|---|---|
| 角色设定 | 约束输出风格和知识范围 | 你是一位资深Java架构师... |
| 清晰指令 | 明确 Do/Don’t + 输出格式；用 XML 标签、Markdown 标题等分隔符区分指令/上下文/示例/输入 | 请用JSON格式返回，包含name和reason字段 |
| Few-shot 示例 | 通过输入输出样本示范模式，示例要多样、有代表性 | 给 3–5 组 Q&A 示例 |
| 思维链（CoT） | 分步推理提升复杂任务准确率 | 请分步分析这个问题 |
| 结构化输出约束 | 强制返回可解析格式 | 优先用 API 的 Structured Outputs（按 JSON Schema 约束）；不支持时再在 Prompt 里给格式示例 |
高级推理模式对比：
| 模式 | 原理 | 适用场景 |
|---|---|---|
| Zero-shot | 直接提问，无示例 | 简单明确任务 |
| Few-shot | 提供 2-5 个示例 | 格式/风格约束 |
| CoT | ”分步推理” | 数学、逻辑、多步分析 |
| ReAct | Thought→Action→Observation 循环 | Agent 工具调用 |
| ToT（Tree-of-Thought） | 多路径并行推理，自评选优 | 创意探索、规划 |
常见反模式：
- 指令冲突：System Prompt 和 User Prompt 要求矛盾
- 过长且无结构的 System Prompt：没有公认的 token 阈值，问题在于堆砌互相冲突或无关的规则会稀释重点；长 Prompt 要分段、用标签结构化，关键约束放在显眼位置
- 缺少负面约束：只说”要做什么”不说”不要做什么”，模型容易越界
- Few-shot 顺序敏感：研究发现模型对示例顺序和标签分布有偏好（如偏向最后出现的示例），示例要多样并打乱顺序，别让所有示例长得一样
推理模型与新一代模型的提示差异（以官方文档为准）：
| 要点 | 官方建议 |
|---|---|
| 显式 CoT | 推理模型（OpenAI 的 o 系列与 GPT-5 及之后的模型、开启 thinking 的 Claude）内部已经会推理，OpenAI 明确说写”think step by step”没有必要；Claude 文档建议给”想透彻一点”这类高层指令，通常比手写分步计划效果更好。只有在关闭 thinking 时，才用手动 CoT（如让模型在 <thinking> 标签里推理、<answer> 里给结论）作为后备 |
| Few-shot | OpenAI 建议推理模型先试零样本，确有需要再加示例且要与指令严格一致；Claude 文档仍推荐 3–5 个多样的示例，开启 thinking 时可在示例里用 <thinking> 标签示范推理方式 |
| 推理强度 | 不再靠 Prompt 喊”多想想”，而是用 API 参数控制：OpenAI 的 reasoning.effort（Chat Completions 里是 reasoning_effort）；Claude 新模型用 adaptive thinking + effort 参数，旧的 budget_tokens 已弃用 |
| System / Developer 消息 | OpenAI 推理模型用 developer message 承担原 system message 的角色；Claude 在 system prompt 里设定角色，一句话也有效 |
| Prefill（预填 assistant 开头） | Claude 从 4.6 系列起不再支持在最后一个 assistant 轮预填内容（请求会报错）；原来靠预填强制 JSON、跳过开场白的做法，改用 Structured Outputs 或在 system prompt 里直接要求 |
面试回答（2分钟版）
Prompt工程要放在LLM整个训练流程中理解。模型先经过预训练在海量语料上学习语言能力，然后通过SFT有监督微调学会遵循指令，再用RLHF强化学习对齐人类价值观，最后到使用时的Prompt工程阶段——不修改模型权重，通过设计输入来引导输出。Prompt设计的核心技巧可以总结为五步：第一是角色设定，给模型一个专家身份来约束输出风格和范围；第二是清晰指令，明确告诉模型要做什么、不做什么、输出格式是什么；第三是Few-shot示例，给几个输入输出样本让模型理解期望模式；第四是思维链CoT，让模型分步推理而不是直接给答案，显著提升复杂任务的准确率；第五是结构化输出约束，要求返回JSON或特定格式方便下游解析。实践中，好的Prompt工程能让同一个模型的表现提升非常大，而且迭代成本极低。需要调用外部工具时，还可以用ReAct模式让模型在推理和行动之间交替，实现更复杂的多步骤任务。另外要注意推理模型的差异：它们内部已经会推理，不需要再写“一步步思考”，推理强度改用 API 的 effort 参数控制，few-shot 也建议先试零样本。
追问与易错
追问方向：
- CoT 和 Few-shot 什么时候组合用？什么时候只用其中一个？ → 复杂推理 + 格式约束时组合用（Few-shot 示范格式 + CoT 引导推理）。简单任务只需 Few-shot，纯推理任务只需 CoT
- 结构化输出不稳定（模型偶尔不按格式返回）怎么办？ → 优先用 API 的 Structured Outputs：OpenAI 用
response_format的json_schema类型并开strict（官方建议尽量用它代替只保证合法 JSON、不保证符合 Schema 的 JSON modejson_object），Claude 用output_config.format（json_schema）或工具定义上的strict: true；模型或平台不支持时，再用 Prompt 给 Schema 示例 + 代码层解析容错（校验失败重试） - Prompt 太长 token 成本高怎么优化？ → 精简 System Prompt（去冗余指令）、上下文压缩（摘要替代原文）、渐进式披露（按需加载工具描述）。通常可减 30-50% input token
- 对推理模型还要写“请一步步思考”吗？ → 一般不用。推理模型内部已经做推理，官方建议给清晰的目标和约束、保持简洁，推理深度用 effort 类参数调；只有关闭 thinking 的模型才需要手动 CoT
- 还能用 prefill 强制输出格式吗？ → 看模型。Claude 4.6 及之后的模型不再支持预填最后一个 assistant 轮，改用 Structured Outputs 或直接指令；仍支持预填的旧模型可以用，但迁移时要替换掉
- ReAct 和纯 CoT 在 Agent 场景的区别？ → CoT 是”想完再说”（一次性输出推理链），ReAct 是”边想边做”（思考→调工具→看结果→再思考），Agent 场景需要 ReAct 因为要和外部交互
易错点：
- ❌ “Prompt 越长越好” → 过长导致注意力稀释，关键信息被忽略（lost in middle）
- ❌ “CoT 对所有任务都有效” → 简单任务用 CoT 反而降低效率、增加成本；对推理模型额外写 CoT 指令也基本没有收益
- ❌ “Few-shot 示例越多越好” → 通常 3-5 个足够，过多占用 token 且边际收益递减