原创内容，未获授权禁止转载、转发、抄袭。

很多人用 Codex 做测试，第一步是写提示词。

比如：

帮我生成测试用例。
帮我写 Playwright 脚本。
帮我分析自动化失败原因。

能用，但不稳定。

同一个任务，每次都要重新交代背景、规则、输出格式。

提示词解决一次任务。

Skill 沉淀长期规范。

提示词是临时交代，Skill 是团队规则。

假设团队经常测订单、优惠券、支付。

如果没有规范，Codex 很可能只写：

点击领取优惠券，验证领取成功。

这条用例没错，但太浅。

真正要测的是：

• 同一用户能不能重复领取
• 库存是否扣减
• 券包有没有新增记录
• 并发点击会不会重复发券
• 退款后优惠券状态是否正确回滚

这些规则，才适合写进 Skill。

不是让 Codex 写得更多，而是让它少漏关键风险。

先拆高频任务

不要一上来写万能 Skill。

万能 Skill 最后通常会变成空话。

建议先从高频任务拆：

• 需求测试点分析
• AI 用例评审
• 接口测试设计
• Playwright 脚本生成
• 自动化失败分析
• 上线前风险检查

一个 Skill 只解决一类问题。

比如：

skills/
  qa-testcase-design/
    SKILL.md
  qa-api-test/
    SKILL.md
  qa-playwright/
    SKILL.md
  qa-release-risk/
    SKILL.md

qa-testcase-design 负责用例设计。

qa-api-test 负责接口测试。

qa-playwright 负责 UI 自动化。

qa-release-risk 负责上线风险检查。

拆开写，比塞进一个 Skill 里更稳。

Skill 里写什么

我一般只写这几类：

• 使用场景：什么时候用
• 执行流程：先做什么，再做什么
• 检查清单：哪些风险不能漏
• 输出格式：结果要长什么样
• 禁止事项：哪些内容不要生成
• 示例：什么叫符合团队标准

重点不是写得多。

而是写得具体。

Skill 里不要写愿景，要写规则。

一个最小可用的 Skill，可以这样写：

---
name: qa-testcase-design
description: 根据需求生成测试点，或评审 AI 生成的测试用例时使用
---

# 测试用例设计规范

生成用例前，先提取业务规则和风险点，不要直接堆表格。

每条测试点必须包含：

- 场景
- 前置条件
- 操作
- 预期结果
- 验证方式

核心业务必须说明验证方式。

验证方式可以是页面、接口、数据库、日志、消息。

禁止只写“验证成功”。

涉及订单、优惠券、支付、退款时，必须检查状态流转和数据一致性。

这段不长，但已经能约束 Codex 的输出。

用例要写验证方式

AI 生成用例时，最容易写虚。

比如：

验证下单成功。
验证退款成功。
验证保存成功。

这类预期结果不能直接执行。

取消订单，不能只看页面提示。

还要看：

• order_status 是否变成 CANCELED
• 库存是否释放
• 优惠券是否返还
• 是否没有重复退款
• 操作日志是否记录

比如优惠券领取，有 Skill 后，输出应该更接近这样：

场景	前置条件	操作	预期结果	验证方式
正常领取	用户未领取，库存充足	点击领取	领取成功	页面提示、接口返回、券包新增、库存扣减
重复领取	用户已领取	再次点击领取	提示已领取	接口返回错误码、券包不新增
库存不足	库存为 0	点击领取	领取失败	库存不变、券包不新增
并发领取	同一用户多端同时点击	同时请求领取接口	只成功一次	数据库只有一条领取记录

这才是能评审、能执行的测试点。

自动化 Skill 要限制坏习惯

Codex 可以生成 Playwright 脚本初稿。

但如果没有规范，很容易生成一次性脚本。

自动化 Skill 里建议写清楚：

• 账号、密码、环境地址从环境变量读取
• 定位优先用 role、label、testid
• 测试数据要可准备、可清理
• 核心流程不能只断言页面文案
• 页面元素不明确时写 TODO，不要编选择器
• 脚本失败要保留截图、trace、日志

比如优惠券领取脚本，不要只写：

点击领取按钮，断言页面出现“领取成功”。

更稳的是：

prepareCouponActivity()
prepareUser()
prepareCouponStock()

openActivityPage()
clickReceiveButton()

assertPageToast()
assertReceiveApiResult()
assertUserCouponCreated()
assertCouponStockDecreased()

cleanTestData()

页面断言只是第一层。

业务断言才是关键。

自动化脚本不是把页面点一遍，而是把业务结果验证清楚。

失败分析也能沉淀

自动化失败后，可以让 Codex 帮忙归因。

但要规定分析顺序：

• 先看环境
• 再看数据
• 再看页面元素
• 再看接口返回
• 再看脚本等待和定位
• 最后判断是不是产品缺陷

输出也要固定：

• 失败现象
• 初步原因
• 证据
• 处理建议
• 是否需要开发介入

比如失败日志里有：

优惠券领取后，页面提示成功，但券包接口查询为空。

没有 Skill，Codex 可能只会建议“检查接口”。

有了失败分析 Skill，它应该继续判断：

• 领取接口是否返回成功
• 券包接口是否延迟
• 数据库是否写入领取记录
• 是否存在异步消息未消费

最后给出结论：

页面成功不代表业务成功，优先排查领取后写券包链路。

这类分析才有用。

从复盘里更新 Skill

好的 Skill 不是一次写完的。

它应该从项目复盘里持续更新。

线上出了优惠券退款未返还。

就把规则补进去：

涉及订单、优惠券、支付、退款时，必须检查状态流转和数据一致性。

自动化经常因为数据问题失败。

就补规则：

生成脚本时必须说明测试数据准备和清理方式。

Skill 最有价值的地方，是把踩过的坑变成下次不会漏的规则。

每次复盘，都应该让 Skill 变得更具体一点。

不要写空话

Skill 里不要写：

要保证测试质量。
要关注用户体验。
要提高测试效率。

这些话没有约束力。

更有用的是：

金额字段必须覆盖 0、负数、小数、超限。
订单状态必须覆盖待支付、已支付、已取消、已退款。
权限测试必须同时验证前端入口和后端接口。
自动化脚本不能只断言按钮存在，必须断言业务结果。

规则越具体，Codex 越容易执行。

总结

Codex Skill 的价值，不是让 Codex 变聪明。

而是让 Codex 更懂你的团队习惯。

• 用例怎么设计
• 接口怎么断言
• 脚本怎么写
• 失败怎么分析
• 上线前怎么看风险

这些才是测试团队真正值得沉淀的东西。

把这些写进 Skill，Codex 生成的内容才不会只是“像测试”，而是更接近团队真正能用的测试资产。