从 0 到 1 搭建测试 Skills 平台

两年前，我所在的团队经历了一次让人印象深刻的“事故”。

那是一个周五下午，一个看似平常的版本发布。测试通过，上线，没有报警。但到了周六凌晨，客服系统开始收到投诉——某类用户的订单状态显示异常。问题追溯下来，是一个在历史上出过两次相似 Bug 的边界场景，两次复盘都写进了经验文档，但没有任何机制确保它被测到。

负责这个模块的老同事已经离职三个月了。

那份“经验文档”，没有人在发布前想到去翻它。

这件事让我们开始认真思考一个问题：我们的测试能力，究竟是沉淀在系统里，还是沉淀在个人身上？答案让人不舒服——绝大多数，在人身上。

从那之后，我们花了将近一年的时间，从零开始搭建了一套企业级测试 Skills 平台。这篇文章，是这段实践的完整复盘。不是成功学，有很多弯路和教训。但如果你也在思考如何系统性地提升团队测试能力，希望这些经验对你有用。

一、为什么需要一个“平台”，而不是一堆 Prompts

很多团队在接触 AI 测试工具的早期，会经历一个类似的阶段：每个人各自摸索，积累了一批自己用的 Prompts，效果参差不齐，无法共享，无法复用，换个项目就得从头来。

这不是 Skills，这是“碎片化的个人工具箱”。

真正意义上的测试 Skills 平台，需要解决三个核心问题：

一致性：不同人在面对同类测试场景时，能够得到质量稳定的输出，而不是完全依赖个人能力的高低。

可传承性：团队积累的业务知识、历史 Bug 模式、领域规则，能够以结构化的方式沉淀下来，不随人员流动而流失。

可进化性：平台本身能够随着业务发展、新 Bug 出现、工程实践演进而持续迭代，而不是建完就静止。

这三个问题，靠一堆 Prompts 解决不了。需要的是一套有架构的系统。

二、平台架构：从一张白纸开始的设计

我们没有参考现成的方案，因为那时候几乎没有可参考的企业实践。整个架构是在反复讨论和踩坑中逐步成型的。

2.1 核心分层：三层结构

最终落地的架构分为三层，从下到上依次是：

知识层是地基。没有结构化的业务知识，Skills 就是无本之木。我们把它拆成三个子库：

• 业务规则库：把散落在各处的产品文档、设计评审记录、口口相传的“潜规则”，整理成结构化的规则条目。每条规则有触发条件、约束内容、示例。
• 历史缺陷库：把过去两年的线上 Bug 按模块、缺陷类型、触发场景重新分类整理，提炼出高频缺陷模式。
• 接口契约库：维护所有内部服务的接口定义，包含字段约束、状态码含义、业务语义，而不只是技术定义。

Skills 层是引擎。每个 Skill 是一个封装了特定测试判断逻辑的单元，包含：输入规范（接受什么）、推理模板（怎么想）、输出规范（产出什么）。

应用层是出口。把 Skills 组合起来，面向测试工程师的实际工作场景提供服务。

2.2 一个关键的早期决策

在设计阶段，我们有过一次重要的分歧：Skills 应该是“通用的”还是“领域专属的”？

一派认为应该构建通用 Skills，适用于所有业务场景，维护成本低。另一派认为应该深度定制，每个核心业务模块有自己的专属 Skills，覆盖率更高但维护成本也更高。

我们最终选择了后者，理由很简单：通用 Skills 的价值上限太低。一个不了解“我们的支付流程有哪些特殊约束”的 Skill，生成的用例和任何人都能想到的差不多，没有竞争力。

领域专属 Skills 的确维护成本更高，但它携带的是团队真正的积累，这才是平台的核心价值所在。

三、从零开始的第一个季度：只做一件事

3.1 选择试点模块

平台建设第一个季度，我们只专注于一个模块：订单履约。

选择它的理由：

• 历史 Bug 最多，缺陷数据最丰富
• 业务逻辑最复杂，最能验证 Skills 的深度
• 团队里有一位在这个模块做了三年的工程师，是知识来源
• 发布频率高，能快速获得验证机会

3.2 知识提炼：最痛苦也最关键的一步

我们花了整整三周时间，和那位三年经验的工程师进行了一系列深度访谈。不是让他写文档，而是我们问，他答，我们整理。

问的问题都是很具体的：

• “这个接口你测的时候，脑子里会过哪几个场景？”
• “你见过的最诡异的 Bug，是什么触发的？”
• “新人来了，你会特别叮嘱他注意哪些点？”
• “有没有哪些场景，文档上没写但你知道必须测？”

这个过程得到的东西，比任何一份设计文档都有价值，因为它包含了大量只存在于实践中、从未被书面化的隐性知识。

三周结束，我们整理出：

• 47 条业务规则（其中 31 条在任何文档里都找不到明确描述）
• 23 个高频缺陷模式（覆盖了过去两年该模块 78% 的线上 Bug）
• 12 个“新人必踩坑”场景

3.3 第一批 Skills 的结构

基于这些原材料，我们构建了订单履约模块的第一批 Skills，共 8 个。以“履约状态流转测试 Skill”为例，它的核心结构是这样的：

【Skill 名称】履约状态流转测试
【触发条件】
当测试涉及订单状态变更（创建、支付、发货、签收、退款等任意节点）时触发。
【领域规则注入】
- 规则 #12：备货中状态下，商家拒绝备货时，系统应自动触发退款流程，
  而非等待用户主动申请。（注：此规则在 PRD 中未明确，来源于 2023-Q2 复盘）
- 规则 #18：同一订单在 24 小时内重复申请退款超过 3 次，应触发风控拦截。
- 规则 #23：跨境订单的签收状态变更，需等待海关系统回调，
  不能依赖物流公司单方面更新。
...（共注入 11 条相关规则）
【推理模板】
1. 枚举所有合法状态转换路径（正向 + 反向）
2. 识别每个转换节点的前置条件和后置约束
3. 构造非法状态转换的负向用例
4. 针对上述 11 条领域规则，逐条生成专项用例
5. 推导多步骤组合路径（重点覆盖历史缺陷模式）
【输出规范】
- 格式：Markdown 表格，含用例编号、场景描述、前置条件、操作步骤、预期结果、优先级
- 必须标注：哪些用例对应历史缺陷模式（便于审查时重点关注）
- 优先级规则：涉及领域规则 #12、#18 的用例自动标记为 P0

这个结构和一个普通 Prompt 的本质区别在于：它注入了只有我们团队才知道的业务规则。任何外部工具都生成不了“规则 #12”对应的用例，因为那条规则从未被书面化过。

四、第一个季度结束时，我们验证了什么

4.1 量化数据

三个月后，订单履约模块的数据变化：

这些数据不是为了“证明 Skills 有用”，而是帮助我们校准：哪些地方 Skills 真的有效，哪些地方还有盲区。

4.2 意外的发现

在使用过程中，我们发现了一个没有预料到的收益：Skills 暴露了业务规则的歧义性。

当我们试图把一条口头规则写进 Skill 的时候，会强迫自己把它描述得足够精确，以至于 AI 能够理解并执行。这个过程中，我们发现了好几条规则在不同人的理解里是不一样的——有人认为某个状态下可以退款，有人认为不行。这种歧义以前从来没有被显式化，但它一直在制造 Bug。

把规则写进 Skills 的过程，同时也是一次隐性规则的“审计”。

五、横向扩展：从一个模块到全平台

5.1 复制方法论，而不是复制内容

第一个季度结束后，我们开始将方法论推广到其他模块。但我们很快发现，不能直接复制订单履约的 Skills——每个模块都有自己完全不同的业务上下文。

能够复制的，是这套工作方法：

• 深度访谈 → 隐性知识显式化
• 缺陷数据挖掘 → 高频缺陷模式提炼
• 规则结构化 → Skills 知识层建设
• 灰度验证 → 数据驱动的迭代

每个模块按这套流程走一遍，大约需要四到六周。我们优先选择缺陷率高、发布频繁、有资深人员愿意配合的模块。

5.2 建立 Skills 治理机制

当平台覆盖的模块超过五个之后，一个新的问题开始显现：谁来维护这些 Skills？它们会不会腐化？

我们建立了一套治理机制，核心是三个绑定：

与 Bug 复盘绑定：每次线上问题复盘，有一个固定的结论项——“对应哪个 Skill 需要更新，或者是否需要新建 Skill”。这让 Skills 的更新有了稳定的触发机制。

与发布流程绑定：每个模块在发版前，有一个检查项——“本次变更影响的 Skills 是否已经同步更新”。这是最容易被忽视的，但也是最重要的。

与 Owner 绑定：每个 Skill 有指定的 Owner，负责审查 AI 生成的用例质量，并在发现问题时更新 Skill 定义。这不是额外负担——它本来就是测试工程师的核心职责，只是工作方式变了。

5.3 一个让平台真正活起来的机制

在所有治理机制里，有一个效果最显著——我们叫它“Skill 周报”。

每两周，平台会自动生成一份报告，内容包括：

• 哪些 Skills 被使用次数最多
• 哪些 Skills 生成的用例被人工修改比例最高（说明这个 Skill 质量有问题）
• 哪些模块出了线上 Bug，但没有对应的 Skill 覆盖

最后一条是关键。它直接指向“Skills 体系的盲区在哪里”，驱动平台持续进化。

六、踩过的坑：让后来者少走弯路

坑一：一开始就追求“大而全”

我们最早的方案，是试图在第一个版本里覆盖所有模块。结果是：每个模块都浅尝辄止，哪个都没做深，Skills 的质量不够高，工程师用了觉得“也就那样”，很快失去兴趣。

正确做法：先做一个模块，做到让这个模块的工程师真心觉得“有用”，再推广。深度比广度更重要。

坑二：让测试工程师自己写 Skill 定义

早期我们认为，测试工程师最了解自己的工作，应该让他们自己构建 Skills。结果是：大家都觉得“写 Skill 是额外工作”，推进阻力很大，而且写出来的质量参差不齐。

正确做法：由专人（我们后来叫“Skills 架构师”）负责访谈和抽象，测试工程师负责审查和反馈。知识的提取和结构化，需要专门的能力，不能随手分配。

坑三：忽视“规则冲突”的问题

随着 Skills 覆盖的规则越来越多，我们开始遇到规则之间相互矛盾的情况——A 模块的规则 #5 和 B 模块的规则 #12 在某个交叉场景下，预期行为是冲突的。

这不是 Skills 的问题，而是业务规则本身没有统一。但 Skills 把这个问题暴露出来了。

正确做法：当跨模块规则冲突出现时，不要在 Skill 层面打补丁，要推动业务和产品明确规则，把最终确认的结果写回 Skill。不要让 Skill 成为业务模糊性的遮羞布。

坑四：把“Skills 生成的用例”当成“最终用例”

这个坑有人会踩，但踩了往往不承认。因为 Skills 输出的用例格式整齐、看起来很全面，容易让人放松警惕，直接提交而不仔细审查。

我们在第四个月出过一次这样的事——一个 Skill 对一条业务规则的理解有偏差，生成了一批“预期结果”写错的用例，测试通过了，但实际上是测错了方向。

正确做法：Skills 的输出永远是草稿，人的审查永远是必选项。把“审查 Skills 输出”作为测试工程师的一项正式技能来培养，不是可选的，是必须的。

七、一年后，平台是什么样子

到今天，这套平台覆盖了我们核心业务的 11 个模块，共 64 个 Skill 单元，知识层存储了 312 条业务规则、186 个历史缺陷模式。

但更重要的，是一些数字之外的变化：

新人上手速度变了。以前新人需要两三个月才能独立承担一个模块的测试工作，现在有了 Skills 作为“业务知识脚手架”，这个时间普遍缩短到三四周。他们不再需要从零开始积累业务感知，Skills 把前人的经验直接传递给了他们。

发布信心变了。工程师在发版前，会主动检查“这次变更对应的 Skills 有没有遗漏的场景”，而不是凭感觉说“我觉得测得差不多了”。这个习惯的改变，比任何流程规定都有效。

团队对测试的理解变了。越来越多的人开始把“构建和优化 Skills”看作测试工程师的核心工作之一，而不是“写用例”本身。这个认知的迁移，是整个实践里最让我满意的收获。

结语

从那个周六凌晨的线上故障到现在，已经过去了将近两年。那个“经验文档”里的 Bug 模式，今天以 Skill 的形式活在平台里，每次发布前都会被自动触发检查。

那位三年前离职的同事带走的，不再是一个无法填补的空洞。

这大概是搭建这套平台最值得做的理由——让团队的积累真正属于团队，而不是属于某几个人。

如果你也在考虑从零开始做这件事，我的建议是：不要等到方案完美了再动手。选一个模块，找一个有经验的人，花三周时间把他脑子里的东西掏出来，做成第一批 Skills，用一个迭代周期验证它，然后根据结果决定下一步。

这件事没有捷径，但也没有想象中那么难。