目录
一、行业在变，但很多人还没意识到变化的方向
二、变化的本质：不是写得更快，而是经验变得可复用
三、核心技术拆解：Skill不是提示词，是工作流
四、对照组：手撸用例 vs Skill生成的真实差距
五、工程落地：你的团队也能复制这套逻辑
六、下一站：测试工程师的核心竞争力在变
一、行业在变，但很多人还没意识到变化的方向
去年年底，跟几个测试负责人吃饭，聊到一个很有意思的现象。
话题很统一：团队里有人已经在用Claude Code做自动化测试了，还有人专门写了Skill来生成测试用例。但更多的人，还在手点。
不是不会，是还停留在“AI能帮写测试用例吗”这个讨论阶段。
做技术的应该能感受到——当大部分人还在讨论“能不能”的时候，第一批实践者已经跑出结果了。GitHub Copilot Workspace上线后，有一个数据值得关注：企业级代码库中AI生成的端到端测试用例通过率只有31%，剩下69%里有一半逻辑错误，一半直接崩CI/CD管道。AI生成代码不行，不是AI不行，而是用的人没把它当成一个工程问题在解决。
人的问题在于：需求来了，七八十页的文档，加一堆原型图。边界值一个个算，场景流慢慢梳理，XMind一个节点一个节点敲。一个需求快的一两小时，慢的大半天就没了。
这已经不是一个效率问题了，这是人的脑力和工作时间被低价值重复劳动消耗的典型症状。
二、变化的本质：不是写得更快，而是经验变得可复用
说到AI测试，很多人第一反应：AI能生成用例吗？能写脚本吗？能操作浏览器吗？
回答都能。但这个问题本身，指向的是错的。
真正该问的不是“AI能不能做某件事”，而是“我们怎么把测试这件事封装成AI可以执行的任务”。
今天AI测试领域正在发生一个根本性变化：从“AI写脚本”转向“Agent+MCP+Skills”智能体系统。过去做接口自动化，人读Swagger → 人分析场景 → 人写脚本 → 人执行 → 人看报错 → 人改代码 → 人回归。每一环都手动推。现在Agent模式下，AI可以规划、生成、执行、校验、修复、报告，串成一个完整闭环。
核心不在于模型自己会不会测试，而在于你有没有把测试能力工程化封装出来。
一个资深测试看到接口文档，脑子里会过这些：参数为空要测吗，状态码异常要测吗，鉴权失败要测吗，接口依赖关系怎么处理，前置数据从哪来。这些判断很值钱，但很难复用。新人学得慢，团队沉淀也难。Agent+MCP+Skills的价值，就是把经验拆成可调用、可组合、可复用的能力。
本质不是AI替代人，是显性路径替代隐性经验。
可以被截图传播的观点句：AI测试不是把需求丢给大模型，而是把测试流程拆成模型能理解、工具能执行、结果能验证的工程链路。
三、核心技术拆解：Skill不是提示词，是工作流
Skill，Claude在2025年10月推出的功能。很多人以为是又一个“AI新特性”，但其实是把提示词从“瞬态输入”变成了“复用资产”。
别用错位简化理解它。简单说，Skill就是在~/.claude/skills/目录下放一个Markdown文件，把常用提示词、工作流程、代码规范都写进去。需要的时候@skill一下就能调用。
手写提示词的痛点很明显。每次从文档复制粘贴，一天下来半小时没了。长对话到20轮，Claude Code会忘你最初提过什么。Skill一次性解决了这些：Git管理版本、团队仓库同步、对话再长也不会失效。
结构上，Skill采用“三层渐进式披露”。Claude启动时只预加载技能名称和描述，几乎不占上下文窗口。判断相关时再加载完整指令，必要时调脚本。所以Skill里塞再多内容，也不会撑爆上下文。
那Skill和MCP什么关系？MCP是协议，管AI怎么以统一方式调用外部工具和服务。Skill封装做事方法——教AI怎么处理特定任务。二者配合使用，不是二选一。
一个测试用例生成Skill典型有五个模块：多模态理解、质量预审、测试设计方法叠加、记忆进化，以及输出格式化。按顺序执行，每一步的输出是下一步的输入。不是简单需求扔给LLM出用例。
这四个测试设计方法的核心顺序：
等价类划分：把输入分成有效和无效区间，不遗漏不重叠
边界值分析：上限、下限、临界点，精确计算，不是靠感觉“试试边界”
场景法：基本流、备选流、异常流，覆盖业务主干和每条分支
错误推测：高风险模块重点补特殊字符、极端值、并发场景
很多AI工具输出的用例，本质就是把需求复述一遍，加个“验证一下是否正确”。这不叫测试设计，叫翻译。
四、对照组：手撸用例 vs Skill生成的真实差距
一份中等复杂度的需求，人工写用例快的两小时，慢的大半天。Skill在3分钟内生成完整结构用例。
但速度不是核心差别。
真正的差别在于：一致性和覆盖面。
人工的问题不在能力，在一致性的失效。场景法里基本流、备选流、异常流，不是不知道，是赶工时容易漏。边界值上限下限临界点，不是不会算，是项目多了就懒得每个需求都从零算一遍。
Skill一旦写好，每次调用逻辑一致、覆盖维度固定，不会因为今天状态差而漏测。
像OpenTest这样的框架已经把全流程打透了：捕获登录态 → 解析需求文档 → 生成测试用例 → 执行测试 → 生成报告。在Cursor、Claude Code、OpenClaw上都能直接跑。
最值得关注的不是“AI能不能做”，而是“做出来的质量已经逼近甚至超过平均水平”。深圳一家厂商的AI测试产品，AI生成测试案例采纳率接近60%。过半数用例AI生成直接可用，测试设计的工作就从“从零设计”变成“审核+补充”。
可以被截图传播的观点句：测试设计不是翻译需求，而是构造有效验证。
五、工程落地：你的团队也能复制这套逻辑
如果你还在手点，代码层面上Skill门槛其实很低。聊几个实践落地的关键点。
上下文：比模型强不强重要得多。 很多人踩的坑是：找了个最新的大模型，API调上去，输出牛头不对马嘴。模型强不代表能理解你的业务。Skill把提示词标准化、把流程固定、把业务上下文作为参数传入，比换模型成本低得多，效果稳定得多。测试流程拆成模型能理解、工具能执行、结果能验证的工程链路，才是落地的正确姿势。
多模态：图片里读场景。 现实里的需求不总是规范的Word文档，有时是Figma截图、原型图，甚至业务流程图。Skill需要内置视觉理解协作者，直接识别图片中的用户流、页面跳转、数据流向。光靠文字需求生成用例，场景覆盖率会直接打折扣。
质量预审：用三层校验机制让用例一次成型。 最怕AI胡诌——提示词写得再仔细，模型也会在某些点上放飞。一个可行的做法是：生成用例集后，用质量预审模型自动扫描——输入逻辑自洽性、与需求文档的匹配度、场景完整性。经审核的最终输出，基本可以做到不依赖人工再修补就能进入正式用例库。
Skill第一个版本，先做你最熟悉的模块。 不必一上来就要覆盖全量。选个需求稳定、边界清晰的功能模块打样。调试Skill比调试普通提示词难一点，因为多层调用链路。但这正是工程能力的分水岭。Skill模板放团队仓库，Git管理版本，新人入职就知道“那边有我们团队封装好的测试用例生成Skill”，比手写任何培训文档都高效。
未来测试工程师的分水岭，不是会不会用AI，而是能不能把测试经验封装成可复用的工程能力。Skill本质上就是在干这件事。
六、下一站：测试工程师的核心竞争力在变
OpenClaw和Cursor、Copilot、Claude Code不是替代关系，是不同层级的工具。Copilot/Cursor：写代码的助手，AI辅助，人主导。Claude Code：理解和修改代码的助手，人驱动流程，AI执行。OpenClaw：任务执行型Agent，AI主导，人给目标。
这个分层正全面映射到测试领域。
Skill代表的不是“生成用例更快”，而是测试经验封装成可复用能力的工程范式。当你所在团队能把测试设计、脚本生成、执行校验、失败修复串成闭环，还能沉淀到Skill里被反复调用时，测试就不再是手工作坊了。
测试设计从隐性知识变成能配置、能复用、能持续迭代的工程资产。
这跟“AI会不会取代测试工作”没直接关系。真正的分水岭是：当团队在Skill里沉淀了100个测试场景包，当你所在的行业测试用例生成效率已经从“小时”进入“分钟”区间，你是依然在复制粘贴提示词的那个人，还是已经在设计下一版测试系统的Skill的那一个。
我很好奇的是：你现在的系统中，有没有一个可以沉淀测试经验、并且能被AI直接调用执行的反馈闭环？
