企业官网建设流程全解析

做测试这行，最烦的就是重复劳动。需求评审要挑毛病，用例设计要凑边界，接口联调要对着文档比对，回归跑完了还要写报告。以前这些活全靠人肉堆，直到我把 AI 真正拉进工作流，才发现问题不在 AI 能不能干，而在你愿不愿意把测试经验沉淀成让它能照做的“Skill”。所谓 Skill，往白了说就是一套结构化提示词加固定模板，让 AI 别再说“根据需求设计测试用例”这种正确的废话，而是按资深 QA 的套路，输出能直接落地的东西。这篇文章把我日常在用的 25 个 AI 测试 Skill 全部列出来，分类讲清楚每个是干嘛的，再挑几个核心技能拆开给你看，照着抄就能用。

1. 为什么测试工程师需要自己的 Skill 库

1.1 Skill 和普通 Prompt 的差别

很多人觉得“用 AI 写测试用例”很简单，打开对话框输入“帮我写登录模块的测试用例”，AI 确实能给出二三十条，看着还挺全。但仔细一读，全是“输入正确用户名密码，验证登录成功”“输入错误密码，验证提示错误”这种正确但没用的东西。它不会告诉你密码错误重试次数有没有上限，不会主动提多端登录要不要互踢，更不会把边界值、异常流、权限矩阵这些测试思维带进去。问题不在模型，在提示词太偷懒。

Skill 要解决的就是这件事。它把测试工程师脑子里那套“需求进来该看什么、用例怎么拆、格式怎么出、边界在哪”全部显式写出来，让 AI 照着执行。我自己的习惯是给每个 Skill 定义一个完整的人设、任务目标、执行步骤、输出格式、约束条件和示例。比如同样是生成登录用例，加了 Skill 之后 AI 会先列需求疑点，再按等价类、边界值、异常流、权限流四个维度输出表格，每个用例都带前置条件和可执行步骤。这种差距，基本就是新人和老 QA 的差距。

你可以把 Skill 理解成给实习生的一本操作手册：光告诉他“去测一下登录”不够，你得告诉他拿什么账号、开什么工具、重点看哪些字段、发现了问题填什么表。AI 也一样，它能力很强，但非常依赖你把隐性知识显性化。把经验写进 Skill，等于把你自己从重复劳动里解放出来。

1.2 我沉淀 Skill 库的三个原则

做 Skill 库不是把网上别人写的几十个 Prompt 复制一遍就完事，那样既不贴合你的项目，也养不成自己的体系。我给自己定了三个原则。

第一个原则是问题驱动。凡是让我在测试过程中重复花 30 分钟以上的纯手工活，就值得做成一个 Skill。比如接到需求先写测试要点、接口联调前比对契约、每日跑完自动化后汇总失败原因，这些都是高重复、可模板化的场景。从问题出发做的 Skill，你做完了会真觉得省事，而不是为了攒数量。

第二个原则是输出格式固定。Skill 的产出越结构化，下游用起来越爽。我希望 AI 输出 Markdown 表格就用表格，希望出 JSON 就严格给 schema，希望生成代码就带完整函数签名。这样 AI 的结果可以直接进用例管理系统、自动化脚本或者测试报告模板，不用二次加工。

第三个原则是持续迭代。Skill 不是写一次就封版的东西。我每用一次，只要发现 AI 漏了什么场景，就把这个场景补进 Skill 的 examples 里；只要发现输出格式哪项不顺眼，就当场改掉。大概用两周，一个 Skill 就会从粗糙框架变成顺手的老伙计。定期给 Skill 库做版本管理，我是直接扔在 Git 仓库里的，每次修改都有记录，回滚也方便。

2. 25 个 Skill 全景速览：先看地图再动手

2.1 通用测试 Skill（1-15）

下面这 15 个是我日常产出最高的一部分，覆盖了从需求分析到自动化执行到可靠性评估的完整链路。每个 Skill 都用一个短名加核心用途表示，方便你快速定位。

我自己的使用频率大致是：需求陷阱扫描器和用例矩阵生成器几乎每个迭代都用；接口契约检查员和 pytest 脚手架生成器在联调阶段天天用；压测、弱网、老化那套每周至少用一两次。这张表里的每个 Skill 都不是孤立存在，比如需求扫描器扫出来的风险点会直接喂给用例矩阵生成器，用例矩阵生成器产出的场景又会被 pytest 脚手架生成器转化成自动化脚本，后面我会用登录模块当例子串起来。

2.2 安全与专项 Skill（16-25）

后面这 10 个，有的偏安全合规，有的偏特定领域。这类 Skill 平时不一定天天用，但遇到专项测试时，没有它们全靠人肉查会非常痛苦。

安全类的 Skill 我单独强调一句：所有安全测试相关操作，只允许在你有授权的测试环境执行。线上生产环境严禁直接跑注入类用例，这既是对业务负责，也是保护自己。后面讲实操时我还会再提边界。

3. 需求与用例类 Skill 实操拆解

3.1 用“需求陷阱扫描器”打爆登录需求

我拿最常见的登录模块举例。假如 PRD 里只写了一句“用户可以使用手机号和密码登录，登录状态保持 7 天”。把这句话丢给普通 Prompt，AI 会给你一本正经的用例，但不会指出这需求本身有多少坑。用需求陷阱扫描器，它会按几个方向使劲踩需求。

我先在 Skill 里定义输入：需求描述、涉及角色、期望支持的端、需要遵守的规范。然后在输出里要求它给一张“需求疑点清单”，每一条都要写清楚类型、风险描述、建议补充项。拿这个登录例子，AI 会把下面这些问题全列出来：“登录失败连续几次会锁定？锁定多久？”“密码规则是什么，大小写和特殊字符有没有限制？”“忘记密码流程走短信还是邮箱，验证码有效期多久？”“多设备同时登录允许吗，新登录后旧会话是否踢出？”“登录接口有没有频控，触发后的返回码和文案是什么？”“7 天保持期间 token 失效后，是静默续期还是重新登录？”

你以为这就完了？它还会继续踩“手机号是否国际区号、校验位判断”“操作日志要不要记录登录 IP”“未登录状态访问其他页面是跳转还是弹窗”“退出登录时服务端 token 是否立即失效”。这一步做完，需求评审会上你手上直接多了一张硬问题清单，产品和技术想糊弄都难。这个 Skill 的核心思路是让 AI 站在“可测性”角度反向审需求，而不是替产品经理做需求。

3.2 用“用例矩阵生成器”批量产出高质量用例

需求疑点清完之后，把修正后的需求描述再喂给用例矩阵生成器。这个 Skill 的输出格式我卡得很死，要求按四个维度分组，每个用例必须包含用例编号、前置条件、测试步骤、测试数据、预期结果、优先级。

四个维度是等价类输入、边界值、异常流、权限流。还拿登录说事：等价类有合法手机号、非法手机号、合法密码、非法密码；边界值有 11 位手机号的前后边界、密码长度最小值最大值、验证码有效期前后；异常流有多次输错、网络超时、服务端 500、重复提交；权限流有未登录访问、低权限用户访问管理页、已登录但 token 过期。

为了让 AI 真的能输出可执行用例，而不是写“输入正确的手机号和密码”，我会在 Skill 里给它一个数据表，里面预置一组测试账号和手机号段，规定它必须用这些具体数据去填测试数据列。比如“手机号只能为 11 位数字”这个规则，它就会生成 10 位、12 位、含字母、含特殊字符、开头为 0、全 0、正常号码这些具体输入。这样产出的用例拉到用例管理平台，直接变成一个可以排期的测试计划。

3.3 如何给 Skill 注入项目上下文

Skill 想要好用，光靠通用模板不够，它必须知道你的项目长什么样。我给每个核心 Skill 都配了一张“项目背景卡”，用固定格式写清楚业务模块清单、环境地址、测试账号矩阵、常用规则、历史缺陷关键词。目录结构大概是这样的：

skills/ skill_requirement_trap/ SKILL.md prompt.txt examples/ login_demo.md order_demo.md project_contexts/ login_module.md order_module.md automation_templates/ pytest_template.py

Skill 启动时先加载项目背景卡里的内容和对应模块的 examples，再进入正式任务。这样做有一个明显的好处：AI 生成的用例会贴近你项目的真实规则，而不是凭空想象。比如你们系统规定用户名不允许包含字母，背景卡里写了，AI 就不会再生成“包含字母的用户名”这种无效用例。项目中沉淀下来的历史缺陷关键词也很重要，AI 会主动增强对这些区域的覆盖，把回归风险压下来。这一步做完，你的 Skill 才真正变成你项目的 Skill，而不是通用的网上下载包。

4. 自动化与接口测试 Skill：把 AI 接进流水线

4.1 pytest 脚手架生成器，告别手搓测试类

接口自动化是我日常工作量最大的地方，也是 AI 最能提效的地方。pytest 脚手架生成器的逻辑很简单，我把项目里规范和模板全部塞进 Skill，它收到接口文档后直接生成可直接运行的测试文件。

比如我在 Skill 里定义了 fixture 风格：必须有一个 conftest.py 统一管理 session、base_url 和日志；接口测试类必须继承一个基础类；所有断言不允许用裸 assert，要用封装好的断言方法；每个用例都要带标签，方便 -m 做筛选。AI 拿到 OpenAPI 定义，会先画出接口清单，再按模块拆分测试文件，生成参数化用例。我给它的输出要求是每个文件都要能直接跑，不然就是不合格。

实际用下来，一个具备 20 个接口的新模块，从拿到文档到生成全部 pytest 测试文件，大概只要十几分钟。以前手搓至少要半天。这里有个细节很多人会忽略：AI 生成的断言往往是“看见 200 就认为通过”，这个习惯非常危险。我会在 Skill 里规定，断言必须覆盖业务状态码、关键字段值和数据库落库结果，比如注册成功后用户表里有没有对应记录，这些都是靠历史教训沉淀出来的。

4.2 接口契约检查员和联调规范校验器

联调最痛苦的不是功能不对，而是接口契约对不上。后端说返回了，前端说字段结构不对，最后查出来是联调双方看的文档版本不一样。接口契约检查员这个 Skill，我通常配合 OpenAPI 文件一起用。

它的工作流是：先读取 OpenAPI 定义，再读取实际接口抓包样本，比对响应状态码范围、字段名大小写、嵌套结构、数组空值时是 null 还是空列表、错误信息字段名是否统一。比对结果用表格输出，每个差异项都标出“文档说是什么、实际是什么、影响级别”。有了这个表，联调会上不用争论，直接把 diff 结果丢出来，谁改谁心里有数。

联调规范校验器则是管“风格”的。它会检查接口命名是驼峰还是下划线、分页参数是不是统一 page/pageSize、时间字段是时间戳还是字符串、错误码有没有按模块分段。这些规范光靠 code review 人工盯太累，让 AI 批量扫一遍反而准。我会把规范写成规则集放进 Skill 里，AI 每扫一个接口就对照规则打分，分数低的接口自动触发重新评审。这套流程跑顺之后，联调效率提升非常明显。

4.3 多环境配置解析器

自动化测试最怕环境切换。dev 环境连的数据库、测试账号、回调地址和 staging 完全不一样，每次切环境都手改配置一定会出事。多环境配置解析器这个 Skill 做的事情就是把配置统一成标准格式，用 pydantic-settings 之类的工具管理，AI 负责帮你把散落在各处的配置项整理成 schema。

我实际的做法是建一个 config 目录，每个环境一个 yaml 文件，里面只有 base_url、超时时间、账号池、开关项四类内容。Skill 启动时自动读取当前环境的 yaml，并注入到所有测试代码中。AI 还会在每次生成 pytest 文件时自动引用环境变量，而不是把地址写死在代码里。这样一来，本地、内网测试、预发布三套环境之间切换，只需要改一个环境变量。这个 Skill 技术上不复杂，但对稳定性的提升是决定性的，环境配错踩出来的坑，比业务断言错误可怕得多。

5. 性能、安全与专项测试 Skill 怎么用

5.1 性能与可靠性：从压测到老化测试

压力场景生成器是我做容量评估时的主力。我只需要给它业务流程描述和预期吞吐量，它就生成一份 Locust 脚本或者 JMeter 测试计划。生成完它还会自动核对任务比例，比如登录占 30%、下单占 40%、查询占 30%，总 QPS 要覆盖目标值并预留 20% 余量。性能测试讲究的是场景不要乱，先让 AI 把用户模型梳理出来，再动手写脚本，这样压测结果才有参考意义。

RTMP 流媒体检测器则针对直播和视频场景。我以前测直播流，最烦的就是不知道当前画面到底卡了多久。后来我让它帮我生成一套基于 ffprobe 的脚本，定时去拉流并记录音视频帧到达间隔，一旦间隔超过阈值就算一次卡顿。连续观测 5 分钟，自动汇总出平均延迟、抖动、卡顿次数。弱网模拟器更直接，用的是 tc 命令模拟延迟和丢包，AI 会帮我生成一组不同网络档位的测试矩阵，比如 3G 弱覆盖、Wi-Fi 高延迟、跨地域长距离，每档配置对应的丢包率和延迟时间。

老化测试编排器是设备稳定性测试的刚需。它生成一个主循环脚本，让设备连续跑 72 小时，每隔一段时间自动执行一次完整的业务冒烟、重启应用、记录内存和温度。整个执行过程全自动，跑完之后自动汇总哪些指标异常。资源泄漏观察员其实是它的小跟班，用 psutil 实时采样内存、CPU、线程数、文件句柄数，当指标持续上涨时输出趋势图，辅助判断是不是存在泄漏。这块的难点不在写脚本，而在设计“什么指标涨多少算异常”，我是把历史正常数据喂给 AI 当基线，让它自动做对比。

5.2 安全测试：必须在授权边界内做

安全测试 Skill 的使用，我把合规红线放在最前面。所有操作都只允许在测试环境执行，且要有书面授权。这不只是流程问题，是真会出事的。

敏感信息存储检测器是我检查移动端 App 时的常用 Skill。它的目标不是“破解什么”，而是验证内部的敏感信息保护措施。AI 会生成一份检测清单，包括本地数据库字段是否有明文密码、SharedPreferences 里 token 是否加密、日志输出有没有打印完整手机号、HTTP 请求里密码字段是否明文传输、Apk 包里是否硬编码了密钥。我拿到清单之后，用抓包和静态检查工具逐项验证，产出“不符合项+风险等级+修复建议”的三列报告。这套流程走下来，App 登录密码是否明文存储，答案非常清晰。

越权访问探测器的思路是给 AI 输入角色权限矩阵，让它生成跨级别访问的用例。比如普通用户能否调用管理员接口、A 用户的订单能否用 B 用户的 token 访问。输入注入测试助手则是针对参数输入的安全用例设计，我会特别要求它在用例中标注“测试环境执行，禁止生产数据”，并让 AI 把请求 URL、请求体、预期防护效果写清楚，方便测试和研发复现。第三方 SDK 权限审计器的价值在于查合入的 SDK 到底申请了哪些敏感权限，AI 帮我把 AndroidManifest 或 iOS 的权限声明和隐私政策挨个比对，统计出“声明了但没用”“用了但没声明”两类问题。

这些 Skill 统一有一个特点：它们不替你做攻击，只帮你把检查项想全、把证据组织好。真正的执行和安全判断，还是得靠人来。

5.3 专项领域：AI 模型、车载、GIS 与内网部署

AI 模型评估器是我测大模型输出质量时用的。你问 AI“今天天气怎么样”，它说什么都行；但要是做一个客服问答机器人，就必须验证回复的格式、语气、信息完整度。这个 Skill 会定义一套评分体系：格式遵从度、事实准确度、幻觉率、拒答率、响应延迟。我定义一组标准问题集，AI 先生成答案，再用另一个模型或规则去打标，最终算出一个可对比的分数。多模型交叉验证器则是拿同一组问题去问不同模型，把答案并排列在一起，标出互相冲突的地方。冲突的地方要么是事实性错误，要么是逻辑不一致，这就是模型质量的核心风险点。

车载电子系统测试助手和 GIS 空间数据质检器，属于垂直领域的 Skill。前者针对 CAN 信号、诊断协议、UDS 服务这些概念，AI 可以辅助生成信号范围测试和会话切换用例；后者针对 GIS 数据，让 AI 生成拓扑关系检查和属性一致性检查规则，比如面图层不能重叠、节点必须落在边界线上、属性字段值不能越界。这类 Skill 不需要让 AI 直接操作专用设备，但让它生成检查和用例框架，能帮领域测试省下大量查规范的时间。

内网模型评测部署器解决的是环境问题。有些项目数据敏感，模型评测环境必须搭在隔离内网里。AI 在这里的主要工作是帮你生成部署 checklist：离线包怎么同步、依赖怎么用私有源安装、模型权重文件怎么校验、评测任务怎么调度、自定义 Skill 挂到哪个目录。我实际踩过的坑是模型和依赖版本不匹配，所以我会让 AI 在生成部署脚本时把所有依赖导出成带哈希的清单，上传到内网后逐一校验。这个问题处理完，整个内网评测环境就能稳定复现，不会出现“在能上网的机器跑得好好的，一到内网就各种报错”的情况。

6. 这些 Skill 怎么组合成日常测试工作流

6.1 从需求评审到上线回归的完整串联

单个 Skill 好用，组合起来才是核武器。我现在的日常迭代流程是一条贯穿的流水线。

需求评审阶段，我会先跑需求陷阱扫描器，把产出问题清单发到评审群里；需求确认后，马上跑用例矩阵生成器，把用例输出到用例库。提测阶段，接口文档一到手，先跑接口契约检查员做文档和代码的比对，再跑 pytest 脚手架生成器生成自动化脚本。开发自测通过之后，我执行自动化用例，失败结果自动汇总回传；同时跑一次联调规范校验器，检查所有新增接口是否符合团队规范。上线前再根据业务影响范围决定是否跑一轮压力测试和老化测试。这条流水线每个环节都有 AI 参与，但核心判断始终在我手里。AI 负责把重复的、机械的部分速度拉满，我负责做最终决策。

6.2 用多模型协作把测试设计做得更厚

测试最怕思维盲区，一个人设计用例总有没想到的地方。我现在经常用多模型协作来削弱这个问题。具体做法是同一份需求描述，扔给两个不同的大模型去各自生成测试方案，然后把两份结果并排放到一起，让其中一个扮演“挑刺者”，专门找对方方案里缺失的场景和逻辑漏洞。挑出来的差异点，不少是单独一个人想不起来的边角场景，比如并发场景下的重复提交、缓存一致性问题、异常恢复后的状态一致性。

我还试过让一个模型生成测试数据，另一个模型做数据校验，比如生成一堆用户信息后，检查是否有身份证校验位错误、手机号是否符合号段规则、日期字段是否在合理范围内。两个模型各干各的，交叉验证，产出的数据质量比单个模型高得多。不过要说清楚，多模型协作不是模型越多越好，一般 2 到 3 个足够，再多管理成本就上来了。

6.3 Skill 库的管理和迭代习惯

Skill 库做起来之后，最怕的是放在那里不更新。我自己用 Git 管理整个 skills 目录，每个 Skill 文件里有一个 CHANGELOG 片段，记录改了什么、为什么改。遇到 AI 输出不满意的情况，我会先看是不是自己给的上下文不清晰，如果是，就补背景卡；如果背景卡没问题，就把这次失败案例加到 examples 里，作为负面示例。一个 Skill 迭代几次之后，AI 的表现会稳定很多，因为 examples 就是最有效的 few-shot。

迭代的节奏也不用太快。我个人的建议是每个迭代周期至少 review 一次使用频率前五的 Skill，每次至少补一个新场景。这样做一两个迭代，你就能明显感觉到 AI 的产出越来越贴近项目实际。这个习惯是我觉得整个 Skill 工作流里最值得长期坚持的。

7. 常见问题与避坑记录

7.1 AI 生成用例太泛怎么办

最典型的反馈是“AI 生成的用例看着对，但没法执行”。根因通常是你在 Skill 里没约束输出粒度。我给用例矩阵生成器加了两条硬性规定：第一，测试步骤必须带具体按钮名、输入框标签、接口路径；第二，测试数据列必须用项目真实的数据样本，不允许写“有效手机号”这种抽象词，要写“13800138000”。加了这两条之后，AI 出错的概率下降非常明显。如果还是泛，就把一个优秀示例和糟糕示例同时塞进 Skill 里，让它先学会区分再输出。

7.2 AI 幻觉导致断言和预期结果写错

这是自动化测试场景最坑的问题。AI 没见过系统的真实逻辑，经常凭经验写预期结果，比如接口明明返回 400，它写 200。我的解决办法是两条线并行：一条是接口契约检查员，让它基于 OpenAPI 定义生成断言，而不是自由发挥；另一条是在 pytest 脚手架生成器里禁用“猜测型断言”，所有断言都必须引用接口文档中的响应示例或数据库状态。前者管结构，后者管行为，双管齐下之后，幻觉断言大幅减少。

7.3 安全测试 Skill 误报和越权风险

安全测试类 Skill 在生成用例时，偶尔会把“可能存在问题”说成“确认存在漏洞”，这是误报。我处理的方法是要求 AI 在输出每条结论时都必须附带证据位置和复现步骤，人工验证通过后才能记为缺陷。另外一个容易忽略的坑是越权访问探测器生成用例时，可能会无意中接触敏感数据。我要求所有越权用例只跑测试账号和测试数据，并且禁止输出真实手机号、身份证号、银行卡号，只允许用脱敏后的合成数据。合规和安全永远是底线，不能让 AI 帮你提效反而把自己搭进去。

7.4 内网部署模型评测环境时会遇到什么

内网部署最麻烦的不是模型本身，而是依赖环境。AI 生成的部署脚本如果依赖在线拉包，在内网基本跑不起来。我的做法是让 AI 先生成一份完整的离线依赖清单，包括模型文件、Python 包、系统库、评测工具，每一项都带版本号和校验值，然后在能联网的环境统一打包，传到内网后用脚本逐项校验。另一个常见坑是 Skill 目录路径写死，导致换机器后找不到。我会让 AI 在部署脚本里统一使用相对路径，并通过环境变量注入根目录，这样换台机器也不用改脚本。

7.5 别让 Skill 库变成“收藏夹”

最后说一个很普遍的问题：很多人下载了一堆 Skill，结果真正用的只有两三个，剩下的全在吃灰。我的经验是做减法。Skill 库不是多多益善，而是只在有真实痛点时新增。我每次准备加一个新 Skill 前，都会先问自己“接下来两周我会不会至少用三次”，答案是否定的，就不加。这样留下来的每一个 Skill 都是被反复打磨过的，而不是收藏夹里积灰的文档。测试这行，真正值钱的不是工具，是你愿意花多少时间把经验沉淀成让 AI 能复用的东西。

我个人在实际操作中还有一个体会：Skill 不只用来测业务功能，也可以用来测测试资产本身。我会定期用一个“测试资产审计 Skill”去扫描用例库，找出重复用例、过时预期、孤立的自动化用例，然后倒逼自己补充和维护。这个思路听起来简单，做起来才发现，AI 帮你把测试资产管清楚了，日常执行才真正轻松。如果你也想搭建自己的一套测试 Skill 库，不用追求一步到位到 25 个，先挑日常最痛的一个场景，把 Skill 写到能稳定帮你省时间，再慢慢加。用不了一个月，你回头看自己手搓用例的日子，会有种回不去的感觉。