一句话解释

提示词工程（Prompt Engineering）就是研究“怎么跟大模型说话”的方法：通过把任务、背景、要求和示例组织好，让模型更准确、更稳定地给出你想要的结果。

为什么提示词会影响结果

大语言模型的工作方式是：根据它看到的全部输入，预测接下来最合适的内容。它看不到你的脑子，只能看到你写下的文字。你说得越模糊，它就越要“猜”，而猜的方向未必是你想要的。

举个例子，“写一篇产品介绍”和“为一款面向自由职业者的记账 App 写一段 150 字左右的应用商店介绍，语气轻松，突出自动分类账单这个功能，不要使用夸张形容词”，后者得到的结果几乎一定更接近需求。

提示词工程的本质，不是学习神秘咒语，而是练习把需求表达清楚。

一个好提示词的基本要素

刚入门时，可以按下面几个要素检查自己的提示词：

任务：要模型做什么，用明确的动词表达，比如“总结”“改写”“分类”“翻译”“找出错误”。

背景：模型完成任务需要知道的信息，比如读者是谁、用途是什么、已有哪些资料。

要求与约束：字数、语气、格式、必须包含或必须避免的内容。

输出格式：希望得到列表、表格、JSON 还是一段话。格式说得越具体，越方便后续使用。

示例（可选）：给一两个“输入—输出”样例，往往比长篇描述更有效。

不必每次都写全，但当结果不理想时，通常就是其中某一项缺失了。

常用技巧

1. 给模型一个角色或视角。 比如“你是一名有经验的技术文档编辑”。它的作用在于帮模型确定语气和专业程度，但不能代替具体要求。

2. 用分隔符区分指令和材料。 当提示里包含需要处理的文本时，用引号、三重反引号或 XML 风格的标签把材料包起来，并说明“下面标签里的内容是待处理的文章”。这样模型不容易把材料里的句子当成指令。

3. 少样本示例（Few-shot）。 想让模型按特定风格或格式输出时，直接给出几个示例。示例要彼此有差异，否则模型可能过度模仿某个细节。

4. 让模型分步骤思考。 对于推理、计算、多条件判断类任务，要求模型“先列出分析步骤，再给出结论”，通常能提高准确率。这一思路在研究中被称为“思维链”（Chain-of-Thought）。

5. 拆分复杂任务。 与其在一个提示里要求“调研 + 写大纲 + 写全文 + 校对”，不如拆成几步，每一步检查结果后再进行下一步。

6. 允许模型说“不知道”。 明确写上“如果资料中没有相关信息，请直接说明”，能减少模型硬编答案的情况。

7. 正面描述期望。 与其只说“不要写得太长”，不如说“控制在 100 字以内”。告诉模型该做什么，往往比只告诉它不该做什么更有效。

把提示词当作代码来迭代

好的提示词很少一次写成，通常需要反复调整：

  1. 先写一个简单版本，跑几次看看结果。
  2. 找出问题：是理解错了任务，格式不对，还是遗漏了要点？
  3. 针对性修改：一次只改一处，方便判断是哪个改动起了作用。
  4. 用多个测试输入验证：一个例子效果好不代表普遍好用，准备几种典型和边界情况一起测。
  5. 保存有效版本：把好用的提示词整理成模板，记录适用场景。

如果是在产品中使用提示词，还应当建立一组固定的测试用例，每次修改后都跑一遍，避免“修好一个、弄坏另一个”。

常见误区

误区一：存在万能的“神级提示词”。 网上流传的模板可以参考，但效果和具体任务、具体模型高度相关，照搬往往不如自己根据需求写。

误区二：提示词越长越好。 无关信息会分散模型注意力，也会增加成本。该写的写清楚，不该写的删掉。

误区三：加上“请认真回答”“这很重要”就能提升质量。 这类空泛的强调作用有限，具体的要求和示例才是关键。

误区四：换个模型，提示词照样好用。 不同模型对指令的理解习惯不同，迁移时需要重新测试和调整。

误区五：提示词能解决一切问题。 如果模型缺乏相关知识，再好的提示词也无济于事，这时应考虑提供资料（如 RAG）或换用更合适的模型。

延伸阅读