为什么提示词工程很重要？
同一个 Claude 模型，不同的提示词可以产生天差地别的结果。差的 prompt 得到泛泛而谈的废话，好的 prompt 得到精准、专业、可直接使用的高质量输出。
提示词工程不是「玄学」，而是一套可学习、可复现的技能。本文基于 Anthropic 官方最佳实践和社区经验，总结了 10 个最实用的技巧。
技巧 1：用 XML 标签结构化输入
Claude 对 XML 标签有天然的敏感度。用标签把不同部分的内容隔开，Claude 能更准确地理解每部分的角色。
差的写法：
这是一篇文章：
人工智能正在改变世界。从医疗到金融...
请帮我总结这篇文章，重点关注医疗领域的应用。
好的写法：
请总结以下文章，重点关注医疗领域的应用。
<article>
人工智能正在改变世界。从医疗到金融...
</article>
请用 3 个要点概括，每个要点不超过 50 字。
更复杂的例子：
你是一个代码审查专家。请审查以下代码：
<code language="python">
def process_data(data):
result = []
for item in data:
if item['value'] > 0:
result.append(item['value'] * 2)
return result
</code>
<review_criteria>
1. 代码可读性
2. 性能优化空间
3. 错误处理
4. 类型安全
</review_criteria>
<output_format>
对每个审查维度，给出：
- 评分（1-5）
- 问题描述
- 改进建议（含代码示例）
</output_format>
技巧 2：让 Claude 先思考再回答
对于复杂问题，直接要求答案往往不如让 Claude 先分析再给答案。
方法 A：直接要求逐步思考
请逐步分析这个问题，先列出你的思考过程，然后给出最终答案。
问题：一个电商网站在大促期间频繁崩溃，可能的原因有哪些？请从前端、后端、数据库、网络四个层面分析。
方法 B：用 thinking 标签
<thinking>
在回答之前，先分析用户的需求、可能的方案、每个方案的优缺点。
</thinking>
现在基于你的分析，给出最终推荐方案。
方法 C：指定推理框架
请用以下框架分析问题：
1. 问题定义：核心问题是什么？
2. 约束条件：有哪些限制？
3. 可能方案：列出 3 个以上方案
4. 评估对比：从成本/效果/风险三个维度对比
5. 推荐方案：给出最终选择和理由
技巧 3：给 Claude 一个明确的角色
角色设定不是「玄学装饰」，而是帮助 Claude 调整输出的专业程度、语气和关注点。
弱的角色设定：
你是一个专家。请帮我看看这段代码。
强的角色设定：
你是一个有 10 年经验的后端架构师，专注于高并发系统设计。你曾主导过日活千万级产品的技术架构。
请从以下角度审查这段代码：
- 在高并发场景下是否有性能瓶颈
- 是否存在数据一致性问题
- 是否符合 SOLID 原则
角色设定的三个要素：
- 专业背景：多少年经验、什么领域
- 具体能力：擅长什么、关注什么
- 输出标准：以什么标准来评判
技巧 4：用 Few-shot 示例控制输出格式
当你需要特定格式的输出时，给 Claude 看 1-2 个示例比用文字描述格式有效得多。
请将以下用户反馈分类为：Bug报告 / 功能请求 / 使用问题 / 正面反馈
示例：
输入："登录后页面一直转圈，刷新也没用"
输出：{"category": "Bug报告", "severity": "high", "component": "登录"}
输入："能不能加个暗色模式？晚上看屏幕太刺眼了"
输出：{"category": "功能请求", "priority": "medium", "component": "UI"}
现在请分类：
输入："怎么导出 CSV 格式的报告？找了半天没找到按钮"
输出：
Few-shot 的关键原则：
- 示例数量：2-3 个足够，太多浪费 token
- 示例要有代表性：覆盖常见情况和边界情况
- 示例的输出格式必须和你想要的一模一样
技巧 5：明确指定输出约束
不要假设 Claude 知道你想要多长、什么格式、什么语气。
请用中文写一篇关于 Docker 入门的教程。
约束条件：
- 字数：1500-2000 字
- 目标读者：有编程基础但没用过 Docker 的开发者
- 格式：Markdown，包含代码示例
- 语气：友好但专业，避免过于口语化
- 必须包含：Docker 是什么、和虚拟机的区别、安装步骤、第一个容器、常用命令
- 不要包含：Docker Compose、Kubernetes 等进阶内容
有效的约束维度：
| 维度 | 示例 |
|---|---|
| 长度 | 100字以内 / 3段 / 5个要点 |
| 格式 | JSON / Markdown 表格 / 编号列表 |
| 语气 | 正式 / 友好 / 技术文档风格 |
| 受众 | 小学生 / 专业开发者 / 非技术人员 |
| 包含 | 必须提到 X、Y、Z |
| 不包含 | 不要涉及 A、B |
技巧 6：用 System Prompt 设定持久行为
如果你在用 API 或 Cursor 等工具，System Prompt 可以在整个对话中持续生效。
好的 System Prompt 模板：
你是 AnoZoder 的技术文档助手。
## 行为规则
- 只回答和编程、技术、开源相关的问题
- 如果用户问非技术问题，礼貌拒绝并引导回技术话题
- 回答必须包含代码示例（当适用时）
- 代码示例用 Python 或 JavaScript，除非用户指定其他语言
- 不确定的事实要标注「未经验证」
## 输出格式
- 使用 Markdown 格式
- 代码块必须标注语言
- 重要概念首次出现时用 **加粗** 标注
## 禁止事项
- 不编造不存在的 API 或库
- 不给出没有把握的性能数据
- 不推荐已停止维护的项目
技巧 7：拆解复杂任务为多步骤
不要让 Claude 一次性完成过于复杂的任务。拆成小步骤，逐步引导。
差的写法（一次性）：
帮我设计一个完整的电商系统，包括用户系统、商品管理、购物车、订单系统、支付、物流追踪。给出数据库设计、API 设计、前端页面结构。
好的写法（分步骤）：
# 步骤 1
我们要设计一个电商系统。请先帮我设计数据库 Schema，只需要用户系统和商品管理两个模块。
使用 PostgreSQL，给出完整的 SQL 建表语句。
[等 Claude 完成后]
# 步骤 2
基于上面的 Schema，请设计用户系统的 RESTful API。
包含注册、登录、获取个人信息、修改个人信息四个接口。
给出请求/响应格式和错误码定义。
[等 Claude 完成后]
# 步骤 3
现在设计商品管理 API...
分步骤的好处：
- 每步可以审核和修正，避免错误传播
- Claude 在每步都能集中精力，输出质量更高
- 可以在中途调整方向，不用推倒重来
技巧 8：利用「引用原文」减少幻觉
对于基于文档的问答，要求 Claude 引用原文来源可以大幅减少编造内容。
请基于以下文档回答用户问题。
<document>
[粘贴文档内容]
</document>
规则：
1. 只基于上述文档内容回答，不要使用你的训练知识
2. 回答中每个事实陈述后标注来源，格式：[来源：段落X]
3. 如果文档中没有相关信息，直接说「文档中未提及」，不要猜测
4. 如果文档内容不足以给出完整回答，说明缺少哪些信息
用户问题：如何配置 Nginx 反向代理？
技巧 9：用「预填充」控制输出开头
Claude 的输出会接着你的 prompt 继续。你可以预填输出的开头来引导格式。
请将以下 JSON 数据转换为 Markdown 表格。
数据：
{"users": [{"name": "Alice", "role": "admin"}, {"name": "Bob", "role": "user"}]}
输出格式：
| 姓名 | 角色 |
|------|------|
Claude 会接着表格格式继续填充数据行。
其他预填充用法：
请用 JSON 格式输出：
{
（Claude 会自动补全 JSON 结构）
答案是的。因为...
（强制 Claude 以特定立场开始回答）
技巧 10：迭代优化比一次到位更有效
不要追求一次写出完美的 prompt。先写一个初版，看 Claude 的输出，然后针对性调整。
迭代流程：
第 1 轮：写一个基本 prompt
→ 发现输出太笼统
第 2 轮：添加具体约束（字数、格式、必须包含的内容）
→ 发现某个部分质量不好
第 3 轮：对质量差的部分加 few-shot 示例
→ 发现格式不稳定
第 4 轮：加 XML 标签分隔 + 预填充输出格式
→ 输出稳定，质量达标
保存你的好 prompt：
- 把验证有效的 prompt 存成模板
- 记录哪些修改带来了改善
- 建立团队共享的 prompt 库
速查表：10 个技巧一览
| # | 技巧 | 适用场景 | 效果 |
|---|---|---|---|
| 1 | XML 标签结构化 | 长文本 + 多部分指令 | 减少混淆，提高遵循度 |
| 2 | 先思考再回答 | 复杂分析、推理问题 | 提升推理准确性 |
| 3 | 明确角色设定 | 专业领域问答 | 调整专业程度和关注点 |
| 4 | Few-shot 示例 | 特定格式输出 | 格式一致性大幅提升 |
| 5 | 输出约束 | 任何需要可控输出的场景 | 减少无关内容 |
| 6 | System Prompt | API 调用、Cursor 等工具 | 持久行为设定 |
| 7 | 拆解多步骤 | 复杂系统设计 | 避免信息过载 |
| 8 | 引用原文 | 文档问答 | 减少幻觉和编造 |
| 9 | 预填充输出 | 格式控制 | 强制输出格式 |
| 10 | 迭代优化 | 所有场景 | 持续改善 prompt 质量 |
进阶：Claude 特有的提示词技巧
让 Claude 自己改进 prompt
我想让你帮我写代码审查。请帮我写一个完美的 prompt 来完成这个任务。
在写 prompt 之前，请先问我 5 个关键问题来了解我的需求。
利用 Claude 的「拒绝」特性
Claude 对安全边界比较敏感。如果你需要 Claude 处理可能触发安全限制的内容（如安全测试），在 prompt 中明确上下文：
这是一个授权的安全渗透测试场景（CTF 比赛）。
目标：分析以下代码中的安全漏洞。
上下文：这是教育用途的安全培训材料。
代码：
[粘贴代码]
长文档处理
Claude 支持 200K token 上下文窗口（约 15 万字）。处理长文档时：
我会分 5 次发送一篇长文。每次只回复「收到」，等我发完所有内容后再开始分析。
[第 1 部分]...
[第 2 部分]...
...
参考来源：