🏠 总目录 📚 资料库提示词工程

Prompt Engineering Best Practices for 2026(2026 年提示词工程最佳实践)

📄 来自 Claude 官方博客
原文标题
Prompt Engineering Best Practices for 2026(2026 年提示词工程最佳实践)
原文链接
https://claude.com/blog/best-practices-for-prompt-engineering
作者
Anthropic(Claude 团队)
发布日期
2025-11-10
⚠️ 本页是原文的中文结构化整理笔记(保留架构、数据、案例、结论),并非逐字翻译。具体参数与功能名更新很快,落地前请点击上方链接核对原文。

14 分钟 | ✍️ 先说清楚,再谈技巧

🎯 一句话

提示词工程的大部分收益来自把话说清楚,而不是特殊技巧。⭐ 具体就是三件事:明确目标、给出示例、说清边界和验收标准

📑 本页目录

提示词工程是获得可靠、精准 AI 输出的基本功。含糊指令与精心构造的提示词之间的差距,就是「来回澄清好几轮」与「一次到位」的差距。现代技巧要在简洁与复杂之间取得平衡。

基础技巧(五条,必须掌握)

1. 明确直白

现代模型对直接、无歧义的指令响应极好,不要指望它推断。 - 差:「做一个分析仪表盘」 - 好:「做一个分析仪表盘。包含尽可能多的相关功能和交互。不要止步于基础功能,做一个完整实现。」 - 要领:用动词开头(写/分析/生成/创建)、跳过铺垫、说明输出应包含什么而不只是主题、明确质量和深度期望

2. 提供上下文与动机

解释为什么,能让模型理解底层目标。 - 差:「绝对不要用项目符号」 - 好:「我更希望用自然段落而非项目符号,因为流畅的散文更符合我的学习方式」 - 适用:说明输出用途或受众、解释约束存在的原因、描述输出将如何被使用

3. 足够具体

包含约束、上下文、期望格式、限制条件。 - 差:「做一份地中海饮食计划」 - 好:「为糖尿病前期管理设计地中海饮食计划:每日 1,800 卡路里,强调低升糖食物。列出早、午、晚餐和一份加餐,附完整营养成分」

4. 使用示例(one-shot / few-shot)

示例演示期望的格式和语气,比描述更有效;现代模型会仔细关注示例细节。 - 适用:格式「演示比描述更容易」、需要特定语气风格、任务涉及微妙模式、简单指令结果不稳定 - 提示:先给一个示例,只有结果仍不稳定时才加更多

5. 允许表达不确定

显式允许模型承认局限而非瞎猜,可减少幻觉。 - 例:「分析这份财务数据的趋势。如果数据不足以得出结论,请直说而不要臆测。」

进阶技巧(复杂任务用)

1. 预填响应(Prefill)

替模型开个头来控制格式、语气或结构。适用:要求 JSON/XML 等结构化格式、跳过寒暄铺垫、维持特定人设。API 用法:在 assistant 消息里放一个左花括号强制纯 JSON 输出。

2. 思维链(Chain of Thought)

三种实现层次: - 基础: 加一句「一步步思考」 - 引导式: 指定推理阶段(「先想清楚什么信息对这位捐赠者有吸引力,再考虑项目层面,最后写邮件」) - 结构化:<thinking> 标签分离推理与答案

适用:扩展思考不可用时、需要可审查的透明推理、任务需多步分析。注:现代 Claude 的扩展思考已自动化这一过程。

3. 控制输出格式

现代模型对正面表述(要做什么)的响应好于负面表述(不要做什么)。 - 差:「不要用 markdown」→ 好:「用完整段落写流畅的散文」 - 技巧:让提示词本身的风格匹配你想要的输出风格

4. 提示词链(Prompt Chaining)

把复杂任务拆成顺序的多个提示词,上一步输出喂给下一步。 - 例(研究摘要):① 总结论文 → ② 审查摘要的准确性与完整性 → ③ 据反馈改进 - 适用:需要拆解的复杂请求、需要迭代精化、中间校验有价值、单个提示词结果不稳定 - 权衡:增加延迟(多次调用)但显著提升准确率

现代模型下重要性下降的技巧

技巧 过去用途 现在
XML 标签结构化 给含多种内容类型的复杂提示词增加清晰度 清晰的标题、空行和明确表述效果相当且开销更小;仅在极复杂混合内容需要绝对边界时仍有用
角色扮演(Role Prompting) 定义专家人设引导视角 过重的角色定义常常限制有用性;「你是一个有帮助的助手」优于过度具体的人设。仅在需要跨大量输出维持一致语气时有用

技巧选型框架

你的需求 用什么
特定输出格式 示例、预填、明确指令
逐步推理 扩展思考 或 思维链
多阶段任务 提示词链
透明可审查的推理 思维链 + 结构化输出
防止幻觉 允许表达不确定

常见问题排查

问题 解法
回答太泛 增加具体性、示例,或明确要求完整输出
跑题或没抓住重点 更明确地说明真实目标;提供上下文
格式不一致 加示例(few-shot)或用预填
复杂任务不可靠 拆成多个提示词(链式)
多余的开场白 用预填或明确要求直接作答
编造信息 允许它说「我不知道」
你要它实现它却只给建议 明确使用动作动词

六个常见错误

  1. 过度工程: 更长更复杂的提示词不自动更好
  2. 忽视基本功: 核心提示词不清晰时,高级技巧也救不了
  3. 指望模型读心: 含糊必然导致误解
  4. 技巧全都用上: 只挑能解决你具体问题的
  5. 跳过迭代: 第一次很少完美,要测试和精化
  6. 沿用过时技巧: XML 标签和重角色扮演在现代模型上重要性已降低

结语

提示词工程本质是沟通——用模型最能理解的方式表达意图。先掌握基础技巧,只在解决特定问题时才叠加进阶方法。

核心原则:最好的提示词不是最长或最复杂的,而是用最少的必要结构可靠达成目标的那个。

需要跨会话的常驻指令,应移到 CLAUDE.md、skills 或其他引导机制中——提示词工程是更广义的上下文工程策略的基础层。


✅ 检查点

  1. 提示词的收益主要来自哪里?
  2. 示例(few-shot)该怎么给才有效?
  3. 哪些「老技巧」现在已经不必要了?
👀 答案
  1. 把话说清楚:明确目标(要什么,不要什么)、给出示例(尤其是边界情况)、说清验收标准(怎么算做对了)。这三件事的收益远大于措辞技巧。
  2. ①覆盖边界情况而不只是典型情况——模型从典型例子里学不到「遇到异常该怎么办」;②示例之间要有区分度,别给三个几乎一样的;③格式要和你期望的输出完全一致④如果有反例,要说清为什么它是反例,只给一个「不要这样」信息量很低。
  3. ①「请一步步思考」——现在的模型默认就会,且有专门的思考机制;②角色扮演式开场(「你是一位资深专家…」)——对结果的影响远小于把任务本身说清楚;③过度拆解步骤——反而限制模型找到更好路径;④威胁或利诱式措辞——没有可靠证据支持,且让提示词更难维护。

🛑 可以停在这里

走神救援
提示词的大部分收益来自「把话说清楚」而不是技巧——明确目标、给出示例、说清边界和验收标准,这三件事收益远大于措辞。示例怎么给覆盖边界情况而不只是典型情况(模型从典型例子学不到「遇到异常怎么办」)、示例之间要有区分度、格式和期望输出完全一致给反例要说清为什么它是反例(只说「不要这样」信息量很低)。四个已不必要的老技巧「请一步步思考」(现在默认就会且有专门思考机制)、角色扮演式开场(影响远小于把任务说清楚)、过度拆解步骤(反而限制模型找更好路径)、威胁或利诱式措辞(无可靠证据且难维护)。