企业官网建设流程全解析

1. 为什么我把 AI 测试 Skill 当成日常工具箱来攒

这两年测试圈子里聊得最多的话题，已经从“你会不会写自动化脚本”变成了“你手里有多少个能直接调用的 Skill”。我自己是从传统自动化测试一路走过来的，Selenium、Pytest、接口自动化、性能压测这些活都干过，后来接触到 Agent 和 Claude 这类工具之后，慢慢意识到一件事：真正拉开效率差距的，不是你 Prompt 写得多花哨，而是你有没有把高频测试动作沉淀成一个个可复用、可组合的 Skill。

所谓 Skill，说白了就是把一段固定的工作流程、判断逻辑、输出格式封装起来，让 AI 在需要的时候直接调用。它跟普通的提示词不一样，提示词是你每次都要重新描述一遍需求，而 Skill 更像是一个带参数的函数，你告诉它输入什么，它就按既定规则吐出结果。我日常在用的这 25 个 Skill，覆盖了用例生成、接口校验、日志分析、缺陷归因、测试报告整理、环境巡检、数据构造这些环节，基本把测试工作里重复度最高的部分都包住了。

这篇文章适合两类人看：一类是刚接触 AI 测试、想知道 Skill 到底能干什么的测试同学；另一类是已经在用 Agent 做测试、但手里工具零散、想系统化整理一套工具箱的从业者。我不会只列名字，而是把每个 Skill 的设计思路、关键参数、实操步骤和踩过的坑都讲清楚，你照着搭就能用。核心关键词 AI、测试、Skill、Agent、Claude 会贯穿全文，因为它们本来就是这套东西的骨架。

先说清楚一个前提：Skill 不是万能的，它解决的是“重复劳动”和“标准化输出”，不是“替你做决策”。我见过太多人一上来就想搞一个全自动测试 Agent，结果连最基本的用例评审逻辑都没理清，最后做出来的东西没人敢用。所以我的思路一直是：先把单个动作做扎实，再谈组合和编排。

2. 25 个 Skill 的整体设计与分类思路

2.1 按测试生命周期划分的四层结构

我攒这 25 个 Skill 不是拍脑袋凑数，而是按测试工作的生命周期分了四层。第一层是需求与用例层，负责把模糊的需求描述转成结构化用例；第二层是执行与校验层，负责跑接口、比对响应、检查数据；第三层是分析与归因层，负责看日志、定位失败原因、聚类缺陷；第四层是报告与协作层，负责整理结果、生成周报、同步给相关方。这样分层的好处是，每个 Skill 的职责边界很清楚，组合的时候不会互相打架。

为什么强调边界清楚？因为我早期犯过一个错，把一个 Skill 设计成“既能生成用例又能执行测试还能出报告”，结果参数一多就失控，AI 经常搞混输入输出的格式。后来我把它拆成三个独立 Skill，每个只干一件事，反而稳定得多。这跟写代码是一个道理，单一职责原则在 Skill 设计里同样适用。

下面这张表是我对 25 个 Skill 的分类概览，你可以先有个整体印象，后面再逐个展开。

2.2 为什么选择 Skill 而不是纯 Prompt

很多人问我，直接用 Prompt 不就行了，为什么要费劲封装成 Skill。我的回答是：Prompt 适合一次性任务，Skill 适合高频重复任务。你想想，你每天要生成十几条接口用例，如果每次都重新写一遍“请根据以下接口文档生成正常、异常、边界三类用例，输出格式为表格，包含用例编号、前置条件、步骤、预期结果”，这本身就是浪费。封装成 Skill 之后，你只需要传入接口文档，剩下的格式和规则都是固定的。

另一个原因是可维护性。Prompt 散落在各个聊天记录里，改一次要翻半天；Skill 是集中管理的，你改一处，所有调用它的地方都生效。而且 Skill 可以带参数校验，比如你传入的接口文档格式不对，它会直接报错，而不是硬着头皮生成一堆垃圾用例。这一点在团队协作里特别重要，因为不是每个人都清楚你的 Prompt 该怎么写。

还有一个容易被忽略的点：Skill 可以组合。比如“接口断言”这个 Skill 的输出，可以直接作为“失败归因”Skill 的输入，形成流水线。纯 Prompt 很难做到这种稳定的衔接，因为每次输出的格式可能都有细微差异。Skill 通过固定输出结构，让上下游能够可靠对接。

2.3 工具选型：Claude、Agent 框架与本地模型的取舍

在工具选型上，我主力用的是 Claude 系列模型，原因是它在长文本理解和结构化输出上比较稳，尤其是处理接口文档、日志这类半结构化内容时，不容易丢信息。Agent 框架我用的是比较轻量的方案，核心就是任务编排和 Skill 调用，没有上太重的框架，因为测试场景往往需要快速迭代，框架太重反而拖慢节奏。

本地模型我也试过，通过 Claude Code 调用本地模型跑一些敏感数据的测试。这里要说明的是，本地模型在简单任务上够用，比如日志关键字提取、格式转换，但涉及复杂推理的归因分析，还是得用能力更强的模型。我的建议是混合使用：敏感数据走本地，复杂分析走云端，中间用统一的 Skill 接口隔开，这样切换成本最低。

提示：Skill 的模型依赖要解耦。不要把模型名称硬编码在 Skill 里，而是通过配置传入，这样换模型的时候不用改 Skill 本身。

3. 需求与用例层的 6 个 Skill 拆解

3.1 需求拆解 Skill：把一段话变成测试点清单

这个 Skill 是我用得最频繁的一个。输入是一段需求描述，输出是结构化的测试点清单，包含功能点、约束条件、依赖项、风险点。它的核心逻辑是先识别需求里的名词和动词，名词通常是操作对象，动词通常是操作行为，然后围绕“对象+行为”组合出测试点。

关键参数有三个：requirement_text（需求原文）、domain（业务领域，用于补充领域知识）、granularity（粒度，可选粗、中、细）。粒度这个参数很关键，粗粒度只输出功能模块级别，细粒度会拆到具体字段和边界。我一般先用粗粒度过一遍，确认大方向没错，再对重点模块用细粒度拆。

实操中我发现一个坑：需求描述里经常有隐含条件，比如“用户登录后可以查看订单”，隐含了“未登录不能查看”“登录态过期不能查看”这些反向场景。所以我在 Skill 里加了一条规则，强制输出反向场景和异常场景，避免遗漏。这条规则是我踩过坑之后加的，之前漏测过一个登录态过期的场景，上线后出了问题。

3.2 边界用例生成 Skill：等价类与边界值的自动化

边界用例是测试里最容易漏也最容易出问题的地方。这个 Skill 的输入是字段定义，包括类型、取值范围、是否必填，输出是边界值用例集合。它的原理就是经典的等价类划分和边界值分析，但用 AI 来做的好处是，它能自动识别一些不那么明显的边界，比如字符串长度、特殊字符、编码问题。

我给它设的参数包括field_type（字段类型）、min_value、max_value、nullable（是否可空）、special_chars（是否允许特殊字符）。输出会覆盖最小值、最大值、最小值减一、最大值加一、空值、超长值、特殊字符值这几类。对于数值型字段，还会额外生成精度边界，比如小数位数。

这里有个经验：不要完全信任 AI 生成的边界值，尤其是涉及业务规则的字段。比如“年龄”字段，技术上范围是 0 到 150，但业务上可能只允许 18 到 65。所以我在 Skill 里加了一个business_rule参数，让使用者显式传入业务约束，AI 会优先遵循业务约束，而不是纯技术边界。

3.3 等价类划分 Skill：减少冗余用例

等价类划分的目的是用最少的用例覆盖最多的场景。这个 Skill 的输入是一组输入条件，输出是划分好的等价类表，每个等价类标注有效或无效，并给出代表值。它的价值在于帮你砍掉重复用例，我实测下来，一个中等复杂度的功能，用这个 Skill 能把用例数量压缩 30% 到 40%，同时覆盖率不降。

参数方面，input_conditions是输入条件列表，constraints是条件之间的约束关系。约束关系这块是难点，因为很多条件不是独立的，比如“用户类型”和“折扣力度”是联动的。我在 Skill 里用了一个简单的规则引擎来处理约束，先让 AI 识别条件之间的依赖，再据此合并等价类。

注意：等价类划分完成后，一定要人工复核一遍。AI 有时候会把两个看似等价但实际有细微差别的类合并，这种差别在特定场景下可能就是缺陷来源。

3.4 用例优先级排序 Skill：把有限时间花在刀刃上

测试时间永远不够，所以优先级排序很重要。这个 Skill 的输入是用例列表，输出是按优先级排序后的列表，并标注排序理由。它的排序逻辑综合了三个维度：业务影响面、出错概率、修复成本。业务影响面看这个功能有多少用户在用，出错概率看这个模块历史缺陷密度，修复成本看一旦出问题要多久能修好。

我用impact_score、probability_score、cost_score三个参数来量化，每个维度 1 到 5 分，最后加权求和。权重可以按项目阶段调整，比如上线前更看重业务影响面，迭代中期更看重出错概率。这个 Skill 帮我解决了一个老问题：以前排优先级全靠拍脑袋，现在至少有了一套可解释的规则。

3.5 测试数据构造 Skill：造出像真实业务的数据

测试数据构造是个体力活，尤其是需要关联多张表的时候。这个 Skill 的输入是表结构定义和关联关系，输出是一批符合业务规则的测试数据。它的核心能力是理解外键关联，保证造出来的数据在表之间是一致的，不会出现订单表里有用户 ID 但用户表里没有这个用户的情况。

参数包括schema（表结构）、relations（关联关系）、row_count（数据量）、data_style（数据风格，如正常、边界、异常）。我一般会造三批数据：一批正常数据用于主流程，一批边界数据用于边界测试，一批异常数据用于容错测试。这个 Skill 配合数据清理 Skill 一起用，效果最好。

3.6 用例评审 Skill：提前发现用例本身的问题

用例写完不代表就对了，评审环节经常能发现遗漏、冗余、描述不清的问题。这个 Skill 的输入是用例集合，输出是评审意见，包括缺失场景、重复用例、步骤不清晰、预期结果不可验证这几类问题。它的判断依据是一套我总结的用例质量检查清单，比如每条用例是否只有一个明确的验证点，步骤是否可独立执行，预期结果是否可观测。

我给它设了checklist参数，可以自定义检查项。默认清单包含 12 项检查，覆盖完整性、独立性、可执行性、可验证性。实测下来，这个 Skill 能发现大约 70% 的人工评审能发现的问题，剩下 30% 需要结合业务上下文判断，AI 暂时还替代不了。

4. 执行与校验层的 8 个 Skill 实操

4.1 接口断言 Skill：从响应里自动提取校验点

接口测试的核心是断言，但手写断言很繁琐。这个 Skill 的输入是接口响应和预期规则，输出是断言结果。它的聪明之处在于能自动识别响应里的关键字段，比如状态码、业务码、数据体里的核心字段，然后根据预期规则生成断言。我给它设了response、expected_rules、strict_mode三个参数，严格模式下任何未预期的字段变化都会报警，宽松模式只校验指定字段。

实操中我发现，接口响应里的时间戳、随机 ID 这类字段不能直接比对，所以 Skill 里内置了动态字段识别规则，遇到这类字段会自动跳过或做模式匹配。这个细节很关键，不然每次跑断言都会因为时间戳不同而失败。

4.2 响应比对 Skill：新旧版本接口的差异检测

做接口重构或者版本升级时，需要比对新旧接口的响应差异。这个 Skill 的输入是两个响应体，输出是差异清单，标注新增、删除、修改的字段。它的比对是递归的，能深入到嵌套结构里。参数包括old_response、new_response、ignore_fields（忽略字段列表）。

我一般用它来做回归测试，把上一个版本的响应存下来，新版本跑完后自动比对。这里有个技巧：忽略字段要配置好，像request_id、timestamp这种每次都变的字段必须忽略，否则差异清单里全是噪音。

4.3 数据一致性检查 Skill：跨表跨库的数据校验

数据一致性是很多缺陷的根源。这个 Skill 的输入是校验规则，比如“订单表的用户 ID 必须在用户表里存在”，输出是一致性检查结果。它支持跨表、跨库的校验，核心是把规则翻译成查询语句，然后比对结果。

参数包括rules（校验规则列表）、data_sources（数据源配置）、sample_rate（抽样比例）。全量校验太慢的时候，可以设置抽样比例，先抽 10% 看看有没有问题。我踩过的坑是：抽样校验通过不代表全量没问题，所以关键规则还是要全量跑，非关键规则可以抽样。

4.4 环境巡检 Skill：上线前的基础设施检查

每次上线前，我都会跑一遍环境巡检。这个 Skill 的输入是环境配置，输出是巡检报告，检查项包括服务是否可达、依赖是否正常、配置是否一致、磁盘空间是否充足。它的价值在于把零散的检查动作标准化，避免漏检。

参数包括env_config（环境配置）、check_items（检查项列表）、timeout（超时时间）。我一般会配置两套检查项，一套是基础检查，每次上线都跑；一套是深度检查，大版本上线才跑。基础检查控制在 2 分钟内完成，深度检查可以跑 10 分钟。

4.5 日志关键字监控 Skill：实时捕捉异常信号

测试执行过程中，日志里会冒出各种异常信号。这个 Skill 的输入是日志流，输出是异常事件列表。它的核心是关键字匹配加模式识别，关键字包括 ERROR、Exception、Timeout、Failed 这些，模式识别则用于捕捉一些没有明确关键字但明显异常的情况，比如响应时间突然飙升。

参数包括log_stream、keywords、patterns、alert_threshold（告警阈值）。我一般设置成 5 分钟内出现 3 次同类异常就告警，避免偶发噪音干扰。

4.6 接口性能基线 Skill：建立性能参考线

性能测试不是每次都做，但基线要一直维护。这个 Skill 的输入是接口列表和基线数据，输出是当前性能与基线的对比。它的作用是快速发现性能退化，比如某个接口响应时间从 200ms 涨到了 500ms，虽然还没到告警线，但已经偏离基线了。

参数包括api_list、baseline_data、deviation_threshold（偏差阈值）。我一般设置偏差超过 20% 就标记出来，人工确认是不是有问题。

4.7 测试数据清理 Skill：用完即清，避免污染

测试数据造出来容易，清理起来麻烦。这个 Skill 的输入是数据标识，输出是清理结果。它的核心是识别测试数据的特征，比如特定的前缀、特定的时间范围，然后批量清理。参数包括data_pattern、clean_scope、dry_run（试运行）。

我强烈建议开启dry_run模式，先看看会清理哪些数据，确认无误再真正执行。我早期有一次没开试运行，把一批生产数据误删了，虽然最后恢复了，但教训很深刻。

4.8 断言结果聚合 Skill：把零散结果汇总成结论

跑完一堆断言后，结果往往是零散的。这个 Skill 的输入是断言结果列表，输出是聚合结论，包括通过率、失败分类、失败趋势。它的价值在于让你一眼看清整体质量状况，而不是淹没在细节里。

参数包括assertion_results、group_by（分组维度）、trend_window（趋势窗口）。我一般按模块分组，看哪个模块失败最多；趋势窗口设成最近 7 天，看失败率是在上升还是下降。

5. 分析与归因层的 7 个 Skill 深度用法

5.1 日志聚类 Skill：把海量日志压缩成几类问题

日志分析最头疼的是量大。这个 Skill 的输入是日志集合，输出是聚类结果，把相似的日志归为一类，并标注每类的出现次数和代表样本。它的聚类依据是日志模板，把变量部分抽象掉，只保留固定结构。

参数包括logs、similarity_threshold（相似度阈值）、min_cluster_size（最小聚类大小）。相似度阈值我一般设 0.8，太低会把不同问题混在一起，太高又会把同一问题拆散。

5.2 失败归因 Skill：从失败现象倒推根因

这是我最喜欢的一个 Skill。输入是失败用例和对应的日志、响应，输出是可能的根因列表，按可能性排序。它的推理逻辑是：先看失败现象，比如超时、断言失败、连接拒绝，再结合日志里的线索，推断是环境问题、数据问题、代码问题还是用例问题。

参数包括failure_info、context（上下文，如最近变更）、history（历史相似失败）。我给它加了历史相似失败这个参数后，归因准确率明显提升，因为很多失败是重复出现的，历史记录里有现成的答案。

5.3 缺陷去重 Skill：避免重复提单

同一个问题被不同人提了多次，是测试协作里的常见浪费。这个 Skill 的输入是新缺陷描述和已有缺陷列表，输出是重复判定结果。它的判断依据是缺陷标题、复现步骤、错误信息的相似度。

参数包括new_defect、existing_defects、similarity_threshold。我一般设 0.75，这个阈值下误判率比较低。如果拿不准，Skill 会输出“疑似重复”，让人工确认。

5.4 缺陷严重程度评估 Skill：统一评级标准

不同人评严重程度的标准不一样，导致优先级混乱。这个 Skill 的输入是缺陷描述，输出是建议的严重程度等级，并给出理由。它的评估维度包括影响用户数、功能可用性、数据安全性、是否有绕过方案。

参数包括defect_desc、impact_scope、workaround（是否有绕过方案）。我把它接入缺陷管理系统后，新缺陷会自动带上建议等级，评审时只需要确认或调整，效率提升不少。

5.5 测试覆盖率分析 Skill：找出没测到的地方

覆盖率不只是代码覆盖率，还有需求覆盖率和场景覆盖率。这个 Skill 的输入是需求列表和用例列表，输出是覆盖率报告，标注哪些需求没有对应用例，哪些场景没有覆盖。

参数包括requirements、test_cases、coverage_type。我一般会同时看需求覆盖率和场景覆盖率，前者看有没有漏功能，后者看有没有漏场景。

5.6 回归范围推荐 Skill：精准圈定要回归的用例

每次发版都要回归，但全量回归太慢。这个 Skill 的输入是变更内容和用例库，输出是推荐的回归用例集合。它的逻辑是：根据变更影响的模块，找出关联的用例，再结合历史缺陷密度，优先推荐高风险用例。

参数包括changes、test_case_library、risk_weight。我实测下来，这个 Skill 能把回归用例数量压缩到全量的 20% 到 30%，同时漏测率控制在可接受范围内。

5.7 质量趋势分析 Skill：从数据里看质量走向

质量不是某一个时间点的快照，而是趋势。这个 Skill 的输入是历史测试数据，输出是质量趋势报告，包括缺陷发现率、缺陷修复率、用例通过率的变化趋势。它的价值在于提前发现质量下滑的信号。

参数包括historical_data、time_window、metrics。我一般看最近 4 周的趋势，如果缺陷发现率持续上升，说明代码质量在下降，需要提前介入。

6. 报告与协作层的 4 个 Skill 与组合玩法

6.1 测试报告生成 Skill：从数据到报告的一键转换

这个 Skill 的输入是测试执行数据，输出是结构化测试报告，包含测试概况、通过率、失败分析、风险提示、建议。它的模板可以自定义，我一般用两套模板，一套是日常迭代的简版，一套是版本发布的详版。

参数包括test_data、template、audience（受众）。受众这个参数很实用，给开发看的报告侧重技术细节，给产品看的报告侧重业务影响，给管理层看的报告侧重风险和结论。

6.2 缺陷摘要 Skill：把长描述压缩成一句话

缺陷描述往往很长，同步给相关方时需要摘要。这个 Skill 的输入是缺陷详情，输出是一句话摘要，包含问题现象、影响范围、当前状态。参数包括defect_detail、max_length、focus（关注点）。

我一般把摘要控制在 50 字以内，方便在群里快速同步。focus 参数可以指定关注现象、影响还是进度，不同场景用不同关注点。

6.3 进度同步 Skill：自动生成站会发言

每天站会都要说昨天做了什么、今天做什么、有什么阻塞。这个 Skill 的输入是任务列表和状态，输出是站会发言稿。参数包括tasks、date、style（风格，简洁或详细）。

这个 Skill 帮我省了不少时间，以前站会前要花 10 分钟整理，现在一键生成，稍微改改就能用。

6.4 知识沉淀 Skill：把测试经验变成可复用文档

测试过程中积累的经验，如果不沉淀就浪费了。这个 Skill 的输入是测试记录和问题解决过程，输出是知识文档，包含问题描述、排查过程、解决方案、预防措施。参数包括records、doc_type、tags。

我一般把这类文档按模块和问题类型打标签，方便后续检索。这个 Skill 配合前面的归因 Skill 一起用，能把一次性的排查经验变成团队资产。

6.5 组合玩法：把 Skill 串成流水线

单个 Skill 好用，组合起来更强。我常用的一个流水线是：需求拆解 → 边界用例生成 → 用例评审 → 接口断言 → 失败归因 → 测试报告生成。这条流水线跑下来，从需求到报告基本能自动化 60% 到 70% 的工作量。

组合的关键是接口对齐，也就是上一个 Skill 的输出格式要能被下一个 Skill 直接消费。我在设计每个 Skill 的时候，都会预留标准化的输出结构，比如用例统一用 JSON 格式，包含 id、title、steps、expected 这几个字段。这样组合的时候不需要额外转换。

提示：组合流水线不要一上来就搞太长，先从两三个 Skill 串起来，跑通了再逐步加长。我见过有人一上来就串了十个 Skill，结果中间任何一个环节出问题，整条线就断了，排查起来很痛苦。

7. 实操中踩过的坑与常见问题排查

7.1 Skill 输出不稳定的三种典型原因

第一种是输入格式不统一。同一个 Skill，你这次传的是纯文本，下次传的是 JSON，输出自然不一样。解决办法是给每个 Skill 定义严格的输入 schema，传之前先校验。

第二种是参数缺失。有些参数看起来可选，但实际上不传会导致 AI 自由发挥。我的做法是把关键参数设为必填，宁可多填几个，也不要让 AI 猜。

第三种是模型版本变化。同一个 Skill，换个模型版本，输出风格可能就变了。所以我在 Skill 配置里锁定了模型版本，升级前先跑回归测试。

7.2 常见问题速查表

7.3 独家避坑技巧

第一个技巧：给 Skill 加“自检”步骤。在输出最终结果前，让 AI 自己检查一遍格式和逻辑，发现问题就重试。这个自检步骤能过滤掉大部分低级错误。

第二个技巧：保留 Skill 的调用日志。每次调用的输入、输出、耗时都记下来，出问题的时候能快速定位。我用这个日志发现过好几次参数配置错误。

第三个技巧：定期回归测试 Skill。模型会更新，业务会变化，Skill 也要跟着调整。我一般每个月跑一次 Skill 回归，确保它们还在正常工作。

第四个技巧：不要过度依赖单一 Skill。再好的 Skill 也有边界，关键决策还是要人工把关。我见过有人完全信任 AI 生成的用例，结果漏了核心场景，上线后出了大问题。

8. 我个人的一些实际体会

这套 Skill 工具箱我攒了大概半年多，从最开始的三五个，慢慢加到现在的 25 个。最大的感受是，Skill 的价值不在于数量，而在于你能不能把它们真正用起来。我见过有人收集了几百个 Prompt，但日常还是手动干活，因为那些 Prompt 没有形成工作流。

另一个体会是，Skill 的设计要跟着业务走，不能为了技术而技术。我早期设计过一个很复杂的归因 Skill，用了很多推理链，结果实际用的时候发现，大部分失败原因就那么几类，简单的规则匹配就够了。后来我把它简化了，反而更好用。

还有一点，Skill 是需要维护的。业务变了、接口变了、模型变了，Skill 都要跟着更新。我现在每个月会花半天时间做 Skill 维护，检查有没有失效的、有没有需要优化的。这个投入是值得的，因为一旦 Skill 失效而你没发现，它产生的错误结果可能比不用还糟糕。

最后分享一个小技巧：新手不要一上来就追求大而全的 Skill，先从最小的动作开始，比如“把这段日志里的错误提取出来”，跑通了再逐步加功能。Skill 的成长是迭代出来的，不是设计出来的。我现在这 25 个 Skill，每一个都经历过至少三次改版，才变成现在稳定可用的样子。