夜雨聆风
故事是这样的。
上周跟一个测开同学聊天，他打开桌面给我看。十几个自动化脚本半成品，Postman 集合散成一地，缺陷描述还在记事本里改第五版。他说自己不是不会测，是每天都在「点点点」，点完需求点用例，点完用例点回归，点完回归又去补数据。
我当时就愣住了。
不是哥们，这哪是测试，这是体力劳动外包给自己。
坦率的讲，Agent 真正打动我的地方，不是它会聊天，而是它能接住那 80% 重复、可固化、可审计的活。剩下的边界判断、风险权衡、质量决策，还是得你来。
你如果关注这个领域的话，会发现大家最近都在聊同一件事。大模型会答，但容易抽卡。Agent 能办事，但没规范就会乱跑。Skill 把规范焊进 Agent，测试人终于能把经验从脑子里搬到项目里。
这篇就聊一件事。怎么用一套可复用的 Skill，把测试里的重复工作焊进 Agent 工作流，再塞回你自己的项目里。可能有些想法还不成熟，但我已经尽量按能落地的方式写。
一、先搞清楚，Skill 到底是什么
很多朋友把 Skill 当成「更长一点的 Prompt」。其实差着一层。
大模型给你的是单轮回答。你问一句，它回一段。Agent 更进一步，能拆任务、调工具、连着仓库跑命令，像个会动手的同事。而 Skill，是把某类测试能力封装成项目里的操作手册。启动时只加载名称和简介，任务对上了才展开完整正文。这叫渐进式披露，省 token，也更稳。
我是真的觉得，这层设计对测试特别友好。你想想看，Mock 数据规范、Code Review 清单、接口断言模板、分支命名规矩，这些东西你每天都在用。不收成 Skill，就只能靠聊天框抽卡。收成 Skill，输出结构固定，新人也能复用，老同学请假也不会把经验带走。
回到主线。Skill 不是替代你思考，是把重复规范工作固化下来，让你专注真正难的部分。会不会被淘汰，不取决于你会不会点页面，而取决于你能不能把经验变成可调用资产。
二、目录结构长什么样，怎么用起来
一个最小可用的 Skill，目录通常就这么简单。
SKILL.md 顶部是 frontmatter，告诉 Agent 这是谁、干什么、必要时用哪个模型。正文写清输出套路和约束。触发方式可以是斜杠命令，也可以是自然语言。比如打开目标文件后说「解释这段代码」，或者直接 /explain-code。
轻量任务还可以绑小模型，又快又省。代码解释、日志归类这类，没必要每次都上最贵的模型。
插件市场装好的 Skill，有时项目目录里看不到新文件，这是正常的，它托管在用户主目录后台加载。团队要共享的关键 Skill，建议显式放进项目 .claude/skills，跟着仓库走版本。装完记得 /reload-plugins，再用 /skills 确认列表里真有它。
怎么说呢，目录不是花架子。目录立住了，经验才有地方落。你如果还把规范写在群聊和脑子里，Agent 永远学不会你的项目脾气。
三、几类核心能力，按测试场景升番看
别一上来堆八个名字。按你日常最痛的场景往上翻，比较爽。
1）读代码不再抽卡，explain-code
测开天天读框架源码、接口封装、PO 层。以前同一段代码，今天问一遍，明天再问结构又变。explain-code 把输出钉死成「类比 → ASCII 流程图 → 分步拆解 → 常见踩坑」。带新人 Code Walk，终于不用每次重新组织语言。
这块需要注意一下。你不是让它「随便讲讲」，你是在训练它按测试人需要的信息密度说话。哪里可能空指针，哪里容易漏断言，这些得写进 Skill 正文约束里。
2）一眼看清仓库，codebase-visualizer
新入职、接手老项目、写测试方案架构说明时最管用。脚本扫完生成可折叠目录树、类型着色、体积统计。中文说「可视化分析当前代码库」就能触发，首次执行可能要你批准一下脚本。
你要画测试范围，先看清山头在哪。哪些目录是核心交易，哪些是边角工具，体积突然暴涨的文件往往藏坑。这块我自己用过几次，比纯靠「问 AI 项目结构」靠谱太多。
3）自己造能力，skill-creator + 自定义测试 Skill
官方有个「用 Skill 创建 Skill」的引导器。你把需求糊成几条，比如只服务「订单幂等回归」「日志归类出 P0」。它会扫已有能力、找缺口、生成规范目录。注意新旧重叠时删旧留新，用 /skills 保持列表干净。
一个 Agent 最好专注一件事，术业有专攻。负责自动化回归的，就别硬塞性能测试分析。负责自然语言查库的，就别再让它建表删库。越专，决策越稳。
4）别让 AI 乱发挥，spec + plan
这是我最推荐测开落地的黄金搭档。
先 /spec，一句话变规范。
审阅通过后再 /plan，引用规范文件生成实现计划。大改前先 commit 留回滚点，再让 Agent 按步骤连续执行。你从「陪聊改代码」变成「审规范、审计划、盯风险」。
我跟你说，测开最容易踩的坑，是跳过审阅直接让它写。结果断言丢了，异常路径没了，界面倒是好看。规范驱动，就是把「先想清楚再动手」焊进流程。
5）测试看板别长 AI 味，frontend-design
很多同学用 Agent 搓仪表盘，结果白底紫渐变，一看就是模板。frontend-design 走「设计说明 Markdown，再按规范改代码」双阶段。暗黑科技风、图表层次、动效这些，可以写进需求里。测开自己做质量看板，也算门面。
升番到这儿，你会发现一件事。基础是解释和可视化，进阶是自造 Skill，炸点是规范驱动。一层层焊上去，Agent 才像同事，不像话痨。
四、对测试人到底有什么好处，提效落在哪
我非常理解那种焦虑。你不是天天写框架的开发，你是被排期追着跑的测试同学。回归永远来不及，造数永远手搓，缺陷描述永远被开发嫌弃。AI 一来，又有人跟你说测试要被替代。
这话听着有点刺耳，但我始终坚信，被替代的是「只会重复点击」的那部分动作，不是测试这个岗位。
Skill 真正帮你的，是把这些「可重复」的部分变成资产。用例骨架、断言模板、日志归类、接口冒烟、缺陷报告润色、环境检查清单，都能收。AI 负责结构化和第一稿，你负责挑边界、判风险、签质量。效率不是玄学，是把 80% 体力劳动从你脑子里搬到可调用能力里。
顺着上面的再聊聊。传统模式是 IDE、浏览器、聊天窗来回复制，上下文碎一地。AI 原生终端协作是以仓库为真源，读写文件、跑命令、看结果一气呵成。Skills 把规范焊进流程，Hooks 把检查挂到动作前后，外部工具链接到模型侧。测开的主战场，本来就在终端和仓库里。
你也可以回想一下自己的一周。有多少时间花在「重新组织同一种输出」上。那部分，就是 Skill 该吃掉的。接口冒烟从半小时压到几分钟，缺陷描述从反复改语气变成一次过审，这些小账加起来，才叫提效。
五、怎么塞进你自己的测试项目
别空想，按一周节奏落地。
第一天，做工作审计。列出你最耗时的三项重复劳动，登录回归、造数、缺陷复盘，任选其一。别拿虚构 Demo 骗自己，一定要贴真实业务模块。
第二天，装 explain-code，对真实业务文件跑通。感受「输出结构稳定」这件事。你会开始意识到，稳定性比灵光一现更值钱。
第三天，用 skill-creator 做一个团队专属 Skill。比如「支付模块回归清单」或「接口失败日志归类」。description 写清楚触发场景，避免误触。能写进历史事故和优先级规则就更好。
第四天，走一遍「spec 到 plan 再到执行」。哪怕只做欢迎页这种小需求，也要把审阅习惯练出来。一开始可能会有点笨拙，花的时间比手动还长。挺住，第二周就会顺。
第五天，把 Skill 放进项目目录，跟同事共享。定期 /skills 清理重叠项。轻量任务绑小模型，复杂架构再上大模型。
结合项目时记住三件事。业务规则写进 Skill，不要只写在群聊里。输出格式固定成表格或 Markdown，方便进用例库。关键结论留「待人工确认」区，防止模型幻觉直接进报告。
再说一句实在的。你可以把现有的 Playwright 脚本、接口集合、缺陷模板，当成 Skill 的「知识附件」慢慢喂进去。不是一夜换成全自动，是先让 Agent 懂你的项目口音，再让它帮你干脏活。
我也不知道这套对每个人都完美。我自己也还在摸索。但我觉得方向对了。测试人的护城河，不是点得更快，而是经验能沉淀、能复用、能指挥 Agent 干活。
屏幕前的你如果还在靠收藏夹里的 Prompt 硬扛，不妨今晚就先建一个最小 Skill，跑通一次再说。大时代啊，朋友们。别再把青春耗在点点点上了。
六、资料自取
需要本篇提到的 Skill 目录样例以及测开 Agent 落地清单的朋友，可以在公号后台回复关键词「666」，我整理成资料包发给你。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
谢谢你看我的文章，我们，下次再见。