上个月，团队里一个测试新人跑来找我，问了一个很具体的问题。
“哥，我看你们都在聊Skill，我也想写一个。但我看了一圈案例，有用例生成的、有需求拆解的、有场景补全的，每个看起来都挺复杂。我该从哪个开始？”
我说：“你先别想着写用例生成。那个Skill需要你懂业务规则、懂断言分层、懂边界条件，你写出来大概率跑不通，跑不通你就放弃了。”
他问：“那我写什么？”
我说：“写缺陷报告生成。 规则最死，见效最快。你今天下午就能跑通，明天就能用上。”
一、为什么缺陷报告生成，是新手最好的“第一个Skill”？
因为它的输入和输出都是确定的。
你给AI一句口语化的描述——“登录页点提交没反应，控制台报了个错”——它输出一份标准格式的Bug报告：标题、复现步骤、预期结果、实际结果、环境、优先级、附件说明。
这件事不需要AI“理解业务规则”，不需要它“判断边界条件”，不需要它“设计测试策略”。它只需要把口语化的信息，填进一个固定的模板里。
规则越死，AI越不容易跑偏。 你用用例生成做第一个Skill，AI可能给你生成一堆表面用例，你改到崩溃。你用缺陷报告生成做第一个Skill，AI输出的东西你一眼就能看出对不对——因为格式是固定的，填错了你马上就知道。
见效快，是新手坚持下去的唯一动力。
二、先看一个真实的对比
你收到的原始信息（口语化描述）：
“用户反馈登录页点提交没反应，我复现了一下，确实没反应。控制台报了个错，好像是跨域相关的。用的Chrome，测试环境。”
你手工写的Bug报告（耗时约12分钟）：
标题：登录页点击提交按钮无响应，控制台报CORS错误复现步骤：
打开测试环境登录页
输入正确账号密码
点击“提交”按钮预期结果：登录成功，跳转首页实际结果：页面无任何响应，控制台报CORS错误环境：Chrome最新版，测试环境优先级：P1附件：控制台截图
用Skill生成（耗时约15秒）：
你把那段口语化描述粘进去，Skill自动输出上面那份完整报告。你只需要花1分钟检查一下环境字段和优先级对不对，剩下的10分钟省下来了。
一个Bug省10分钟，一天提5个Bug，就是50分钟。一个月省下来的时间，够你把用例生成Skill也写出来了。
三、SKILL.md怎么写？直接复制这个模板
name: bug-report-generator
description: 将口语化的缺陷描述转换为标准Bug报告。当用户提到“提Bug”“写缺陷报告”“生成Bug单”时触发。
when_to_use: 测试人员需要将发现的问题整理成标准缺陷报告时使用。
任务
将用户提供的口语化缺陷描述，转换为团队标准格式的Bug报告。
输出格式（严格按以下结构）
标题
[模块] 问题简述（不超过30字）
复现步骤
- [第一步操作]
- [第二步操作]
- [第三步操作]
预期结果
[系统应该表现出的正确行为]
实际结果
[系统实际表现出的错误行为]
环境
- 浏览器/设备：[从输入中提取，未提供则标注“需确认”]
- 环境：[测试/预发/生产]
- 版本号：[如提供则填写，未提供标注“需确认”]
优先级
P0/P1/P2（根据影响范围判断，判断依据写在括号里）
附件说明
[需要补充什么截图/日志]
规则
- 输入中没提供的信息，标注“需确认”，不要编造
- 复现步骤必须是可执行的，不能写“复现一下”
- 实际结果要写“系统做了什么”，不是“我觉得有问题”
- 优先级判断依据必须写出来，不能只给结论
三个关键设计：
第一，强制标注“需确认”。 输入里没说环境，AI就写“需确认”，不要自己编一个“Chrome最新版”。编造信息比漏信息更危险，因为它看起来是真的。
第二，复现步骤必须可执行。 不能写“复现一下登录问题”，要写“1. 打开登录页 2. 输入账号密码 3. 点击提交”。Agent不知道“复现一下”是什么意思。
第三，优先级要给判断依据。 不能只写“P1”，要写“P1（影响核心登录流程，但非全量用户）”。判断依据是给人复核用的，结论是给系统用的。
四、怎么用？三个字：直接调
Skill写好了，在Claude Code里输入：
/bug-report-generator 用户反馈登录页点提交没反应，我复现了一下确实没反应，控制台报了个跨域相关的错，用的Chrome，测试环境
Agent会自动加载Skill的规则，输出一份结构化Bug报告。
你拿到报告后，做三件事：
检查“需确认”的字段，补上真实信息
检查优先级判断依据，确认是否合理
补上截图附件
整个过程从12分钟压缩到2分钟。
五、进阶：让Skill和缺陷系统打通
基础版跑通之后，可以加一步：把生成的报告直接推送到Jira/TAPD。
在Skill的scripts/目录放一个create_issue.py，Agent生成报告后调用这个脚本，自动在缺陷系统里创建工单。
步骤3：创建缺陷工单
运行 python scripts/create_issue.py --project TEST --summary "<标题>" --description "<报告正文>" 在缺陷系统创建工单，返回工单号。
这一步的价值不是“省了复制粘贴”，是让“提Bug”这件事从“人操作”变成“Agent操作”。 你只需要审核Agent生成的报告，确认后它自己创建工单。
六、避坑指南
坑一：一开始就想让AI“智能分析根因”。 缺陷报告生成Skill只做“格式化”，不做“根因分析”。根因分析需要看代码、看日志、看调用链路，那是另一个Skill的事。第一个Skill要窄，要浅，要跑得通。
坑二：输入太模糊。 你给AI一句“登录有问题”，它只能输出一份全是“需确认”的报告。至少给三样东西：什么操作、什么结果、什么环境。
坑三：不检查“需确认”字段。 AI标注“需确认”的地方，是你没提供的信息。直接提交上去，开发会回来问你“到底什么环境”。那两分钟的检查，不能省。
坑四：优先级只给结论不给依据。 AI写“P1”，你不写判断依据，开发会问“为什么是P1不是P2”。依据是给复核用的。
坑五：写完不迭代。 每发现一次AI漏掉的字段，就补进模板。三个月后，你的Skill会比你记忆里的格式更全。
最后
测试人的第一个Skill，不要选最难的，要选最“死”的。
缺陷报告生成规则最固定，输入输出最明确，跑通它只需要一个下午。跑通之后，你才有信心去写用例生成、需求拆解、场景补全那些更复杂的Skill。
而且它见效最快。你明天提Bug的时候就能用上，省下来的时间，够你学下一个Skill。
从最死的地方开始，从最快见效的地方开始。 这是写Skill，也是做任何事的第一原则。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
