7.5.5 Prompt 工程实践

学习目标

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

一、Prompt 工程最常见的误解

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

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

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

礼貌与否通常不是关键。

更准确的一句话

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

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

二、先看一个“坏 prompt”

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

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

帮我分析这条评论。

问题在哪？

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

改成一个更清楚的版本

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

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

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

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

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

任务目标够不够清楚？

先问：

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

输出格式够不够清楚？

再问：

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

约束够不够清楚？

例如：

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

示例够不够有引导性？

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

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

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

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

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

print(prompt_spec)

预期输出：

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

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

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

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

任务：文本摘要

版本 1：太泛

总结这段话。

问题：

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

版本 2：更具体

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

这就好很多了。

版本 3：再加边界

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

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

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

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

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

fact
opinion

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

一个示例

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

for ex in few_shot_examples:
    print(ex)

预期输出：

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

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

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

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

一个典型场景：信息抽取

如果你只是说：

帮我抽取简历信息。

那模型可能：

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

更好的版本

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

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

不要输出任何额外解释。

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

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

不要一次改很多地方

Prompt 调试最怕这样：

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

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

更好的方式

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

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

这和调模型超参数很像。

Prompt 调试闭环漫画

九、一个小型 Prompt 评估示例

先定义测试样本

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

for case in test_cases:
    print(case)

预期输出：

{'input': '这门课讲得很清楚。', 'expected': 'positive'}
{'input': '内容有点乱。', 'expected': 'negative'}

为什么这一步重要？

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

真正更成熟的做法是：

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

十、初学者最常踩的坑

写 prompt 时没有明确定义输出

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

觉得 prompt 调优只能靠灵感

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

只看单条成功案例

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

留下的证据

学完这一页，至少保留这张证据卡：

基线提示: 第一版和失败情况
已更改变量: 每次只改一个 Prompt 维度
评分: 简单通过/失败或评分量表结果
失败类别: 指令、上下文、格式或歧义
下一次迭代: 尝试一个具体的修改

小结

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

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

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

练习

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

参考实现与讲解

坏 prompt 往往很模糊，比如“分析一下”。更好的版本要写清任务、输入、期望输出、标签、约束和至少一个失败边界。
few-shot 版本应包含有代表性的正向、负向、中性例子，然后要求新样例使用同样标签格式。
结构化摘要可以返回 {"summary": "...", "key_points": ["..."], "risks": ["..."], "missing_info": ["..."]}。
Prompt 工程是接口设计，因为它定义模型与周围系统之间的输入、输出、约束、校验期望和失败处理。