约 6.8k 字    24 分钟阅读

为什么大多数提示词指南只讲”是什么”不讲”为什么” #

网上充斥着”提示词技巧 100 条”之类的文章，列出各种模板和套路，却很少解释为什么这些技巧有效。结果就是：换一个模型、换一个任务，技巧就失灵了。

本文反过来，先从 LLM 的底层工作原理（Token 分词、注意力机制、上下文窗口）出发，推导出提示词设计的原则，再用 OpenAI GPT-5.5、Anthropic、Google 的开源实践验证这些原则。理解了”为什么”，你就能自己推导出”是什么”。

一个重要前提：随着模型能力提升（如 GPT-5.5），提示词的”最佳实践”正在变化——从”过程堆叠”转向”结果导向”。但底层原理不变，变的是模型对提示词的依赖程度。下文会标注哪些原则在新模型上需要调整。

消息角色：提示词的权限层级 #

Developer > User > Assistant #

OpenAI 在 Model Spec 中定义了消息角色的权限链（Chain of Command），这直接影响提示词的组织方式：

角色权限类比内容
developer最高函数定义系统规则、业务逻辑、输出格式
user次之函数参数任务输入、配置数据
assistant最低函数返回值模型生成的回复

从 token 角度理解：developer 消息中的指令在注意力计算中享有更高权重——模型被训练为优先服从 developer 指令，即使 user 消息与之矛盾。这意味着：

1
2
3
4
5
6
7
# 差：把规则和任务混在 user 消息里
user: 你是一个翻译助手，请翻译以下文本，只输出译文：
      Hello World

# 好：规则放 developer，任务放 user
developer: 你是翻译助手。只输出译文，不添加解释。
user: Hello World

分离 developer 和 user 消息不仅是 API 规范，更是利用模型训练时的注意力偏好——规则放在高权限区，模型遵循更稳定。

官方推荐的 Developer Message 结构 #

OpenAI 指南给出了 developer message 的标准段落顺序：

1
2
3
4
5
6
7
8
9
10
11
# Identity
[模型的目的、沟通风格和高层目标]

# Instructions
[生成回复的规则：该做什么、不该做什么、如何调用工具]

# Examples
[输入/输出示例，用 XML 标签标注]

# Context
[私有数据、参考文档等，通常放在末尾]

为什么 Context 放末尾？因为上下文是每次请求变化的，放末尾便于 prompt caching（后文详述），同时不干扰前面指令区的注意力。

Token：模型看到的世界不是文字 #

LLM 不读字，它读 Token #

大语言模型处理的最小单位不是字符，也不是词，而是 Token。Token 由 BPE（Byte Pair Encoding）算法对文本切分得到：

1
2
"提示词工程" → ["提示", "词", "工程"]        # 中文，约 3 token
"prompt engineering" → ["prompt", " engine", "ering"]  # 英文，约 3 token

关键特性：

现象说明对提示词的影响
常见词是单个 token“the”、”is”、”你好” 各占 1 token常见表达更省 token、更稳定
生僻词被拆碎罕见术语可能拆成 3-5 个子词模型对生僻词理解更模糊
空格也是 token“ hello” 和 “hello” 是不同的 token多余空格可能影响模式匹配
标点边界“你好。”和”你好” 是不同的 token 序列标点影响模型对句子边界的感知
中英文混合成本高中文一字约 1-2 token，英文一词约 1-3 token同样上下文窗口，中文能放更多内容

从 Token 角度理解提示词质量 #

一个 8192 token 的上下文窗口，不是 8192 个”信息单元”。如果提示词中充满冗余表述、模糊指代、无关上下文，有效信息密度很低，模型需要在大量噪声 token 中寻找关键信号。

好的提示词 = 高信息密度的 token 序列。

1
2
3
4
5
6
7
8
9
# 差：低密度，大量 token 浪费在客套上
你好，我想请你帮我做一件事，就是帮我写一段代码，用Python语言，
实现一个快速排序算法，如果你方便的话能不能帮我写一下，谢谢你了

# 好：高密度，每个 token 都在传递信息
用 Python 实现快速排序，要求：
1. 原地排序，空间复杂度 O(log n)
2. 包含类型注解
3. 处理空列表和单元素列表的边界情况

注意力机制：模型如何”阅读”你的提示词 #

自注意力的本质 #

Transformer 的核心是自注意力（Self-Attention）：对于序列中的每个 token，模型计算它与所有其他 token 的关联强度（注意力分数），然后加权聚合信息。

1
注意力分数 = softmax(Q · K^T / √d_k)

这意味着：

  1. 每个 token 都在和所有其他 token “对话”
  2. 距离近的 token 通常注意力更高（但非绝对）
  3. 重复出现的 token 会强化对应位置的注意力
  4. 关键词越独特，越容易获得高注意力权重

从注意力角度理解提示词原则 #

原则 1：关键信息放前面或后面，别埋在中间 #

研究表明，LLM 存在 “中间遗忘”（Lost in the Middle）现象：位于上下文中间位置的信息，注意力分数系统性偏低。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 差：关键要求埋在中间
你是一个专业的翻译助手。你需要帮助用户翻译各种文本。
你的翻译应该准确、流畅、自然。请在翻译时注意保持原文的语气和风格。
【关键：只翻译用户提供的文本，不要添加任何解释或注释】
如果你遇到不确定的地方，可以保留原文。请开始工作吧。

# 好：关键信息前置 + 末尾强调
【规则】只翻译用户提供的文本，不添加解释或注释。

你是专业翻译助手，翻译需准确、流畅，保持原文语气和风格。

以下是需要翻译的文本：
<text>

再次提醒：只输出翻译结果，不添加任何解释。

原则 2：用分隔符划清注意力边界 #

分隔符（如 ###、---、XML 标签）在 token 层面创造了清晰的边界，帮助模型区分”指令区”和”数据区”，避免注意力跨区泄漏。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Anthropic 的 XML 标签法（Claude 推荐）
请总结以下文档的关键要点。

<document>
<long_text>
</document>

请用以下格式输出：
<summary>
- 要点 1
- 要点 2
</summary>

# OpenAI 的分隔符法（GPT 推荐）
请总结以下文档的关键要点。

"""
<long_text>
"""

输出格式：用 3 个要点概括。

为什么 XML 标签更好？因为 <document> 和 </document> 是明确的 token 序列，模型在训练数据中见过大量类似结构，注意力能精确匹配开闭标签。而 """ 在代码中常表示多行字符串，语义不如 XML 标签明确。

原则 3：重复关键词强化注意力信号 #

注意力机制中，重复出现的 token 会在多个位置产生注意力峰值，形成”注意力锚点”。

1
2
3
4
5
6
7
8
9
# 差：每次换不同说法
你是一个翻译助手。请将下面的内容转成英文。翻译时要保持通顺。
转换完成后，请检查一遍译文。

# 好：统一用"翻译"，强化注意力锚点
你是翻译助手。请翻译以下文本。
翻译要求：准确、通顺、保持原文语气。
翻译完成后，检查译文是否有遗漏。
只输出翻译结果，不要输出其他内容。

上下文窗口：有限空间的分配艺术 #

上下文窗口是零和博弈 #

模型能处理的 token 总量是固定的（如 GPT-4o 128K、Claude Sonnet 200K）。每多一个 token 的提示词，就少一个 token 的生成空间，同时也稀释了已有 token 的注意力。

1
总窗口 = 系统提示词 + 用户输入 + 历史对话 + 模型输出

上下文分配策略 #

组成部分建议占比说明
系统提示词5-15%角色、规则、输出格式
参考/示例10-30%Few-shot 示例、参考文档
用户输入10-20%实际任务数据
模型输出预留30-50%留足生成空间
缓冲10%分词误差、意外长输出

Prompt Caching：复用 token 降低成本 #

OpenAI 支持 prompt caching：如果多次请求的前缀 token 相同，缓存命中后只需计算增量部分，降低成本和延迟。

从 token 角度理解：缓存以前缀精确匹配为基础。这意味着：

  1. 不变的内容放前面：Identity、Instructions、Examples 放 developer message 开头
  2. 变化的内容放后面：用户输入、动态 context 放末尾
  3. 一个字符的差异就会 break cache：前缀必须逐 token 一致
1
2
3
4
5
6
7
# 差：动态内容在前，每次都 break cache
developer: 用户 <user_name> 你好，请翻译以下文本。规则：只输出译文。
user: <text>

# 好：静态规则在前，动态数据在后，前缀可缓存
developer: 你是翻译助手。只输出译文，不添加解释。
user: <text>

Few-Shot 示例的 token 成本 #

每个 few-shot 示例都占用上下文窗口。示例越多，模型理解越好，但可用空间越少。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 0-shot：省 token，但模型可能误解格式
请提取以下文本中的实体和关系。

# 1-shot：1 个示例锚定格式，性价比最高
请提取以下文本中的实体和关系。

示例：
输入：苹果公司CEO蒂姆·库克在加州库比蒂诺发表演讲。
输出：{"entities": [{"text": "苹果公司", "type": "ORG"}, {"text": "蒂姆·库克", "type": "PERSON"}, {"text": "加州库比蒂诺", "type": "LOC"}], "relations": [{"head": "蒂姆·库克", "relation": "CEO_OF", "tail": "苹果公司"}]}

现在请处理：
输入：<text>
输出：

# 3-shot：格式更稳定，但 token 成本 3 倍
# 仅在格式复杂或任务困难时使用

OpenAI 官方推荐用 XML 标签 + id 属性组织 Few-Shot 示例，便于模型精确匹配输入输出对：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<product_review id="example-1">
我非常喜欢这款耳机——音质太棒了！
</product_review>

<assistant_response id="example-1">
Positive
</assistant_response>

<product_review id="example-2">
续航还行，但耳垫感觉很廉价。
</product_review>

<assistant_response id="example-2">
Neutral
</assistant_response>

id 属性让模型在注意力计算时能精确关联输入和输出对，避免示例之间的注意力串扰。

检索预算：搜索的停止规则 #

GPT-5.5 引入了检索预算（Retrieval Budget）概念——本质是搜索任务的停止条件，告诉模型”什么时候证据够了”。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 差：没有停止规则，模型可能反复搜索
请搜索相关信息并回答问题。

# 好：明确的检索预算
普通问答：先用宽泛关键词搜索一次。
如果 top 结果已包含足够的可引用证据，直接回答，不要再次搜索。

仅在以下情况才再次检索：
- top 结果未回答核心问题
- 缺少必需的事实、参数、日期或来源
- 用户要求穷尽式覆盖或对比
- 需要读取特定文档、URL 或记录

不要为了改善措辞、添加示例、引用非关键细节而再次搜索。

从 token 角度看，检索预算的价值在于：避免搜索结果token 挤占上下文窗口。每次检索返回的内容都进入上下文，过多的检索结果会稀释注意力，反而降低回答质量。

Token 生成：为什么”思考过程”影响输出质量 #

自回归生成的本质 #

LLM 的生成是自回归的：每次只生成一个 token，然后将这个 token 加入序列，再预测下一个。这意味着：

  1. 已生成的 token 是后续 token 的上下文
  2. 中间推理 token 会影响最终答案的质量
  3. 早期的错误 token 会级联放大

Chain of Thought 为什么有效 #

1
2
3
4
5
6
7
8
9
10
# 不带 CoT：直接生成答案，中间没有推理 token
Q: 一个商店有 23 个苹果，卖掉 17 个，又进货 12 个，请问还有多少？
A: 18

# 带 CoT：生成推理 token 序列，每一步为下一步提供上下文
Q: 一个商店有 23 个苹果，卖掉 17 个，又进货 12 个，请问还有多少？
A: 初始有 23 个苹果。
   卖掉 17 个：23 - 17 = 6 个。
   进货 12 个：6 + 12 = 18 个。
   答案是 18。

CoT 有效的本质是：推理过程中的每个 token 都成为后续 token 的注意力上下文，相当于把”一步到位”的难题拆成了多步简单的 token 预测。

温度与采样：确定性 vs 创造性 #

温度行为适用场景提示词策略
0-0.3高确定性，倾向最高概率 token代码、数学、事实问答严格格式，明确约束
0.4-0.7平衡通用任务适度示例，清晰指令
0.8-1.0高随机性，探索低概率 token创意写作、头脑风暴开放式，鼓励发散

低温时提示词的每个 token 都至关重要（模型严格遵循）；高温时提示词更像”方向指引”（模型会自由发挥）。

Reasoning 模型 vs GPT 模型：不同的提示词策略 #

资深同事 vs 初级同事 #

OpenAI 官方用一个精妙的类比区分两类模型的提示词策略：

模型类型类比提示词策略典型模型
Reasoning 模型资深同事给目标，信任它自己规划细节o3、o4-mini
GPT 模型初级同事给明确指令，逐步指导GPT-5.5、GPT-4o

这与前述的 CoT vs Outcome-first 对应：

  • Reasoning 模型：内置 CoT（内部生成推理 token），提示词只需高层目标。过度指定过程会干扰模型自身的推理链。
  • GPT 模型：需要外部 CoT 辅助（提示词中铺设推理步骤），但也随版本提升逐渐向 outcome-first 靠拢。

选择模型的决策树 #

1
2
3
4
5
任务复杂度高？
├── 是 → 需要多步推理/规划 → Reasoning 模型（outcome-first 提示）
└── 否 → 简单生成/转换
    ├── 速度优先 → 小模型（GPT-4o-mini）
    └── 质量优先 → 大模型（GPT-5.5，outcome-first + 少量必要约束）

模型版本化：生产环境的必修课 #

OpenAI 强烈建议生产环境固定模型快照（如 gpt-5.5-2026-06-14 而非 gpt-5.5），因为同一模型的不同快照可能产生不同输出。

提示词也应版本化管理：

  • 提示词存在代码中（而非平台保存的可复用对象）
  • 用类型化函数参数注入动态值
  • 配套测试和评估套件
  • 通过部署系统灰度发布

结果导向 vs 过程堆叠：新一代模型的范式转变 #

CoT 不是万能的——推理效率的提升 #

CoT 在早期模型（GPT-3.5、GPT-4）上效果显著，因为这些模型的推理能力较弱，需要人类在提示词中铺设推理步骤。但随着模型推理能力的提升（GPT-5.5、Claude Sonnet 4），过度指定过程反而成了负担。

OpenAI GPT-5.5 官方指南明确指出：

Shorter, outcome-first prompts usually work better than process-heavy prompt stacks.

原因从 token 角度理解：

过程堆叠的问题Token 层面的影响
过多步骤指令占用上下文窗口，挤压生成空间
过度约束搜索路径缩小模型的概率搜索空间，导致机械输出
遗留旧提示词的冗余噪声 token 稀释注意力，干扰模型自身推理

描述终点，而非每一步 #

1
2
3
4
5
6
7
8
9
10
11
12
13
# 差：过程堆叠，逐步指挥
首先检查用户资格，然后查询账户余额，接着对比政策规则，
然后判断是否允许操作，然后执行操作，最后生成回复。
每一步都要详细记录。

# 好：结果导向，定义成功条件
端到端解决客户问题。

成功标准：
- 根据可用政策和账户数据做出资格判定
- 在回复前完成所有允许的操作
- 最终回复包含 completed_actions、customer_message、blockers
- 如证据不足，只询问最小缺失字段

这不是说不需要 CoT——模型内部的推理仍然需要。而是说不需要在提示词中替模型规划推理路径，让模型自己选择最高效的解决方案。

何时该用 CoT，何时该用 Outcome-first #

场景推荐策略原因
早期模型（GPT-3.5/4）CoT + 过程指导模型推理弱，需人工铺设路径
新一代模型（GPT-5.5+）Outcome-first模型推理强，过度约束反而降质
数学/逻辑题CoT 仍有效明确的推理步骤有助正确性
开放式任务Outcome-first路径不唯一，约束路径会限制创造力
Agent 工作流Outcome + 停止条件需要目标 + 何时停止的规则

开源实践验证 #

OpenAI GPT-5.5：结果导向 + 结构化模板 #

GPT-5.5 官方提示词指南代表了最新范式，核心原则：

原则底层原理实践方法
结果优先推理效率提升，过程约束变噪声描述目标 + 成功标准，不指定路径
消息角色分层注意力权限链 developer > user规则放 developer，任务放 user
Markdown + XML 格式化注意力边界 + 语义标记Markdown 标记结构层级，XML 标记内容边界
停止条件上下文窗口零和博弈明确何时重试、回退、放弃、停止
检索预算搜索结果 token 挤占窗口定义”证据够了”的判断规则
人格分离注意力分区personality（声音）与 collaboration style（工作方式）分开
Preamble自回归生成的首 token 延迟多步任务先输出简短状态更新
验证循环自回归错误的级联效应要求模型用工具检查输出
Prompt Caching前缀 token 复用降低成本静态内容前置，动态内容后置

Markdown 与 XML 的分工：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# Identity                    ← Markdown 标题标记结构层级
你是代码审查助手。

# Instructions
* 检查安全漏洞               ← Markdown 列表标记规则
* 检查性能问题

# Examples
<user_query>                  ← XML 标签标记内容边界
如何声明变量？
</user_query>
<assistant_response>
var first_name = "Anna";
</assistant_response>

# Context
<diff>                        ← XML 标签包裹动态数据
<code_diff>
</diff>

Markdown 负责结构层级（标题、列表），XML 负责内容边界（开闭标签包裹数据）。两者互补，不混用。

GPT-5.5 推荐的结构化提示词模板：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Role: [1-2 句定义模型的功能、上下文和职责]

# Personality
[语气、风格、协作方式]

# Goal
[用户可见的结果]

# Success criteria
[最终回答前必须满足的条件]

# Constraints
[策略、安全、业务、证据和副作用限制]

# Output
[章节、长度和语气]

# Stop rules
[何时重试、回退、放弃、询问或停止]

关键洞察：避免滥用绝对规则。 旧提示词常用 ALWAYS、NEVER、must 来控制行为。GPT-5.5 指南建议：这些词只用于真正的不可变规则（安全规则、必需输出字段），而非判断类决策（何时搜索、何时询问、何时使用工具）。判断类决策应该用决策规则替代绝对规则。

Agent 场景的特殊实践：

GPT-5.5 在 agentic 任务中有三个额外要求：

  1. 规划与持久性：要求模型分解子任务，每次工具调用后反思是否完整解决
  2. Preamble：调用工具前简短说明原因（但仅在关键步骤，非每步都说）
  3. TODO 跟踪：用 TODO 列表或 rubric 跟踪进度，避免遗漏步骤
1
2
3
你是一个 agent，持续工作直到用户问题完全解决。
将用户请求分解为所有必需的子请求，逐一确认完成。
不要只完成部分请求就结束。每次工具调用后反思结果。

Anthropic：结构化标签 + 角色预填 #

Anthropic（Claude）的实践强调两点：

1. XML 标签结构化

1
2
3
4
5
6
7
8
9
10
11
<role>你是代码审查专家</role>
<context>这是一个 Python Web 项目的 PR</context>
<instructions>
  1. 检查安全漏洞
  2. 检查性能问题
  3. 检查代码风格
</instructions>
<code><diff></code>
<output_format>
  按严重程度排序，每条包含：行号、问题、建议
</output_format>

为什么有效：XML 标签在 token 层面创造了明确的语义边界，模型的注意力能精确定位到每个区块，不会把”角色”和”指令”混为一谈。

2. 预填充回答前缀

1
2
Human: 请用 JSON 格式输出分析结果。
Assistant: {

让模型从 { 开始续写，因为第一个 token 已被固定为 {，后续 token 的概率分布被强烈约束在 JSON 格式内。

Google：CRISPE 框架 #

Google 提出的 CRISPE 框架，本质是对提示词的 token 分区设计：

字母含义Token 分区
CRCapacity & Role（角色）前置 token，设定模型行为模式
IInsight（洞察）背景上下文，提供注意力素材
SStatement（指令）核心任务，最高注意力权重区
PPersonality（个性）输出风格约束
EExperiment（实验）迭代优化

提示词反模式 #

反模式 1：过度礼貌 #

1
2
3
4
5
# 差：浪费 token，分散注意力
麻烦您了，如果您有空的话，能不能帮我看看这段代码有没有什么问题呢？非常感谢！

# 好：直接明确
审查以下代码的安全漏洞和性能问题。

反模式 2：负面指令过载 #

1
2
3
4
5
6
7
# 差：大量"不要"指令，注意力分散在禁止项上
不要使用 var，不要用 console.log，不要用回调函数，不要用 any 类型，
不要用 require，不要用同步方法，不要用全局变量，不要用 eval...

# 好：转为正面指令，告诉模型"做什么"
使用 const/let 声明变量，用 TypeScript 类型注解，
用 ES Module import，用 async/await 异步。

注意力机制对”不做什么”的处理弱于”做什么”——因为”不要 X”中的 X 本身会被注意力捕获，反而激活了相关概念。

反模式 3：模糊的格式要求 #

1
2
3
4
5
6
# 差："格式好看一点"
请把结果整理得好看一点。

# 好：精确到 token 级别的格式约束
输出格式：
{"summary": "一句话摘要", "key_points": ["要点1", "要点2"], "sentiment": "positive|negative|neutral"}

反模式 4：上下文过载 #

1
2
3
4
5
6
7
8
# 差：把整个项目代码塞进上下文，信号被噪声淹没
这是整个项目的代码（5000行），请帮我找到 login 函数的 bug。
<5000行代码>

# 好：只给相关函数，附上调用关系
以下是 login 函数及其调用的辅助函数（共 80 行），用户报告登录失败。
<相关函数代码>
调用链：login() → authenticate() → checkPassword()

反模式 5：过程堆叠（GPT-5.5 特别警告） #

1
2
3
4
5
6
7
8
9
# 差：逐步指挥，缩小模型搜索空间
首先检查 A，然后检查 B，然后逐字段对比，
然后思考所有可能的异常，然后决定调用哪个工具，
然后调用工具，然后向用户解释整个过程。

# 好：定义终点和成功条件，让模型选路径
端到端解决用户问题。
成功标准：资格判定完成、允许的操作已执行、回复包含必要字段。
用最少的工具循环完成，但不要为减少循环而牺牲正确性。

反模式 6：滥用绝对规则 #

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 差：ALWAYS/NEVER/must 泛滥，判断类决策被僵化
你必须 ALWAYS 先搜索再回答。
你 NEVER 不能猜测。
你 must 使用工具验证每个事实。
你 only 能输出 JSON。

# 好：绝对规则只用于真正的不变量，判断类用决策规则
# 绝对规则（安全/格式）
输出必须是合法 JSON。
不要在回复中包含用户 API key。

# 决策规则（判断类）
搜索后再回答，除非你已有足够的上下文证据。
不确定时询问用户，而非猜测。

提示词评估清单 #

基于上述原理，一份好的提示词应通过以下检查：

  • 信息密度：是否每个句子都在传递有效信息？有无客套话和冗余？
  • 消息角色分层：规则是否放在 developer 消息中？任务数据是否放在 user 消息中？
  • 注意力聚焦：关键要求是否在开头和结尾？是否被埋在中间？
  • 边界清晰：是否用 Markdown 标记结构层级、XML 标签标记内容边界？
  • 关键词一致：同一概念是否始终用同一个词？避免同义词分散注意力？
  • 正面表述：是否用”做什么”替代了”不做什么”？
  • 上下文精简：是否只包含必要的信息？有无过载？
  • 格式明确：输出格式是否用具体示例或模板定义？
  • Few-Shot 必要性：0-shot 能否完成？1-shot 是否足够？避免过度示例？
  • 模型类型匹配：Reasoning 模型用 outcome-first？GPT 模型是否需要更多约束？
  • CoT vs Outcome-first：模型是否足够强到用 outcome-first？还是需要 CoT 辅助？
  • 停止条件：是否定义了何时重试、回退、放弃、询问或停止？
  • 检索预算：搜索任务是否有明确的”证据够了”规则？
  • 绝对规则克制：ALWAYS/NEVER/must 是否只用于真正的不变量？判断类决策是否改用决策规则？
  • Prompt Caching：静态内容是否前置？动态内容是否后置？前缀是否可缓存？
  • 版本固定：生产环境是否固定模型快照？提示词是否版本化管理？
  • Token 预算：提示词长度是否在上下文窗口的合理占比内？

总结 #

好的提示词不是”技巧堆砌”，而是对 LLM 工作原理的理解应用：

底层原理推导出的原则对应实践
Token 分词信息密度最大化删除冗余，精炼表达
消息角色权限链规则高权限、数据低权限规则放 developer，任务放 user
注意力机制聚焦关键信息首尾放置重点，Markdown+XML 划界
上下文窗口合理分配空间精简上下文，控制 Few-Shot，设检索预算
Prompt Caching前缀复用降成本静态前置，动态后置
自回归生成利用中间 tokenCoT 让模型”先想后答”（早期模型）；Outcome-first 让模型自选路径（新模型）
温度采样匹配任务确定性严格任务用低温，创意任务用高温
模型类型差异Reasoning 自主推理，GPT 需引导资深同事给目标，初级同事给步骤
推理效率提升结果导向优于过程堆叠描述终点 + 成功标准 + 停止条件，不指定每一步

理解这些原理后，面对任何新模型、新任务，你都能自己推导出合适的提示词策略，而不是死记硬背别人的模板。

参考资料 #