## 一、开篇：测试用例 Skill 写不好，问题出在哪？
测试用例 Skill 写不好，AI 生成的用例不是幻觉编造就是输出格式三天两头变------问题不在 AI 不够聪明，而在于你的 Skill 没做"封装"。 本文提出「六维封装法」：边界锚点 / 角色方法论 / 正反样本库 / 粒度层级 / 输出契约 / AI 自检，六个维度系统化封装一个高质量 Skill。文末附可直接照搬的 Checklist 与 Skill 模板骨架。读完后你能得到：一个能稳定输出、可入库、可演进的高质量 Skill 工程方法论。
先看一道几乎每个测试团队都踩过的体验曲线：
- 第一天：惊艳------"这用例写得比我实习生还快！"
- 第三天：皱眉------"这个登录功能什么时候支持声纹识别了？需求文档里根本没有。"
- 第七天：放弃------"算了，改它生成的东西比我自己写还累。"
把 AI 当成一个能力极强、但对你的业务一无所知的新员工来看待。你会怎么带新人？你会给他：
- 明确的职责边界------哪些归你管，哪些别瞎碰；
- 方法论培训------用你们团队认可的用例设计方法；
- 好坏样例------照着这个写，别照着那个写；
- 交付标准------什么格式、什么颗粒度；
- 复核机制------交活之前先自查一遍。
这就是本文要讲的 六维封装法：把"带新人"的经验，工程化为 Skill 的六个封装维度。这套方法在我们的测试团队落地后，用例生成的一次可用率（生成后无需大改即可入库的比例）从不到 40% 提升到了 80% 以上。
先看全貌：
| 维度 | 解决什么问题 | 一句话心法 |
|---|---|---|
| 1. 边界锚点 | AI 幻觉、编造功能 | 没根据的兜底，不如不写 |
| 2. 角色和方法论 | 漏测、方法单一 | 给方法，不给自由发挥 |
| 3. 正反样本库 | 风格漂移、质量不稳 | 一条反面样本胜过十句嘱咐 |
| 4. 粒度和层级 | 用例过粗或过碎 | 一个测试点一条用例 |
| 5. 输出契约 | 格式不稳定、无法入库 | 格式即合同 |
| 6. AI 自检 | 质量不可持续 | 让 Skill 自己查自己 |
下面逐一拆解。
二、维度一：边界锚点------如何治好 AI 的"幻觉病"？
2.1 痛点
AI 最危险的不是不会写，而是写得太像真的。
让 AI 根据 PRD 生成登录模块的用例，它可能顺手给你补上"第三方账号登录""声纹登录""异地登录二次验证"------需求文档里一个字都没提。这些用例读起来逻辑通顺、步骤完整，如果不和原文比对，很容易被直接入库，变成一堆"测了个寂寞"的伪需求用例。
2.2 封装原则
核心原则：禁止编造。"没用"的兜底不如不写。
很多人写 Skill 时喜欢加一句"如果信息不足，请合理推演补充"------这是幻觉的助燃剂。正确做法是反向操作：给 AI 划定一个明确的知识边界，边界之外，宁可空着，不许编着。
2.3 落地示例
在 Skill 中明确写入这类锚点条款：
text
【边界约束】
1. 所有用例必须严格基于《XX系统 V2.3 需求规格说明书》原文生成，
不得引入文档之外的任何功能假设。
2. 每条用例必须能对应到至少一条原始需求条目，
并在"需求追溯"字段标注需求编号。
3. 禁止推演未提及的功能；如发现需求描述存在歧义或缺口，
不要自行补全，将问题列入"待确认清单"单独输出。
4. 无法从原文获得前置条件时，前置条件字段写"待补充（需求未明确）"，
严禁编造。注意第 3 条的精妙之处：它没有让 AI 闭嘴，而是给了它一个合法的出口------把疑问放进"待确认清单"。信息缺口被显式地暴露出来，而不是被幻觉悄悄填平。实践中，这份"待确认清单"本身往往就是一份高价值的测试左移产出，可以直接拿去和产品经理对齐。
三、维度二：角色和方法论------怎样避免 AI 漏测？
3.1 痛点
只给 AI 一个"资深测试工程师"的人设，它生成的用例往往有两个毛病：
- 方法单一：90% 的用例都是正向功能验证，异常分支、组合条件大面积缺失；
- 正向泛滥：正向用例占比过高，而真正容易漏掉 Bug 的恰恰是异常和边界场景。
这是漏测的直接来源。
3.2 封装原则
人设是虚的，方法论是实的。 与其告诉 AI"你是专家"，不如直接把专家的分析框架喂给它------让 AI 执行一套确定性的算法，而不是模仿一种模糊的气质。
3.3 落地示例
text
【角色与方法论】
角色：你是测试团队的用例设计专家，严格遵循本团队设计规范。
方法论（每个功能点必须综合使用以下方法，并标注所用方法）：
- 等价类划分：有效/无效等价类均需覆盖
- 边界值分析：取 min-1 / min / min+1 / max-1 / max / max+1
- 场景法：覆盖基本流 + 每一条备选流
- 判定表：存在多输入组合的功能必须构造判定表
- 正交法：参数组合爆炸时用正交表裁剪
结构化约束：
1. 正向用例占比 <= 35%，其余为异常、边界、组合场景。
2. 每个功能点必须至少覆盖一条正常流程（Happy Path）作为基线。
3. 若某方法不适用于当前功能，需说明原因，不得静默跳过。第 2 条值得强调："正向占比 ≤ 35%"和"必须覆盖正常流程"并不矛盾。前者防止正向用例挤占异常场景的坑位，后者保证基线场景不丢------有基线，异常才有参照系。
标注"所用方法"还有个额外收益：评审时可以一眼看出哪个功能点只用了一种方法，方法论覆盖的盲区直接可视化。
四、维度三：正反样本库------为什么一条反面样本胜过十句嘱咐？
4.1 痛点
你在 Skill 里写"用例要简洁、聚焦、可执行"，AI 依然会输出这样的东西：
步骤 1 ：打开浏览器，输入网址，进入登录页面，观察页面加载是否正常。
步骤 2 ：在输入框中仔细查看，然后输入正确的用户名和密码，注意不要输错。
步骤 3：点击登录按钮，耐心等待系统响应，查看是否跳转到首页。
步骤冗长、验证点含糊、一条步骤塞进三个动作。你反复修改提示词里的形容词，收效甚微。
4.2 封装原则
不要跟 AI 讲道理，给它看例子。
大模型的上下文学习（In-Context Learning）能力，远强于它对抽象形容词的理解力。"简洁"有一万种理解，但一条具体的反面样本只有一种含义。 AI 不要写流水账？你给它看一条"禁止写成这样"，它立刻就懂。
4.3 落地示例
在 Skill 中维护一个正负样本库：
text
【正向样本】（团队公认的标准写法）
用例编号：TC-LOGIN-001
用例标题：正确的账号密码登录成功
前置条件：账号 user01 已注册且状态正常
操作步骤：
1. 在登录页输入 user01 / 正确密码
2. 点击【登录】
预期结果：
1. 跳转至系统首页，右上角显示 user01 昵称
【负向样本】（绝对不能这么写）
用例标题：测试一下登录功能好不好用
操作步骤：
1. 打开浏览器输入网址进入登录页面观察页面是否正常
2. 在输入框中仔细查看然后输入正确的用户名和密码注意不要输错
3. 点击登录按钮耐心等待系统响应查看是否跳转到首页
错误点：标题无验证点 | 步骤动作堆叠 | 口语化描述 | 无独立预期结果注意负向样本的最后一行------把错误点显式标注出来。这相当于不仅给 AI 看了"错误的答案"，还讲了"为什么错"。模型对这种"错误归因"式标注的响应非常敏感，规避效果显著。
样本库的位置也有讲究：建议放在 Skill 靠后的位置（临近生成指令），因为上下文学习对"离指令最近的示例"记忆最牢。
五、维度四：粒度和层级------如何控制用例粒度，一个测试点一条用例？
5.1 痛点
粒度失控有两种极端：
- 过粗："验证登录模块全部功能"------一条用例塞了十几个验证点，执行失败后无法定位是哪一步的问题，也无法单独标记通过/失败；
- 过碎："点击输入框""输入字符 a""输入字符 b"------步骤被拆成了原子操作，用例数量爆炸，维护成本指数级上升。
5.2 封装原则
一条用例 = 一个独立的测试点。 用例是最小的可执行、可判定、可追溯单元。
判断标准很简单：这条用例的预期结果，能否用一个"是/否"来判定？如果一条用例有五个预期结果、五个验证维度，那它其实是五条用例穿着一件马甲。
5.3 落地示例
text
【粒度约束】
1. Web 功能测试中，一条用例只对应一个独立测试点，
预期结果聚焦单一验证目标。
2. 单条用例的操作步骤控制在 3-5 步；超过 5 步时，
必须评估是否应拆分为多条用例。
3. 层级要求：模块 → 功能点 → 用例，三层结构，
用例编号体现层级（如 TC-LOGIN-PWDERR-001）。
4. 登录功能按测试点拆分示例：
- TC-LOGIN-001 正确账号密码登录成功
- TC-LOGIN-002 密码错误登录失败并提示
- TC-LOGIN-003 账号锁定后登录被拒
- TC-LOGIN-004 密码连续错误 N 次触发锁定
（而不是一条"验证登录的各种情况"）"3-5 步"这个数字不是铁律，而是一个强制反思的触发器：当 AI 想写第 6 步时，它必须先停下来问自己"这是不是该拆了？"。粒度约束的本质不是限制步骤数，而是限制思维发散。
六、维度五：输出契约------如何把输出格式写成"合同"？
6.1 痛点
今天生成 Markdown，明天生成 Word；今天字段叫"预期结果"，明天变成"期望输出"；今天 6 列表格，明天混进两行散文。下游的用例管理系统、评审流程、自动化脚本对接全部遭殃------输出不稳定，Skill 就永远只是个玩具，进不了工程管线。
6.2 封装原则
交付格式是 Skill 与下游系统之间的合同，必须一次性谈死。 格式、字段、顺序、命名，全部写进 Skill，不留任何"由 AI 自行决定"的空间。
6.3 落地示例
text
【输出契约】
1. 输出格式：Markdown，用例以表格呈现。
2. 表头及顺序（固定，不得增删改列名）：
| 用例编号 | 用例标题 | 所属功能点 | 优先级 | 前置条件 |
| 操作步骤 | 预期结果 | 设计方法 | 需求追溯 |
3. 字段规则：
- 用例编号：TC-模块-序号，全大写
- 优先级：P0/P1/P2 三级
- 操作步骤：有序列表，每步一个动作
- 需求追溯：需求编号（REQ-xxx），无对应时填"待确认"
4. 表格之后单独输出两节：【待确认清单】【覆盖度统计】。
5. 除上述内容外，不得输出任何寒暄、解释性文字。第 5 条常被忽略却极其关键："不得输出寒暄"。AI 天然喜欢在正文前后加"好的，以下是根据您的需求生成的用例......"这类废话，对自动化解析是致命的。合同不仅约定"必须有什么"，还要约定"必须没有什么"。
七、维度六：AI 自检------为什么 Skill 必须能自己查自己？
7.1 痛点
即便前五个维度都做了，AI 偶尔还是会"失手"：某条用例忘了标需求追溯，正向占比悄悄涨到了 50%。而 Skill 一旦写完就束之高阁，错误模式就会持续复现------没有反馈闭环的质量，是无法演进的。
7.2 封装原则
让 AI 在交付前执行一次自检，把评审规则前置到生成环节。 更进一步：自检清单本身也由 AI 根据历次评审意见生成和迭代------这是 Skill 从"静态脚本"进化为"活文档"的关键机制。
7.3 落地示例
text
【AI 自检清单】（交付前逐项核对，输出核对结果）
□ 所有用例均可追溯到需求编号，无"编造功能"嫌疑
□ 正向用例占比 <= 35%
□ 每个功能点至少一条正常流程用例
□ 单条用例步骤 <= 5 步，单一验证点
□ 输出符合契约：字段、列序、编号规则完全一致
□ 边界值用例覆盖了 min-1/max+1 两侧
□ 歧义与缺口已列入【待确认清单】
【自检结果输出格式】
- 通过项：...（简列）
- 未通过项：...（说明原因及修正动作）
- 修正后重新交付完整结果。落地节奏上，建议这样运营这份清单：
- 冷启动：先由人工评审 AI 产出，把高频问题逐条沉淀进自检清单；
- 半自动化：清单稳定后，让 AI 每次生成都附上自检结果，人只看"未通过项"；
- 持续演进 ：每月把新的评审意见喂回 Skill，更新清单------Skill 是用出来的，不是写出来的。
一个能自我检查、持续吸收评审反馈的 Skill，才是团队真正的资产，而不是某个人电脑里的一份提示词。
八、收尾：六维封装法落地 Checklist
最后，把六个维度压缩成一张可以直接照着做的 Checklist。下次写（或重构）Skill 时，逐项打勾：
markdown
## Skill 六维封装 Checklist
### 维度 1：边界锚点
- [ ] 明确了知识来源（哪些文档/哪些范围）
- [ ] 写入"禁止编造"条款，禁止 AI 自行补全需求
- [ ] 为信息缺口提供合法出口（待确认清单）
- [ ] 要求用例可追溯到原始需求条目
### 维度 2：角色和方法论
- [ ] 人设之外，给出了具体的设计方法清单
- [ ] 量化了结构约束（如正向占比 <= 35%）
- [ ] 要求标注所用方法，保证方法论可审计
- [ ] 明确正常流程的基线要求
### 维度 3：正反样本库
- [ ] 提供 1-2 条团队公认的正向样本
- [ ] 提供典型负向样本，并标注错误点
- [ ] 样本库放置在临近生成指令的位置
- [ ] 样本与团队最新规范保持同步
### 维度 4：粒度和层级
- [ ] 定义了"一条用例一个测试点"的判定标准
- [ ] 设定步骤数上限（建议 3-5 步）作为拆分触发器
- [ ] 规定了编号规则与层级结构
- [ ] 给出了拆分正确与拆分过碎的对比例子
### 维度 5：输出契约
- [ ] 固定了输出格式与完整字段列表
- [ ] 列名、顺序、取值枚举全部显式约定
- [ ] 约定了"禁止输出"的内容（寒暄、解释）
- [ ] 输出可直接进入下游系统（评审/入库/解析）
### 维度 6：AI 自检
- [ ] 内置了自检清单，交付前强制执行
- [ ] 自检结果随正文一起输出
- [ ] 建立了评审意见回流机制（月度迭代）
- [ ] 指定了 Skill 的 Owner 和版本记录一个可以直接套用的 Skill 模板骨架
text
# [Skill 名称]：测试用例生成
## 1. 角色
你是 XX 团队的用例设计专家，严格遵循以下全部规范。
## 2. 边界锚点
（知识来源 / 禁止编造 / 追溯要求 / 待确认出口）
## 3. 方法论
（等价类 / 边界值 / 场景法 / 判定表 / 正交法 + 结构约束）
## 4. 粒度与层级
（一用例一测试点 / 3-5 步 / 编号规则）
## 5. 正反样本库
（正向样本 x1-2 / 负向样本 x1 + 错误点标注）
## 6. 输出契约
（格式 / 字段 / 列序 / 禁止项 / 附加输出节）
## 7. AI 自检清单
（逐项核对 / 未通过项修正后重交）八、附：本文要点速查（FAQ）
Q1：什么是 Skill 六维封装法？
A：把"带新人"的经验工程化为 Skill 设计的六个封装维度------边界锚点、角色方法论、正反样本库、粒度层级、输出契约、AI 自检。
Q2：六维中哪一维最关键？
A：边界锚点（治幻觉）和输出契约（定格式）。先做这两维，一周内就能看到明显改善。
Q3：正反样本库放在 Skill 的哪个位置？
A：放在 Skill 靠后位置（临近生成指令），上下文学习对"离指令最近的示例"记忆最牢。
Q4：粒度约束的"3-5 步"是铁律吗？
A：不是铁律，而是"强制反思的触发器"。超过 5 步时先问是否该拆，而非机械执行。
Q5：AI 自检清单怎么冷启动？
A：先由人工评审 AI 产出，把高频问题逐条沉淀进清单；清单稳定后让 AI 每次输出自检结果。
九、写在最后
六维封装法的本质，是完成一次视角转换：
写 Skill 不是在"许愿"，而是在"带人"。
- 边界锚点，是不让新人越权；
- 方法论，是给他标准作业流程；
- 正反样本，是给他看好活和烂活的实物对比；
- 粒度契约，是约定交付颗粒度；
- 输出契约，是签好接口协议；
- AI 自检，是建立转正前的复核机制。
AI 的能力上限由模型决定，但能力下限由你的 Skill 决定。模型每个月都在换代，而"如何把人的经验封装给机器"这套工程方法，会长期保值。
从今天起，别再让 AI "自由发挥"了------用六维封装法，把它变成一个真正靠谱的团队成员。