企业官网建设流程全解析

1. 从“会用AI”到“用好AI”：测试Skill到底解决了什么问题

这两年AI工具迭代的速度，快到让人有点喘不过气。我身边不少做测试的朋友，从最开始拿AI写个正则、生成几条边界用例，到现在开始琢磨怎么把AI塞进整个测试流程里，变化其实就发生在短短一年多。但真正拉开差距的，不是谁用的模型更强，而是谁手里攒了一套趁手的测试Skill。

所谓Skill，说白了就是给AI Agent预设好的、可复用的能力单元。你可以把它理解成给一个新来的实习生准备的“操作手册+工具箱”——手册告诉他遇到什么场景该干什么，工具箱里装着具体干活的家伙。没有Skill的Agent，就像一个聪明但没受过训练的新人，你得每次从头解释需求；有了Skill，它就知道“哦，这是接口测试，我该先读Swagger，再生成用例，再跑pytest，最后出报告”。

我日常在用的这25个Skill，覆盖了从需求分析、用例设计、接口测试、UI自动化、性能压测到缺陷定位的完整链路。它们不是什么高深的东西，很多就是几段提示词加几个脚本的组合，但胜在稳定、可复用、能串起来。这篇文章我会把这25个Skill拆开揉碎讲清楚：每个Skill解决什么问题、核心原理是什么、怎么配置、踩过哪些坑。不管你是刚接触AI测试的新手，还是已经在搭Agent架构的老手，应该都能从里面挑几个直接拿去用。

提示：Skill不是越多越好。我见过有人攒了上百个Skill，结果Agent每次选Skill都要犹豫半天，反而变慢。25个是我实测下来覆盖度和响应速度比较平衡的一个数量级。

2. 测试Skill的底层逻辑：为什么是Agent+Skill而不是纯提示词

2.1 纯提示词的天花板在哪里

刚开始用AI做测试的时候，我也是纯提示词流派。打开对话框，粘贴需求文档，让它生成用例。头几次确实惊艳，但用久了问题就出来了。

第一个问题是上下文漂移。同一个对话里聊到第十轮，AI已经忘了最开始定的用例格式规范，生成的用例字段开始缺胳膊少腿。第二个问题是不可复用。我精心调好的一段提示词，换个人用、换个项目用，效果就打折，因为里面隐含了很多我自己的语境。第三个问题是无法执行。AI生成的用例再漂亮，也得手动复制到测试平台里，中间但凡有个格式转换，就容易出错。

这三个问题归结起来就是：纯提示词只能做“一次性生成”，做不了“流程化执行”。而测试工作恰恰是高度流程化的——需求进来，分析，设计，执行，回归，报告，每一步都有明确的输入输出。

2.2 Skill的本质：把提示词、工具、约束打包

Skill的出现，本质上是把“提示词工程”升级成了“能力工程”。一个完整的Skill通常包含四层：

• 触发条件：什么情况下该调用这个Skill。比如“当输入包含接口定义文件时”触发接口用例生成Skill。
• 提示词模板：具体让AI怎么思考、怎么输出。这部分是核心，但不再是全部。
• 工具绑定：这个Skill能调用哪些外部工具。比如读文件的工具、跑pytest的工具、查数据库的工具。
• 输出约束：结果必须符合什么格式。比如必须是JSON、必须包含哪些字段、必须通过什么校验。

这四层打包在一起，才是一个能稳定干活的Skill。我打个比方：纯提示词像是给AI一张纸条，上面写着“帮我测一下登录功能”；而Skill像是给AI一个工位，工位上贴着操作规范、摆着测试工具、放着结果模板，它坐下来就能按部就班地干。

2.3 Agent架构下Skill的调度逻辑

在Agent架构里，Skill不是孤立存在的。一个测试Agent通常有一个调度器，负责根据当前任务决定调用哪个Skill。调度逻辑我见过三种主流做法：

第一种是关键词匹配，最简单，也最不稳。用户说“测接口”，就匹配到接口测试Skill。问题是用户说“验证一下API返回”可能就匹配不上了。

第二种是向量检索，把每个Skill的描述向量化，用户输入也向量化，算相似度。比关键词匹配稳，但遇到描述模糊的Skill还是容易选错。

第三种是路由Agent，专门用一个轻量模型来判断该走哪个Skill。这个最稳，但成本也最高。我目前用的是“向量检索+规则兜底”的混合方案，实测下来准确率能到九成以上，成本也可控。

注意：Skill之间的依赖关系要提前理清楚。比如“生成测试报告”这个Skill依赖“执行测试”的输出，如果调度器把顺序搞反了，Agent就会卡住。我的做法是在Skill元数据里显式声明depends_on字段，调度器先做拓扑排序再执行。

3. 25个测试Skill全拆解：从需求到报告的完整链路

3.1 需求分析与用例设计类Skill（6个）

Skill 1：需求拆解器

输入一段需求描述，输出结构化的测试点列表。核心提示词是让AI按“功能点-业务规则-边界条件-异常场景”四个维度拆。我试过直接让它生成用例，结果粒度太粗；先拆测试点再生成用例，质量明显提升。这个Skill绑定了文档解析工具，能直接读Word和PDF。

Skill 2：用例生成器

基于测试点生成标准格式用例。关键是输出约束要严——我要求每条用例必须包含用例编号、前置条件、操作步骤、预期结果、优先级五个字段，缺一个就重试。实测下来，加了格式校验之后，用例可用率从六成提到了九成。

Skill 3：边界值挖掘器

专门针对数值型输入找边界。这个Skill内置了等价类划分和边界值分析的规则，AI负责补充业务语义上的特殊边界。比如金额字段，除了0和最大值，还得考虑负数、小数位、币种切换。

Skill 4：场景串联器

把离散的用例串成端到端场景。比如“用户注册-登录-下单-支付-退款”这样一条链路。这个Skill的价值在于发现用例之间的依赖关系，很多bug只在跨模块流转时才暴露。

Skill 5：用例评审助手

反向检查用例质量。让AI扮演挑剔的评审者，找出用例中的遗漏、冗余和歧义。我一般用它做二次校验，能揪出不少“看起来写了其实没测”的用例。

Skill 6：需求变更影响分析器

当需求文档更新时，自动比对新旧版本，找出受影响的用例。这个Skill绑定了diff工具，输出的是“需要修改的用例清单+修改建议”。

3.2 接口测试类Skill（7个）

Skill 7：Swagger解析器

读Swagger/OpenAPI文档，提取所有接口定义。输出结构化的接口清单，包含路径、方法、参数、响应码。这是接口测试的起点，解析不准后面全白搭。

Skill 8：接口用例生成器

基于接口定义生成正向和反向用例。正向用例覆盖正常参数组合，反向用例覆盖缺参、类型错误、越界、鉴权失败等。我要求它每个接口至少生成3条反向用例。

Skill 9：pytest脚本生成器

把接口用例转成可执行的pytest脚本。这个Skill绑定了代码模板，生成的脚本直接能跑。关键是要处理好参数化和断言，我一般让它用@pytest.mark.parametrize做数据驱动。

Skill 10：Mock数据生成器

根据字段类型和业务规则生成合理的测试数据。比如手机号要符合号段规则，身份证要能通过校验位。这个Skill内置了常见数据类型的生成规则，AI负责补充业务特定规则。

Skill 11：接口依赖分析器

分析接口之间的调用依赖，确定执行顺序。比如下单接口依赖登录接口返回的token。这个Skill输出的是依赖图，调度器据此排序。

Skill 12：断言增强器

检查生成的断言是否充分。很多自动生成的脚本只断言状态码200，这远远不够。这个Skill会提示补充响应体字段校验、数据库校验、下游接口校验。

Skill 13：接口回归选择器

代码变更后，自动选择需要回归的接口用例。基于代码覆盖率数据和接口依赖图，挑出最小回归集。实测能减少六成以上的回归工作量。

3.3 UI自动化类Skill（5个）

Skill 14：页面元素定位器

根据页面截图或DOM结构，生成稳定的元素定位表达式。优先用># skill_08_api_case_generator.yaml name: api_case_generator description: 基于接口定义生成正向和反向测试用例 trigger: keywords: ["接口用例", "API用例", "生成用例"] input_types: ["api_definition"] tools: - read_file - write_file output_schema: type: array items: case_id: string api_path: string method: string case_type: enum[positive, negative] params: object expected: object depends_on: ["swagger_parser"]

加载的时候，调度器会扫描所有YAML文件，建立Skill索引。我一般把Skill按类别放在不同目录下，方便管理。

4.2 从Swagger到用例的完整链路

假设现在有一个用户中心的Swagger文档，我要生成完整的接口测试用例。

第一步，调用Skill 7（Swagger解析器）。它读取user_center.yaml，输出接口清单。我实测过一个中等规模的文档，大概40个接口，解析耗时在8秒左右。

第二步，调用Skill 11（接口依赖分析器）。它分析出登录接口是其他接口的前置依赖，输出依赖图。

第三步，调用Skill 8（接口用例生成器）。这是核心步骤。提示词模板大致是这样的：

你是一名资深接口测试工程师。基于以下接口定义，生成测试用例。 接口定义： {api_definition} 要求： 1. 每个接口至少生成1条正向用例和3条反向用例 2. 反向用例必须覆盖：必填参数缺失、参数类型错误、参数越界、鉴权失败 3. 用例格式严格遵循output_schema 4. 参数值要符合业务语义，不要用test123这种无意义数据 输出JSON数组，不要有其他内容。

第四步，调用Skill 12（断言增强器）。检查生成的用例断言是否充分，补充响应体字段校验。

第五步，调用Skill 9（pytest脚本生成器）。把用例转成可执行脚本。

整个链路跑下来，40个接口大概生成180条用例，耗时3分钟左右。人工写的话，保守估计要两天。

4.3 参数计算与阈值设定

几个关键参数我调了很久才找到比较合适的值：

温度这个参数特别值得说。一开始我用默认的0.7，生成的用例确实花样多，但格式经常跑偏。降到0.3之后，格式稳定性大幅提升，代价是用例多样性略降。对于测试用例这种要求规范性的场景，低温度是更优解。

4.4 执行与结果收集

脚本生成后，直接跑pytest。我一般用pytest -n auto开多进程，40个接口的180条用例，并行跑大概90秒。结果输出到Allure报告，同时把原始结果JSON喂给Skill 25（测试报告生成器）。

报告生成器会做几件事：统计通过率、按接口分组展示失败用例、提取失败原因、给出风险提示。我特别喜欢它的“风险提示”部分，它会根据失败用例的分布，判断是偶发问题还是系统性问题。

5. 踩坑实录：25个Skill用下来最容易翻车的地方

5.1 Skill选择错误：Agent为什么总挑错工具

最常见的坑是调度器选错Skill。我遇到过好几次，明明要生成接口用例，Agent却调用了UI用例生成器。排查下来发现是Skill描述写得太模糊，两个Skill的description都包含“生成用例”这个短语，向量相似度太接近。

解决办法有两个：一是把description写得更具体，接口用例的写“基于HTTP接口定义生成请求级测试用例”，UI的写“基于页面元素生成浏览器操作级测试用例”；二是在trigger里加input_types约束，接口用例只接受api_definition类型的输入。

5.2 上下文超限：长文档处理的分片策略

需求文档一长，AI就记不住。我试过直接塞一份50页的PRD进去，结果AI只处理了前几页，后面的全忽略了。后来改成分片处理+摘要传递：先把文档按章节切成小块，每块单独分析出测试点，再把所有测试点汇总。这样虽然多花点时间，但覆盖度有保障。

分片大小我一般控制在2000字左右。太小了碎片化，太大了还是超限。切分的时候尽量按语义边界切，别在句子中间断开。

5.3 输出格式漂移：如何让AI稳定输出JSON

让AI稳定输出JSON是个老大难问题。我试过三种方案：

第一种是纯提示词要求“只输出JSON”，成功率大概七成。第二种是加few-shot示例，成功率提到八成五。第三种是用结构化输出API（比如某些模型支持的JSON mode），成功率九成五以上。

我现在用的是“JSON mode + schema校验 + 失败重试”的组合。如果第一次输出不符合schema，就把错误信息喂回去让它重试，最多重试三次。实测下来，三次之后还失败的案例极少。

5.4 常见问题速查表

提示：每次调完Skill，一定要拿同一批输入跑回归，对比输出差异。我有次改了一个提示词，接口用例质量上去了，但UI用例全崩了，就是因为两个Skill共用了部分模板。

6. 进阶玩法：让25个Skill协同起来

6.1 Skill编排：串行、并行与条件分支

单个Skill再强，也只是个工具。真正的威力在于编排。我目前用的编排模式有三种：

串行编排适合有严格先后顺序的链路，比如“解析Swagger→生成用例→生成脚本→执行→出报告”。这种最简单，按顺序调就行。

并行编排适合互不依赖的任务，比如同时生成接口用例和UI用例。我一般用asyncio.gather并发跑，能省不少时间。

条件分支适合需要判断的场景，比如“如果接口有鉴权，就先生成登录用例；如果没有，直接生成业务用例”。这个用规则引擎实现，判断条件写在Skill的元数据里。

6.2 多Agent协作：分工与通信

当Skill多到一定程度，单个Agent管不过来，就得上多Agent。我现在的架构是三个Agent：

• 设计Agent：负责需求分析、用例设计，挂载Skill 1-6。
• 执行Agent：负责接口、UI、性能测试的执行，挂载Skill 7-22。
• 分析Agent：负责缺陷分析、报告生成，挂载Skill 23-25。

三个Agent之间通过消息队列通信。设计Agent产出用例后，发消息给执行Agent；执行Agent跑完，把结果发给分析Agent。这样各司其职，单个Agent的上下文压力小很多。

6.3 持续优化：Skill的版本管理与效果追踪

Skill是要迭代的。我给每个Skill加了版本号，每次修改都记changelog。更重要的是效果追踪——我会记录每个Skill的调用次数、成功率、平均耗时、人工修正率。这几个指标能直观反映Skill的健康度。

比如我发现Skill 8（接口用例生成器）的人工修正率一度高达30%，排查下来是提示词里没强调业务语义，生成的数据太随意。改了提示词之后，修正率降到8%。

7. 我个人的一些实操体会

这套25个Skill的组合，我用了大半年，最大的感受是：AI测试的瓶颈不在AI，在于你怎么把测试工作拆成AI能理解的原子任务。拆得越细，Skill越好写，效果越稳。反过来，如果你指望一个Skill搞定整个测试流程，那大概率会失望。

另一个体会是，不要追求全自动。我现在这套流程，人工介入点还有三四个，比如用例评审、缺陷确认、发布决策。这些环节需要人的判断，硬要自动化反而增加风险。AI负责干重复的、有规律的活，人负责干需要判断的、有风险的活，这个分工我觉得挺合理。

最后分享一个小技巧：每次写完一个新Skill，先拿历史项目的数据跑一遍，对比人工结果。如果AI的结果和人工结果差异超过两成，说明Skill还有问题，别急着上生产。这个“历史数据回测”的习惯，帮我避了不少坑。