提示词工程入门：怎么写好AI提示词

为什么提示词的措辞很重要

语言模型不了解你的处境，它只看得到你发过去的文字。提示词含糊时，模型会用最典型的答案去填补空白，这样的答案通常泛泛而谈、篇幅过长，或者对准了错误的读者。提示词工程的大部分工作，就是消除这些猜测。

有个好用的检验方法：一位聪明的新同事，从没见过你，只凭你这条消息能把任务做好吗？如果他得先问三个问题，那模型也需要这三个问题的答案。OpenAI、Anthropic 和 Google 的官方指南，用不同的话说的是同一条核心建议：表达清楚具体，提供背景，给出示例，说明想要的格式。

好提示词的六个组成部分

并不是每条提示词都需要六个部分齐全，但对照这份清单检查一遍，就能修好大多数不够好的提示词。

较长的输入材料，要放在清晰的标记之间，比如 XML 风格的标签或三重引号，让模型能区分你的指令和要处理的文字。这也能降低一种风险：输入里藏着的指令（比如粘贴进来的网页中），被误当成命令执行。

改写前后对比

下面是一条典型的不够好的提示词：

Summarize this article.

模型会给出一份摘要，但多长、给谁看、什么形式，都不确定。下面是同一个请求，补全了这些空白：

You are helping a busy product manager decide whether to read a research article.

Summarize the article below for that reader.
- Start with one sentence: the main finding.
- Then 3 bullet points: method, key number, main limitation.
- Use plain English. Explain any technical term in a few words.
- Under 100 words in total.
- If the article does not state a limitation, write "No limitation stated".

<article>
{paste the article here}
</article>

每个部分的作用：

• 第一行设定了读者和目的。模型现在知道摘要为什么而写，所以会据此取舍内容。
• 要点结构固定了格式，每份摘要看起来都一样，也便于比较。
• 字数上限防止模型凑字数。
• 关于缺少局限的规则，告诉模型遇到边界情况该怎么做，而不是自己编一个。
• 标签把文章和指令分隔开。

文字说不清时，给示例

有些要求很难描述，却很容易演示：一种语气、一套标注方案、一种特定的输出风格。加入几个做好的示例，这种做法叫少样本提示（few-shot prompting）。一个示例（one-shot）往往就很有帮助，两到五个各不相同的示例通常能覆盖主要情况。

Classify each support message as BILLING, SHIPPING, PRODUCT or OTHER.
Reply with the label only.

Message: I was charged twice for order 5521.
Label: BILLING

Message: The handle on my mug cracked after one week.
Label: PRODUCT

Message: Do you have a shop in Osaka?
Label: OTHER

Message: {new message}
Label:

示例之间要有差异。如果它们全都又短又客气，模型处理一封又长又愤怒的消息时可能会出问题。还要检查示例与规则是否一致：模型照搬示例的倾向，比遵循书面指令更强。

针对特定情况的技巧

• 先要步骤，再要答案。对数学、逻辑或多部分的决策，让模型先把问题推演一遍再给最终答案，能提高准确率，这叫思维链（chain-of-thought）提示。当前许多模型会在内部这样做（通常叫推理或思考模式），所以一句“请仔细作答”有时就够了。
• 拆分大任务。与其在一条提示词里写“调研、列提纲、写报告”，不如分成三条提示词，检查每一步的输出。这叫提示词链（prompt chaining）。
• 只有角色能增加信息时才设定角色。“你是一位越南的税务会计”会改变用词和假设，“你是世界一流的天才”则没有任何作用。
• 说明要做什么，而不只是不要什么。“用短句写”比“不要啰嗦”更有效。
• 允许回答“我不知道”。告诉模型，可以说信息缺失。这样能减少编造的事实，但不能杜绝。
• 输出要由代码读取时，要求机器可读的格式，比如带命名字段的 JSON。大多数 API 也能直接强制使用 JSON schema。

像测试代码一样测试提示词

在一个例子上有效的提示词，换下一个可能就失效。如果这条提示词会被反复使用，或者给别人用，就要测试：

1. 写下好的输出是什么样子：长度、格式、必须正确的事实。
2. 收集10到20个真实输入，包括困难的：特别短的、特别长的、跑题的、另一种语言的。
3. 把提示词在所有输入上跑一遍，阅读每一条输出。
4. 每次只改一处，再把整组输入重跑一遍，这样你知道是哪处改动起了作用。
5. 把最终的提示词和测试集放在一起保存。更换模型或模型更新时，把这组测试再跑一遍。

最后一步很关键，因为同一条提示词在不同模型上，甚至在同一模型的新版本上，表现都可能不同。模型厂商的提示词工程指南也因此会随时间变化。

常见错误

• 一条提示词里目标太多。十条同等权重的规则，会被部分忽略。把最重要的规则放在最前面，清单保持简短。
• 自相矛盾，比如“要详细”和“不超过50词”。模型只能满足其中一个，违反另一个。
• 靠大写字母或威胁（“你必须”）而不是讲清理由。简短地解释一条规则为什么存在，通常效果更好。
• 没有把输入和指令分开，让模型把文档的一部分当成了命令。
• 轻信输出中的事实。写得再好的提示词，仍会产生自信的错误。要核对人名、数字、引文和链接。