需求分析-生成用例skill

写在前面

打开任何一个技术社区，搜「AI 测试」，你会看到成堆的「50 个测试神级 Prompt」「一句话让 AI 帮你写用例」。我自己也收藏过一大把。

但用了一段时间我发现一个问题：这些 Prompt 全是「用完即弃」的。这次的对话调得再好，下次换个需求还得从头贴一遍；同事想复用，我只能把聊天记录甩给他；哪天我把 Prompt 改好了，也没有任何机制让全组同步用上新版本。

说白了，写 Prompt 是一种对话技巧，不是工程资产。

这篇文章想讲的，是我怎么把一整条测试流程——从需求分析到写用例，再到用例评审——固化成 3 个可以串起来跑的 Claude Code Skill，让 AI 从「聊一聊」变成一条能复用、能协作、能自查的流水线。

一、先分清：Skill 和 Prompt 不是一回事

很多人把 Skill 理解成「存起来的 Prompt」，这是最大的误解。核心区别有四条：

最后一条是关键：Skill 可以被别的 Skill 编排。这意味着你不再是「和 AI 聊三次」，而是搭出一条流水线——上一个 Skill 的产出，是下一个 Skill 的输入。

这就是这篇文章的主角。

二、这条流水线长什么样

我把测试的前半段拆成了三个 Skill，各管一段、首尾相接：

三层的定位，一句话各自概括：

• 分析层 requirement-analysis：只回答「这个需求要测哪些点、风险在哪、哪里没说清」，不写用例。
• 生成层 test-case-generator：把测试点/需求，变成固定 13 列的标准用例。
• 质检层 testcase-review：检查这批用例「全不全、能不能执行、能不能追溯」，把缺口写成清单回流给生成层补。

注意那条从质检层拐回生成层的箭头——这是一个闭环，不是一条直线。后面会讲它是怎么咬合的。

三、逐层看：每一层的输入输出契约

Skill 之所以能串起来，靠的不是「都是 AI」，而是每一层的契约都定死了。逐层拆开看。

3.1 分析层：只做分析，坚决不写用例

输入：需求。可以是文字、PRD 文档（PDF/Word/Markdown），也可以是原型图、UI 截图——用视觉能力识别页面元素、交互、校验规则。

输出：一份结构化分析文档，固定四块：

1. 测试点清单——按维度拆解，这需求到底要测哪些点；
2. 风险清单——哪里容易出问题、哪里代价高；
3. 需求疑问清单——PRD 没说清、需要找产品确认的点；
4. 覆盖率自检——显式写出「哪些维度没覆盖、做了哪些假设」。

这一层有两条我很看重的纪律：

第一，它绝不直接输出可执行用例。 这是刻意的。分析结果本身就有价值——用来对齐测试范围、做需求评审——不该被埋在「顺手把用例也写了」里面。更重要的是，把「分析」单独拎出来，你才有机会在生成用例之前，让人先 review 一遍测试点：AI 负责按维度穷举（体力活），人保留业务判断和风险拍板（脑力活）。

第二，不臆造需求。 PRD 没写的，一律进「疑问清单」，绝不自己编一个验收标准当成既定事实。这是 AI 产出最容易翻车的地方——它太想给你一个「完整」的答案，结果把没说的当成说了的。

提取测试点时，是对照一份维度清单逐项过一遍的，不是凭直觉只写想得到的那几个。每个维度都要「过一遍并判断是否适用」。如果你的业务涉及海外、国际化、或者未成年人合规，这几类维度尤其是重灾区——功能点看着都测了，一到弱网、断网、文案截断、监护人同意流程就集体失忆。

3.2 生成层：固定 13 列，格式即契约

输入：分析层的测试点清单，或者直接给需求。

输出：严格 13 列的标准用例表，一列不能少、顺序不能乱：

| 执行用例ID | 用例编号 | 用例类型 | 用例等级 | 标题 | 维护人 | 所属分组 | 一级模块 | 二级模块 | 功能点 | 前置条件 | 步骤描述 | 预期结果 |

这里有几个约定值得说：

• 用例编号有生成规则：前缀取「需求核心短名的拼音首字母大写」，序号三位连续递增。比如需求「用户注册」→ 前缀 ZC → ZC-001、ZC-002…同一批用例共用前缀、连续不重复。这样不同需求的编号天然带区分，往用例平台批量导入时不会撞号。
• 「用例类型」列填的是平台枚举（功能测试/性能测试/接口测试/安全相关…），而边界、异常是「设计方法」不是「类型」——绝大多数用例（含正向、边界、异常场景）类型都填「功能测试」，负向覆盖度由质检层按内容去统计，不靠这一列。这个坑我踩过：早期把「边界测试」直接填进类型列，导入平台后被静默归成「无」，类型信息全丢了。
• 步骤和预期必须具体：不许出现「正确输入」这种词，要写成「输入 6–20 位字母数字」。预期结果必须可断言，不能是「显示正常」。

为什么要把格式钉死到这个程度？因为格式就是给下游质检层的契约。列不固定，下一层的脚本就没法稳定定位这张表、没法逐列校验。生成层的「固定 13 列」，是整条流水线能不能自动质检的地基。

（生成层还能顺带把用例批量写进用例管理平台，这块是工程细节，跟本文的主线关系不大，略过。）

3.3 质检层：整条链的灵魂所在

这一层是我个人最得意的，因为它把「AI 该干什么、代码该干什么」这条边界，划得最干净。

输入：生成好的 13 列用例（必需）+ 分析层的测试点清单（可选，有则能做覆盖率红线）。

输出：一份评审报告 + 一份能直接回流给生成层的补充用例清单。

它从三个角度查漏：

1. 对着测试点查（可追溯）：每个测试点都有用例覆盖吗？反过来，有没有不对应任何测试点的「孤儿用例」？覆盖率红线 100%。
2. 对着维度查（横向）：对照维度清单逐项判断，适用却没覆盖的就是漏点。
3. 对着可执行性查：结构合规、每条预期可验证、无重复。

但真正的重点，是它内部的分工方式——这引出下面单独的一节。

四、为什么一定要拆三层，而不是写一个「万能 Prompt」

这是我最想讲清楚的一点。很多人会问：你直接写一个超长 Prompt，让 AI「分析需求 + 生成用例 + 自己检查一遍」，不就完了？

我试过，会死在四个地方：

1. 分析结果没法单独复用。 塞在一次输出里，「分析」就成了生成用例的副产品。可实际上，我常常只想要那份测试点清单和疑问清单——拿去做需求评审、跟产品对齐范围。拆开，分析才成为一等公民。

2. 没地方插「人工检查点」。 好的测试流程里，「测试点」是要经人过一遍的：AI 穷举，人拍板哪些真要测、哪些是业务上不可能的。一个大 Prompt 从需求直接吐用例，你连插一脚的机会都没有。分析层「不直接出用例」，就是专门为了留出这个断点。

3. 没法插「确定性质检」。 用例质量里有一大堆客观指标——ID 连不连续、覆盖率多少、逆向用例占比够不够——这些靠 LLM「自己检查一遍」极不可靠。它们必须交给代码算。而代码只能作用在稳定的结构化产物上（固定 13 列）。所以「生成」和「质检」必须是两层，中间隔着一个格式契约。

4. 单 Prompt 的头号翻车：虚假全覆盖。 让一个模型在一次输出里同时穷举、生成、自查，它的注意力被摊薄，最典型的结果是——它信誓旦旦告诉你「都测到了」，但拿不出任何可追溯的依据。把质检单独拆成一层，配上覆盖率红线，就是为了把「感觉全覆盖」变成「可复算的覆盖率」。 一个数字，一票否决。

五、让三层咬合的三个契约

拆成三层容易，让它们能真正串起来跑，靠的是三个刻意设计的契约：

契约一（分析 → 生成）：模块层级对齐。 分析层拆需求时，就按「一级模块 → 二级模块 → 功能点」的层级来，这套层级和生成层的字段是一一对应的。所以分析结果能原样喂进生成层，不用再转换。

契约二（生成 → 质检）：固定 13 列。 前面说过了，格式即契约。生成层输出雷打不动的 13 列，质检脚本才能稳定解析、逐列校验。

契约三（质检 → 生成）：补充清单即输入格式，形成闭环。 这条最妙。质检发现的缺口，不是写成「网络场景再多测测」这种废话，而是写成生成层认识的结构——[功能点] 维度：要覆盖的场景，预期方向。比如：

[登录-邮箱登录] 网络：弱网(2G)下登录，预期 X 秒内超时并可重试
[注册-监护人同意] 合规：未满 13 岁注册，预期进入家长同意流程

这样的清单可以直接回流给生成层补生成，补完再评，形成闭环。这就是那条拐回去的箭头——评审不是终点，是下一轮生成的输入。

六、贯穿始终的一条铁律：确定性归代码，语义归 LLM

如果这篇文章你只记一句话，我希望是这句。

在质检层内部，我把所有工作按一个标准劈成两半：

能用算法唯一确定答案的，交给脚本；需要理解语义、做判断的，才交给 LLM。

脚本（一个纯标准库的 Python 检查器）负责这些客观、可复算、零幻觉、不烧 token 的事：

• 结构合规：13 列齐不齐、ID 连不连续、用例类型和等级在不在合法枚举内；
• 逆向占比：统计边界 + 异常场景的占比，低于阈值（默认 40%）就判不达标——专治「一水儿的 happy path」；
• 无信息预期：用正则揪出「显示正常」「页面正确」这类根本没法断言的预期；
• 近重复检测：用 SequenceMatcher 算用例之间的相似度，超阈值就提示疑似重复、建议合并；
• 覆盖率算术：覆盖数 / 测试点总数，红线 100%，并列出未覆盖的测试点和孤儿用例。

LLM 负责这些只有理解语义才能做的事：

• 逐维判断每个维度「这需求适用吗 / 现有用例覆盖了吗 / 覆盖够全吗」；
• 判断某条预期结果，放在它的上下文里到底能不能断言；
• 以及最关键的一步——把每个测试点映射到具体的用例编号，产出一份 mapping。

这份 mapping 长这样，由 LLM 产出：

测试点ID,测试点,覆盖用例编号
TP-001,邮箱密码正常登录,TC-001
TP-002,密码错误拦截,TC-002 TC-005
TP-003,断网时登录提示,

（TP-003 的覆盖列留空 = 没被任何用例覆盖，会被红线拦下。）

而整个设计里最重要的一条红线是：脚本绝不自己去猜「某条用例覆盖了哪个测试点」。因为那只能靠字符串匹配去瞎蒙，蒙出来的是虚假覆盖率——比真话更危险。脚本只对 LLM 产出的 mapping 做算术。

你看这条边界划得多干净：

• 建立「测试点 ↔ 用例」的语义对应，是 LLM 的活（它擅长理解「这条用例是不是在测那个点」）；
• 在这个对应关系上算账——覆盖率、缺口、孤儿——是脚本的活（它擅长精确、不会累、不会编）。

谁都不越界。这才是「AI + 工程化」该有的样子：不是把所有事都丢给模型，也不是不用模型，而是把每件事交给最适合的执行者。

七、几条落地经验

真正把这套跑起来之后，攒下几条心得：

• 契约先行。先把每层的输入输出、层与层之间的衔接格式定死，再写 Skill 内容。契约是流水线的骨架，骨架歪了后面全歪。
• 确定性的事，一行代码都别交给模型。ID 连续、占比、覆盖率这些，模型算十次可能对九次，那第十次就是线上事故。写进脚本，一次对，永远对。
• 给 AI 留断点，别追求一步到位。分析层刻意不出用例、质检层刻意不改用例，都是为了在流程里留出人工可以介入的缝。全自动听着爽，实际用起来最怕的就是没法插手。
• 让缺口能回流。评审的价值不在「挑出问题」，而在「挑出的问题能被直接修」。把补充清单写成下游认识的格式，闭环才真正闭上。

结语

回到开头那个问题：为什么不满足于收藏一堆 Prompt？

因为 Prompt 是你和 AI 的一次性对话，而 Skill 链是一条沉淀下来的、能复用能协作的生产线。前者随聊天记录消失，后者进了知识库、能被团队每个人调用、能被下一个 Skill 编排。

这三个 Skill——分析、生成、质检——本质上是把「一个测试工程师脑子里的流程」外化成了可执行、可串联、可自查的工程资产。AI 在里面扮演的，不是「替我干活的黑盒」，而是「流水线上负责语义判断的那道工序」，旁边还站着一个负责算账的脚本，各司其职。

如果你也在做 AI + 测试，别停在写 Prompt 那一步。试着把你重复在做的那条流程，拆成几个有明确契约的 Skill，让它们串起来。 那一刻你会发现，你不是在用 AI，你是在用 AI 造工具。

本文基于笔者实际落地的一套 Claude Code Skill 链整理，示例中的需求、编号、字段均为演示用途。欢迎在评论区交流你的 Skill 编排思路。