Claude 终极使用指南

主题

02.1 提示词的第一性原理 ​

从"模型到底在做什么"推导出提示词的四条不变量。理解这四条，你不需要背技巧清单。

读完你能做什么：面对任何新的提示词技巧，你能判断它为什么有效、什么时候会失效。

一、模型在做的唯一一件事 ​

抛开所有包装，一次推理只做一件事：

给定前面所有的 token，预测下一个 token 的概率分布，采样，重复。

所有提示词技巧的有效性，最终都必须还原到这一句话上才算真的理解了。

1.1 由此推出的第一个结论 ​

你的提示词不是"命令"，是"上下文"。

你写 请务必用中文回答 之所以有效，不是因为模型"服从"了你，而是因为在训练数据的分布里，一段包含「请用中文回答」的文本，后面接中文的概率远高于接英文。

这解释了为什么以下三种写法效果差异巨大：

text
❌ 尽量简洁一点
   → "尽量"在训练语料中经常与"但如果...就可以不"共现，约束力弱

⚠️ 请简洁
   → 有效，但"简洁"的定义完全由模型的先验决定

✅ 每个回答不超过 5 句话。不要写开场白和总结段。
   → 可验证的具体约束，模型的输出空间被真正压缩

二、四条不变量 ​

不变量 1：具体性 > 礼貌性 ​

模型不会因为你说"请"而更努力。但它会因为你给出可验证的标准而输出得更准。

弱约束强约束
写得好一点每段不超过 3 句；每个技术断言必须给出验证命令
代码要健壮处理这三种边界：空输入、超长输入（>10MB）、并发写入
尽快只给方案不给实现；实现留到我确认后
分析一下按「现状 → 问题 → 根因 → 三个候选方案 → 推荐」结构分析

自检方法：读一遍你的提示词，问自己「如果模型交了一份不满意的答卷，我能指着提示词里的哪一句说它违规了？」如果指不出来，说明约束不够具体。

不变量 2：结构 > 篇幅 ​

一段 500 字的散文式提示词，效果通常不如 200 字的结构化提示词。

原因：注意力机制在处理有明确边界的块时，比处理连续散文更容易维持指令的独立性。当你把「背景」「任务」「约束」「输出格式」混在同一段里，它们在表示空间中相互干扰。

text
❌ 散文式
我在做一个电商系统，最近发现订单模块有性能问题，可能是数据库查询的问题，
也可能是缓存没配好，你帮我看看应该怎么排查，最好给个步骤，另外我们用的是
MySQL 8 和 Redis，团队只有 3 个人，时间比较紧，所以方案不要太复杂，
输出的时候麻烦用表格。

✅ 结构式
<context>
电商系统订单模块出现性能问题。
技术栈：MySQL 8 + Redis。团队 3 人，时间紧张。
</context>

<task>
给出性能问题的排查步骤。
</task>

<constraints>
- 方案复杂度限制在 3 人团队 1 周内可完成
- 每一步必须给出具体的诊断命令或 SQL
- 按「最可能 → 最不可能」排序
</constraints>

<output_format>
表格：| 步骤 | 诊断方式 | 若命中说明什么 | 修复动作 |
</output_format>

第二种写法的字数更少，但每条指令都在独立的容器里，不会互相稀释。这是 02.2 XML 标签控制术 的理论基础。

不变量 3：正向指令 > 负向指令 ​

text
❌ 不要写太长
❌ 不要用专业术语
❌ 不要给我一堆废话

✅ 每个回答控制在 200 字以内
✅ 面向没有相关背景的读者，术语首次出现时用一句话解释
✅ 第一句话直接给结论

为什么：负向指令要求模型先激活"不该做的事"的表示，再抑制它。这在概率空间里是一个更弱的操作 —— 类似于「不要想一只粉红色的大象」。正向指令直接指向目标分布。

例外：当某个错误行为非常具体且高频时，负向指令是有效的补充：

text
✅ 金额计算一律用 BigDecimal。禁止使用 double 或 float。

注意这里是「正向 + 负向」的组合，正向指令给出替代方案，负向指令封死具体的错误路径。单独的负向指令才是无效的。

不变量 4：位置携带权重 ​

上下文中不同位置的内容，对输出的影响力不同。粗略的排序：

text
影响力：  最近的用户消息  >  系统提示词  >  上下文开头  >  上下文中段

实践推论：

内容该放哪
长文档、参考资料靠前（上下文开头）
稳定的角色与规则系统提示词 / [Custom Instructions] (自定义指令)
本轮的具体任务与格式要求最后（紧邻你的提问）
最关键的一条约束在最后重复一遍

这条不变量在长上下文中影响巨大，完整机制见 03.2 注意力分布与位置效应 与 04.2 注意力机制自白。

三、一个把四条不变量全用上的模板 ​

text
<!-- 不变量 4：长资料放最前 -->
<reference_material>
{此处粘贴长文档 / 代码 / 数据}
</reference_material>

<!-- 不变量 2：结构化分块 -->
<role>
你是一名有 10 年经验的分布式系统工程师，擅长在资源受限的团队中做务实取舍。
</role>

<context>
{项目背景，3-5 条事实}
</context>

<task>
{一句话说清要做什么}
</task>

<!-- 不变量 1：具体、可验证 -->
<constraints>
- {约束 1，含可验证的标准}
- {约束 2}
- 上述材料未涵盖的信息，明确标注「材料未涵盖」，不要基于通用经验推测
</constraints>

<!-- 不变量 3：正向表述 -->
<output_format>
按以下结构输出：
1. 结论（不超过 3 句）
2. 依据（每条注明出自材料的哪一部分）
3. 未知项与需要我补充的信息
</output_format>

<!-- 不变量 4：最关键约束在末尾重复 -->
再次强调：每个结论必须能追溯到 reference_material 中的具体位置。

四、什么时候不需要这么复杂 ​

上面的模板适用于高风险、可复用、需要稳定输出的场景。日常对话没必要这样写。

判断标准：

场景用法
一次性的简单问题直接问，一句话
你会重复问 10 次的问题花 10 分钟写成模板
输出要给别人看 / 进生产完整结构化
探索性讨论自然对话，边聊边收敛

提示词工程的真正成本不在写，在于验证。 一个复杂模板只有在你实际测试过 5-10 个输入之后，才知道它是否稳定。

五、检验你是否真的理解了 ​

试着解释以下现象（答案在对应章节）：

  1. 为什么把长文档放在提问前面比放在后面效果好？→ 03.2
  2. 为什么给 3 个示例比给 1 个示例效果好，但给 30 个反而可能变差？→ 02.3
  3. 为什么「先引用原文，再回答」能显著降低幻觉？→ 04.3
  4. 为什么在长会话里，你最开始定的规则会逐渐失效？→ 04.2

延伸阅读 ​

基于 VitePress 构建 · 内容采用原作者授权

© 2026 星创数学 XCMath