适合人群
本文适合以下读者：
- 使用 AI 工具（Claude、ChatGPT、Gemini 等）但经常得到「泛泛而谈」输出的用户
- 希望从「能用」到「精通」提示工程水平的工程师和创作者
- 对 AI 效率技巧感兴趣、希望每次对话都产出高质量结果的技术爱好者
- 希望建立系统化 AI 使用工作流的团队和个人
前置要求：有基本 AI 聊天工具使用经验，理解「提示词」这一概念。
准备清单
- ✅ 一个 AI 模型访问权限（Claude、ChatGPT、Gemini 等均可）
- ✅ 一个实际工作问题（用于练习技巧）
- ✅ 记笔记的工具（用于保存模板）
- ✅ 10 分钟练习时间
操作步骤
核心认知：模型不是瓶颈，提示词才是
2026 年的一个令人不安的真相是：模型不是瓶颈，提示词才是。
两个人用完全相同的模型、完成完全相同的任务，得到的结果可能天差地别。一个人获得的是需要全部重写的泛泛之谈，另一个得到的是可以直接使用的精准、专业输出。
差别从来不在模型，永远在提示词。
提示工程不是噱头，不是技巧，它是当前 AI 经济中最有价值的单项技能——因为它决定了每次 AI 交互的质量天花板。
而大多数人的提示工程能力很差。不是因为它难，而是因为从没人教过他们正确的方法。
本文将从入门到精通，系统性地介绍专家级提示工程技术。
第一层：基础认知——为什么大多数提示词会失败
根本原因：LLM 被训练为预测最可能的「下一个词」。当你的提示词模糊时，模型会用最统计意义上最可能的内容来填补空白——而这意味着最通用、最平均的内容。
「写一篇关于 AI 的文章」 → 产生平均内容，因为模型生成了最可能的一篇 AI 文章——听起来和所有其他 AI 文章一样。
「写一篇 1500 字的博客，讨论为什么大多数企业在 AI 落地中失败，目标读者为中型 SaaS 公司的 CTO，语气直接且数据驱动，结构为反对派开头+三个具体失败模式及案例+90天执行计划」 → 产生独特内容，因为模型有足够约束产生特别的东西。
核心原则：具体性战胜通用性。 每个添加到提示词中的细节都移除了一维模型可能落入「平均」的自由度。
专家提示词的 6 大要素
每个专家写的提示词都包含以下六要素，无论是显式还是隐式：
要素 1：角色（Role） — Claude 在这个对话中是谁？不是「一个有用的助手」，而是具体的「一个拥有 15 年 B2B SaaS 产品经验的高级产品策略师」。
你是拥有 15 年经验的 React 架构师，
曾在 AWS、Netflix 和 Vercel 工作。
对性能优化、状态管理和可维护性有深刻理解。
角色塑造了每个回答的词汇、深度和视角。
要素 2：上下文（Context） — Claude 需要了解你的什么情况？行业、受众、约束、目标。没有上下文，Claude 用假设填补空白；有上下文，它用相关信息填补空白。
背景：
- 我在开发一个面向中小企业的 CRM 系统
- 目标用户是非技术背景的销售经理
- 现有系统使用 React 18 + TypeScript
- 目前在状态管理上遇到困难（正在用 Redux）
要素 3：任务（Task） — 具体要做什么？不是「帮我做营销」，而是「写一份竞品分析，比较我们的产品在定价、功能和信息传达三个方面与三个特定竞争对手的差异」。
任务：
对比 TypeScript、Rust 和 Go 这三种语言在后端 API 开发中的适用性。
从以下维度分析：开发效率、运行时性能、生态系统成熟度、
学习曲线、团队招聘难度。
要素 4：格式（Format） — 输出应该是什么样子？
格式要求：
1. 一个对比表格（竖轴：三种语言，横轴：五个维度）
2. 用颜色标记优劣（绿色=优势，黄色=中等，红色=劣势）
3. 表格后跟一段 200 字的推荐意见
4. 最后列出在什么场景下应该选择哪种语言
要素 5：约束（Constraints） — Claude 不要做什么？
约束：
- 不要使用营销术语
- 不要包含适用于所有公司的通用建议
- 不要超过 800 字
- 不要假设读者熟悉特定数据库技术
- 如果你不确定某个数据点，明确指出「此处需要验证」
负面约束切断了最常见的失败模式。
要素 6：质量标准（Quality Standard） — 「足够好」的定义是什么？
质量标准：
分析应该足够具体，让我们的产品团队
在 5 分钟内无需追问额外信息就能做出决策。
一个专家提示词命中全部六要素。一个新手提示词通常只命中一到两个。这个差距解释了几乎所有的输出质量差异。
第二层：结构化技术
XML 标签——清晰结构
Claude 是在结构化输入上训练的。XML 标签不是 hack——而是模型处理多组件复杂提示词的设计方式。
<context>
我是一个独立开发者，正在构建一个 SaaS 应用
用于项目管理。目前使用 React + Firebase。
</context>
<task>
分析我目前技术栈的优势和局限，
并提出一个从 Firebase 迁移到 Supabase 的详细方案。
</task>
<constraints>
- 迁移方案分 5 步，每步可独立执行
- 每一步都必须保证服务不中断
</constraints>
<format>
输出为表格形式：迁移步骤 | 涉及组件 | 预计工时 | 风险等级
</format>
每种标签精确告诉 Claude 该部分的作用。上下文做背景处理，任务做指令处理，约束做边界处理。
先放上下文，后提问题
当你需要处理长文档或参考资料时，始终将内容放在问题之前：
[以下是我们公司过去 12 个月的财务数据：...]
基于上述财务数据，识别 3 个最令人担忧的趋势，
并解释为什么每个趋势需要 CFO 立即关注。
模型先处理文档、建立理解，然后带着完整的上下文遇到问题。把问题放在前面会导致回溯式重新解读，效果明显更差。
少样本示例
一条示例胜过 10 段描述。展示你想要的模式：
示例：
输入："销售增长 34% 但客户留存下降了 12%"
输出：分析：营收健康增长，但留存问题表明产品价值或用户体验存在深层问题。
输入："营销支出增长 50% 而线索量仅增长 8%"
输出：分析：营销效率显著下降，建议审视渠道ROI和目标受众精准度。
---
现在分析这条：「员工数增长了 200%，但人均产出下降了 15%」
3-5 个多样化示例（覆盖正常情况和边界情况）产生的输出质量超过了任何量的描述性指令。
第三层：高级技术
链式方法
永远不要在一个提示词中让 Claude 做五件事。把它们链起来：
提示 1：「研究建筑工程管理领域的 TOP 5 竞争对手。」
提示 2：「基于这份竞争分析，找出 3 个最大的定位空白，还没有竞品在填补。」
提示 3：「基于这些空白，为我方产品写一份定位声明，明确占据其中一个空白。」
提示 4：「根据这个定位，写首页标题、副标题和三个支撑要点。」
每个提示聚焦一件事，每步输出都有深度，你能在每步进行审查和纠正——一次性巨型提示做不到这一点。
自我纠错循环
Claude 的每个第一版回复都是草稿。让它修改：
重读你的回答。从准确性、具体性和可执行性三个维度
给自己打 1-10 分。对任何低于 8 分的维度，
解释不足在哪里并修复。只显示改进后的版本。
改进后的版本在 85-90% 的情况下更好。这只需 15 秒，就能产生可衡量的质量提升。每个重要任务都用上它。
带动机的约束
告诉 Claude 为什么约束存在，而不仅是什么约束：
差：「控制在 200 字以内。」 好：「控制在 200 字以内——这用于 Telegram 帖子，超长会被平台截断。」
差：「不要用术语。」 好：「不要用术语——读者是非技术背景的企业主，遇到不懂的词汇会直接划走。」
当 Claude 理解约束背后的原因时，它应用约束的方式会更智能，并能捕捉到单纯规则会遗漏的边界情况。
多角度分析
需要深度决策时：
从三个角度分析这个定价决策：
1. 追求增长最大化的 CEO 视角——想要最大市场占有
2. 关注利润和现金流的 CFO 视角
3. 想要公平价格的客户视角
每个角度：3 句话陈述其立场。
然后综合三个视角给出一个平衡的建议。
标明你最终权衡了哪个视角最多及其原因。
这迫使 Claude 考虑取舍，而不是优化单一维度。产生的结果比单一视角提示词好得多。
元提示词
当你写不好提示词时，让 Claude 帮你写：
我想实现的目标：[描述你的目标]
背景：[背景信息]
好的输出应该是什么样：[描述或例子]
请写出最有效的提示词来实现这个目标。
补充缺失的上下文，消除歧义，
为最高质量输出优化结构。
Claude 知道什么会产生好的输出。元提示技术利用这个知识，在你提交请求之前改进你的指令。生成的提示几乎总是比你自己写的好，因为它能捕捉到你没注意到的盲点。
第四层：系统级掌握
单个提示词是战术，系统才是战略。
上下文文件系统
为每类工作创建持久的 Markdown 文件：
- writing-rules.md — 你的语气、受众、质量标准
- analysis-framework.md — 如何评估数据、什么指标重要
- project-context.md — 当前项目、状态、关键决策
每个会话开始时：「完整阅读 [文件]。遵循每一条规则。如果你即将违反某条规则，停下来告诉我。」
Claude 会将会话全程应用文件中的规则。你永远不需要重新解释你的偏好。随着你根据输出质量更新文件，它们会越来越智能。
模板库
每个写过的好的提示词都应该保存为可复用的模板。去掉具体内容，替换为变量，保留结构。
## 模板：竞品分析
角色：{行业} 的资深产品分析师
上下文：{公司背景}，目标客户是 {目标客户}
任务：对比 {竞品A}、{竞品B}、{竞品C} 在 {维度} 方面的表现
格式：{格式要求}
约束：{约束}
质量标准：{质量标准定义}
数月后，你会积累一套覆盖所有任务类型的模板库。内容创作、分析、代码审查、战略规划、邮件撰写——你从不需要从零开始。抽取模板，填入变量，始终如一地获得优秀输出。
这种复利效应才是真正的专家优势。 每个好结果都成为下一个的基础。
每周反馈循环
每星期五：回顾本周的 AI 输出。哪些没达到预期？什么提示词改动本可以解决？应该在上下文文件中添加什么新规则？
坚持每周做这个循环三个月的人，提示能力相比一开始判若两人。不做的人会永远停留在原来的水平。
常见问题
Q: 提示工程还重要吗？AI 模型不是越来越聪明了吗？
A: 实际上，模型越聪明，提示工程越重要。随着模型变强，它们能更好地理解复杂指令，但也更容易在模糊提示下产生「过于丰富」的输出。Claude Opus 4.7 就是第一个「惩罚不良提示」的模型——模糊的提示会得到更差的结果，而精心设计的提示会产生远超平均水平的输出。更多内容参见 OPUS 4.7 提示指南。
Q: 我已经在用 AI 了，这些技巧真的值得花时间学习吗？
A: 用一个简单计算来回答：假设你每天与 AI 对话 10 次，每次平均消耗 5 分钟。如果提示工程技巧使每次对话的产出质量提升 50%（这很保守），意味着你每天节省了大约 25 分钟的重写和纠正时间。一个月就是 500 分钟。投资一小时学习这些技巧，回报是几十倍的。作为参考，Claude Code 35 个进阶技巧中提到的成本优化方法也能帮你显著降低 Token 消耗。
Q: 这些技巧适用于所有 AI 模型吗？
A: 大部分技巧适用于 Claude、ChatGPT、Gemini 等主流模型。不过有些模型对结构化提示（如 XML 标签）的支持程度不同：
- Claude：对 XML 标签、角色设定、多角度分析效果最好
- ChatGPT：对链式方法和少样本示例效果最好
- Gemini：对多模态输入（文字+图像）和上下文优先效果好
核心原则（具体性、六要素、链式方法、自我纠正）在所有模型上通用。参考 AI Agent 团队协作了解更多多模型协作策略。
Q: 什么时候应该用结构化提示词（XML/模板），什么时候应该随意聊天？
A: 区分场景：
- 高质量输出优先（写报告、做分析、写代码、规划方案）→ 用结构化提示词
- 快速问答（查定义、查概念、闲聊）→ 自然对话即可
- 创意头脑风暴 → 有一定结构但留出发挥空间
建议为最重要的工作流创建模板库，日常小问题随意聊。这平衡了质量和效率。
参考来源
下一步建议
- CLAUDE.md 配置优化指南 — 将提示工程原则编码为持久化规则
- Claude Code 35 个进阶技巧 — 掌握 Claude Code 的全部潜力
- 创建你的第一个提示词模板库：今天选一个常见工作流，写一个模板，下周再用一次
- 设置每周五 15 分钟的 AI 输出回顾仪式