提示词工程：把模糊需求变成精确指令

同一个模型，同样的需求，有人得到一份能直接用的方案，有人得到一段正确的废话。差距通常不在「提示词技巧」，而在于有没有把需求说清楚。

模型不会读心。它只能根据你写下的文字，推测你没写下的部分。提示词工程要做的，就是减少这种推测。

一、为什么提示词时好时坏

输出的方差，往往来自输入的缺失。比如「帮我写个产品介绍」，模型需要自己决定：写给谁看、多长、什么语气、突出什么卖点、放在哪里。每一次它都可能在猜，而每次猜的都不一样。

与其反复重试，不如把这些隐含假设显式写出来。这就是提示词工程最核心的工作。

二、一个好提示词的五个零件

零件	作用	示例
角色	限定知识视角与语气	你是资深 B2B 产品市场经理
背景	补齐模型不知道的上下文	产品是面向中小企业的报销 SaaS
任务	说明要产出什么	写一段 120 字以内的官网首屏文案
约束	划出边界与禁区	不堆形容词，不使用「赋能」等空词
输出格式	让结果可直接使用	主标题 + 副标题 + 三个标签

五个零件不必每次都写全，但缺哪个，就要接受模型在那个维度上自由发挥。

三、从模糊到精确：一个改写示例

先看一个常见的模糊提示词：

帮我写个产品介绍。

再看改写后的版本：

你是资深 B2B 产品市场经理。

背景：产品是面向中小企业的报销 SaaS，核心差异是 10 分钟完成部署，
目标客户是 50 到 300 人的公司。

任务：写一段官网首屏文案。

约束：
- 总长度不超过 120 字
- 每句话都要有具体信息，不堆形容词
- 不使用「赋能」「闭环」「抓手」这类空词
- 读者是财务负责人，不是工程师

输出格式：
- 一句主标题（不超过 14 字）
- 一句副标题（不超过 30 字）
- 三个卖点标签（每个不超过 6 字）

改写后的版本没有使用任何「高级技巧」，只是把原本藏在脑子里的信息写了出来。输出会稳定得多，也更容易验收。

四、进阶技巧

少样本示例

当风格难以用文字描述时，给两到三个输入输出示例，比写十行形容词有效。示例要覆盖边界情况，否则模型会过度模仿。

任务分解

复杂任务不要一口气问完。先让模型列提纲，你确认后再逐段展开。这样每一步都可检查，错误不会滚雪球。

自检指令

在输出前加一句「先列出三个可能出错的地方，再给出最终答案」，能明显减少事实性错误。注意，自检不是事实核查，关键结论仍需外部验证。

结构化输出

需要程序解析时，直接给 JSON Schema，并说明「无法确定的字段填 null，不要编造」。这比事后用正则修补可靠得多。

五、不要做的事

• 堆砌强调词：「请务必」「一定要」写十遍，不如给一条明确约束。
• 让模型猜关键信息：缺少的数据就明说缺失，或先问清楚。
• 把五十页文档塞进上下文：先检索、摘要，再喂给模型。
• 不做评测就换提示词：感觉变好了，不等于真的变好了。
• 把提示词当成一次性消耗品：好提示词值得版本管理和回归测试。

六、把提示词当成代码

生产环境里的提示词，应该有版本号、有变量、有测试集。每次修改都记录改了什么、为什么改、指标如何变化。这样做的好处是，当效果回退时，你知道该退回到哪一版。

提示词工程的终点，不是找到一句万能咒语，而是建立一套可复现、可迭代、可验收的需求表达方式。