提示词工程指南：从基础到实践

date

Mar 4, 2025

slug

prompt-engineering-guide

status

Published

summary

本文探讨了提示词工程的真实定位，指出提示词仅是整体工程的一个环节，而非决定性因素，揭示将提示词神话化的误区，强调更多关注工程实现对产品体验的关键影响。

提示词的发展历史

在大语言模型成为主流之前，NLP 领域主要采用"预训练+微调"的范式。这意味着我们先用海量语料训练通用语言模型，再针对具体任务（如文本分类、情感分析）进行微调。当时，模型主要学习预测被掩盖的词或上下文关系，而非理解和执行人类指令。

这些早期模型无法"听懂"自然语言指令，主要因为：

模型未对指令进行调整：它们的训练目标是预测文本片段或分析上下文关系，不是理解并执行开放式任务

缺乏少样本学习能力：这些模型需要大量标注数据和专门结构的微调，无法仅通过提示词即完成任务

转折点出现在 2020 年，当 OpenAI 发布了 GPT-3，这个拥有 1750 亿参数的庞然大物展示了惊人的能力：无需微调，仅通过自然语言描述和少量示例，就能在多种 NLP 任务上取得不错效果，这标志着"提示工程"时代的开始。

随后，通过指令微调（如 OpenAI 的 InstructGPT）和 RLHF（基于人类反馈的强化学习），大语言模型变得更擅长理解并遵循人类指令，而后来 ChatGPT 的爆火让提示词工程走出技术圈，成为大众话题。

这是一场范式的根本转变：从让模型适应任务，到用任务去适应模型（将 NLP 任务用提示词的方式写出来，然后再让 LLMs 去完成任务）。以往，每个 NLP 任务可能需要单独训练或微调一个模型，如今，同一个大语言模型通过不同的提示词就能完成各种任务。

用编程 vs 提问来类比：过去我们通过数据和优化来"编程"模型执行特定任务；现在我们更多是用提示词"提问或指示"，让模型调用已学到的知识给出结果。

这种变化带来了三大优势：

可迁移性提升：一个 LLM 能覆盖以前几十个模型的功能

开发门槛降低：不需要复杂的模型训练知识，会写提示词就能使用 AI（所以现在很多所谓的 AI 产品经理和 AI 开发工程师岗位应该改名为大模型 API 产品经理，大模型 API 开发工程师 🤣）

迭代速度加快：修改提示比重新训练模型要快得多

随着 Claude 3.5 Sonnet 和 GPT 4o 等更全能模型的出现，提示词技巧也在进化，链式思维提示、角色扮演、多轮对话策略等技巧被广泛应用。

如何写好提示词

提示词的写法没有放之四海而皆准的公式，最有效的方式取决于你的使用场景。根据实际需求和场景来选择合适的提示词策略，才能获得最佳效果。

日常对话

当你只是与 AI 进行日常聊天时，采用渐进式提示通常更自然有效。你可以从简单问题开始，然后根据 AI 的回应逐步深入，在多轮对话中逐步完善你的要求。这种方式不需要精心设计复杂提示词，而是通过自然对话引导 AI 达到你的目标。

比如你想获取一份报告，可以先简单问："请帮我写一份关于气候变化的报告吗？"然后根据回复再补充："我想重点关注最近五年的数据趋势，长度大约 1500 字，目标读者是大学生。"这样的交流更接近人类自然对话，也给了 AI 更多理解你需求的机会。

日常场景不需要过度优化提示词，保持对话自然流畅即可。但很多人和 AI 交流经常出现的问题就是不会好好沟通：

首先是假定 AI 知道上下文，但 AI 实际上缺乏我们认为"显而易见"的背景信息。比如直接说"这个怎么修？"而不提供"这个"指的是什么，或者说"帮我写个邮件"却不说邮件内容和目的。记住，AI 没有通过其他渠道了解你的情况，它只知道你明确告诉它的信息。

其次是不会有效对话（无法清晰表达需求或按照逻辑顺序提供信息）。很多人与 AI 交流时，要么过于简短模糊，如"写个故事"；要么信息杂乱无序，在一段话中跳跃多个主题。更有效的方式是按照合理顺序提供信息，先说明目标，再提供相关细节，就像你会对一个人解释一样。这也就是 AI，如果是一个正常人类，根本就不会理你。

第三个问题是不会准确表达自己的想法。很多人只会输出情绪（"我需要一个超级棒的营销方案！"），而不会输出具体思路（”我的产品是 XXX，特点是 XXXX，我需要一个针对 18-25 岁用户的社交媒体营销方案，强调产品的 XXX"），AI 需要具体、明确的指引，而不是模糊的期望，提供足够的细节让AI能够理解任务的具体背景和限制条件。

如果你开始学习如何与 AI 交流，首先应该学会正确表达自己的想法。这意味着：

明确你的目标：在开始对话前，先想清楚你到底想从 AI 那里得到什么，是信息、创意、分析还是建议？

提供足够上下文：简洁但完整地说明相关背景，想象你在向一个聪明但完全不了解你的情况的人解释。

逐步细化需求：从基本需求开始，然后根据AI的回应逐步添加细节和调整方向，不必一次说完所有要求。

给出反馈：当 AI 的回答不符合预期时，具体指出哪里不对，而不是简单说"不行"或"重写"。例如："这个分析缺少了对中国女性白领用户群体的考虑，请增加这部分内容？"

当 AI 的回答不理想，可以直接告诉AI哪里需要改进，大多数情况下它能根据反馈调整。这种互动式的过程通常比试图一开始就写出完美提示词更简单有效。

AI 应用开发

在 AI 应用开发中，提示词已经不仅是与模型交互的工具，而是整个应用的核心组件之一，这种环境下需要结构化的提示词工程方法，确保提示词能够被有效迭代、维护和共享，这对于产品稳定性和团队协作至关重要。

明确的任务提示

很多时候 AI 应用并不是多轮对话的形态时，需要一次性精准的回应，就需要更严谨的"一次性精准提示"，这就像给一位高级专家下达明确任务指令。那么这个提示词，最基础所需要的内容大致如下：

说明任务目的

提供必要的上下文信息

通过例子展示期望输出

预先定义异常情况的处理方式

结构化设计

在应用开发中，提示词可以适当采用模块化设计，将一个复杂提示词分解为不同功能模块，比如角色、上下文、约束、示例等，这样不同团队成员可以快速了解和理解不同模块的作用，迭代中也不必每次都修改整个提示词，也方便日后排查问题。

同时在很多场景中，如果一些上下文 or 约束是类似的，我们最好应该复用模块，而不是重新撰写。

版本管理

像代码一样，提示词也需要进行版本管理。使用 Git 等工具跟踪提示词的变更，为每次更新添加有意义的提交信息。

针对重大更新，应当建立发布流程，包括测试、审核和部署步骤。确保每个版本都有明确的标识，便于在出现问题时快速回滚，也可以方便对比不同版本提示词的效果和差异。一个好的实践是使用语义化版本号（如 v1.2.3），或日期版本号（2025-03-04）。

团队协作与沟通

如果内部达成一致，可以考虑使用专门的工具或平台管理提示词库，例如一些开源、托管的大模型开发监控产品或者开发内部工具，你甚至可以考虑在这些平台上进行提示词的 AB 测试。

另外这些提示词应该在团队内允许查看和沟通的，这不是什么非常机密的东西，它就像代码一样，应当允许团队内的产品、开发或其他任意相关人查看和随时讨论。一个 AI 应用中，提示词脱离背后工程将意义大减。

常用提示词模式及优缺点

下面是几种常见的提示词模式，大部分人应该多少就有听过和用过：

角色扮演提示

角色扮演提示通过指定 AI 扮演特定角色来引导回答方向。例如"你是一名经验丰富的财务分析师，请分析以下季度报表数据并指出关键趋势。"这种方式能引导模型采用特定专业视角，增加回答的专业性和深度，并有助于保持一致的语气和风格。

然而，过度依赖角色设定可能限制模型发挥其全部能力，有时候它会产生刻板印象化的回答，而不是真正深入分析问题，比如 Anthropic 的 Amanda Askell 说："我几乎从未使用过这种角色扮演的提示技巧——即使以前是更糟糕的模型。"她认为直接清晰地表达需求往往更有效。

链式思维提示

链式思维提示 (Chain-of-Thought, CoT) 鼓励模型一步步展示思考过程。典型格式是"请一步步思考这个问题...[问题]"或"让我们一步步分析..."。这种方法实质上是让模型在生成最终答案前，先显式地输出中间推理步骤，类似于人类解题时的"草稿过程"（当然最近又有个什么 CoD，Chain of Draft）。

这种方法在解决复杂推理问题时特别有效，它使思考过程透明化，便于检查潜在错误，在一些测试中提高了数学和逻辑问题的准确性。

这里需要注意，使用 CoT 时有个关键点：必须让 AI 输出完整的思维过程，而不是直接跳到答案。如果只是加上"让我们一步步思考"但没有要求模型展示思考步骤，那效果基本与普通提示没什么区别。

对于面向用户的应用，如果你想隐藏思考部分但又需要精确答案，可以要求 JSON格式输出，设置"思考过程"和"结果"两个分开的字段。

示例驱动提示

示例驱动提示 (Few-Shot Prompts) 通过提供几个输入-输出对的示例，然后提出新问题。

这种方法通过示例直观展示期望输出，降低了对复杂指令的依赖，能有效引导模型理解特定任务格式。

不过它也有缺点，比如占用 token 较多，而且示例选择可能无意中引入偏差（尤其出现在一些智能程度较低的模型中），模型有时会过度关注示例特征而忽视更广泛的模式，导致泛化能力受限。

结构化输出提示

结构化输出提示要求模型以特定结构（如 JSON、XML、特定的 Markdown 等）输出结果。例如"分析以下文本的情感，并以 JSON 格式返回结果，包含'情感'和'置信度'两个字段"。

这种方法产生的输出易于程序处理和解析，规范了回答格式，提高了结果的一致性，特别适合需要自动化处理结果的场景。

在之前，这种复杂结构可能增加错误率，模型有时会偏离请求的格式，但在 2024 年的迭代中，大部分大模型服务商的 API 都提供了结构化输出的能力，这一点可以参考 OpenAI 官方的文档，写得非常细致。

使用结构化输出的提示词工程也会有一些不一样，通常你还需要去定义 JSON Schema，这个时候提示词就不仅是自然语言了：

此外可能还存在非常多的提示词撰写方式，但是知道有多少种方法并不是最重要的，更重要的应该是大家应该多尝试，多评估。

如何评估 AI 的输出

如果你要把提示应用到 400 个不同的案例中，通常人们会只考虑最常见的情况，看到提示在这些情况下能够得到正确的结果，然后就不再继续思考了。但实际上，你需要去找到那些不常见的情况，思考提示在这些情况下可能会出现的模糊不清。比如，你有一个提示说，“我将发送给你一些数据，我希望你提取出所有名字以 G 开头的行。”那么你就需要考虑，“如果我发送的这个数据集中根本没有以 G 开头的名字怎么办？如果我发送的不是数据集，而是一个空字符串呢？”这些都是你必须去测试的情况，因为只有这样你才能给模型更多的指令，让它知道在这些特殊情况下该怎么做。 ——— Amanda Askell(Anthropic 模型对齐微调专家)

许多人评估提示词效果时只靠主观感受："这个回答看起来不错"，但在专业环境中，我们需要更客观的评估方法。

但是评估提示词效果不应只依靠主观感受，而应建立系统化的评估流程，只有通过客观数据，才能确定提示词是否真正达到了预期效果。

比如说一个电商客服 AI 的评估指标可能包括：准确回答率、解决问题速度、满意度评分、需要人工干预的比例等，这些客观指标比起"感觉更好"更有说服力。

建立评估框架

首先，我们需要明白，评估的主体不应该只是提示词，假设你作为一个 AI 产品的产品策划，为了保证最终的用户体验，你需要评估模型、提示词、流程等等各种方面。

因此评估方法应该多元化，包括人工评估和自动化指标结合，虽然人工评估耗时，但能捕捉到细微差别，对于主观性较强的任务尤为重要。

自动化指标能提供可量化的表现数据，例如，对于 Chat PDF，可以测量回复相关性、完整性等方面；对于强格式输出的，比如说你希望 AI 输出 20-40 字，英文占比 40%，那么都可以通过编写脚本来进行评估打分，这些客观指标比主观感受更具说服力，也更便于团队内部讨论和决策。

专门工具如 Promptfoo 可以帮助批量评估，这类工具允许你定义多个测试用例和评估指标，自动对比不同提示词版本的表现：

定义测试用例集：创建多个代表性输入，包括常见查询和边缘情况

设置评估指标：定义如何衡量成功，如准确性、相关性或完整性

配置变体：设置多个不同版本的比较对象（模型/提示词/流程）进行对比测试

执行自动化测试：工具会将每个测试用例通过每个变体发送给 AI

分析结果：比较不同模型/提示词/流程的表现，找出最佳或最合适的方案

例如使用 Promptfoo 的简单配置可能如下：

这类 AI 生成效果评估工具虽然需要一定的学习成本，但对从事 AI 产品策划的人来说，这应该是必须要学习的部分。

实际应用中，可以建立一个整体的面向业务的评分工程，对模型、提示词、流程等在各个维度的表现进行量化评估：

内容质量

准确性（输出内容与事实的符合程度）
相关性（回答与用户问题的相关程度）
完整性（是否覆盖了问题的所有方面）

输出格式

字数
输出语言
Markdown or JSON or XML or HTML

速度

Time To First Token (TTFT)：首 Token 延迟，从输入到输出第一个 token 的延迟
Time Per OutputToken（TPOT），单 Token 生成时间

成本：在商业应用中，除了效果外，成本控制同样重要，常用的优化方式包括

删除冗余指令和不必要的装饰性语言，降低 token 消耗
根据任务复杂度选择合适的模型，先用轻量模型处理基础任务，仅在必要时调用智能程度较高的模型
对于重复性高的查询实施缓存策略，避免重复 API 调用

通过这些量化指标，可以更客观地比较不同提示词的效果，指导后续优化。当然有人可能会提到说上面的内容质量部分怎么评分？这里建议可以采取人类 + LLMs 综合评估的方式，目前很多评估工具都是支持的，比如说先让一个能力较强的 AI 打一遍分数，然后人类再核对一遍。这里就像是在训练模型常用的 RLHF（基于人类反馈的强化学习，Reinforcement Learning from Human Feedback）。

利用这一套工程你可以去评估任何 AI 应用相关的内容。

持续改进机制

AI 应用的优化应该是一个持续过程，而非一次性任务，尤其是提示词的优化。

先建立初始表现基准，然后定期评估效果，识别表现不佳的方面，有针对性地改进，最后再次评估验证改进效果。

因此收集和分析用户反馈很重要，提供便捷的反馈渠道，如满意度评分或问题报告按钮。实际用户的使用体验和问题报告能揭示测试环境中可能忽略的问题，对负面反馈进行深入分析，找出提示词的不足之处，发现提示词可能未覆盖的场景，能让产品更贴近实际需求。

让提示词回归工具

我觉得把提示弄得太抽象是一种过度复杂化的方式。实际上，很多时候你只需要写一个非常清晰的任务描述，而不是构建复杂的抽象。但是话虽如此，你确实经常需要将一系列指令编译成具体的结果。因此，精确性，以及编程中考虑的版本控制和管理实验的历史记录等问题，这些都同样重要。 ——— Zack Witte(Anthropic 提示工程师)

提示词的真实定位

随着提示词工程热度上升，一种误解也随之蔓延——仿佛掌握了一些"魔法提示词"，就能让 AI 产出惊人成果（我觉得真的是滑天下之大稽），这种观点把提示词过度神话化了。

事实上，在 AI 产品开发中，提示词只是整体工程中的一个环节，而非决定性因素。就像做一个 PDF 摘要和聊天产品，虽然提示词很重要，但用户体验的差距更多来自工程实现的差异。

如何高效处理 PDF 文件，如何分块、索引和检索内容，如何维护对话上下文——这些工程问题往往对产品体验有着更根本的影响，在这个过程中，提示词只是连接各个组件的"胶水"，而非决定产品成败的核心：

采用更先进的文档解析技术，能够准确保留表格、图表和格式信息

实现更智能的分块策略，在保持语义完整的同时优化检索效率

上下文管理更高效，能够在 token 限制内最大化包含相关信息

具备完善的兜底处理机制，在召回失败时能使用 Fallback 方案

当然也有可能采用了更新的技术，例如 voyage-multimodal-3 这一多模态向量模型对于检索部分以图片为主的 PDF 来说，效果会更好等等

常见误区与正确心态

在实际开发中，常见的提示词工程相关误区包括：

过度优化陷阱：花费数周时间微调提示词措辞，却只带来微不足道的改进

万能提示幻想：寻找一个能解决所有问题的"完美提示"，而非针对具体场景定制

提示词保密：将提示词视为核心机密，过度保护而不是在团队内共享和改进

忽视评估：在不同数据和场景下缺乏系统评估，导致提示词在实际应用中表现不佳

忽略用户反馈：过度依赖内部评估而非真实用户体验

更健康的心态是：提示词只是工具，不是秘密武器。它重要但非核心，应达到"足够好"即可，关键是确保它能与系统无缝配合，并建立客观评估机制。

AI 应用真正的核心竞争力在于产品的整体：数据处理、模型集成、上下文管理、错误处理、用户界面和用户体验设计。

结语

提示词工程是 AI 应用开发的重要环节，但并非全部。它是帮助我们与 AI 系统有效沟通的工具，而非神秘的魔法。

未来，撰写提示词会成为所有团队成员的基础技能，而真正的竞争力仍是这些传统的能力——识别场景需求、设计整体解决方案等。

部分对话引用来源：Claude AI圆桌论坛：资深提示工程团队手把手教你写提示词