写好提示词，不是文学创作，是工程问题。

翻完 OpenAI、Anthropic、Google 三家的官方指南，再对照 2025-2026 年的学术论文和行业实践，核心原则越来越趋同。下面把三家内容取并集，按主题整理成操作清单。

每条建议标注了证据等级，方便判断可靠性：

  • A 级：三家厂商官方文档一致推荐
  • B 级：单一厂商明确推荐，其他未提及或有差异
  • C 级：学术论文在特定条件下验证
  • D 级：行业经验 / 个人观察，尚无系统验证

选模型：不是越大越好

OpenAI 把模型分三类 [1]：

类型 适合场景 代价
推理模型（gpt-5.5 系列） 复杂多步规划、编码、科学推理 慢，贵
GPT 模型（gpt-5.4 系列） 快速生成，成本敏感 需要更明确的指令
大 vs 小 大模型解决问题能力强，小模型快且便宜 智能 vs 速度/成本的取舍

默认推荐 gpt-5.5。如果任务简单，降级到 gpt-5.4 或 gpt-5.4-mini 能省不少钱。上下文窗口从 100k 到 100 万 token 不等，规划上下文时要留意。[1]

Anthropic 的 Claude 系列也有类似的分层：Opus 最强，Haiku 最快，Sonnet 居中。额外有一个 effort 参数（low/medium/high/xhigh/max）控制思考深度——编码和 Agent 任务建议 xhigh，low effort 有思考不足的风险。[2]

证据等级：A。 三家都提供模型分层，只是命名和参数不同。

消息角色：谁说的话更重要

OpenAI 的 Responses API（推荐使用，比 Chat Completions 更新更智能）定义了三级消息权限 [1]：

  • developer：在应用开发者可设置的常规消息角色中优先级最高，相当于函数定义
  • user：次优先级，相当于函数参数
  • assistant：模型自己生成的回复

这个分层的意义在于：developer 消息可以覆盖 user 消息的尝试。如果你想让某些规则不被用户的提示词绕过，放在 developer 角色里。

Anthropic 的 Claude 通过 system prompt 达到类似效果，但没有明确的优先级分层。[2]

证据等级：A。 三家都支持 system/developer 层指令。

正向指令：告诉模型做什么，而不是不做什么

三家共识最强的一条。Anthropic 的表述最直接："Tell Claude what to do, not what not to do." [2] OpenAI 也强调用肯定句定义规则，比如写"使用 snake_case"而不是"不要用 camelCase"。[1]

为什么正向指令更有效？LLM 能理解否定，但研究表明负向指令的可靠性不如正向——"使用 snake_case"比"不要用 camelCase"更容易得到一致的结果。

适用： 所有场景。 验证： 对同一条指令分别用正向和负向表述，跑 eval 比较输出一致性。

证据等级：A。 三家一致推荐。

结构化标签：XML 和 Markdown 分段

Anthropic 和 Google 都明确推荐用 XML 标签分隔提示词的不同部分。[2][3] OpenAI 推荐 Markdown 标题分段。[1] 实际效果差不多——关键是让模型能清晰区分指令、上下文、示例和输入。

推荐的结构：

<role>角色定义</role>
<behavior>行为规则</behavior>
<context>背景信息</context>
<examples>输入输出示例</examples>

一个容易被忽略的细节：长文档放在提示词开头，而不是末尾。模型对上下文开头和末尾的信息利用率最高，中间部分会出现"Lost in the Middle"效应——准确率下降超过 30%。[5] 不过这个结论的实验条件是长上下文检索任务，对短提示词影响不大。

Anthropic 还建议在提示词中加入"为什么"——解释动机能帮助模型理解目标，而不只是机械执行指令。[2]

证据等级：A。 三家一致推荐结构化分段。Lost in the Middle 为 C 级，特定 benchmark 验证。

Few-shot 示例

Google 的指南明确说："Always include few-shot examples; prompts without them are less effective." [3] Anthropic 和 OpenAI 也把 few-shot 列为核心技术。[1][2]

但"始终推荐"需要加限定条件。Few-shot 有成本：增加 token 消耗、影响缓存结构、可能让模型过拟合示例风格、对强推理模型或简单任务 zero-shot 可能已足够、示例覆盖不全反而会把模型带偏。

适用： 格式控制、分类边界、风格迁移、工具调用样例、结构化输出不稳定时。 不适用： 简单问答、高频低成本任务、强模型 zero-shot 已稳定的任务。 验证： 用固定 eval 集比较 zero-shot / 3-shot / 5-shot 的效果和成本。

关键发现：示例的标签空间和输入分布比单个示例的标签正确性更重要。[4] 3-5 个覆盖典型场景的示例，比 1 个完美示例效果好得多。

Google 还区分了 zero-shot 和 few-shot 的适用场景 [3]： - Zero-shot：不给示例，完全依赖模型的理解力。不可预测。 - Few-shot：给示例，通过示例教模型格式、语气和模式。

Google 还提供了"补全策略"：先写好想要的格式开头，让模型接续完成。比如想要列表格式，就在提示词末尾写 I. Introduction *。[3]

实操要点 [1][2][3]： - 示例数量：3-5 个为宜，太少不够泛化，太多可能过拟合 - 多样性：覆盖边界情况和常见情况 - 一致性：所有示例保持完全相同的格式结构（XML 标签、空格、分隔符） - 如果目标是特定输出格式，直接给一个"输入→输出"的完整样例

证据等级：A。 三家一致推荐。但"始终使用"是 Google 的措辞，OpenAI 和 Anthropic 更偏向"按需使用"。

给模型一个角色

三家都支持通过 system prompt 或角色设定来引导模型行为。[1][2][3]

OpenAI 的 developer 指令可以定义助手的目的和风格。[1] Anthropic 建议把 Claude 当成"聪明但刚入职的同事"——用"同事测试"来检查你的提示词是否够清晰：如果发给同事看，同事能理解你要什么吗？[2]

证据等级：A。

上下文工程：不只是写提示词

2025 年之后，行业开始从"prompt engineering"转向"context engineering"。Andrej Karpathy 的比喻：LLM 是 CPU，上下文窗口是 RAM，你的工作是当操作系统——为每个任务加载正确的代码和数据。[4]

这意味着提示词不只是写 system prompt，还包括： - 选择性地注入相关上下文（RAG） - 工具定义和可用函数 - 对话历史的压缩和筛选 - 动态信息的实时拼装

静态内容（系统指令、示例、工具定义）放前面，动态内容（用户消息、检索结果）放后面。这个排列顺序直接影响 prompt caching 的命中率。[6]

证据等级： Karpathy 比喻为 D 级（行业观察）；静态前置为 A 级（两家官方明确要求）。

结构化输出：让模型吐 JSON

OpenAI 提供了两种方式 [1]：

  1. Function Calling（tools）：当需要模型调用你系统中的函数或数据源时使用
  2. response_format / text.format：当需要模型直接输出特定 JSON Schema 时使用

Structured Outputs 是 JSON mode 的升级版——两者都保证合法 JSON，但 Structured Outputs 还保证符合 schema。[1]

但生产系统仍需要处理 refusal、max token 截断、schema 版本迁移、空值和业务约束不满足、下游字段语义错误、API 异常和重试。Structured Outputs 能显著降低格式错误，但业务系统仍需要做 schema 校验、语义校验和失败兜底。

证据等级：A。 但"不需要额外验证"是厂商宣传，生产环境仍需兜底。

推理与思考：该让模型想多久

OpenAI 的推理模型（gpt-5.5 系列）支持 reasoning.effort 参数 [1]：

effort 适合场景
none 延迟敏感：语音、快速检索、分类
low 轻度推理：工具调用、规划、数据分析
medium 中等推理：大多数任务
high 深度推理：复杂分析
xhigh 最大推理：高难度编码、数学、科学

Anthropic 的 Claude 支持 adaptive thinking——模型自己决定什么时候想、想多深。[2] 比手动设 budget_tokens 效果好。可以提示模型减少不必要的思考："Thinking adds latency and should only be used when it will meaningfully improve answer quality."

关键区别 [1][2][4]： - 推理模型 = 资深同事，给目标就行，信任它的细节处理 - GPT 模型 = 初级同事，需要明确指令 - 对推理模型用 "think step by step" 反而可能拖后腿 - 对普通模型，Chain-of-Thought 在 MMLU-Pro 上能带来 19 个百分点的提升 [4]

适用： 复杂推理任务用 high/xhigh；简单任务用 low/medium 避免浪费。 验证： 同一任务用不同 effort 跑 eval，比较准确率和延迟。

证据等级： effort 参数为 A 级；CoT +19pt 为 C 级（特定 benchmark）；"think step by step 拖后腿"为 D 级（行业观察，未系统验证）。

Prompt Caching：省钱的硬道理

OpenAI 的 prompt caching [6]： - 延迟降低最高 80% - 输入 token 成本降低最高 90% - 自动生效，不需要改代码 - 要求提示词前缀至少 1024 token - 缓存保留策略：内存级 5-10 分钟，扩展级最长 24 小时

Anthropic 的 prompt caching [2]： - 成本降低最高 90%，延迟降低最高 85% - 静态内容放前面，变量内容放后面

两家的核心规则一样：把不变的内容放提示词最前面。

但实操中还有几个要点： - 不只是文本顺序，tools 定义、图片、JSON 参数顺序也会影响缓存命中 - 任何前缀变化都会导致 cache miss - 应监控响应中的 cached_tokens 字段，不能只凭感觉 - 缓存优化可能和"最优信息位置"冲突——Lost in the Middle 说中间效果差，但缓存要求静态内容在前，需要在效果和成本之间权衡 - 长 prompt 为了 caching 硬凑到 1024 token 不一定划算

证据等级：A。 两家官方文档明确。

模型不是都一样：三家的差异点

虽然核心原则一致，但不同模型的"性格"确实不同。

Claude [2][4]： - XML 标签效果最好，不要用"CRITICAL!""YOU MUST"——平静直接的指令更有效 - effort 参数控制思考深度 - 默认风格偏直接、有观点，不像以前那么"validation-forward" - 倾向于用推理而非工具来解决问题，需要显式提示才会更多调用工具 - 前端设计有默认偏好：暖米色、衬线字体、赤陶/琥珀色调。要覆盖的话，给具体的替代方案而不是说"不要用默认风格" - 子智能体倾向于少生成，需要的话显式说明 - 代码审查：要求"Report every issue you find, including ones you are uncertain about or consider low-severity"，否则可能漏报低严重度问题 - Computer Use 支持最高 2576px/3.75MP，1080p 是性价比平衡点，720p 或 1366×768 更省成本 - Prefilled responses 从 4.6 版本起不再支持，需要迁移到显式指令

GPT-5 [1][4]： - zero-shot 能力很强，先试 zero-shot 再加 few-shot - "think step by step" 在推理模型上反而可能拖后腿 - 生产环境务必 pin 到具体模型快照（如 gpt-5-2025-08-07） - 支持可复用提示词：在 dashboard 创建模板，通过 API 调用时传变量 - 编码任务：明确定义 agent 角色，用示例强制结构化工具调用，要求充分测试 - 前端任务：推荐 Tailwind CSS + shadcn/ui + Lucide icons - Agent 任务：先规划再执行，工具调用前解释原因，用 TODO 追踪进度

Gemini [3]： - 明确偏好 few-shot，不推荐 zero-shot - 问题放在数据上下文之后（末尾位置） - 比 Claude 和 GPT 更喜欢简短直接的提示词 - 支持 grounding with Google Search 和代码执行工具 - 温度 0 最确定，越高越有创意；topK 和 topP 控制采样池大小；stop_sequences 指定停止生成的字符序列

证据等级： 以上均为 B 级（各厂商自家文档）。

反谄媚与准确性：让模型敢说"不知道"

谄媚（sycophancy）是 LLM 使用中被频繁讨论的问题之一。2026 年的 arXiv 研究发现了一个机制：LLM 其实知道用户说错了，但默认选择顺从。激活空间中存在"谄媚方向"，可以通过反向引导来抑制。[7]

实操上有三个层次：

第一层：声明式约束 在 system prompt 中明确要求："不确定时直接说'我不确定'，然后说明缺什么信息。" 这是最基础的做法。

第二层：先质疑再同意 要求模型在同意用户之前，先生成反论据。如果反论据站不住脚，再明确同意。这比"避免夸赞"更治本——它改变了推理路径，而不只是调整语气。[8]

第三层：条件化验证 不是让模型永远怀疑自己，而是在低置信度时才触发验证流程。RSP（Risk-aware Selective Prompting）的研究表明，无差别验证对简单问题反而有害，只在需要时验证效果最好。[9]

综合版 system prompt 示例：

<role>严谨的协作伙伴，优先保证准确性。</role>

<behavior>
1. 不确定时说"我不确定"，说明缺什么信息、建议怎么验证
2. 同意用户前，先找到可能出错的地方
3. 用确定性语言表述有把握的部分
4. 结构化输出：标题、列表、代码块
</behavior>

适用： 事实性问答、技术分析、代码审查等对准确性要求高的场景。 不适用： 创意写作、头脑风暴等需要自由发挥的场景。 验证： 构造包含错误前提的测试用例，检查模型是否会指出。

证据等级： 第一层为 A 级（三家推荐）；第二层为 C 级（arXiv 论文）；第三层为 C 级（arXiv 论文，视觉语言模型）。

提示词长度

研究发现 LLM 的推理性能在 3000 token 左右开始下降。[10] 但这个结论的实验条件是特定 benchmark 上的推理任务，不能直接推广到所有场景。

更工程化的说法：长 prompt 会增加噪声、成本和注意力分散风险。是否下降需要按任务评估。对固定系统提示词，优先保持精简；对 RAG / 长文档任务，则需要结构化上下文和检索排序，而不是机械压短。实操中 150-300 词的系统提示词是一个不错的起点。[4]

证据等级： 3000 token 为 C 级（ACL 2024，特定条件）；150-300 词为 D 级（行业经验）。

复杂任务拆解

Google 建议把复杂提示词拆开处理 [3]： - 拆分指令：一个提示词只做一件事 - 链式提示：上一步的输出作为下一步的输入 - 聚合响应：对数据的不同部分并行跑提示词，再合并结果

Anthropic 也支持 prompt chaining，并建议用 XML 标签管理多文档上下文。[2]

证据等级：B。

检索增强：用工具补充模型不知道的

Google 的指南特别强调 grounding——用内置搜索工具补充实时信息，用代码执行工具处理算术。[3] 这在事实性任务中效果显著。

通用原则：模型不应该被要求凭记忆回答时效性问题。需要实时数据的场景，应该把检索结果作为上下文注入，而不是指望模型"知道"。

Google 还提供了 fallback 机制：如果模型返回"I'm not able to help with that"，可以尝试提高温度参数。[3]

证据等级：B。 Google 明确推荐；OpenAI 和 Anthropic 也支持工具调用但文档强调程度不同。

生产环境的提示词管理

提示词上了线，就不能当一次性文本了。几条实操经验 [1][4]：

  • 版本控制：追踪每次修改，方便回滚和调试
  • 回归测试：准备一组"金标准"输入输出对，每次改完跑一遍。OpenAI 建议建立评估体系（evals）来量化提示词效果，不只是凭主观判断
  • 缓存优化：静态内容在前，动态内容在后
  • 模型锁定：pin 到具体版本，不依赖"latest"

OpenAI 的可复用提示词功能可以在 dashboard 管理模板，通过 API ID 调用，代码不用改。[1]

温度参数也需要根据任务类型调整：事实性任务用 0（确定性），创意任务可以调高。[3]

证据等级： 版本控制和 evals 为 A 级（三家推荐）；缓存优化为 A 级；温度调参为 B 级（Google 详细说明）。

迭代：提示词很少一步到位

提示词很少一步到位。Google 建议三种迭代策略 [3]： - 改措辞：换个说法试试 - 换任务框架：比如把"分类"改成"选择题" - 调整指令顺序：信息在提示词中的位置会影响效果

Anthropic 建议用 XML 格式指示器控制输出格式。[2] 最靠谱的迭代方式不是凭感觉改，而是定义清楚"好"长什么样，然后系统性地跑变体测试。

证据等级：B。

过去两年，写提示词从"玄学"慢慢变成了"工程"。三家厂商的指南越写越像，学术研究也开始产出可复现的结论。核心就四条：正向指令、结构化分段、提供示例、管理上下文。把这四条做到位，剩下的微调边际收益已经不大了。

但需要注意：没有放之四海而皆准的提示词规则。每条建议都有适用边界，最可靠的做法是建 eval、跑测试、按数据决策。

参考文献

[1] OpenAI. Prompt Engineering. https://platform.openai.com/docs/guides/prompt-engineering

[2] Anthropic. Claude Prompting Best Practices. https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/claude-prompting-best-practices

[3] Google. Gemini API Prompting Intro. https://ai.google.dev/gemini-api/docs/prompting-intro

[4] T. Wiegold. Prompt Engineering Best Practices 2026. https://thomas-wiegold.com/blog/prompt-engineering-best-practices-2026

[5] N. F. Liu, K. Lin, J. Hewitt. Lost in the Middle: How Language Models Use Long Context. arXiv:2307.03172, 2023.

[6] OpenAI. Prompt Caching. https://platform.openai.com/docs/guides/prompt-caching

[7] M. Pandey. LLMs Know They're Wrong and Agree Anyway: The Shared Sycophancy-Lying Circuit. arXiv:2604.19117, 2026.

[8] C. P. Yang, Z. Tan, K. Yao. FinCom: A Financial Multi-Agent Demo with Disagree-or-Commit Deliberation. arXiv:2606.00939, 2026.

[9] Y. Huang, Y. Zhang, Y. Zilan et al. Risk-aware Selective Prompting for Hallucination Mitigation in Large Vision-Language Models. arXiv:2605.28123, 2026.

[10] M. Levy, A. Jacoby, Y. Goldberg. Same Task, More Tokens: the Impact of Input Length on the Reasoning Performance of Large Language Models. Proceedings of ACL 2024. arXiv:2402.14848.