原本只想让 AI 帮忙写几条测试用例，结果折腾了两个月，搭了一套让 AI 按我的标准干活的体系。
我 2024 年入行做测试，公司就我一个测试。没人带，没规范，写用例全靠自己摸索。
今年 3 月，我开始用 AI 帮忙写测试用例。最开始的想法很简单——把需求扔进去，让它出用例，我省时间。
然后就被教做人了。
第一回合：丢个原型进去，回来一堆小说
第一次尝试是这样的：我拿到一个视图功能的原型图，直接贴给 AI——「帮我生成测试用例」。
它很积极。几秒钟就吐了三十多条。
往下翻了几条我就傻了。它把一款小程序报名应用理解成了 AI 绘画软件，写的用例全是「验证 AI 生成画作的风格选择功能」「验证画作导出分辨率」。根本不是一个世界的东西。
你把原型丢给 AI，它不会跟你说「我不确定这是什么业务」。它会用想象力填满所有空白。 而且填得特别自信。
没办法，一条条纠正。我说这是报名应用，不是 AI 绘画。它说好的明白了，重新来——然后这次理解成了健身打卡软件。
反复拉锯了好几轮，终于把业务背景对齐了。但新问题又出来了。
第二回合：格式一塌糊涂
业务背景对上了，它开始正经出用例了。但格式让我头疼。
它有自己的一套结构思路。从「模块」到「功能点」到「场景描述」到「验证要点」到「前置条件」到「操作步骤」到「预期结果」等等。看着很工整，但中间的「验证要点」层级完全是冗余的——操作步骤和预期结果已经能说清楚的事，多一层纯废话。
还有更致命的——它特别喜欢在预期结果里写「功能正常」「显示正常」「交互正常」。「正常」是什么意思？谁来判断？测试人员执行时看到这四个字根本不知道该验证什么。
每次让它重新出用例，格式都有细微差异。这次用了 A 方案，下次自己换 B 方案。我光纠正格式就浪费了大量对话。
这时候我的用法还是最原始的——出错了我就纠正，再出错再纠正。 像一个家长跟在小孩后面收拾东西，没有规矩，全靠临时管教。
第三回合：开始记「血泪账本」
被反复折腾之后，我想了一个办法——每次纠正完 AI，就把这次踩的坑记下来。下次让它干活之前，先把记的坑贴给它看——「注意不要犯这些错误」。
这就是 测试用例生成过程经验总结教训文件.md 的雏形。
第一个被记进去的教训是四舍五入累计误差。报名折扣计算，73 折，两个人下单。AI 算出来的订单总额比实际多了 1 分钱。原因在哪？它在计算时先算每个人的原始折扣价（21.754 元），显示时四舍五入成 21.75，但累加时用的还是原始值 21.754，21.754+21.754=43.508，四舍五入变成 43.51，而我预期的是 21.75×2=43.50。
这条教训我记了四百多字：问题是什么、怎么发现的、根本原因在哪、防止再犯的检查点是什么。
后来陆续又记了八个。读错目录导致用了旧版格式、手机号校验规则不精确、埋点范围越界画蛇添足、需求变更后影响链分析不完整……每次都是一段真实的生产事故。
同时，我还让 AI 自己总结——「把这轮对话里你犯的错误、我纠正你的内容，总结成可复用的经验」。它总结完我再改，改完存进文件夹。
一个多月下来，文件夹里躺了 8 个文件。最长的一个 678 行，最短的 269 行，合起来两千多行。我还给它们写了一个索引文件，规定了读取优先级——生成用例前先读流程指导，再读设计经验，最后读技能文件。
这个阶段的本质是——用文件当外置记忆。 经验不在我脑子里，也不在 AI 的记忆里，在文件里。每次干活前手工加载。
还是出了问题
这个方法有效，但脆弱。
5 月的一天，AI 读了备份目录里的旧版经验文件——那个版本里格式标准是七级层级。我没注意到它读错了目录。它按照旧版标准输出了 20 多条七级结构的用例，我审阅时才发现不对劲。纠正花了整整一轮对话。
问题不在 AI。问题是「该读什么」这件事没有被约束——它想读哪个版本就读哪个版本，我没有给选择的规则。
两千多行经验文件，每次使用都靠我手动指定「先读 A 再读 B 别忘了 C」。说漏一个，它就在那个地方栽跟头。
而且这 8 个文件有一个根本性的结构问题——它们写的是「上次发生了什么」，不是「这次该怎么做」。是经验日记，不是工作流程。
转折：撞见一种不一样的写法
5 月下旬，我翻到了社区里一些工程的 Skill 写法。跟我那套完全不同的思路。
我举个具体例子。有一个叫「系统化调试」的 skill，它的开头不是「我学到了什么」，而是：
## 触发条件
遇到任何 bug、测试失败、异常行为时使用
## Iron Law
没有找到根因之前，禁止提出修复方案。
## 四个阶段
Phase 1：根因调查 → Phase 2：隔离 → Phase 3：修复 → Phase 4：验证
还有一个叫「写 skill」的 skill——用 TDD 的思维来约束 skill 的创建过程：
1. 先让 agent 在没有 skill 的情况下跑（RED）
2. 记录它在哪里犯错、说了什么理由
3. 针对性地写 skill 规则（GREEN）
4. 再跑一遍，看它是否遵守（验证）
5. 发现新漏洞 → 补规则 → 再验证（重构）
我被戳中了。
我的 9 个教训文件，每一个都是在 RED 阶段产生的——agent 真实犯过错的记录。但我把它们变成了事后总结，而工程化的写法是把它们变成事前约束。我换了种组织方式：
| 原始经验文件 | 工程化 skill |
|---|---|
| 触发方式：我手工指定读哪个 | 触发条件：满足条件自动匹配 |
| 结构：「今天我学到了什么」 | 结构：「遇到什么场景 → 按什么流程走」 |
| 质量：靠我事后审查 | 质量：完成前自检清单 |
| 内容：2000 多行散落笔记 | 内容：9 个模块化、可维护的单元 |
不是把 8 个文件拆成 9 个。是彻底改变组织逻辑——从「记录型」变成「执行型」。
从经验到体系的蜕变
重构之后，9 个 skill 串成了一条完整链路：
需求/原型 → 业务理解 → 原型分析 → 测试点设计
→ 【阶段一：人工确认测试点】
→ 测试用例生成 + 测试数据设计
→ 【阶段二：人工确认用例】
→ 最终输出 → 经验沉淀 → 更新 skill
两个人工确认点是吃过亏才加的。以前 AI 偏了我不一定第一时间发现，它出三四十条用例，有十条基于错误假设，一眼扫过去根本看不出来。加了确认点之后，在错误进入用例之前就被拦截了。
还有一个关键是经验沉淀闭环。每次任务结束，AI 输出经验总结和修改建议，我审过之后才允许更新 skill。这保证了两件事：skill 的每一次修改都是基于真实使用中暴露的问题，而且我始终对 skill 的内容有控制权。
最近跑下来的一次完整案例
前两天拿一个新需求跑： 小程序的 手机号 登录功能。
2 个页面，几个输入框、几个按钮。看起来简单，但按逻辑走完链路，输出落到了——49 条用例：
| 模块 | 条数 | 覆盖 |
|---|---|---|
| 欢迎页 | 12 条 | 页面加载、三个入口、协议拦截、防重复点击 |
| 手机验证码登录页 | 21 条 | 输入校验、倒计时全态、登录链路、异常处理 |
| 数据埋点 | 16 条 | 按页面独立统计，page_view / click / 业务事件 / localStorage |
中间审了一遍，纠正了三个业务理解——验证码有效期 5 分钟改为 10 分钟、未注册用户验证成功后直接创建账户不跳注册页、去掉了演示环境的临时逻辑。典型的「需求理解偏差」，但因为走了确认流程，修正成本只是一轮对话。
顺带又抓了几个系统性问题。
第一，页面加载验证。我当时觉得「页面正常打开」太基础了没必要单独写，想省掉。被老板一句话堵回来：页面都没加载出来，你后面测什么？现在每个页面第一条用例就是它。
第二，按钮覆盖。我之前习惯用流程链路代替单个按钮验证——「用户从 A 走到 B 自然会点到它」。但按钮的禁用态、倒计时态、连点防护，流程链路覆盖不到。现在每个按钮独立一条用例，不受流程依赖。
第三，埋点模块。我之前把埋点揉在各个功能用例里，想到哪写到哪。结果覆盖不全，维护起来也找不到。现在所有埋点单独拉出来，按页面统计。
这三条当场写进了 skill 的铁律里。以后再跑，不需要我提醒。
我的角色变了
刚开始的时候，我是 AI 的指挥者——「帮我写几条用例」。
后来变成了纠错者——「格式不对」「那个地方漏了」「重新理解一下」。
记经验那会儿，我是记录员——「上次在这踩了坑，这次注意」。
现在，我成了流程设计师。 不是跟 AI 说「你要注意什么」，而是给它一个内置了所有规则的工作框架。新人进来，不需要知道我踩过哪些坑，按流程走就行。
从用 AI 写用例，到教 AI 怎么设计用例。这条路走了两个月。
还没走完。下一步打算用 PE（Prompt Engineering）方法论把 skill 重写一轮——不是「按什么做」，而是「为什么这样做、在什么条件下可以调整」。那是下一篇文章的事了。
2026 年 5 月
