提示工程入门指南：从零开始写出可用的提示词

提示工程（Prompt Engineering，PE）指的是与 AI 模型进行有效沟通、让它产出符合预期的结果的过程。它要解决的问题很具体：同一个模型，换一种问法，输出质量可能相差很远。提示工程就是把「我想要什么」拆解成模型能稳定执行的指令。这篇教程面向刚开始接触 AI 与提示工程的读者，也适合已经用过聊天式 AI、但输出总是不稳定、想建立一套可复用方法的人。站内另有一份提示工程指南工具页，可以配合本文一起看。全文按「先准备、再动手、最后跑通一个完整例子」的顺序展开，每一步都给出可以直接照抄的提示词结构。

准备工作

提示工程本身不需要安装任何软件，但要让练习有效果，需要先把下面几件事准备好。

一个可用的模型入口

你需要能访问至少一个对话式大语言模型。可以是网页版聊天界面，也可以是通过 API 调用的模型服务。两者的区别在于：网页版适合快速试错，API 适合把提示词固化进程序、批量跑测试。刚开始练习时，网页版足够；当你需要比较同一提示词在多次调用下的稳定性时，再考虑 API。

如果你打算用 API，需要提前准备账号与密钥，并确认所用模型支持你需要的上下文长度。具体的模型名称、可用地区、调用配额与计费方式，各家服务差异很大且经常调整，请以对应服务官网的当前信息为准。

明确你要解决的任务

在写第一条提示词之前，先用一句话写下目标。例如「把一段会议记录整理成待办清单」「给一段代码找出潜在的边界条件错误」「把产品说明改写成面向新用户的介绍」。目标越具体，后面拆解指令时越不容易跑偏。反过来，如果目标本身是「帮我写点东西」，那么无论提示词怎么优化，输出都会发散。

准备验证材料

提示工程不是写完就结束，而是「写—测—改」的循环。因此要提前准备能判断输出好坏的依据：几段真实的输入样本、一份期望输出的样子、或者一份检查清单。没有验证材料，你只能凭感觉判断输出「看起来还行」，无法判断改动是否真的带来了提升。

了解难度分级

提示工程的内容跨度很大，从完全不需要编程的基础技巧，到需要计算对数概率、强化学习知识的进阶技术。可以按下面的分级判断自己该从哪一层入手：

• 初学者友好，无需编程：提示词的基本结构、角色设定、示例引导、输出格式约束。
• 简单，需要基本编程知识：把提示词接入脚本、批量处理输入、解析结构化输出。
• 中级，需要编程技能与一定领域知识：例如需要理解对数概率、采样参数对输出的影响。
• 进阶，需要编程专业知识与深入领域理解：例如涉及强化学习相关技术。

需要说明的是，标记为中级和进阶的内容，通常也能在不具备先验领域知识的情况下读懂其思路，只是自己动手实现时会需要额外补充背景。因此不必因为分级而跳过感兴趣的主题。

操作步骤

第一步：把任务拆成「角色、任务、约束、格式」四块

一条可用的提示词通常包含四个部分。先按这四块写草稿，再逐块打磨。

• 角色：模型以什么身份回答。例如「你是一名负责代码审查的资深工程师」。
• 任务：要它做什么，用动词开头，一句话说清。例如「找出下面函数在输入为空时的行为问题」。
• 约束：边界条件。例如「只讨论输入为空和输入超长两种情况」「不要重写整个函数」。
• 格式：输出长什么样。例如「用表格输出，列为：问题、触发条件、建议修改」。

草稿可以写成这样：

你是一名负责代码审查的资深工程师。
任务：找出下面函数在输入为空时的行为问题。
约束：只讨论输入为空这一种情况，不要重写整个函数。
格式：用表格输出，列为「问题」「触发条件」「建议修改」。

代码如下：
{在这里粘贴代码}

四块齐全的提示词，输出通常已经比随口一问稳定很多。缺哪一块，输出就会在哪一块发散：缺角色，语气和深度不可控；缺约束，模型会顺手改掉你没让它改的东西；缺格式，结果难以直接使用。

第二步：用示例锁定输出风格

当格式要求用文字描述起来很啰嗦时，直接给一两个输入输出示例更有效。示例要覆盖你真正关心的边界情况，而不是只给最典型的那一个。

请按下面的示例风格，把用户反馈归类。

示例 1：
输入：登录之后页面一直转圈，等了五分钟也没进去。
输出：类别=可用性；严重度=高；摘要=登录后页面卡在加载状态

示例 2：
输入：希望增加深色模式。
输出：类别=功能建议；严重度=低；摘要=用户希望支持深色模式

现在处理：
输入：{待分类的反馈}

示例的作用是让模型从「理解你的描述」变成「模仿你的样例」。示例数量不必多，但每个示例的字段、标点、大小写最好保持一致，否则模型会学到不一致的格式。

第三步：明确要求模型在信息不足时提问

模型常见的失败模式是：在信息不足时仍然编出一个看起来合理的答案。可以在提示词里加一条兜底规则：

如果输入信息不足以完成判断，不要猜测。
请列出你缺少哪些信息，并说明每种信息会如何影响结论。

这条规则对摘要、分类、审核类任务尤其有用，因为它把「沉默的错误」变成了「显式的缺口」。

第四步：要求分步推理，但只输出结论

对于需要多步判断的任务，可以让模型先列出判断依据，再给结论。这样既保留了推理过程带来的准确率提升，又不会让最终输出被大段过程淹没。

请先逐条列出你判断所依据的原文片段，然后给出结论。
最终输出只保留「依据」和「结论」两部分，不要输出其他内容。

注意不要把「分步推理」和「输出格式」混在一起要求。先让它想清楚，再单独规定最终呈现形式，两者分开写更不容易互相干扰。

第五步：固定输出格式，便于程序解析

如果输出要交给程序处理，就明确要求结构化格式，并给出字段名与取值规则。

只输出一个 JSON 对象，不要加解释、不要用代码围栏。
字段：
- category：字符串，取值只能是 bug、feature、question 之一
- severity：字符串，取值只能是 high、medium、low 之一
- summary：不超过 30 字的摘要
- missing_info：字符串数组，信息充足时为空数组

字段名、取值范围、长度限制都写清楚，比只说「输出 JSON」可靠得多。取值用枚举而不是自由文本，可以避免后续解析时遇到同义不同词的情况。

第六步：迭代——每次只改一个变量

拿到第一版输出后，不要一次性重写整条提示词。挑一个最明显的问题，只改对应的那一块，再跑一次同样的输入。常见的问题与改法对应关系如下：

现象	优先调整的部分
输出太长、夹杂无关内容	格式块：明确长度上限与禁止出现的内容
语气或专业深度不对	角色块：写清身份与面向的读者
改动了不该改的内容	约束块：列出「不要做什么」
格式时对时错	示例块：补一个格式正确的示例，并统一示例写法
信息不足时仍在编造	兜底规则：要求列出缺失信息

每次只改一处，才能知道是哪一处改动起了作用。如果同时改三处，输出变好了也不知道该保留哪一条。

第七步：用同一批输入做回归测试

提示词改到满意后，把之前准备的验证样本全部重跑一遍。重点看两类情况：原本正确的输出有没有被改坏，以及边界样本是否仍然稳定。提示词和代码一样，修好一个问题可能引入另一个问题。测试样本建议保留下来，后续每次调整都复用同一批，这样比较才有意义。

一个完整示例

下面把前面的步骤串起来，做一个「把用户反馈整理成结构化记录」的最小可用例子。

目标

输入一条用户反馈原文，输出类别、严重度、摘要和缺失信息，供后续工单系统使用。

完整提示词

你是一名负责整理用户反馈的产品运营。

任务：阅读下面这条用户反馈，输出一条结构化记录。

约束：
1. 只依据反馈原文判断，不要补充原文没有的信息。
2. 如果原文信息不足以判断严重度，把 severity 设为 unknown，并在 missing_info 中列出缺少什么。
3. 摘要不超过 30 字，使用陈述句。

格式：只输出一个 JSON 对象，不要加解释、不要用代码围栏。
字段：
- category：bug、feature、question 之一
- severity：high、medium、low、unknown 之一
- summary：不超过 30 字的摘要
- missing_info：字符串数组，信息充足时为空数组

示例：
输入：登录之后页面一直转圈，等了五分钟也没进去。
输出：{"category":"bug","severity":"high","summary":"登录后页面卡在加载状态","missing_info":[]}

输入：希望增加深色模式。
输出：{"category":"feature","severity":"low","summary":"用户希望支持深色模式","missing_info":[]}

现在处理：
输入：{在这里粘贴用户反馈原文}

运行与检查

把反馈原文替换进最后一行，提交给模型。拿到输出后按顺序检查三件事：

1. 输出是否是一个可直接解析的 JSON 对象，没有多余文字或代码围栏。
2. category 与 severity 是否落在允许的取值范围内。
3. summary 是否只复述了原文信息，没有引入原文没有的细节。

如果第 1 条不通过，通常是格式块写得不够硬，可以在格式块开头加一句「只输出 JSON，第一个字符必须是左花括号」。如果第 3 条不通过，说明约束块需要更明确地禁止推测，或者补一个「信息不足」的示例。

扩展成批量处理

单条跑通之后，可以把同一条提示词放进脚本循环，对一批反馈逐条调用。此时要注意：每条输入之间要相互独立，不要把多条反馈拼进同一次调用，否则模型可能把不同反馈的信息混在一起。批量处理时也建议保留原始输入与输出的对应关系，方便抽查。

注意事项

• 提示词不是一次写成的。 第一版输出不理想是常态，按「每次只改一个变量」的方式迭代，比反复重写整条提示词更有效。
• 示例要一致。 多个示例之间字段名、标点、大小写不统一，模型会学到混乱的格式，输出稳定性反而下降。
• 不要指望提示词消除所有不确定性。 同一提示词多次调用仍可能有差异，涉及关键判断的场景应保留人工复核环节。
• 模型与配额信息会变。 模型名称、上下文长度、调用配额、计费方式都属于易变信息，使用前请以对应服务官网的当前信息为准。
• 按需阅读，不必从头到尾。 提示工程的内容覆盖面很广，从基础技巧到需要编程与领域知识的进阶技术都有。不熟悉 AI 与编程的读者可以从基础部分入手；已有基础的读者可以直接跳到中级内容。分级只表示实现难度，不代表理解门槛。
• 结构化输出要校验。 即使提示词要求只输出 JSON，也应在程序侧做解析与字段校验，解析失败时走兜底逻辑，而不是假设输出一定合规。