别再堆 Prompt 了：AI 测试真正缺的是一套质量规则库

最近做了几轮 AI 测试实践，我越来越明显地感受到一个问题：

很多人把 AI 测试效果不稳定，归因于 Prompt 写得不好。

于是大家不断优化 Prompt：

请生成更完整的测试用例。
请考虑边界值。
请覆盖异常场景。
请输出表格。
请注意权限和多端。
请不要遗漏回归测试。

这些当然有用。

但实践下来会发现，只靠 Prompt 仍然不稳定。

同一个 Prompt，换一个需求，AI 可能又会：

• 把待确认项写成正式用例；
• 把 PRD 没说的流程补全；
• 把“导出受影响”理解成“新增字段”；
• 把“影响 PC/H5”理解成“两端完全一致”；
• 把“需财务复审”理解成完整审批链；
• 写出“页面正常展示”“流程结束”这种不可验证预期。

这说明问题不只是 Prompt。

更底层的问题是：

AI 缺少一套稳定的质量判断规则。

Prompt 解决的是“这次怎么问”。
规则库解决的是“每次怎么判断对不对”。

---

一、为什么只靠 Prompt 不够？

我们先看一个简单例子。

假设有这样一段 PRD：

报销金额 ≤5000 元时，仅直属上级审批。
5000 元 < 报销金额 ≤20000 元时，需部门负责人审批。
报销金额 >20000 元时，需财务复审。
审批中可撤回，撤回后状态回到草稿。
任一节点驳回后，状态变为已驳回，申请人可修改后重新提交。
本次改动影响 PC 端、H5 端和报销数据导出。
批量导入是否支持，待产品确认。

如果直接让 AI 生成测试用例，它大概率能生成不少内容：

• 3000 元走直属上级；
• 5000 元走直属上级；
• 10000 元走部门负责人；
• 20000 元走部门负责人；
• 25000 元走财务复审；
• 审批中撤回；
• 驳回后重提；
• PC / H5 测试；
• 导出测试。

看起来还不错。

但真正评审时会发现很多问题。

比如 AI 可能写：

金额 >20000 元时，审批链为部门负责人 + 财务复审。

但 PRD 只写了：

金额 >20000 元时，需财务复审。

它并没有说一定还有部门负责人。

再比如 AI 可能写：

导出文件包含审批状态、审批人、审批时间字段。

但 PRD 只写：

报销数据导出受影响。

它没有给字段清单。

再比如 AI 可能写：

H5 端状态展示与 PC 端一致。

但 PRD 只说影响 PC 和 H5，没有说两端必须完全一致。

这些问题都不是简单多写一句 Prompt 就能彻底解决的。

因为 AI 的倾向是：

遇到空白，就用常见业务经验补全。

而测试工程师的职责恰恰相反：

遇到空白，要暴露出来，标记为待确认，而不是替产品补全。

这就是为什么我们需要质量规则库。

---

二、什么是 AI 测试质量规则库？

质量规则库不是测试用例库。

测试用例库告诉你：

某个功能具体怎么测。

质量规则库告诉 AI：

什么内容能写成正式用例，什么内容必须待确认，什么预期不可验证，什么推断不能写入测试结论。

更简单地说：

质量规则库是一组让 AI 输出更稳定的“测试判断标准”。

它可以包括：

qa-rules/
├── requirement-review-rules.md
├── testcase-quality-rules.md
├── boundary-value-rules.md
├── state-machine-rules.md
├── permission-test-rules.md
├── multi-platform-rules.md
├── export-test-rules.md
└── ai-output-review-rules.md

这些规则不是为了写得好看，而是为了让 AI 在生成内容时知道：

• 哪些不能编；
• 哪些不能猜；
• 哪些要标待确认；
• 哪些预期必须可验证；
• 哪些用例不能入库；
• 哪些内容要自检。

---

三、从一次 OpenClaw 实操里提炼出的 8 条规则

最近我用 OpenClaw 跑了一次完整的测试分析流程：

输入 PRD
→ 生成需求评审问题
→ 收敛评审问题
→ 生成测试点
→ 人工纠偏
→ 测试点收敛
→ 可入库用例筛选
→ 正式用例生成
→ 用例自检
→ 输出最终修正版用例

这个过程中，AI 暴露了不少典型问题。

这些问题非常适合沉淀成规则库。

---

规则 R1：PRD 未明确的规则必须标记为待确认

这是最重要的一条。

只要 PRD 没有明确说明，就不能写成确定性预期。

错误示例：

财务复审通过后，流程结束。

问题是，PRD 只写了“需财务复审”，没有说明：

• 财务复审是否终审；
• 复审通过后状态是什么；
• 是否还有后续付款流程；
• 页面展示什么终态。

正确写法：

财务复审通过后的终态待产品确认，暂不生成正式用例。

或者：

金额 >20000 元时，仅验证审批链中包含财务复审节点，不验证财务复审后的终态。

这条规则可以写成：

## R1：PRD 未明确的规则必须标记为待确认

如果某个预期无法从 PRD 原文或用户确认结果中推导出来，必须标记为“待确认”，不得写入正式测试用例。

禁止写法：
- 流程结束
- 终审通过
- 状态变为已完成
- 字段取值正确
- 与 PC 端一致

正确写法：
- 该终态 PRD 未定义，需产品确认后补充用例。

---

规则 R2：“需某节点审批”不等于完整审批链

这是审批类需求里非常常见的问题。

PRD 写：

金额 >20000 元时，需财务复审。

AI 很容易补成：

直属上级 → 部门负责人 → 财务复审

或者：

部门负责人 → 财务复审

但这些都是推断。

除非 PRD 明确写了完整链路，否则只能验证 PRD 明确的部分。

错误示例：

金额 25000 元时，审批链包含部门负责人和财务复审。

正确示例：

金额 25000 元时，审批链中包含财务复审节点；完整审批链组成待确认。

规则可以这样写：

## R2：“需某节点审批”不等于完整审批链

如果 PRD 只写“需 A 节点审批”，不得自动推断还包含 B、C 节点。

错误：
- 金额 >20000 时，审批链为部门负责人 + 财务复审。

正确：
- 金额 >20000 时，验证审批链中包含财务复审节点。
- 是否还包含其他审批节点，进入待确认清单。

---

规则 R3：“导出受影响”不等于新增字段

导出类需求里，AI 也很容易过度推断。

PRD 写：

本次改动影响报销数据导出。

AI 可能直接写：

导出文件包含审批状态、审批人、审批时间、当前审批节点字段。

但这几个字段 PRD 并没有明确。

错误示例：

导出文件中包含审批状态字段，且状态值为审批中。

正确示例：

导出文件可正常生成、可打开，导出记录数量与筛选范围内页面记录数量一致。
导出字段清单及字段取值规则待确认后补充字段级用例。

规则可以这样写：

## R3：“导出受影响”不等于新增字段

如果 PRD 只说明导出受影响，但没有给字段清单，不得生成字段明细校验。

可生成：
- 导出功能可用性；
- 文件可下载、可打开；
- 文件非空、未损坏；
- 导出记录数量与筛选结果一致。

不可生成：
- 审批状态字段校验；
- 审批人字段校验；
- 审批时间字段校验；
- 当前审批节点字段校验。

---

规则 R4：“影响 PC/H5”不等于两端完全一致

PRD 写：

本次改动影响 PC 端和 H5 端。

这只能说明两个端都在影响范围内，不代表两端功能完全一致。

AI 可能写：

H5 端状态展示与 PC 端一致。

这个预期就有问题。

因为 PRD 没说“两端一致”，也没有说明端差异策略。

正确写法应该是：

H5 端状态正确展示为审批中、草稿、已驳回。

不要写：

与 PC 端一致。

规则可以这样写：

## R4：“影响 PC/H5”不等于两端完全一致

如果 PRD 只写影响多个端，不得默认多端功能和展示完全一致。

错误：
- H5 端状态展示与 PC 端一致。

正确：
- H5 端状态正确展示为审批中、草稿、已驳回。
- PC/H5 是否存在端差异，进入待确认清单。

---

规则 R5：终态未定义时，不得写“流程结束”

这是状态流转用例里最容易出现的问题。

PRD 通常会写：

提交后状态变为审批中。
撤回后状态回到草稿。
驳回后状态变为已驳回。

但可能没有写：

审批通过后状态是什么。

此时 AI 很容易写：

审批通过后流程结束。
审批通过后状态变为已完成。
审批通过后状态变为已通过。

这些都不应该进入正式用例。

规则可以这样写：

## R5：终态未定义时，不得写“流程结束”

如果 PRD 没有定义审批通过后的状态，不得生成审批通过后的确定性用例。

禁止：
- 流程结束；
- 终审通过；
- 状态变为已完成；
- 状态变为已通过；
- 无更多待审批节点。

正确：
- 审批通过后的终态待确认。
- 该场景暂不生成正式用例。

---

规则 R6：预期结果必须可验证

AI 很喜欢写一些“看起来没错，但无法执行判断”的预期。

比如：

页面正常展示。
审批流程正确。
数据正确。
操作成功。
系统表现正常。

这类预期对测试执行没有太大价值。

因为测试人员无法判断什么叫“正常”。

更好的写法是：

不推荐	推荐
页面正常展示	报销单状态展示为“审批中”
审批流程正确	直属上级待办中出现该报销单
导出正常	导出文件可下载、可打开，记录数一致
权限正确	普通员工无法看到非本人报销单
提交成功	系统生成报销单号，状态变为审批中

规则可以这样写：

## R6：预期结果必须可验证

预期结果必须能通过页面状态、数据记录、文件内容、日志或接口返回进行验证。

禁止只写：
- 正常；
- 正确；
- 成功；
- 合理；
- 符合预期。

应写成：
- 状态展示为“审批中”；
- 审批人待办中出现该单据；
- 导出文件可打开且记录数一致；
- 操作后生成报销单号。

---

规则 R7：多端用例不要机械复制

很多 AI 生成用例时，会把 PC 用例复制一遍，再把“PC”替换成“H5”。

这样看似覆盖全面，实际会造成用例膨胀。

更好的方式是：

场景	处理方式
PC 和 H5 无明确差异	PC 端详细验证，H5 端做核心状态流验证
PRD 明确两端有差异	分别生成端独立用例
端一致性未确认	不写“与 PC 一致”，只验证本端状态正确
全量用例过多	收敛为基础流程 + 关键状态验证

在这次实操里，最终保留的策略是：

• PC 端保留 3 条：提交、撤回、驳回重提；
• H5 端收敛成 1 条核心状态流验证。

这比简单复制一整套用例更合理。

规则可以这样写：

## R7：多端用例不要机械复制

如果 PRD 只说明多个端受影响，但没有明确端差异，不应复制全部用例。

默认策略：
- PC 端做较完整流程验证；
- H5 端做核心状态流验证；
- 不写“与 PC 端一致”；
- 如存在端差异，待确认后补充端独立用例。

---

规则 R8：用例生成后必须自检

这是整个流程里最容易被忽略，但最有价值的一步。

我们这次用 OpenClaw 生成正式用例后，让它做了一次自检。

自检发现了 3 个问题：

问题	说明	修正
H5 用例写“与 PC 端一致”	端一致性未确认	改成本端状态正确展示
PC 用例写“页面跳转”	UI 交互未定义	改成状态展示为审批中
驳回用例写“查看驳回信息展示”	驳回字段未定义	改成状态展示为已驳回

如果没有自检，这些内容很可能会进入正式用例。

所以规则库里必须有一条：

## R8：正式用例生成后必须自检

自检项包括：
1. 是否把待确认项写成确定用例；
2. 是否存在 PRD 未明确预期；
3. 是否出现“流程结束”“终审”“字段取值”等未确认结论；
4. PC/H5 是否机械重复；
5. 预期结果是否可验证；
6. 是否遗漏待确认问题清单；
7. 是否存在需求外编造；
8. 是否存在可合并重复用例；
9. 是否将待确认功能生成正式用例；
10. 导出相关用例是否写入未确认字段明细。

这不是普通 Review，而是把规则库变成可执行检查项。

---

四、质量规则库如何接入 OpenClaw？

在 OpenClaw 里，我建议这样组织：

openclaw-sqa-lab/
├── AGENTS.md
├── prompts/
│   ├── 01-requirement-review.md
│   ├── 02-test-point-design.md
│   ├── 03-test-point-scope.md
│   ├── 04-case-eligibility.md
│   ├── 05-formal-case-generation.md
│   └── 06-case-self-check.md
├── rules/
│   ├── testcase-quality-rules.md
│   ├── boundary-value-rules.md
│   ├── state-machine-rules.md
│   ├── multi-platform-rules.md
│   ├── export-test-rules.md
│   └── ai-output-review-rules.md
└── skills/
    ├── sqa-prd-review/
    ├── sqa-test-design/
    └── sqa-test-case-gen/

其中：

文件/目录	作用
AGENTS.md	告诉 OpenClaw 工作原则和规则入口
prompts/	存放固定流程 Prompt
rules/	存放质量判断规则
skills/	把成熟流程 Skill 化

AGENTS.md 不需要写得很长，它更像地图：

# OpenClaw 测试助理工作说明

你是测试助理，协助需求评审、测试点设计、用例生成和用例自检。

工作时必须遵守：
- 不编造 PRD 没有的规则；
- 不明确内容标记为待确认；
- 正式用例必须基于已确认规则；
- 用例生成后必须自检；
- 质量规则参考 rules/ 目录。

真正的细节放到 rules/ 里。

---

五、规则库应该怎么写？

规则库不要写成大段理论，最好按下面这种格式写：

# 规则编号：R1
# 规则名称：待确认项不得入库

## 适用场景

PRD 中出现：
- 待确认
- 需产品确认
- 方案未定
- 后续补充
- 暂不明确

## 错误写法

批量导入报销单成功。

## 正确写法

批量导入是否纳入本期，待产品确认后补充用例。

## 自检问题

1. 是否把“待确认”内容写成了正式用例？
2. 是否给待确认内容写了确定性预期？
3. 是否将该问题列入待确认清单？

这个格式有 4 个好处：

1. AI 容易读取；
2. 人也容易维护；
3. 可以直接转成自检 Prompt；
4. 后续可以沉淀进 Skill。

---

六、规则库如何持续迭代？

规则库不是一次写完的。

它应该来自真实错误。

每次 AI 输出有问题，不要只是手工改掉，而要追问一句：

这个错误应该沉淀成哪条规则？

例如：

AI 错误	应新增或更新的规则
写了“页面跳转”	不推断 UI 交互方式
写了“审批状态字段”	字段未确认不得做字段级校验
写了“H5 与 PC 一致”	端一致性未确认不得写一致
写了“流程结束”	终态未确认不得写流程结束
写了 5000.01	金额精度未确认不得默认小数位
写了批量导入正式用例	待确认功能不得入库

这样规则库就会越来越贴合真实项目。

AI 的输出也会从“每次靠提醒”，变成“每次按规则”。

---

七、Prompt、规则库、Skill 三者的关系

很多人会把这三个东西混在一起。

其实它们不是一回事。

类型	解决的问题
Prompt	这次任务怎么做
规则库	什么输出算合格
Skill	把稳定流程封装成可复用能力

举个例子。

Prompt 可能是：

请基于 PRD 生成正式测试用例。

规则库会告诉 AI：

不能把待确认项写成正式用例。
不能写 PRD 未定义终态。
不能推断导出字段。
预期必须可验证。

Skill 则把流程固定下来：

输入 PRD
→ 生成评审问题
→ 测试点设计
→ 可入库筛选
→ 正式用例生成
→ 用例自检
→ 修正版输出

三者配合起来，AI 测试输出才会稳定。

只靠 Prompt，相当于每次重新交代任务。

加上规则库，才是给 AI 一套长期可复用的判断标准。

---

八、从“Prompt 工程”到“质量工程”

如果只是不断优化 Prompt，测试工程师很容易陷入一种低效循环：

AI 生成不好
→ 改 Prompt
→ 这次好了
→ 下次换需求又出问题
→ 再改 Prompt

更好的方式是：

AI 生成不好
→ 找出错误类型
→ 沉淀成规则
→ 加入自检
→ 更新 Skill
→ 下次减少同类问题

这就是从 Prompt 工程走向质量工程。

测试工程师真正的价值，也不只是写一句更厉害的 Prompt，而是把团队的测试经验沉淀成：

• 规则；
• 模板；
• 检查项；
• 风险清单；
• Skill；
• 反馈回路。

这才是长期有价值的东西。

---

九、一个最小可用的规则库模板

如果你想马上开始，可以先不用做复杂系统。

先建一个最小版本：

rules/
├── testcase-quality-rules.md
├── boundary-value-rules.md
├── export-test-rules.md
└── ai-output-review-rules.md

testcase-quality-rules.md

# 测试用例质量规则

1. 每条正式用例必须有 PRD 原文或确认结果作为依据。
2. 待确认内容不得生成正式用例。
3. 操作步骤必须可执行。
4. 预期结果必须可验证。
5. 不允许只写“正常”“正确”“成功”。
6. 不允许写 PRD 未定义的终态。
7. 不允许写 PRD 未定义的字段取值。

boundary-value-rules.md

# 边界值规则

1. 金额、时间、数量、次数等阈值必须覆盖边界前、边界点、边界后。
2. 如果 PRD 使用 ≤、<、> 明确边界，必须正确识别边界归属。
3. 如果金额精度未说明，不得默认支持小数。
4. 小数边界必须标记为待确认，除非 PRD 明确支持小数。

export-test-rules.md

# 导出测试规则

1. 如果 PRD 只写“导出受影响”，只能生成基础导出回归用例。
2. 基础导出回归包括：文件可生成、可下载、可打开、记录数量一致。
3. 字段清单未确认时，不得生成字段明细校验。
4. 导出权限未确认时，不得写权限类确定性预期。

ai-output-review-rules.md

# AI 输出自检规则

检查：
1. 是否把待确认项写成确定用例；
2. 是否存在需求外编造；
3. 是否存在不可验证预期；
4. 是否出现流程结束、终审、字段取值等未确认结论；
5. 是否多端机械重复；
6. 是否遗漏待确认清单；
7. 是否把扩展风险写成正式用例。

这就是一个最小可用质量规则库。

先跑起来，再逐步补。

---

十、小结

AI 测试输出不稳定，很多时候不是因为 Prompt 不够长，而是因为缺少规则库。

Prompt 解决的是：

怎么让 AI 做这次任务。

规则库解决的是：

AI 每次输出时，如何判断什么能写，什么不能写，什么要待确认。

经过这次 OpenClaw 实操，我更确定一件事：

AI 测试真正要沉淀的，不只是 Prompt，而是质量规则。

这些规则来自真实项目里的错误：

• 待确认项被写成正式用例；
• PRD 空白被 AI 用常识补全；
• 导出字段被 AI 自行假设；
• 多端一致性被默认成立；
• 终态未定义却写了流程结束；
• 预期结果不可验证；
• 用例生成后没有自检。

把这些错误沉淀下来，变成规则，再接入 OpenClaw、Claude Code、Codex 或其他工具，AI 输出才会越来越稳定。

所以，与其不断堆 Prompt，不如先问自己：

我的质量规则库在哪里？

如果没有，就从最小版本开始。

先写 10 条规则。
先接入一次自检。
先让 AI 不再把待确认项写成正式用例。

这一步做对了，AI 测试才算真正从“能生成”走向“可复用、可入库、可持续改进”。