面向测试场景的提示词设计：五个模板与效果对比

不用背"提示词五要素"。这篇直接给 5 个我每天都在用的提示词，每个都配上同一个任务下"随口问 AI"和"用这个提示词"的产出对比。 文中数据为脱敏示例，提示词可直接复制使用。

0. 先看结果（TL;DR）

#	提示词	解决的任务	随手问的可用率	用提示词后
P1	用例生成	从 Swagger 生成用例	31%	84%
P2	脚本转换	用例 → pytest 脚本	40%	84%
P3	失败诊断	失败日志分类	50%	85%（与人工一致率）
P4	影响面分析	从 diff 定回归范围	漏 3 个模块	P0 清单 9 条全命中
P5	报告汇总	结果 → 给决策者的简报	每次结构不同	固定 4 段，可直接转发

可拿走：prompts/ 目录 5 个文件（含占位符说明）+ 参数配置 + 评测集做法。 说明：这里的"可用率"是我同一批任务、同一模型、只改提示词得到的实测值。

1. 我的基准材料（保证对比公平）

• 同一批 30 个接口的 Swagger + DDL + 业务规则 8 条 + 历史 Bug 10 条
• 同一批 20 条失败日志
• 同一次改动（git diff --stat，涉及 11 个文件）
• 同一模型、temperature 固定

2. 五个提示词（逐个给完整版 + 前后对比）

P1 用例生成

【角色】你是资深接口测试工程师，熟悉支付与订单风控规则。
【任务】基于下面材料，为这一个接口生成可执行测试用例。
【输入】
- 接口定义：<粘贴该接口的 Swagger 片段>
- 相关表结构：<粘贴 DDL>
- 业务规则：<粘贴规则清单，逐条编号>
- 历史缺陷：<粘贴近 6 个月同模块 Bug 标题+现象>
- 环境信息：<base_url、测试账号来源、造数脚本路径>
【输出格式】严格 JSON：
{"api":"...","cases":[{"id":"...","title":"...","priority":"P0|P1|P2","type":"正常|边界|异常|权限|幂等",
"preconditions":[],"data_preparation":[],"request":{},"expected":[],"assertions":[],"confidence":0-1}],"unknowns":[]}
【约束】
1. 字段名/枚举值/路径必须逐字来自 Swagger，禁止推测
2. 覆盖：正常 1 条 + 边界 ≥2 条（0/负数/上限/精度）+ 异常 ≥2 条 + 幂等或并发 ≥1 条
3. expected 必须写具体值（如 amount == 199.80），禁止"返回成功"这类不可断言表述
4. data_preparation 必须是可执行调用（脚本名 + 参数），禁止状态描述
5. 材料未定义的规则写入 unknowns，不要自行假设
6. 每条给 confidence，依据不足时 < 0.75

前后对比（同 30 个接口，逐条人工判定可用性）：

指标	随口问（"给这个接口写测试用例"）	用 P1
直接可用	31%	84%
编造字段	9 处	0 处
有具体值断言	12%	79%
输出 unknowns（承认信息不足）	无	17 条

为什么这么写：最关键的其实是第 1 条与第 4 条 —— 它们把两类最常见的错误（编字段、写不可执行的数据准备）堵在生成阶段，比事后用校验脚本修便宜得多。

P2 脚本转换

【角色】你是 Python 自动化测试开发工程师。
【任务】把下面的用例转成可执行 pytest + requests 脚本。
【输入】
- 用例 JSON：<粘贴>
- fixture 清单（只能用这些）：<粘贴 `pytest --fixtures -q` 输出或手写清单>
- 环境变量白名单：<粘贴 .env.example>
- 表名字典：<粘贴 {"orders":"orders","items":"order_items"}>
- 一个已有用例文件作为风格示例：<粘贴>
【输出格式】只输出 .py 文件内容，不要解释文字与代码围栏
【约束】
1. 禁止硬编码 URL/账号/token，一律从 fixture 或环境变量取
2. 只能使用清单里的 fixture；不确定就用 seed()，不要引用不存在的 fixture
3. 断言含业务字段值 + 至少一项副作用（DB/状态）
4. 每条用例可独立运行
5. SQL 表名必须来自表名字典
6. 异常场景用 monkeypatch 或参数化，禁止 time.sleep
7. 信息不足的用 pytest.skip("信息不足：<原因>") 标记，不要编造

前后对比（50 条用例 → 脚本）：

指标	随口问	用 P2
一次跑通	40%	84%
硬编码出现	7 处	0 处
自创 fixture	6 处	0 处
单条可独立运行	78%	100%

为什么这么写：fixture 清单 与 环境变量白名单 是这份提示词的灵魂 —— 模型没有项目上下文，你不给清单，它就会按"通用经验"编一套。

P3 失败诊断

【角色】你是测试开发工程师，擅长故障排查。
【任务】把失败归类为 A 代码缺陷 / B 测试数据问题 / C 环境问题 / D 用例自身问题，并给出排查步骤。
【输入】
- 用例与步骤：<粘贴>
- 完整错误堆栈：<粘贴>
- 原始请求响应：<粘贴>
- 环境信息（版本/commit/环境标识）：<粘贴>
- 该用例近 5 次执行结果：<粘贴>
- 近期相关变更：<粘贴 diff 摘要>
【输出格式】
1. 归类 + 置信度（0-1）
2. 判断依据：逐条引用输入中的具体行（不要只给结论）
3. 排查步骤：最多 3 步，按成本从低到高
4. 若判 A：疑似模块/函数 + 最小验证方式
5. 信息不足时列出"还需要什么"，不要臆测
【约束】
- 先排除 C（环境）与 B（数据），再考虑 A（代码）；除非堆栈明确指向业务代码行
- 不要输出材料中未出现的异常类型
- 不要建议"加 sleep / 加大超时"作为最终解法（可作临时隔离并注明）
- 置信度 < 0.7 → 直接输出"无法判定，建议人工介入"

前后对比（20 条失败）：

指标	随口问	用 P3
与人工结论一致	50%	85%
误判为"代码缺陷"	5 条	1 条
给出可执行排查步骤	少数	20 条全给（平均 3 步）
主动承认信息不足	无	3 条

为什么这么写：约束里的**"排除顺序"**是关键 —— 模型天生倾向归因到"最有价值"的类别（代码缺陷），强制它先排除环境与数据，误提缺陷直接少一半。

P4 影响面分析

【角色】你是资深测试分析师。
【任务】分析本次变更的影响面，输出回归重点（不要生成用例）。
【输入】
- 变更文件列表：<粘贴 git diff --stat>
- 关键 diff：<粘贴核心改动>
- 模块依赖说明：<粘贴目录结构或调用关系>
- 接口文档片段：<粘贴相关 Swagger>
- 历史缺陷（按模块）：<粘贴>
【输出格式】
一、变更性质：file | 逻辑/接口/配置/数据/注释 | 是否影响对外行为
二、影响点清单：P0/P1/P2 | 影响点 | 受影响业务 | 判断依据 | 回归方式(自动化/手工/无需)
三、必须人工确认项（材料不足的，不要猜）
【约束】
- 每条结论必须写"判断依据"
- 必须专门检查：配置变更、数据库 DDL 变更、被其它模块依赖的公共组件、跨服务契约

前后对比（同一次改动，我拿人工梳理的清单当基准）：

指标	随口问	用 P4
P0 影响点覆盖	6/9（漏了配置项、DDL、公共组件调用方）	9/9
输出可追溯依据	无	100% 有条
误报（不存在的关联）	3 条	0 条

为什么这么写：把"必须专门检查的四类"写进约束 —— 这四类（配置/DDL/公共组件/跨服务契约）是人工也最容易漏的，写进约束后模型会主动找。

P5 报告汇总

【角色】你是测试负责人。
【任务】把本次回归结果汇总成给决策者的简报。
【输入】执行结果数据（用例数、通过率、失败明细、耗时）+ 未修缺陷清单 + 上线关注点
【输出格式】固定四段，每段不超过 5 行：
一、结论（可发布 / 有条件发布 / 不可发布）+ 一句话理由
二、关键数据（通过率、P0 用例覆盖率、遗留缺陷按严重度分布）
三、风险清单（每条：影响面 + 缓解建议）
四、建议的发布后观察项
【约束】数据只能来自输入；禁止"基本没问题"这类模糊表述

前后对比：

指标	随口问	用 P5
输出结构	每次不同（有时散文、有时列表）	固定四段，可直接转发
含发布结论	有时没有	100% 有
模糊表述	常见	0 处（被约束禁止）

3. 四个通用参数（比提示词更容易被忽略）

参数	我的设置	说明
temperature	0.2（需要结构化输出时）；创作类可 0.7	结构化任务要稳，不要"发挥"
输出格式约束	JSON Schema 或"只输出 .py 文件内容"	明确禁止寒暄与解释文字
few-shot 示例	1-2 个（不要更多）	示例过多反而降低泛化（见踩坑 1）
置信度阈值	< 0.75 转人工	让模型自己标"把握不足"，比事后抽查便宜

4. 3 个卡住我的坑

坑 1：few-shot 示例给多了，产出反而变差

现象：喂了 5 个完整用例 JSON 作为示例后，模型对每个新接口都照抄示例的结构与字段（连示例里的 discountRate 都带过来了）。 原因：示例过多时，模型把它当"模板"而不是"风格参考"。 解决：只留 1-2 个示例，且示例里刻意用与目标接口不同的字段名，避免被照抄。

坑 2：约束写到 12 条，模型开始"漏项"

现象：约束堆到 12 条后，data_preparation 这条开始被忽略（约 30% 的用例没写）。 原因：约束过多时模型会"顾此失彼"。 解决：把约束分组——硬约束（字段/格式）在提示词里，业务约束（必须覆盖哪类场景）挪进"输出前自检"：

输出前请自检并把结果附在 JSON 的 self_check 字段：
  cover_normal / cover_boundary(≥2) / cover_exception(≥2) / cover_idempotent /
  data_preparation_executable / fields_from_swagger
任一项为 false 时，说明原因

加上自检后，漏项从 ~30% 降到 4%（那些"漏"其实是被标成 false 让我知道的）。

坑 3：中英混用，字段名大小写不一致

现象：提示词里写"订单金额"，模型输出 amount；另一次写"订单Amount"，输出 Amount（大写开头）→ 断言匹配不到。 解决：提示词里字段一律用代码里的原样写法（amount、orderNo），不写中文别名；并在输出约束里加"字段名大小写必须与输入一致"。

5. 你可以直接拿走的

prompts/ 目录结构（版本化，改动走评审）：

prompts/
├── p1-gen-cases.md          # 用例生成
├── p2-gen-scripts.md        # 脚本转换
├── p3-triage-log.md         # 失败诊断
├── p4-impact-analysis.md    # 影响面分析
├── p5-report-summary.md     # 报告汇总
├── fixtures_list.txt        # P2 的 fixture 清单（pytest --fixtures 生成）
├── env_vars.txt             # P2 的环境变量白名单
└── eval/                    # 评测集：20 条真实任务 + 期望要点

配套习惯（比提示词本身更重要）：

1. 每次改提示词，都拿 eval/ 跑一遍对比产出可用率（我这次 P1 从 84% 提到 91% 就是靠它发现的）
2. 把"模型改对了的地方"也记下来 —— 你的修改类型分布，就是下一版提示词的输入

收益汇总：

任务	随手问	用提示词	提升
用例生成可用率	31%	84%	+53 个百分点
脚本一次跑通率	40%	84%	+44
失败分类一致率	50%	85%	+35
影响面 P0 覆盖	6/9	9/9	全命中

下一步可以做的 2 件事：

1. 先建 eval/（20 条真实任务就够），否则你永远不知道改提示词是变好还是变坏
2. 把 P1-P5 里的约束条目整理成一张检查表，新写提示词时照着补

---

参考资料

• 结构化提示五要素与提示工程分工：AI 辅助软件测试：几个关键路径
• 回归流程分环节提示词的实践：我把回归测试从 3 天压到 3 小时（提示词公开）
• 提示策略的量化对比（zero-shot / few-shot / role / CoT）：VNTU 2026 研究
• 幻觉导致编译失败率等大规模评测结论：EMSE 2026（216,300 用例）

本文由 曲奇 整理，内容由 AI 辅助整理，示例数据为脱敏演示数据；仅供学习参考，转载请注明出处。