提示词工程是什么？核心技巧与学习方法

提示词工程是编写、测试并改进你给 AI 模型的指令，让它稳定地产出你需要的结果。它既包括你在提示词里放什么（任务、背景信息、示例、输入），也包括你怎样组织这些内容（顺序、格式、分隔符）。这个词听起来很技术，但大部分工作其实是认真写作，再加上检查结果。

本页是 Coddy 提示词工程指南的目录。它解释这种做法为什么有效，把核心技巧对应到讲解它们的页面，并展示随手写的提示词和精心设计的提示词有什么区别。

提示词工程为什么有效

语言模型生成文本的方式，是根据摆在它面前的全部内容，一小段一小段地预测接下来是什么。除非相关文字就在它的输入里，否则它无从得知你的意图、你的项目或你之前的对话。所以提示词并不是在请求一个已经理解你的头脑，它就是模型所面对的全部情境。

这会带来一个直接的后果。提示词没有说清的每一个问题，模型都倾向于用最典型的选择来解决：最常见的语言、最常见的长度、最常见的读者。有时候典型的选择正是你想要的；不是的时候，解决办法就是在提示词里把这个问题说清楚。好的提示词会缩小可能回复的范围，直到剩下的大多数回复都有用。

还有两个事实影响着这门手艺。回复是采样得到的，所以同一个提示词在不同的运行中可能给出不同的答案；一个提示词只有在大多数时候都管用才算好，而不是只成功一次。另外，模型会把提示词里的所有文字都当作可能有意义的内容，所以粘贴进来的一封邮件或一句无关的话，都可能被当成指令来读，除非你把它清楚地标记为材料。

随手写的提示词与精心设计的提示词

两个标签页要求做同一件事：把用户评价分成正面和负面。比较一下各自得到的回复。

这些评价是正面的还是负面的？ 1. 这个应用很快，但今天把我登出了两次。 2. 正是我记录跑步需要的东西。 3. 客服一直没回我的邮件。

Try it

Example replyReplies vary between models and runs.

下面是逐条分析：

褒贬参半。 用户喜欢它的速度，但对被登出感到不满。
正面。 这个应用满足了用户记录跑步的需求。
负面。 用户对客服没有回复感到不满。

总体来看，反馈褒贬不一：一条正面，一条负面，一条褒贬参半。

随手写的提示词得到的回复，给人读是合理的，但程序没法用：标签和解释混在一起，冒出了一个问题里没有提供的第三个类别，结尾还加了一段总结。精心设计的提示词定义了每个标签，用一个示例固定了输出的格式，并用标签把评价包起来，让它们不容易和指令混淆。在一千条评价上运行，它给出的输出能让程序稳定得多地解析；如果你需要百分之百的保证，API 的结构化输出功能和代码中的校验步骤可以补上剩下的差距。

核心技巧

下面每种技巧，弥补的都是你想表达的意思和模型实际收到的内容之间的一种差距。大多数真实的提示词会组合使用好几种。

技巧	作用	适用场景
零样本提示	只给指令，不给示例	任务常见，而且描述清楚
少样本提示	展示几个输入和输出的示例	格式或判断标准演示起来比描述更容易
思维链提示	要求先给出推理过程，再给答案	问题有好几个步骤，比如数学或逻辑题
角色提示	设定用谁的口吻和标准	读者和水平很重要
结构化输出	把答案固定为 JSON、表格或模板	结果要交给程序或电子表格读取
分隔符和 XML 标签	把指令和粘贴的材料分开	提示词里包含文档、代码或用户文本
提示词模板	把一个好提示词变成带空格的模板	你会反复提出同一类请求
提示链	把一项工作拆成前后衔接的步骤	一个提示词想做的事太多
自洽性	采样多个答案，取多数结果	单一的推理路径不可靠
思维树	探索多条推理路线并打分	问题需要规划或搜索
ReAct	推理和工具调用交替进行	模型必须查资料或执行操作
元提示	让模型来写或改进提示词	你不知道该怎么措辞
上下文工程	设计模型看到的全部内容，而不只是指令	你在围绕模型开发应用或智能体

如果你是新手，先从怎么写提示词中单个提示词的组成部分学起，然后学少样本提示和结构化输出。这三部分能解决大多数日常问题。

为程序编写的提示词

写进软件里的提示词会在没人见过的输入上运行成千上万次，所以它们要比一条聊天消息交代得更多。下面这个提示词根据代码 diff 编写提交信息。把各个部分关掉，看看每一部分防住了什么：没有示例，风格就会跑偏；没有约束条件，模型可能会用你们团队不用的类型，比如 perf 或 style。

根据 diff 写提交信息

Fill in类型

Parts

你负责为一个遵循 Conventional Commits 格式的团队编写 git 提交信息。

为下面的 diff 写一条提交信息。

feat(cart): 为购物车商品添加数量选择器 fix(api): 用户 id 不存在时返回 404 而不是 500

第一行：type(scope): 摘要，最多 60 个字符，用祈使语气。然后空一行，最多写三个要点，说明为什么要做这次修改。

只能使用这些类型：feat, fix, refactor, docs, test, chore。如果 diff 混合了互不相关的修改，就直接指出来，不要写提交信息。

 function validatePassword(password) {
-  if (password.length > 8) {
+  if (password.length >= 8) {
     return null;
   }
   return 'Password must be at least 8 characters';
 }

Try it

Example replyReplies vary between models and runs.

fix(auth): 接受长度正好为 8 个字符的密码

- 原来的判断用的是 > 8，所以 8 个字符的密码会被拒绝
- 现在规则和错误信息一致，错误信息写的是 "at least 8"

如何学习提示词工程

学习的方法是运行提示词，然后仔细看它返回了什么。一条实用的路线：

学习提示词的组成部分。 任务、背景信息、输入、格式和约束条件。大多数失败都能追溯到缺了其中某一项。
挑一个你经常重复的真实任务， 比如总结工单、解释错误或起草邮件，为它写一个提示词。
收集 5 到 10 个测试输入， 包括棘手的情况：空输入、很长的输入、用其他语言写的输入。
一次只改一处， 然后把所有输入重新跑一遍。如果你一次改了三处，输出变好了，你不会知道是哪处修改起了作用。迭代提示词详细讲解了这个循环。
遇到具体问题时再加技巧。 格式跑偏时加示例，多步骤答案出错时加分步推理，粘贴的文本混进指令时加分隔符。

各大模型厂商也会为自家模型发布提示词指南，值得一读，因为每份指南都说明了该系列模型最吃哪一套。

提示词工程是一份工作吗？

有些公司招聘过“提示词工程师”这个职位，尤其是在聊天模型刚开始普及的时候。更常见的是，这项技能是其他工作的一部分。开发者为自己开发的 AI 功能写提示词，客服团队为回答客户的助手写提示词，分析师和写作者每天都在用。

在开发 AI 产品的团队里，这项工作的范围变宽了。选择把什么放进模型的输入（检索到的文档、工具结果、对话历史、记忆）和指令的措辞同样重要，这项更宽泛的工作常被称为上下文工程。衡量一个提示词在大量输入上是否有效，通常叫作评估，是另一半工作。

新模型带来了哪些变化

早期的提示词工程依赖各种技巧：神奇的短语、精心设定的人设、把一条指令重复好几遍。现在的模型能更好地听懂平实的指令，推理模型在回答前已经会在内部把问题推理一遍，所以让它们“一步一步思考”带来的提升不如从前。

没有改变的是那些从来就不算技巧的部分。除非你说出来，模型仍然无从知道你的读者、你的数据、你的约束条件，以及什么样的结果才算好。把需求说清楚才是长久有用的技能，这也是本指南大部分篇幅讲的内容。

常见问题

用简单的话说，提示词工程是什么？

提示词工程就是认真地为 AI 模型编写指令，让它给出你需要的答案，然后不断测试和调整，直到它能稳定地做到。它既包括你告诉模型什么（任务、背景信息和示例），也包括你怎样组织这些内容（顺序、格式和分隔符）。

不会编程能学提示词工程吗？

能。核心技能，也就是把任务说清楚、提供背景信息、给出示例和指定输出格式，在聊天应用里都能用。当你想把一个提示词运行很多次、用一组输入去测试它，或者把输出交给程序处理时，编程才会派上用场。

学会提示词工程需要多久？

基础知识一个下午就能学完：好提示词的组成部分，再加上几种技巧，比如少样本示例和结构化输出。要在真实任务上得到可靠的结果则需要更久，因为这要靠用大量输入测试你的提示词，并修好它出错的情况。

提示词工程师是一份真正的工作吗？

有些公司招聘过“提示词工程师”这类职位，但更常见的是，这项技能是其他岗位的一部分：开发 AI 功能的开发者、写作者、分析师和客服团队。在开发 AI 产品的团队里，它和评估工作重叠，也和设计模型看到的全部内容重叠，这项工作现在常被称为上下文工程。

有了更新的 AI 模型，提示词工程还有用吗？

新模型需要的技巧更少。它们更能听懂平实的指令，推理模型不用你提醒“一步一步思考”，也会自己把问题推理一遍。仍然有用的是那些从来就不算技巧的部分：说清楚任务，告诉模型它不可能知道的事实，并定义什么样的答案才算好。