从本篇教程开始我们将沿着软件测试全流程逐环节、逐步骤深度拆解系统学习如何借助AI Agent Skill为测试工作的每个核心节点赋能提效。我们的第一站便是软件开发全流程的起点 ——需求分析阶段。很多人觉得测试是从开发完成后才介入可实际上需求分析恰恰是整个项目里风险最高、最容易埋下隐患的环节。行业里一直有一个非常普遍共识「如果需求理解错了后面的测试、设计和开发都是白费」。比如需求模糊、场景缺失、逻辑冲突、边界条件遗漏甚至很多线上缺陷根源都可以追溯到需求环节。正因如此一名专业、成熟的测试工程师绝不能只做被动找 Bug 的执行者我认为至少要具备半个产品经理的业务思维与需求拆解能力。而学会在需求分析阶段利用自定义 Agent Skill 实现需求结构化拆解、用户故事生成、风险点排查、场景补全正是测试工程师从 “功能测试执行者” 迈向 “质量把控者” 的关键一步。即便现实工作当中测试人员很多时候可能无权直接修改需求文档但掌握了AI赋能需求分析工作一方面可以开拓业务测试思维、另一方面可以作为测试人员参加需求评审的有力武器。当然这里有一个需要澄清的地方当下利用 AI 赋能软件测试实现路径其实非常多但Agent Skill 是新手入门最优先掌握、落地成本最低、复用性最强的形态。它可以把固定的工作流、拆解逻辑、评审规则封装成可一键调用的标准化技能一次配置、长期复用完美适配测试岗位大量重复性、流程化的工作场景也是目前企业落地 AI 测试工作流的主流方向。同时我也想提醒大家不要陷入认知误区不要简单把 AI 测试、AI 赋能测试等同于只会使用 Agent Skill。Skill 是工具、是手段而真正的核心是测试思维、业务理解与质量把控逻辑。我们要做的是用 Skill 解放重复劳动把更多精力投入到业务深度分析、风险挖掘、质量策略设计上让 AI 成为测试工程师的得力搭档而非替代者。本篇教程原文出自于「狂师. AI进化社」篇符有限本文内容只是截取教程中很一小部分原教程1/3的内容不到完整详细的保姆级实操教程可在「狂师 . AI进化社」中学习。1. 需求分析阶段1.1 传统需求分析的核心痛点在软件项目正式启动、进入研发实施前需求分析是保障产品方向对齐、开发范围可控、避免后期返工的核心前置环节。行业通用的需求分析的传统流程大致如下收集原始需求 → 梳理整理需求文档 → 组织多方需求评审 → 评审问题优化迭代 需求最终确认评审不通过评审通过收集原始需求梳理整理需求文档组织多方需求评审需求优化迭代 最终确认而回到真实的日常项目场景里我们会发现一个普遍痛点业务方、产品或客户给出的原始需求大多口语化、碎片化、高度简略往往只描述核心操作缺少约束条件、边界场景和异常逻辑。就像我们熟悉的电商购物车模块业务方通常只会这样简单表述用户可以浏览商品将商品添加到购物车从购物车中移除商品修改购物车中商品的数量查看购物车中的商品列表和总金额清空购物车。这样一句话看似把功能讲清楚了但只停留在核心功能动作层面信息极度单薄。在敏捷开发体系中把这类模糊的诉求拆解成一个个可落地、可开发、可测试的最小单元这个最小单元又常被称之为用户故事。一份规范的需求用户故事通常需要具备完整结构化信息用户故事编号、功能概述、参与角色、前置条件、主流程、替代流程、后置条件、异常场景等。如果完全依靠人工把一段大白话式的原始需求逐条梳理、拆分、补全、格式化整个过程模板固定、步骤机械、重复性极高。我们不仅要手动梳理字段、规范编号还要主动脑补库存不足、商品下架、未登录、数量为 0、网络异常等各种隐藏场景不仅耗时耗力、效率低下还极易遗漏关键边界与异常情况。很多后期开发 bug、测试遗漏点、线上问题根源都是人工拆解需求时考虑不全这也是产品经理、业务测试工程师日常最消耗精力、最容易出错的环节。也正因如此这类固定流程 标准化输出 高遗漏风险的工作恰好是最适合交给 AIAgent Skill 去自动化完成的典型场景。1.2 为什么这个环节适合 AI 辅助需求分析工作有三个特点使它天然适合 AI 参与「特点一输入是自然语言输出也是自然语言」需求分析不涉及代码、图表等需要严格语法的产物。输入是自然语言描述的需求输出也是自然语言描述的用例。这恰好是 AI 最擅长的领域。「特点二核心工作是结构化和补全」从模糊需求到结构化详细需求核心工作是两件事「结构化」把散乱的信息组织成标准格式和「补全」发现遗漏的场景和边界条件AI 对这类工作非常在行。「特点三验证成本低」AI 生成的用例是否合理业务人员可以直接阅读判断。不像设计模型或代码那样需要专业背景才能评估「需求用例的验证门槛相对较低」。需求分析本质是信息提取、结构化整理、逻辑补全、格式标准化、反复迭代的工作而规则明确、重复性高、模板固定、容易遗漏细节恰好是 AI 最擅长的场景因此需求分析阶段工作非常适合用 AI 辅助提效。1.3 AI 赋能需求分析 操作方法下面先讲解一下AI 赋能需求分析的操作思路具体Agent Skill开发实现请参考1.4 章节内容。后续本文涉及到讲解操作思路和具体Skill开发实现都是基于shop-lab这个电商实战项目为基础的。第一步从原始需求提取用户故事「场景」产品经理给了一段需求描述或者一句话需求。「原始需求」打开shop-lab项目需求文档以shop-lab这个项目需求文档中注册功能为例功能描述用户通过填写手机号/邮箱、密码等信息完成注册。用户流程进入注册页面 → 填写注册信息 → 验证手机号/邮箱 → 设置密码 → 完成注册。详细说明• 支持手机号和邮箱两种注册方式• 注册时需要进行验证码验证• 密码强度要求至少8位包含字母和数字• 注册成功后自动登录并跳转到首页「Prompt 提示词」打开Claude Code或其它任意AI 编程工具比如Cursor、Trae 皆可输入提示词。(需要注意刚开始建议先用提示词测试一下效果不要直接一上来就直接封装成skill)Claude CodeAI会根据提示词中的要求自动拆解需求用户故事并对每个用户故事生成完整的需求结构化描述生成的效果如下「人的判断」检查需求用户故事划分是否合理、是否必须。比如AI 可能会生成「用户通过手机号注册 」和「户通过邮箱注册 」你需要根据业务需要决定是全部需要还是仅保留其中某一个。第二步审查是否有遗漏场景AI 能按照标准格式生成用户故事但它的更大价值在于「发现人工容易遗漏的场景」。「Prompt 提示词」基于以下xxx (比如购物车)模块的用户故事列表请检查是否有遗漏的场景。 特别关注以下方面 1. 边界条件如数量上限、金额上限 2. 异常场景(如并发冲突、数据不一致) 3. 业务规则(如库存扣减时机、价格变动处理 4. 非功能性需求 (如性能、安全性) 请列出你认为遗漏的场景并说明理由。AI 可能会指出以下遗漏遗漏场景类型理由商品下架后购物车的处理业务规则商品下架后购物车中的商品应该如何展示和处理是否允许结算价格变动后的处理业务规则商品价格变动后购物车中已添加的商品价格是否同步更新购物车数量上限边界条件购物车是否有商品种类数量上限单个商品是否有数量上限并发添加同一商品异常场景用户在多个终端同时添加同一商品到购物车如何处理购物车过期机制业务规则购物车是否有过期时间长期未结算的购物车如何处理结算缺失用例原始需求提到查看总金额但缺少从购物车到结算的用例用户登录/注册缺失用例多个用例的前置条件要求用户已登录但缺少登录用例这些遗漏中有些是关键的如商品下架处理、结算有些可能超出当前范围如并发处理、过期机制。「人的判断」决定哪些遗漏需要纳入当前需求哪些记录为已知风险哪些不需要处理。第三步生成完整的需求用户故事在确认用户故事范围后让 AI 一次性生成所有需求的完整描述。「Prompt提示词」基于以下已确认的需求故事列表请生成完整的需求用例文档。 对每个用户故事确保替代流程覆盖所有已识别的异常场景。 请以表格形式输出每个用例。AI 会生成完整的、经过修订的需求用户故事文档包含了补充的业务规则和边界条件。第四步人机协作的迭代优化AI 生成的需求用户故事不太可能一次就完美一定是需要人工介入、审查调整的。常见的调整包括「调整一合并或拆分用例」AI 可能过度拆分。比如把「浏览商品列表」和「查看商品详情」拆成两个用例但你觉得它们属于同一个用户目标可以合并。「调整二调整替代流程的粒度」AI 可能会列出过于细致的异常场景。比如「网络超时」这种通用异常不一定要在每个用例中都列出。「调整三补充业务上下文」AI 不了解你的项目背景。比如你的购物车是给 B 端客户用的可能有「批量导入商品到购物车」的需求这需要你来补充。一般这种迭代通常 2-3 轮就能得到高质量的详细需求文档。1.4 需求分析Agent Skill开发前面我们已经分析过需求分析本质上是信息提取、结构化整理、逻辑补全、格式标准化、反复迭代优化的工作。这类任务往往特点就是规则清晰明确、重复性强、输出模板固定、人工极易遗漏细节场景恰恰是大模型与 Agent 最擅长处理的场景因此在需求分析环节引入 AI 辅助能极大降低人工成本、减少漏项、提升需求拆解质量。同时需求拆解、用户故事生成这类流程高度标准化完全可以封装成可复用的 Agent Skill实现一次配置、多项目通用不用每次新项目都重复写提示词、重复梳理格式大幅提升测试工程师的长期工作效率。但这时又会引出一个大家都会遇到的实际问题在做 AI 辅助需求分析时我们到底是直接使用开源社区现成的通用 Skill还是根据自身业务和输出规范自建一套专属的 Skill先说结论在真实项目落地过程中我有一个非常深刻的体会不管是直接使用官方现有 Skill还是第三方现成技能想要找到一个完全贴合自己项目规范、工作流习惯、输出格式要求的成品 Skill几乎很难实现。通用型 Skill 往往通用性太强、针对性不足要么输出格式不匹配团队标准要么缺少我们测试视角需要的前置条件、异常场景、风险点无法直接拿来用于需求评审、用例设计。因此最优解永远是基于自身真实的任务要求从零打造属于自己的专属 Skill。当然也不用完全从零白手起家更高效的方式是以现有成熟 Skill比如官方Skill、skill‑creator为基础进行二次开发、定制改造保留成熟的执行逻辑再叠加我们测试行业专属的拆解规则、用户故事模板、编号规范、异常检查逻辑既省时省力又能高度贴合个人工作流。为了让大家清晰掌握落地方法我会分别演示直接查找现有 Skill和从零自建专属 Skill。原教程非常详细篇符太长就不展示完整的Agent Skill开发过程细节有需要学习的同学可以在「狂师. AI进化社」中查看完整实战开发教程。3万字保姆级手把手喂饭教程总的来说在需求分析阶段我们分为了两个Agent Skill。1. Skill 技能开发req‑to‑user‑story下述过程为极简过程完整实战开发教程可移步到「狂师. AI进化社」中查看。req‑to‑user‑story用于将原始需求转化成标准化的需求用户故事。生成详细需求文档skill创建完成后claude code还会自动帮我们生成skill 测试用例进行skill效果验收并且最后还会对各个测试用例进行评分与生成评审页面。SKILL.md内容Skill技能制作好了之后建议先退出claude code重新进入一次这样在Claude code中后续输入/req‑to‑user‑story才能正常识别出来。调用/req‑to‑user‑story直接传入需求文档地址用shop-lab实战电商项目文档中的一个真实需求来验证一下生成效果看是否能正常读取出需求文档内容并且基于需求文档内容拆解用户故事。上传需求文档调用/req‑to‑user‑story从结果中可知能按预期读取到需求文档中的内容并拆解出用户故事。执行完成后会自动在原始的需求文档目录下生成一份带有后缀比如需求规格文档-用户故事版.docx的文档。打开文档可以人工审查一下内容是否符合预期。新生成的 Word 版需求用户故事大家可以结合团队规范、项目要求或个人工作习惯进一步调整模板结构、字段顺序、内容格式、编号规则、异常场景维度等。后续只要把优化后的规则、格式、约束条件同步更新到req‑to‑user‑story这个 Skill 中后续一键调用时AI 就会直接按照最新标准输出内容实现一次优化、长期复用、全程统一不用每次手动修改格式彻底解放重复性整理工作。2. Skill 技能开发review-user-stories很多同学在用上一步的req‑to‑user‑story拆解完用户故事后就直接结束了需求分析环节。但这里有一个关键问题需要我们认清req‑to‑user‑story是对所有需求一视同仁、统一拆解不会区分需求的重要程度、业务优先级。可在真实项目里需求一定有主次之分核心流程、高风险模块需要我们投入更多精力重点深挖、补全边界与异常场景这也对应我们前面 1.3 章节提到的第二步审查是否有遗漏场景。所以本着对需求拆解认真负责的态度我们还需要针对重点用户故事做二次深度校验检查是否存在场景遗漏、逻辑缺失、约束条件不全等问题。讲到这里大家又会遇到一个新的抉择针对重点需求做遗漏场景检查补充我们是在原有req‑to‑user‑story基础上迭代优化还是新建一个独立的 Skill呢先说结论我的个人建议从实战经验角度出发我更推荐新建一个独立的 Skill。原因很简单1、拆开两个技能环节职责清晰req‑to‑user‑story负责批量、快速、标准化拆解基础用户故事新建技能专门做重点需求深度场景校验、风险补充、遗漏点排查2、解耦更灵活后续想单独优化场景检查规则不用改动基础拆解逻辑避免越改越臃肿3、工作流更清晰先批量生成 → 再重点校验符合真实测试工作习惯。如果你实在把握不准还可以问一下AI 让AI 帮我们对比一下这两个方案从AI 的对比结果可知方案一在现有 skill 上扩展即在 SKILL.md 中新增一个「审查模式」分支检测到用户输入是已生成的用户故事时自动切换到审查逻辑。 但这种方式会带来的问题很明显一份文件将两个截然不同的工作流混在一起SKILL.md 会变得特别臃肿。且description 需要同时覆盖「生成」和「审查」两种意图容易误触发。方案二新建一个独立的 skill推荐如 review-user-stories专门负责对已有用户故事进行遗漏审查。一个 skill 负责「生成」一个负责「审查」且两个skill 各自独立演进互不影响且可审查任何来源的用户故事手写的、其他工具生成的不依赖第一个 skill。很显然AI的建议和我的建议是一致的所以我们最终选择方案二新建独立Skill。很快review-user-storiesskill 就创建好了接下来我们可以直接用/review-user-stories方式来调用这个技能。技能创建好之后建议大家一定要仔细认真检查一下SKILL.md内容。接下来我们来验证一下。输入/review-user-stories后面带上待审查的文档路径比如将上一步我们生成好的需求用户故事文档路径传进来。此处我甚至都懒得加过多的文字描述这里严谨一些的话其实还可以补充说明一下你要检查的内容范围。调用/review-user-stories这个技能后会先读取文档内容然后开始系统性审查审查工作主要从边界条件、异常情况、业务规则、非功能性需求等方面进行审查最终还会生成一份独立的需求审查报告。打开审查报告从审查报告文档中可知文档采用内嵌批注式每条原始用户故事完整保留且在原有的用户故事后增加了审查发现以黄色底纹表格展示与原始内容在视觉上明确区分。文档末尾还增加了总体评估汇总、交叉审查、建议新增故事等建议补充内容。有了这份文档后我们就可以基于这份完整的需求用户故事进行后续的人工审查与补充了。到此我们在第一个阶段利用Skill赋能需求分析工作就先到这里。如果你还想优化需求分析其它方面的工作思路和上述是完全一样的就不再赘述了。1.5 Skills 项目源码后续「AI 进化社」中所有实战演练创建生成的skill会统一上传到github学员可按需自取。如果你需要安装使用这些skill将需要的 Skill 目录复制或克隆到你的 Claude Code 技能目录下即可使用。# 克隆仓库gitclone gitgithub.com:xxx/skills.git# 将技能复制到你的项目中使用cp-rskills/req-to-user-story /path/to/your/project/.claude/skills/cp-rskills/review-user-stories /path/to/your/project/.claude/skills/也欢迎通过 PR 提交新的 Skill 或改进现有 Skill。1.6 小结本文演示了 AI 如何辅助需求分析工作「AI的核心价值」把模糊的自然语言需求快速转化为结构化的需求用例并发现人工容易遗漏的场景。「最佳工作流」分步执行 → 逐步确认 → 迭代优化。AI 负责结构化和补全人负责业务决策和优先级判断。需求分析完成后下一步就是基于需求文档识别测试要点生成测试用例了。本篇教程原文出自于「狂师. AI进化社」本文内容只是截取教程中很一小部分原文内容的1/3不到完整详细的保姆级实操教程可在「狂师 . AI进化社」中学习。