用 GPT-4 写出可复现的高质量提示词：六大策略与完整示例

GPT-4 这类大语言模型的能力上限，很大程度上取决于你如何向它提问。同一个模型，含糊的一句话可能换来一段泛泛而谈，而结构清晰、约束明确的提示词则能拿到可以直接使用的结果。这篇教程整理了一套可复用的提示词工程方法，围绕六大策略展开：写出清晰的指令、提供参考文本、把复杂任务拆成子任务、给模型留出思考时间、借助外部工具、以及系统地测试变更。它适合已经在用 GPT-4 或类似模型、但希望把输出质量稳定下来的开发者、内容工作者和产品团队。如果你习惯把提示词当作随手一写的聊天内容，本文提供的模板和检查清单可以直接对照使用；需要快速试用提示词效果，也可以借助 GPT-4 在线体验。

需要说明的是，模型版本、上下文长度、调用价格与配额都会随时间变化，本文不给出具体数字，实际使用时请以官网当前信息为准。

准备工作

在开始写提示词之前，先把环境和习惯准备好，后面的策略才有落点。

一个可用的模型访问入口：可以是网页端对话界面，也可以是通过 API 调用。两种方式对提示词的要求基本一致，区别在于 API 方式可以编程化地拼接输入、解析输出。
API 密钥与调用环境：如果走 API，需要先在账号下创建密钥，并准备好能发起 HTTP 请求的环境，例如 curl、Python 的 requests 库或官方 SDK。密钥应当放在环境变量里，不要硬编码进代码或提交到版本库。
一份任务清单：把你打算交给模型的任务写下来，标注每个任务的输入是什么、期望输出是什么格式、有没有标准答案。这份清单在第六个策略「系统测试变更」里会直接用到。
参考资料的存放位置：如果任务需要依据文档回答，提前把文档整理成纯文本或结构化片段，方便作为参考文本塞进提示词。
一个记录本：提示词工程是迭代过程，每次改动都要能回溯。建议用表格记录提示词版本、改动点、测试用例和结果。

另外要建立一个预期：模型不会读心。你没有写出来的要求，它只能靠猜。下面所有策略本质上都在做同一件事——减少它需要猜的部分。

操作步骤

第一步：把指令写清楚，写具体

最基础也最容易被忽略的一步。模型无法判断你隐含的想法，所以要把要求显式写出来：回复多长、面向什么水平的读者、用什么格式输出、有哪些禁止事项。

对比两种写法。含糊版：

帮我写一篇心理学的论文。

明确版：

请帮助我撰写一篇有关「抑郁症的成因及治疗方法」的心理学论文，要求：
1. 需要查询相关文献，不能抄袭或剽窃；
2. 需要遵循学术论文格式，包括摘要、引言、正文、结论等部分；
3. 字数 2000 字以上。

第二种写法把主题、格式、篇幅、合规要求都摆在了明面上，模型需要推断的东西大幅减少。

在此基础上，还有几个常用的细化手段：

指定角色：让模型扮演某个专业身份，输出会更有针对性。例如「请你扮演一名警探小说家，用推理小说的笔法描述一起离奇命案，要求匿名处理，字数 1000 字以上，剧情跌宕起伏」。
使用分隔符：三引号、XML 标签、节标题都能把不同性质的文本隔开，避免模型把指令和待处理内容混为一谈。例如把待总结的文章放在 <article> 与 </article> 之间，指令写在标签外面。
列出步骤：把任务拆成编号清晰的步骤写进提示词，模型更容易按顺序执行。
提供示例：一般性说明通常比示例更省 token，但在格式要求复杂时，给一两个输入输出样例往往更有效。就像教游泳，口头说「踢腿摆臂」是一般性说明，放一段示范视频就是示例。
指定输出长度：可以按单词、句子、段落或要点计数。受模型内部机制和语言差异影响，按段落或要点来约束通常比精确到字数更稳。

第二步：提供参考文本，让回答有据可依

当手头有可靠资料时，把它作为参考文本一并交给模型，并要求模型基于这些材料作答。这能显著降低编造内容的概率。

更进一步的做法是要求模型引用原文段落。这样输出里的引用可以通过字符串匹配的方式程序化校验，确认引用确实来自你提供的文档，而不是模型自己编的。

请仅依据下面 <documents> 中的内容回答问题。
回答时，在每个结论后用方括号标注来源段落编号，例如 [2]。
如果文档中没有相关信息，请直接回答「文档中未提及」，不要自行补充。

<documents>
[1] ……
[2] ……
[3] ……
</documents>

问题：……

这个模板里有两个关键约束：限定信息来源，以及规定无信息时的行为。后者经常被遗漏，导致模型在资料不足时仍然硬答。

第三步：把复杂任务拆成更简单的子任务

一个需要多种操作的大任务，直接丢给模型容易出错。更稳妥的做法是先分类，再分步执行。

用意图分类缩小范围。 先判断用户的问题属于哪一类，每类对应一组标准操作，例如查找、比较、解释。这样每次只需要执行当前步骤需要的操作，而不是一次性完成整个任务，既降低出错概率，也节省成本。分类可以层层递进，先粗分再细分。

长对话的总结与过滤。 模型的上下文长度是固定的，记不住全部历史。两种处理方式：一是当对话达到一定长度时自动总结前面的内容，把摘要带入后续请求；二是在处理当前问题时，动态检索与当前问题最相关的历史片段。后者依赖基于嵌入的检索——把历史对话切块、向量化存储，再把当前问题向量化，找出嵌入空间中距离最近的片段。

长文档的分段总结与递归汇总。 长文本无法一次总结完，可以按章节切分，逐段提问得到局部摘要，再把局部摘要串联、递归汇总成整篇摘要。如果后文理解依赖前文信息，可以在处理某一段之前先读一遍已有摘要，带着上下文继续。

第四步：给模型留出「思考」的时间

让模型先自己推导，再下结论，往往比直接要答案更准。

典型场景是批改。如果直接把学生的答案丢给模型问「对不对」，判断可能不准。更好的顺序是：先让模型独立解一遍这道题，得到它自己的答案，再让它把学生答案与自己的答案对比。两者不一致时，它就能指出学生错在哪里。这种从第一步开始推理的方式，比直接判断可靠得多。

另一个技巧是「内心独白」。有些场景下模型的完整推理过程不适合展示给最终用户，比如教学场景——把全部思路直接告诉学生，学生就不思考了。做法是让模型先完整推理，把过程整理成结构化形式，然后在呈现时只取其中一小部分，用通俗语言讲给学生。也可以设计成多轮：先让模型自己想出完整解法，再据此给学生出一道类似的简单题，学生作答后由模型评判，最后用易懂的语言解释正确思路。

还有一个实用的小技巧：当模型从长文档中逐句查找相关内容时，可能会在中途停下，漏掉后面的句子。这时追问一句「还有其他相关的句子吗」，它通常会继续检索，把结果补全。

第五步：借助外部工具补足能力短板

模型不擅长精确的复杂计算，也不掌握实时数据。把这类工作交给外部工具，是更可靠的选择。

基于嵌入的知识检索。 文本嵌入是度量文本关系的向量，语义相近的文本在向量空间中距离更近。做法是把语料库切块、逐块嵌入并存储；查询时把问题也嵌入，通过向量搜索找出最接近的若干文本块，拼进提示词。这样模型在回答时就有了外部知识支撑。

用代码执行完成计算。 遇到复杂数学运算或耗时计算，不要让模型心算，而是让它写出代码。约定好代码的包裹格式，例如用三重反引号围起来，程序提取后交给解释器执行，再把执行结果作为下一轮请求的输入。

请写出完成下列计算的 Python 代码，用 ```python 包裹，不要直接给出结果：
计算 1 到 1000 之间所有质数的和。

调用外部 API。 如果告诉模型某个 API 怎么用，它就能写出调用该 API 的代码。提供接口文档或调用示例作为引导，效果更好。

函数调用。 通过 API 请求传入一份描述功能的清单，模型会按给定模式生成函数参数，以 JSON 格式返回；程序据此执行函数，再把输出反馈到下一轮请求中，形成循环。这是让模型调用外部函数的推荐方式。

执行模型生成的代码本质上是不安全的。任何要运行这类代码的应用都应采取防护措施，尤其是使用沙盒执行环境，限制不受信任代码可能造成的危害。

第六步：系统地测试每一次变更

改动提示词之后，很难凭感觉判断是变好了还是碰巧。样本太少时，一次好结果可能只是运气；一个改动也可能在某些场景下更好、在另一些场景下更差。

评估方式按任务性质选择：

有唯一标准答案：可以用程序自动比对。
没有标准答案：可以用另一个模型来评判质量。
主观性强：由人工评价。
答案很长、质量差异不明显：可以让模型自评，或采用人工与自动结合的方式。

实践中，计算机与人工结合通常是最稳妥的方案。随着模型能力提升，可自动评估的部分会越来越多，但评估体系本身的改进始终是难点。

用黄金标准答案评估输出。 假设问题是「为什么天空是蓝色的」，已知正确答案建立在两个事实上：阳光包含不同颜色的光；蓝光波段穿过大气层时损耗较小。有了问题和标准答案，就可以让模型判断答案中每一部分事实对正确性的重要程度，从而知道这个答案依赖哪些关键事实。这类分析能帮你定位提示词该补哪一块信息。

一个完整示例

下面把上述策略串起来，做一个「依据内部文档回答用户问题」的最小可用流程。假设你有一份产品说明文档，需要让模型只依据文档回答用户提问，并给出可校验的引用。

第 1 步：准备文档片段。 把文档切成若干段，每段编号，存成纯文本。

[1] 产品支持通过配置文件设置超时时间，默认单位为秒。
[2] 配置文件位于安装目录下的 config 子目录。
[3] 修改配置后需要重启服务才能生效。

第 2 步：拼接提示词。 把角色、约束、参考文本、输出格式写在一起，用分隔符隔开。

你是一名技术支持工程师。请仅依据 <documents> 中的内容回答用户问题。
要求：
1. 每个结论后用方括号标注来源段落编号，例如 [2]；
2. 如果文档中没有相关信息，回答「文档中未提及」，不要推测；
3. 回答控制在三段以内，语言简洁。

<documents>
[1] 产品支持通过配置文件设置超时时间，默认单位为秒。
[2] 配置文件位于安装目录下的 config 子目录。
[3] 修改配置后需要重启服务才能生效。
</documents>

用户问题：我改了超时时间，为什么没有生效？

第 3 步：检查输出。 期望的回答大致是：配置文件位于安装目录下的 config 子目录 [2]；修改配置后需要重启服务才能生效 [3]。如果模型给出了文档之外的原因，说明约束没有生效，需要加强「不要推测」的措辞，或把参考文本的边界标得更清楚。

第 4 步：程序化校验引用。 从输出中提取所有方括号编号，检查每个编号是否在文档中存在，并核对引用段落是否真的支持该结论。这一步可以用字符串匹配完成，成本很低。

第 5 步：建立测试集并迭代。 准备一批覆盖不同情况的问题：文档能回答的、文档回答不了的、需要跨段组合的。每次修改提示词后重跑整批问题，记录通过率。只有通过率稳定提升，才认为改动有效。

第 6 步：按需引入外部工具。 如果问题涉及计算或实时数据，在流程中加入代码执行或 API 调用环节：让模型输出结构化参数，由程序执行，再把结果回填到下一轮请求。注意把执行环境放在沙盒中。

注意事项

不要指望模型读心。 输出不符合预期时，先检查提示词里是否真的写了这条要求，而不是反复重试碰运气。
参考文本要设边界。 只给资料不设约束，模型仍可能混入自身知识。明确写出「仅依据以下内容」以及「无信息时如何回答」。
引用需要校验。 要求模型标注来源只是第一步，输出中的引用必须通过程序比对确认，否则无法排除编造。
上下文长度有限。 长对话和长文档都需要总结或检索来压缩信息，不能假设模型记得全部历史。
代码执行有安全风险。 模型生成的代码不可信，必须在沙盒环境中运行，并限制其可访问的资源。
单次结果不能说明问题。 评估提示词改动需要成批的测试用例，样本太少时结论不可靠。
模型版本、价格、配额与上下文长度会变化。 本文不涉及具体数值，实际使用前请以官网当前信息为准。