Prompt Engineering

Prompt Engineering(提示工程)是通过设计和迭代输入给模型的指令,来稳定地拿到想要的输出。它常被误解成"话术技巧",实际上在工程语境里它更接近需求规格说明 + 回归测试:把模糊的期望写成模型能执行的明确规则,然后用数据验证有没有做到。

真正有效的几个动作

按实测收益排序,而不是按流传广度:

• 给足上下文和约束。模型不知道你的业务背景、不知道输出要给谁看、不知道什么算错。这些不说,它只能按最通用的方式理解。绝大多数"效果不好"是信息给少了,不是技巧不够。
• 给示例(Few-shot)。想要的格式、语气、判断边界,举两三个例子比写五百字描述有效得多。尤其是举一个反例,告诉它什么情况该拒绝或该输出空值。
• 规定输出格式。要结构化就明确给出 Schema,并使用厂商的结构化输出能力,而不是靠自然语言恳求它"请返回 JSON"。
• 拆步骤。复杂任务让它先分析再结论,或者干脆拆成多次调用。一次调用干五件事,五件事都会打折。
• 给拒答的出口。明确写"信息不足就说不知道",否则模型的默认倾向是编一个完整答案。

被高估的做法

• 威胁、贿赂、情绪化措辞。在现代模型上收益微乎其微,还会污染指令的清晰度。
• 堆砌"你是世界顶级专家"。适度的角色设定有用,层层加码没用。
• 一味加长。Prompt 变长会稀释关键约束,重要的规则要往开头和结尾放,不要埋在中间。

它是工程,不是灵感

区分"会写 Prompt"和"做 Prompt 工程"的,是有没有下面这套东西:

• 固定的评测集。二三十条覆盖典型场景和边界情况的真实样本,每次改 Prompt 都跑一遍。没有它,改动是好是坏全靠感觉。
• 版本管理。Prompt 是代码的一部分,要进仓库、要能回滚、要知道线上跑的是哪一版。
• 模板化。变量用占位符注入,不要字符串拼接,尤其当变量来自用户输入时——那是提示注入的入口。
• 按模型重调。同一个 Prompt 换个模型表现可能明显不同,换模型要重跑评测。

它会不会过时

有一种说法是模型越强就越不需要 Prompt 工程。部分成立:早期那些绕弯的技巧确实在失效。但"把需求说清楚、给出判断标准、定义什么算成功"这件事不会过时——模型再强也读不出你没说的东西。变化的是技巧,不变的是把模糊需求变成明确规格这项工作。