Prompt 工程实践：从验收标准到测试集的五步调优法

前言

最近在学习华为云学堂的 Prompt 工程微认证课程，同时用 ModelArts Studio（MaaS）上开通的大模型服务做了几个小工具。课程里讲的“角色、任务、约束、示例、输出格式”五要素听起来简单，但真正落到业务里，提示词往往要改十几版才稳定。本文把我这段时间的实践整理成一套可复用的步骤，适合刚开始接触大模型应用开发的同学参考。

一、先把需求写成“验收标准”

很多提示词效果不好，根源不在措辞，而在于需求本身没说清。我的做法是在写提示词之前，先用三句话写下验收标准：

• 输入是什么：例如“一段 200~500 字的用户工单描述”。
• 输出是什么：例如“JSON，包含 category、priority、summary 三个字段”。
• 怎样算对：例如“category 只能取 5 个预设值之一，summary 不超过 50 字”。

有了验收标准，后面每次修改提示词都能对照检查，而不是凭感觉判断“好像变好了”。

二、按五要素搭第一版提示词

第一版不追求完美，只要结构完整。我常用的模板如下：

【角色】你是一名经验丰富的云服务工单分类助手。
【任务】阅读用户提交的工单内容，判断问题类别和紧急程度，并给出一句话摘要。
【约束】
1. category 只能是：账号与计费、计算、存储、网络、其他。
2. priority 只能是：高、中、低。
3. 不要编造工单中没有的信息。
【示例】
输入：云服务器突然无法 SSH 登录，业务已中断。
输出：{"category":"计算","priority":"高","summary":"ECS 无法 SSH 登录导致业务中断"}
【输出格式】只输出一行 JSON，不要任何解释。

这里有两个小经验：一是约束用编号列出，比写成一段话更容易被模型遵守；二是示例要覆盖“边界情况”，比如一个看起来像网络问题、实际是计费欠费导致的工单。

三、准备一个小测试集

提示词调优最怕“改好一个、改坏三个”。我会准备 20~30 条真实但已脱敏的样例，每条标注期望结果，保存成表格。每改一版提示词，就把整套样例跑一遍，统计三项指标：

• 格式合规率：输出能否被 JSON 正常解析；
• 字段准确率：category、priority 与人工标注一致的比例；
• 幻觉次数：摘要里出现原文没有的信息的条数。

用 Python 写个几十行的脚本循环调用接口即可，MaaS 的在线推理服务提供兼容 OpenAI 风格的调用方式，用常见的 SDK 改一下 base_url、模型名和 API Key 就能跑通。注意 API Key 放在环境变量里，不要硬编码进代码仓。

四、常见问题与对应改法

1. 输出夹带解释文字，JSON 解析失败。在输出格式里明确“只输出 JSON”，同时在代码侧做兜底：用正则截取第一个大括号到最后一个大括号之间的内容再解析。两手都要有，不要只依赖模型自觉。

2. 分类结果在相近类别之间摇摆。给每个类别补一句判定规则，例如“因欠费导致的资源不可用，归入账号与计费”。规则比多加示例更省 Token，效果也更稳定。

3. 摘要出现臆测内容。把“不要编造”改成可操作的要求：“摘要中的每个名词都必须在原文中出现”。同时把 temperature 调低（例如 0.1~0.3），减少随机性。

五、把提示词当代码管理

提示词稳定之后，我会把它和测试集一起放进代码仓，并遵循几条约定：

1. 提示词单独存放为文本文件，不要散落在业务代码字符串里；
2. 每次修改都写清楚改了什么、为什么改，以及测试集指标的变化；
3. 更换模型或模型版本时，必须重新跑一遍测试集，不能默认效果不变。

这样团队成员接手时能看懂每条约束的来历，也方便回滚。

六、小结

回顾这段实践，我最大的体会是：Prompt 工程本质上是一种“需求工程 + 测试工程”。先定义清楚什么叫对，再用结构化的提示词去逼近它，最后用测试集量化每一次修改的效果。技巧本身并不神秘，关键是形成可重复的流程。希望这套步骤能帮大家少走一些弯路，也欢迎在评论区交流各自的调优经验。