跳到主要内容

Prompt 工程实践

本节定位

前面几节已经讲了：

  • Prompt 基础
  • 高级技巧
  • 结构化输出

这一节不再讲新名词，而是做一件更重要的事：

把 Prompt 当成工程对象来练。

也就是说，不只问“这个 prompt 能不能跑”，而是问“它为什么更稳、哪里更清楚、为什么更适合当前任务”。

学习目标​

  • 学会判断一个 prompt 为什么不好
  • 学会从目标、约束、示例、输出格式四个方向改 prompt
  • 看懂几个典型任务的 prompt 迭代过程
  • 建立 Prompt 调试而不是拍脑袋写 prompt 的习惯

一、Prompt 工程最常见的误解​

1.1 误解：prompt 就是“写得礼貌一点”​

其实 Prompt 工程真正关心的是：

  • 任务定义是否清楚
  • 输出要求是否明确
  • 约束是否可执行
  • 示例是否足够引导

礼貌与否通常不是关键。

1.2 更准确的一句话​

Prompt 是你给模型写的任务接口说明书。

如果说明书含糊，模型输出自然容易飘。

二、先看一个“坏 prompt”​

2.1 任务：把用户评论做情感分类​

一个很差的 prompt 可能长这样：

帮我分析这条评论。

问题在哪？

  • 不知道要分析什么
  • 不知道输出格式
  • 不知道标签范围
  • 不知道要不要解释

2.2 改成一个更清楚的版本​

请判断下面评论的情感倾向，只能输出 positive 或 negative，不要输出其他内容。

评论：这门课讲得很清楚，例子也很多。

这个版本一下子就清楚多了，因为它明确了：

  • 任务：情感分类
  • 输出集合：positive / negative
  • 输出约束：不要额外内容

三、Prompt 调试的四个核心维度​

3.1 任务目标够不够清楚？​

先问：

  • 模型到底要做分类、总结、抽取还是改写？

3.2 输出格式够不够清楚？​

再问：

  • 输出是一句话？
  • 一个标签？
  • JSON？
  • 表格？

3.3 约束够不够清楚？​

例如：

  • 不能编造
  • 不能输出额外解释
  • 只能根据给定文本回答

3.4 示例够不够有引导性？​

有些任务仅靠说明不够，最好补 few-shot 示例。

这四个问题，基本构成了 Prompt 实践的主线。

四、一个可运行的 Prompt 练习器​

下面这个例子不是在调用真实大模型，而是用“任务规范对象”来帮助你学会如何拆 Prompt 需求。

prompt_spec = {
    "task": "sentiment_classification",
    "allowed_labels": ["positive", "negative"],
    "output_format": "single_label",
    "constraints": ["不要输出解释", "只输出标签"]
}

print(prompt_spec)

这个示例看起来简单，但它在教你一件很重要的事：

一个好 prompt 背后，通常有一套更明确的任务规格。

五、一个典型任务的 Prompt 迭代​

5.1 任务：文本摘要​

版本 1：太泛​

总结这段话。

问题：

  • 不知道总结成多长
  • 不知道用什么风格
  • 不知道要不要保留要点

版本 2：更具体​

请把下面文本总结成 3 条中文要点，每条不超过 20 个字。

这就好很多了。

版本 3：再加边界​

请把下面文本总结成 3 条中文要点，每条不超过 20 个字。
只保留事实，不要补充原文没有的信息。

这时 prompt 已经从“会回答”走向“更稳定可控”。

六、few-shot 什么时候特别有用？​

6.1 当任务定义仅靠语言不够清楚时​

例如你让模型判断一句话是：

  • fact
  • opinion

如果只给定义，模型可能理解不稳定。
这时 few-shot 示例就很有帮助。

6.2 一个示例​

few_shot_examples = [
    {"input": "北京是中国的首都。", "output": "fact"},
    {"input": "这门课非常有趣。", "output": "opinion"}
]

for ex in few_shot_examples:
    print(ex)

few-shot 的作用不是“多写点字”，而是：

给模型示范“我想要的判断方式”。

七、结构化任务怎样写 prompt 更稳？​

7.1 一个典型场景：信息抽取​

如果你只是说：

帮我抽取简历信息。

那模型可能：

  • 抽得不全
  • 字段名乱写
  • 多输出解释

7.2 更好的版本​

请从下面简历中抽取信息，并输出 JSON。

字段：
- name: string
- school: string
- skills: list[string]

不要输出任何额外解释。

这已经把任务、结构和边界都交代清楚了。

八、Prompt 实践中的“最小实验”习惯​

8.1 不要一次改很多地方​

Prompt 调试最怕这样：

  • 任务说明改了
  • 例子改了
  • 输出格式也改了

结果你根本不知道是哪一项起作用。

8.2 更好的方式​

一次只改一个变量，例如：

  1. 先只加输出约束
  2. 再只加 few-shot
  3. 再只改格式要求

这和调模型超参数很像。

九、一个小型 Prompt 评估示例​

9.1 先定义测试样本​

test_cases = [
    {"input": "这门课讲得很清楚。", "expected": "positive"},
    {"input": "内容有点乱。", "expected": "negative"}
]

for case in test_cases:
    print(case)

9.2 为什么这一步重要？​

因为 Prompt 工程也要评估。
如果没有测试样本，你就只能凭感觉判断“这个 prompt 好不好”。

真正更成熟的做法是：

  • 有输入集
  • 有期望输出
  • 看 prompt 是否稳定符合预期

十、初学者最常踩的坑​

10.1 写 prompt 时没有明确定义输出​

这会让后处理越来越痛苦。

10.2 觉得 prompt 调优只能靠灵感​

其实它很像普通工程调试：要做小实验、看结果、逐步改。

10.3 只看单条成功案例​

一条样例答对，不代表 prompt 稳。

小结​

这一节最重要的不是背多少 Prompt 技巧，而是建立这样一个习惯：

把 Prompt 当成任务接口来设计、当成系统组件来调试。

当你开始围绕任务目标、格式、约束和示例做迭代，而不是凭感觉写一句话，Prompt 工程才真正开始变成熟。

练习​

  1. 选一个你熟悉的任务，先写一个“坏 prompt”，再一步步改成更好的版本。
  2. 为“情感分类”任务补一个 few-shot 版本。
  3. 把“文本摘要”任务改成结构化输出格式，比如 JSON。
  4. 用自己的话解释：为什么 Prompt 工程不是“写一句好话”，而是“设计任务接口”？