测试群里最常出现的求助是“这条 SQL 线上为什么慢帮我看看”以前的做法是把 SQL 粘到数据库看执行计划再对着表结构一条条排查有没有SELECT *、大偏移深分页、隐式类型转换。查 10 条还能忍查 50 条就会出现人眼扫描容易漏的问题更不要说要补接口断言、造测试数据、整理回归范围这些事情。软件测试真正耗时间的往往不是“执行”而是把这些输入一次次念给不同工具听。这篇文章不打算讲“怎么让 AI 帮你写一条 SQL”而是讲一套可以反复使用的思路把 SQL 质量检测、数据一致性核对、接口用例生成、UI 自动化脚本辅助、测试数据构造、缺陷回归筛选、巡检冒烟这些高频动作封装成 Skill技能包。搭好之后以后遇到同类任务只需要一句话触发不用每次把背景、规则、输出格式重新描述一遍。标题里的“效率提升 200 倍”我的理解更务实当任务可以批量执行、判断规则又足够明确时自动化和人工逐条处理的差距确实可能到两个数量级。它不是一个适合所有场景的指标但 SQL 检测这类“规则型任务”天然适合先自动化。这套 7 大 Skills 也不是独家压箱底方案而是建议你按下面的模板在自己的测试岗位搭一套能跑的版本。如果你是下面这几类人这篇会比较有用已经用过 AI 工具写脚本但发现每次都要从头描述需求的测试工程师经常处理 SQL 数据查验或性能判断的技术人员写接口用例或 UI 自动脚本耗时较长的人想把自己的测试工作流从“零散提问”升级为“标准化产物”的人。1. 核心能力速览这套 Skill 方案解决什么问题先给一张速览表。注意这不是一个下载即用的“测试平台”而是一套组织 AI 工具协作方式的方法。能力项说明方案类型软件测试提效 Skill 集核心价值把高频测试任务的判断规则、输入模板、输出模板固化减少重复沟通覆盖场景SQL 质量检测、数据一致性核对、接口用例生成、UI 自动化脚本辅助生成、测试数据构造、缺陷回归筛选、巡检冒烟使用 AI 工具支持自定义指令 / Skill / API 调用的对话式 AI 编码工具均可尝试硬件门槛普通办公电脑即可无需 GPU除非你要本地跑大模型启动方式不需要一键包把 Skill 目录放入对应工具的 Skills 目录或直接用提示词触发是否支持批量视宿主工具而定接入 AI API 后可以在脚本中批量处理是否支持 API 调用可以。规则文件和提示词可以封装成批量请求脚本主要风险会接触业务 SQL、表结构和一定量的生产数据必须先做脱敏与授权控制为什么我把范围控制在“规则明确的场景”因为 Skill 的工作机制是把人对某类任务的经验沉淀成“规则 示例 输出格式”再让 AI 按固定路径执行。SQL 静态检查非常适合因为怀疑点无非是SELECT *、条件列没有索引、JOIN 类型异常、深分页、类型转换。接口用例生成也适合因为方法论基本固定正常参数、缺参、类型错误、边界值、鉴权失败、SQL 层面的数据断言。反而是“探索性测试”或“完全没标准的业务判断”不适合做 SkillAI 输出会变成看起来认真的空话。真实的高效来源是工作流压缩。比如一条一条 SQL 人工看到 200 条就算每条只看 2 分钟也要接近 7 小时如果规则文件写清脚本批量跑一遍生成报告再由人工抽检高风险项时间会降到十几分钟到半小时。这才是“200 倍”的合理含义不是说模型生成单个结果变快了而是整体流程变短了。2. Skill 机制为什么它比“每次都写 Prompt”更适合测试很多人用 AI 工具的第一步是复制一段 Prompt比如“帮我检查这段 SQL 有没有问题”。第一次有效第二次要重新贴一遍背景第三次还要解释什么是高风险。这个问题的本质是经验没有沉淀而 Skill 正好解决这个沉淀问题。可以把 Skill 理解为“一个带规则和示例的专用任务包”。它不再是一条随时会被聊天记录冲走的 Prompt而是一个目录里面包含任务说明、判断规则、输入格式要求、输出报告模板、正反示例。测试工程师对这套结构应该很熟因为测试工作本身就需要把“验收清单”写清楚Skill 等于把验收清单喂给了 AI让它在执行前就知道要按什么标准交付。一个典型的 Skill 目录长这样sql-review/ ├── SKILL.md # 技能说明用途、触发方式、输入输出 ├── rules/ │ └── sql_static_rules.md # 规则库静态检查要命中哪些风险点 ├── templates/ │ ├── input_prompt.md # 输入模板待检测 SQL 要怎么格式化 │ └── output_report.md # 输出模板检测报告结构 └── examples/ ├── high_risk_query.sql # 反例包含多种风险的 SQL └── ok_query.sql # 正例可接受的 SQL这个目录不绑定具体平台。很多 AI 工具会在对话中自动读取 Skill 目录或要求你先安装到指定目录。如果你的工具没有“Skill”按钮也可以退而求其次把规则文件内容复制到系统提示词里。区别在于维护性差一点但思路一致。触发时最理想的交互是直接写/skill sql-review 检测 sql_case/high_risk.sql并输出 Markdown 报告如果不支持“/skill”语法就改成一条完整指令请读取 sql-review/skills 下的规则文件再检测 sql_case/high_risk.sql 输出格式按 templates/output_report.md 执行。真正值钱的不是“AI 能回答”而是这套文件可以被 Git 管理、多人协作改规则、后续批量跑。测试团队如果能沉淀出这样的规则资产换个新人也只需要把同一个 Skill 目录丢过去产出的报告风格还是统一的。3. 7 大 Skills覆盖软件测试常见场景下面这套 7 个 Skill 的设计覆盖了日常测试中比较常见的重复劳动。你不用照搬先看我为什么要这样切分再结合实际岗位调整。Skill 名称要解决的问题主要输入核心产出1. SQL 静态质量检测新脚本提测前没人系统查 SQL 隐患SQL 文件、表结构 DDL风险清单、修复建议2. 数据一致性核对数据对不上时难定位差异两段 SQL、关联键对账脚本、差异明细3. 接口测试用例生成只测 200 状态码不覆盖边界OpenAPI / JSON 示例pytest 用例、断言脚本4. UI 自动化脚本生成从操作步骤到脚本耗时太长操作文本、页面元素Playwright/Selenium 骨架5. 测试数据构造与造数环境数据不满足状态机表结构、约束说明批量 INSERT 与清理脚本6. 缺陷影响面与回归筛选回归范围靠老师傅经验Bug 描述、变更文件影响分析、回归用例清单7. 巡检冒烟与持续回归每天重复打开页面和接口URL 清单、正反用例可定时执行的巡检脚本3.1 SQL 静态质量检测这个 Skill 放在第一位因为收益最直接。很多测试团队会收到开发提测的建表脚本、数据订正脚本、统计报表 SQL但测试人员自己未必会逐条看执行计划。规则型技能最适合先做。输入建议固定为待检测 SQL 相关表结构 DDL 数据库类型。没有 DDL 时AI 可以推断一部分风险但要明确告诉它“没有表结构只能做启发式分析不要假装知道索引”。输出要覆盖风险等级、命中规则、修复建议并且优先用“是否可以执行计划验证”作为后续人工复核的入口。建议用 Git 保存一份sql_static_rules.md规则库团队评审过的规则才加进去。不要今天让 AI 按 8 条规则查明天又变成 3 条否则报告会不稳定。3.2 数据一致性核对数据核对是测试里少见的“开发不一定会写”的任务。比如订单表和订单明细表的总金额对不上你要自己拼 SQL 查差异。如果你让 AI 每次现写太浪费设计成 Skill 之后输入“哪两张表、什么时间范围、哪个键关联”就可以生成对账 SQL。对账 SQL 的基本模式是两边先按维度汇总再用LEFT JOIN做差值计算。示意如下-- 订单表与订单明细的金额汇总核对测试环境执行 SELECT a.order_date, a.order_total - b.detail_total AS diff_amount FROM ( SELECT order_date, SUM(amount) AS order_total FROM orders WHERE order_date 2025-03-01 GROUP BY order_date ) a LEFT JOIN ( SELECT order_date, SUM(detail_amount * quantity) AS detail_total FROM order_items WHERE order_date 2025-03-01 GROUP BY order_date ) b ON a.order_date b.order_date;运行这个脚本只能在有授权的测试环境或数据快照上执行。如果差异值不等于 0再让 AI 往下拆比如按渠道、支付状态、商品分类分组缩小范围。这个 Skill 的难点不是生成 SQL而是让 AI 先弄清楚两张表的粒度差异避免无效对账。3.3 接口测试用例生成接口测试最怕的不是不会写代码而是用例没有覆盖到“数据正确性”。很多用例只断言了 HTTP 200一旦接口返回 200 但数据少了两条测试依然会漏。这个 Skill 可以要求 AI 输出两层断言第一层是响应状态码和结构第二层是 SQL 或查询接口里的数据结果是否符合预期。输入推荐使用 OpenAPI/Swagger 或者一段真实请求的 JSON。AI 可以解析出参数、必填项、枚举值然后生成 pytest 风格用例。它还可以针对每个参数生成缺省、空字符串、非法类型、超长、越权访问等用例测试人员拿到后补上鉴权信息就能跑。这个 Skill 的边界是不要直接拿生产流量自动生成攻击性用例。涉及权限类测试时要在已授权的测试环境并确认你不是在扫描他人系统。3.4 UI 自动化脚本生成UI 自动化的痛点不是语法而是“操作步骤和选择器不稳定”。这个 Skill 吃进的是测试人员写的自然语言操作流程输出 Playwright 或 Selenium 脚本骨架。AI 最大的帮助是帮你把“点击登录、输入账号、等待列表加载”这类描述翻译成可执行的步骤。生成之后应重点做两件事检查元素定位是否写死检查等待方式是否容易产生随机失败。如果测试网页经常改版建议让 AI 为关键元素生成>1. 禁止 SELECT *只允许查询需要的列 2. 大表查询必须有 WHERE 条件或合适的扫描范围 3. WHERE 条件列要尽量匹配索引避免对索引列做函数运算 4. JOIN 条件避免隐式类型转换 5. 深分页风险LIMIT offset 过大时建议改游标分页或二次查询 6. UPDATE / DELETE 必须带 WHERE不允许全表更新 7. 排序字段需要考虑是否与索引一致 8. 插入前应判断是否需要去重避免重复脏数据 9. 关联表数量过多时建议人工走执行计划确认 10. 对未确定大表行数时COUNT(*) 和 COUNT(列名) 含义不同要结合业务确认这份规则必须放到 Skill 目录里的rules/sql_static_rules.md。放进规则库的前提是“静态可推断”如果某条规则需要真实执行计划才能判断就写成“提示需要执行计划验证”而不是让 AI 假装判断。4.2 设计 Skill 目录与描述卡片接下来创建一个sql-review目录。描述卡片建议使用 Markdown因为它便于阅读也便于大多数 AI 工具理解。参考结构如下sql-review/ ├── SKILL.md ├── rules/ │ └── sql_static_rules.md ├── templates/ │ ├── input_prompt.md │ └── output_report.md └── examples/ ├── high_risk.sql └── ok.sqlSKILL.md的简化内容可以是--- 名称: sql-review 用途: 对 SQL 做静态质量检测输出风险清单与修复建议 输入: - 待检测 SQL 或 SQL 文件目录 - 相关表结构 DDL可选最好提供 数据库: MySQL / PostgreSQL / 其他按实际环境写 输出: - 风险等级 - 命中规则 - 修复建议 - 重写后的示例 SQL可选 不适用: - 不做真实性能基准测试 - 不连接生产库执行 --- 按 rules/sql_static_rules.md 中的规则逐条检查。 输出格式按 templates/output_report.md 执行。这段内容不是官方规范更像一个通用说明卡片。不同 AI 工具的 Skill 机制字段不同实际路径和字段名要按官方文档调整但“任务边界 输入输出 规则引用”的思路是通用的。4.3 写一个可复用的输入模板输入模板解决的核心问题是格式不统一。建议固定为“三段式”数据库类型 表结构 DDL 待检测 SQL。示例 prompt你是 SQL 审查员。现在有一批新增或修改的 SQL 需要做静态质量检测。 请先读取 rules/sql_static_rules.md 中的规则再逐条检查下面的 SQL。 数据库类型MySQL 8.0 表结构 DDL {粘贴 DDL} 待检测 SQL {粘贴 SQL} 输出要求 1. 先写风险等级高 / 中 / 低 / 提示 2. 再写命中的规则编号和具体原因 3. 给出可执行的修复建议 4. 如果修复后的 SQL 会改变结果语义务必说明把这段内容存成templates/input_prompt.md。每次调用 Skill 时只替换大括号里的内容避免临时组织语言导致漏信息。4.4 用高风险 SQL 做验证Skill 是否有效要用真实案例验证。下面是一条适合做反例的 SQLSELECT * FROM orders o LEFT JOIN users u ON o.user_id u.id LEFT JOIN products p ON o.product_code p.code WHERE o.created_at BETWEEN 2025-01-01 AND 2025-03-01 ORDER BY o.created_at DESC LIMIT 0, 5000;如果让这个 Skill 检查应该能发现几个明显问题SELECT *订单和用户、商品多表关联但缺少 where 过滤用户维度的条件深分页偏移量 5000是否缺索引取决于 DDL但在无 DDL 情况下 AI 应输出“提示需要人工确认索引”而不是强行断言。AI 给出的修复建议可能是SELECT o.order_id, o.order_no, o.user_id, u.name AS user_name, p.name AS product_name FROM orders o LEFT JOIN users u ON o.user_id u.id LEFT JOIN products p ON o.product_code p.code WHERE o.created_at 2025-01-01 AND o.created_at 2025-04-01 ORDER BY o.created_at DESC LIMIT 5000 OFFSET 0;注意这不是标准模板MySQL 各版本对LIMIT offset, rows和LIMIT rows OFFSET offset的写法略有差异最终以目标库版本为准。Skill 的价值是输出“减少 SELECT *改为明确字段列表深分页改为游标或二次查询”这类可执行建议而不是直接替你在生产库执行。4.5 怎么判断这个 Skill 是否成功判断标准不是“AI 说了一堆规则”而是三个条件对单条 SQLAI 能不遗漏地命中已定义规则。对没有表结构 DDL 的情况AI 能主动降低置信度而不是乱猜。输出报告的格式稳定可以作为后续批量报告的同一模板。如果第一遍验证不通过通常原因是规则文件写得太抽象、没有给正反示例、输入模板里没有说明数据库类型。修规则或补充示例后重跑不要靠现场改 prompt 来迁就。5. 批量任务与 API 接口接入单条测试跑通后下一步是批量。如果把几十条 SQL 手动复制到网页对话框每执行一次都要等待、复制结果体验很差。更稳妥的方式是让脚本读取目录中的 SQL 文件逐条调用模型 API 或命令行接口把结果写进固定目录。批量处理前一定要确认你使用的是自己的模型服务 API且接口 URL、密钥等环境变量不要写死在脚本里。下面给一套通用 Python 批量调用模板结构可以复用到大部分 OpenAI-compatible 接口。import os import json import time from pathlib import Path import requests API_URL os.getenv(AI_API_URL, https://your-gateway.example.com/v1/chat/completions) API_KEY os.getenv(AI_API_KEY, ) HEADERS { Authorization: fBearer {API_KEY}, Content-Type: application/json, } def load_rules(rule_path: str) - str: return Path(rule_path).read_text(encodingutf-8) def check_one_sql(sql_path: Path, ddl_path: Path, rule_text: str) - dict: sql_text sql_path.read_text(encodingutf-8) ddl_text ddl_path.read_text(encodingutf-8) if ddl_path.exists() else user_content ( f数据库类型MySQL 8.0\n\n f相关表结构 DDL\n{ddl_text}\n\n f待检测 SQL\n{sql_text}\n\n f请按规则文件输出检测报告并给出风险等级和修复建议。 ) payload { model: os.getenv(AI_MODEL, your-model-name), messages: [ { role: system, content: 你是 SQL 静态审查员输出必须按规则文件执行。, }, {role: user, content: user_content}, ], temperature: 0.2, } for attempt in range(3): try: resp requests.post(API_URL, headersHEADERS, jsonpayload, timeout180) resp.raise_for_status() content resp.json()[choices][0][message][content] return {file: sql_path.name, status: ok, report: content} except Exception as exc: if attempt 2: return {file: sql_path.name, status: error, message: str(exc)} time.sleep(5 * (attempt 1))def batch_check(input_dir: Path, output_dir: Path, rule_path: str) - None: output_dir.mkdir(parentsTrue, exist_okTrue) rule_text load_rules(rule_path) for sql_path in input_dir.glob(*.sql): ddl_path sql_path.with_suffix(.ddl.sql) # 同目录下的 DDL 文件按命名约定匹配 result check_one_sql(sql_path, ddl_path, rule_text) out_file output_dir / f{sql_path.stem}_report.json out_file.write_text(json.dumps(result, ensure_asciiFalse, indent2), encodingutf-8) print(fprocessed: {sql_path.name}, status: {result[status]}) if __name__ __main__: batch_check( input_dirPath(./sql_case), output_dirPath(./output), rule_path./rules/sql_static_rules.md, )这段脚本有几个工程点值得学习。第一它把失败任务记录成 JSON而不是让异常中断全部任务。第二采用同目录下.ddl.sql的命名约定来匹配表结构。第三设置了超时和重试降低偶发网络波动的影响。批量任务建议先跑 3 条实验确认输出格式稳定后再跑全量。输出目录里放 JSON 可以方便后续 diff因为回归测试最怕“这次报告和上次报告不一致但没人知道是哪条规则变了”。接口接入还有一个关键点不要把批量任务直接连到生产数据库执行。如果 SQL 文件本身来自生产库提取仍然有数据泄露风险。安全做法是只上传经过脱敏或模拟的表结构和 SQL 模板连接串只出现在受保护的测试环境脚本中。6. 资源占用与性能观察方法这类“测试提效 Skill”和图像模型部署不同不需要关注显存但还是要观察几个指标否则批量跑到一半会卡死或成本失控。最直接的费用指标是 token 消耗。一条很长、带大量 DDL 的 SQL 可能消耗几千 token批量几十条就是几十万 token这对 API 调用成本影响很大。建议观察每次请求返回的usage字段看prompt_tokens和completion_tokens各占多少。如果 DDL 太长可以只保留相关表的建表语句不要每次把整个库结构都塞进去。响应时间方面网页版对话通常以秒到十秒计API 接口可能更稳定。批量脚本里要记录每个文件的开始时间、结束时间、成功或失败原因。如果单个请求超过 180 秒通常不是模型慢而是上传内容过大或接口限流要拆分输入。内存占用和磁盘占用通常不会成为瓶颈。普通办公电脑跑一个批量请求脚本主要的资源消耗在进程和日志记录。建议先规划好输出目录大小因为大量 JSON 报告虽然单个很小但累积多了会占空间而且不便于搜索。按日期建目录是一种不错的选择。更加务实的观察方式是把“单条处理耗时”“平均耗时”“失败重试次数”输出成表格。这样你能判断到底是模型服务慢了还是规则文件太长导致每轮请求都在反复加载。观察维度建议关注点token 消耗是否因为 DDL 过大导致成本增长单次请求耗时是否超过接口超时限制批量并发数建议先 1稳定后逐步调大失败重试次数是否因接口限流或参数错误导致频繁失败输出报告大小是否导致后续人工阅读成本过高7. 常见问题与排查方法下面是这套玩法里最常见的 8 类问题按实际排查顺序整理成表。问题现象可能原因排查与解决方案执行claude命令提示无法识别工具路径没有加入环境变量检查安装目录把 bin 目录加入 PATH在 PowerShell 中执行Get-Command claude确认Skill 目录放好了但对话不生效目录名/触发词不对或工具没有索引到确认目录层级重启对话会话不要嵌套到其他目录里AI 检查 SQL 时漏掉一些规则规则文件没有传给模型或规则样例太少查看输入模板是否引用规则文件给规则加正反示例输出格式不稳定没有使用固定输出模板把报告格式也写入输入模板要求 AI 输出 JSON 或 Markdown批量跑一半卡住接口限流或单条 SQL 过长降低并发数给请求加超时与重试拆分超大 SQL 文件AI 修复建议不适合目标数据库版本没有告诉它数据库版本在输入模板中固定写清 MySQL/PostgreSQL 等版本报告太多人工看不过来没有按风险等级过滤在报告中增加“高风险优先复查”并只导出高风险列表给负责人误把内部 SQL 发给外部大模型未提前做数据合规评估使用脱敏数据或私有化模型涉及业务核心结构时先申请审批同一份 SQL 每次都返回不同结论模型温度过高把请求参数temperature调低比如 0.1 或 0.2如果遇到“报告结果忽好忽坏”尤其要检查规则库和输入模板是不是被聊天上下文覆盖了。Skill 的意义就在于所有内容都从固定文件读取避免这次用的规则和上次不一样。人工在对话里补充临时意见也要谨慎因为那份补充内容可能不会被记录到规则库里。SQL 类任务还有一个隐性坑AI 输出“建议增加索引”时并没有建索引的能力也不会告诉你建索引后对写入性能的影响。测试人员要把这些建议当成探索线索不要直接在生产库执行。最稳妥的验证方式是拿到测试库执行EXPLAIN观察实际执行计划。8. 最佳实践从“能用 AI 写脚本”到“把测试动作自动化”不是所有测试任务都需要做成 Skill也不是做出来的 Skill 都要立刻推广。我的建议是先挑一个最高频 AI辅助软件测试提效：7大Skill让SQL检测与用例生成自动化
测试群里最常出现的求助是“这条 SQL 线上为什么慢帮我看看”以前的做法是把 SQL 粘到数据库看执行计划再对着表结构一条条排查有没有SELECT *、大偏移深分页、隐式类型转换。查 10 条还能忍查 50 条就会出现人眼扫描容易漏的问题更不要说要补接口断言、造测试数据、整理回归范围这些事情。软件测试真正耗时间的往往不是“执行”而是把这些输入一次次念给不同工具听。这篇文章不打算讲“怎么让 AI 帮你写一条 SQL”而是讲一套可以反复使用的思路把 SQL 质量检测、数据一致性核对、接口用例生成、UI 自动化脚本辅助、测试数据构造、缺陷回归筛选、巡检冒烟这些高频动作封装成 Skill技能包。搭好之后以后遇到同类任务只需要一句话触发不用每次把背景、规则、输出格式重新描述一遍。标题里的“效率提升 200 倍”我的理解更务实当任务可以批量执行、判断规则又足够明确时自动化和人工逐条处理的差距确实可能到两个数量级。它不是一个适合所有场景的指标但 SQL 检测这类“规则型任务”天然适合先自动化。这套 7 大 Skills 也不是独家压箱底方案而是建议你按下面的模板在自己的测试岗位搭一套能跑的版本。如果你是下面这几类人这篇会比较有用已经用过 AI 工具写脚本但发现每次都要从头描述需求的测试工程师经常处理 SQL 数据查验或性能判断的技术人员写接口用例或 UI 自动脚本耗时较长的人想把自己的测试工作流从“零散提问”升级为“标准化产物”的人。1. 核心能力速览这套 Skill 方案解决什么问题先给一张速览表。注意这不是一个下载即用的“测试平台”而是一套组织 AI 工具协作方式的方法。能力项说明方案类型软件测试提效 Skill 集核心价值把高频测试任务的判断规则、输入模板、输出模板固化减少重复沟通覆盖场景SQL 质量检测、数据一致性核对、接口用例生成、UI 自动化脚本辅助生成、测试数据构造、缺陷回归筛选、巡检冒烟使用 AI 工具支持自定义指令 / Skill / API 调用的对话式 AI 编码工具均可尝试硬件门槛普通办公电脑即可无需 GPU除非你要本地跑大模型启动方式不需要一键包把 Skill 目录放入对应工具的 Skills 目录或直接用提示词触发是否支持批量视宿主工具而定接入 AI API 后可以在脚本中批量处理是否支持 API 调用可以。规则文件和提示词可以封装成批量请求脚本主要风险会接触业务 SQL、表结构和一定量的生产数据必须先做脱敏与授权控制为什么我把范围控制在“规则明确的场景”因为 Skill 的工作机制是把人对某类任务的经验沉淀成“规则 示例 输出格式”再让 AI 按固定路径执行。SQL 静态检查非常适合因为怀疑点无非是SELECT *、条件列没有索引、JOIN 类型异常、深分页、类型转换。接口用例生成也适合因为方法论基本固定正常参数、缺参、类型错误、边界值、鉴权失败、SQL 层面的数据断言。反而是“探索性测试”或“完全没标准的业务判断”不适合做 SkillAI 输出会变成看起来认真的空话。真实的高效来源是工作流压缩。比如一条一条 SQL 人工看到 200 条就算每条只看 2 分钟也要接近 7 小时如果规则文件写清脚本批量跑一遍生成报告再由人工抽检高风险项时间会降到十几分钟到半小时。这才是“200 倍”的合理含义不是说模型生成单个结果变快了而是整体流程变短了。2. Skill 机制为什么它比“每次都写 Prompt”更适合测试很多人用 AI 工具的第一步是复制一段 Prompt比如“帮我检查这段 SQL 有没有问题”。第一次有效第二次要重新贴一遍背景第三次还要解释什么是高风险。这个问题的本质是经验没有沉淀而 Skill 正好解决这个沉淀问题。可以把 Skill 理解为“一个带规则和示例的专用任务包”。它不再是一条随时会被聊天记录冲走的 Prompt而是一个目录里面包含任务说明、判断规则、输入格式要求、输出报告模板、正反示例。测试工程师对这套结构应该很熟因为测试工作本身就需要把“验收清单”写清楚Skill 等于把验收清单喂给了 AI让它在执行前就知道要按什么标准交付。一个典型的 Skill 目录长这样sql-review/ ├── SKILL.md # 技能说明用途、触发方式、输入输出 ├── rules/ │ └── sql_static_rules.md # 规则库静态检查要命中哪些风险点 ├── templates/ │ ├── input_prompt.md # 输入模板待检测 SQL 要怎么格式化 │ └── output_report.md # 输出模板检测报告结构 └── examples/ ├── high_risk_query.sql # 反例包含多种风险的 SQL └── ok_query.sql # 正例可接受的 SQL这个目录不绑定具体平台。很多 AI 工具会在对话中自动读取 Skill 目录或要求你先安装到指定目录。如果你的工具没有“Skill”按钮也可以退而求其次把规则文件内容复制到系统提示词里。区别在于维护性差一点但思路一致。触发时最理想的交互是直接写/skill sql-review 检测 sql_case/high_risk.sql并输出 Markdown 报告如果不支持“/skill”语法就改成一条完整指令请读取 sql-review/skills 下的规则文件再检测 sql_case/high_risk.sql 输出格式按 templates/output_report.md 执行。真正值钱的不是“AI 能回答”而是这套文件可以被 Git 管理、多人协作改规则、后续批量跑。测试团队如果能沉淀出这样的规则资产换个新人也只需要把同一个 Skill 目录丢过去产出的报告风格还是统一的。3. 7 大 Skills覆盖软件测试常见场景下面这套 7 个 Skill 的设计覆盖了日常测试中比较常见的重复劳动。你不用照搬先看我为什么要这样切分再结合实际岗位调整。Skill 名称要解决的问题主要输入核心产出1. SQL 静态质量检测新脚本提测前没人系统查 SQL 隐患SQL 文件、表结构 DDL风险清单、修复建议2. 数据一致性核对数据对不上时难定位差异两段 SQL、关联键对账脚本、差异明细3. 接口测试用例生成只测 200 状态码不覆盖边界OpenAPI / JSON 示例pytest 用例、断言脚本4. UI 自动化脚本生成从操作步骤到脚本耗时太长操作文本、页面元素Playwright/Selenium 骨架5. 测试数据构造与造数环境数据不满足状态机表结构、约束说明批量 INSERT 与清理脚本6. 缺陷影响面与回归筛选回归范围靠老师傅经验Bug 描述、变更文件影响分析、回归用例清单7. 巡检冒烟与持续回归每天重复打开页面和接口URL 清单、正反用例可定时执行的巡检脚本3.1 SQL 静态质量检测这个 Skill 放在第一位因为收益最直接。很多测试团队会收到开发提测的建表脚本、数据订正脚本、统计报表 SQL但测试人员自己未必会逐条看执行计划。规则型技能最适合先做。输入建议固定为待检测 SQL 相关表结构 DDL 数据库类型。没有 DDL 时AI 可以推断一部分风险但要明确告诉它“没有表结构只能做启发式分析不要假装知道索引”。输出要覆盖风险等级、命中规则、修复建议并且优先用“是否可以执行计划验证”作为后续人工复核的入口。建议用 Git 保存一份sql_static_rules.md规则库团队评审过的规则才加进去。不要今天让 AI 按 8 条规则查明天又变成 3 条否则报告会不稳定。3.2 数据一致性核对数据核对是测试里少见的“开发不一定会写”的任务。比如订单表和订单明细表的总金额对不上你要自己拼 SQL 查差异。如果你让 AI 每次现写太浪费设计成 Skill 之后输入“哪两张表、什么时间范围、哪个键关联”就可以生成对账 SQL。对账 SQL 的基本模式是两边先按维度汇总再用LEFT JOIN做差值计算。示意如下-- 订单表与订单明细的金额汇总核对测试环境执行 SELECT a.order_date, a.order_total - b.detail_total AS diff_amount FROM ( SELECT order_date, SUM(amount) AS order_total FROM orders WHERE order_date 2025-03-01 GROUP BY order_date ) a LEFT JOIN ( SELECT order_date, SUM(detail_amount * quantity) AS detail_total FROM order_items WHERE order_date 2025-03-01 GROUP BY order_date ) b ON a.order_date b.order_date;运行这个脚本只能在有授权的测试环境或数据快照上执行。如果差异值不等于 0再让 AI 往下拆比如按渠道、支付状态、商品分类分组缩小范围。这个 Skill 的难点不是生成 SQL而是让 AI 先弄清楚两张表的粒度差异避免无效对账。3.3 接口测试用例生成接口测试最怕的不是不会写代码而是用例没有覆盖到“数据正确性”。很多用例只断言了 HTTP 200一旦接口返回 200 但数据少了两条测试依然会漏。这个 Skill 可以要求 AI 输出两层断言第一层是响应状态码和结构第二层是 SQL 或查询接口里的数据结果是否符合预期。输入推荐使用 OpenAPI/Swagger 或者一段真实请求的 JSON。AI 可以解析出参数、必填项、枚举值然后生成 pytest 风格用例。它还可以针对每个参数生成缺省、空字符串、非法类型、超长、越权访问等用例测试人员拿到后补上鉴权信息就能跑。这个 Skill 的边界是不要直接拿生产流量自动生成攻击性用例。涉及权限类测试时要在已授权的测试环境并确认你不是在扫描他人系统。3.4 UI 自动化脚本生成UI 自动化的痛点不是语法而是“操作步骤和选择器不稳定”。这个 Skill 吃进的是测试人员写的自然语言操作流程输出 Playwright 或 Selenium 脚本骨架。AI 最大的帮助是帮你把“点击登录、输入账号、等待列表加载”这类描述翻译成可执行的步骤。生成之后应重点做两件事检查元素定位是否写死检查等待方式是否容易产生随机失败。如果测试网页经常改版建议让 AI 为关键元素生成>1. 禁止 SELECT *只允许查询需要的列 2. 大表查询必须有 WHERE 条件或合适的扫描范围 3. WHERE 条件列要尽量匹配索引避免对索引列做函数运算 4. JOIN 条件避免隐式类型转换 5. 深分页风险LIMIT offset 过大时建议改游标分页或二次查询 6. UPDATE / DELETE 必须带 WHERE不允许全表更新 7. 排序字段需要考虑是否与索引一致 8. 插入前应判断是否需要去重避免重复脏数据 9. 关联表数量过多时建议人工走执行计划确认 10. 对未确定大表行数时COUNT(*) 和 COUNT(列名) 含义不同要结合业务确认这份规则必须放到 Skill 目录里的rules/sql_static_rules.md。放进规则库的前提是“静态可推断”如果某条规则需要真实执行计划才能判断就写成“提示需要执行计划验证”而不是让 AI 假装判断。4.2 设计 Skill 目录与描述卡片接下来创建一个sql-review目录。描述卡片建议使用 Markdown因为它便于阅读也便于大多数 AI 工具理解。参考结构如下sql-review/ ├── SKILL.md ├── rules/ │ └── sql_static_rules.md ├── templates/ │ ├── input_prompt.md │ └── output_report.md └── examples/ ├── high_risk.sql └── ok.sqlSKILL.md的简化内容可以是--- 名称: sql-review 用途: 对 SQL 做静态质量检测输出风险清单与修复建议 输入: - 待检测 SQL 或 SQL 文件目录 - 相关表结构 DDL可选最好提供 数据库: MySQL / PostgreSQL / 其他按实际环境写 输出: - 风险等级 - 命中规则 - 修复建议 - 重写后的示例 SQL可选 不适用: - 不做真实性能基准测试 - 不连接生产库执行 --- 按 rules/sql_static_rules.md 中的规则逐条检查。 输出格式按 templates/output_report.md 执行。这段内容不是官方规范更像一个通用说明卡片。不同 AI 工具的 Skill 机制字段不同实际路径和字段名要按官方文档调整但“任务边界 输入输出 规则引用”的思路是通用的。4.3 写一个可复用的输入模板输入模板解决的核心问题是格式不统一。建议固定为“三段式”数据库类型 表结构 DDL 待检测 SQL。示例 prompt你是 SQL 审查员。现在有一批新增或修改的 SQL 需要做静态质量检测。 请先读取 rules/sql_static_rules.md 中的规则再逐条检查下面的 SQL。 数据库类型MySQL 8.0 表结构 DDL {粘贴 DDL} 待检测 SQL {粘贴 SQL} 输出要求 1. 先写风险等级高 / 中 / 低 / 提示 2. 再写命中的规则编号和具体原因 3. 给出可执行的修复建议 4. 如果修复后的 SQL 会改变结果语义务必说明把这段内容存成templates/input_prompt.md。每次调用 Skill 时只替换大括号里的内容避免临时组织语言导致漏信息。4.4 用高风险 SQL 做验证Skill 是否有效要用真实案例验证。下面是一条适合做反例的 SQLSELECT * FROM orders o LEFT JOIN users u ON o.user_id u.id LEFT JOIN products p ON o.product_code p.code WHERE o.created_at BETWEEN 2025-01-01 AND 2025-03-01 ORDER BY o.created_at DESC LIMIT 0, 5000;如果让这个 Skill 检查应该能发现几个明显问题SELECT *订单和用户、商品多表关联但缺少 where 过滤用户维度的条件深分页偏移量 5000是否缺索引取决于 DDL但在无 DDL 情况下 AI 应输出“提示需要人工确认索引”而不是强行断言。AI 给出的修复建议可能是SELECT o.order_id, o.order_no, o.user_id, u.name AS user_name, p.name AS product_name FROM orders o LEFT JOIN users u ON o.user_id u.id LEFT JOIN products p ON o.product_code p.code WHERE o.created_at 2025-01-01 AND o.created_at 2025-04-01 ORDER BY o.created_at DESC LIMIT 5000 OFFSET 0;注意这不是标准模板MySQL 各版本对LIMIT offset, rows和LIMIT rows OFFSET offset的写法略有差异最终以目标库版本为准。Skill 的价值是输出“减少 SELECT *改为明确字段列表深分页改为游标或二次查询”这类可执行建议而不是直接替你在生产库执行。4.5 怎么判断这个 Skill 是否成功判断标准不是“AI 说了一堆规则”而是三个条件对单条 SQLAI 能不遗漏地命中已定义规则。对没有表结构 DDL 的情况AI 能主动降低置信度而不是乱猜。输出报告的格式稳定可以作为后续批量报告的同一模板。如果第一遍验证不通过通常原因是规则文件写得太抽象、没有给正反示例、输入模板里没有说明数据库类型。修规则或补充示例后重跑不要靠现场改 prompt 来迁就。5. 批量任务与 API 接口接入单条测试跑通后下一步是批量。如果把几十条 SQL 手动复制到网页对话框每执行一次都要等待、复制结果体验很差。更稳妥的方式是让脚本读取目录中的 SQL 文件逐条调用模型 API 或命令行接口把结果写进固定目录。批量处理前一定要确认你使用的是自己的模型服务 API且接口 URL、密钥等环境变量不要写死在脚本里。下面给一套通用 Python 批量调用模板结构可以复用到大部分 OpenAI-compatible 接口。import os import json import time from pathlib import Path import requests API_URL os.getenv(AI_API_URL, https://your-gateway.example.com/v1/chat/completions) API_KEY os.getenv(AI_API_KEY, ) HEADERS { Authorization: fBearer {API_KEY}, Content-Type: application/json, } def load_rules(rule_path: str) - str: return Path(rule_path).read_text(encodingutf-8) def check_one_sql(sql_path: Path, ddl_path: Path, rule_text: str) - dict: sql_text sql_path.read_text(encodingutf-8) ddl_text ddl_path.read_text(encodingutf-8) if ddl_path.exists() else user_content ( f数据库类型MySQL 8.0\n\n f相关表结构 DDL\n{ddl_text}\n\n f待检测 SQL\n{sql_text}\n\n f请按规则文件输出检测报告并给出风险等级和修复建议。 ) payload { model: os.getenv(AI_MODEL, your-model-name), messages: [ { role: system, content: 你是 SQL 静态审查员输出必须按规则文件执行。, }, {role: user, content: user_content}, ], temperature: 0.2, } for attempt in range(3): try: resp requests.post(API_URL, headersHEADERS, jsonpayload, timeout180) resp.raise_for_status() content resp.json()[choices][0][message][content] return {file: sql_path.name, status: ok, report: content} except Exception as exc: if attempt 2: return {file: sql_path.name, status: error, message: str(exc)} time.sleep(5 * (attempt 1))def batch_check(input_dir: Path, output_dir: Path, rule_path: str) - None: output_dir.mkdir(parentsTrue, exist_okTrue) rule_text load_rules(rule_path) for sql_path in input_dir.glob(*.sql): ddl_path sql_path.with_suffix(.ddl.sql) # 同目录下的 DDL 文件按命名约定匹配 result check_one_sql(sql_path, ddl_path, rule_text) out_file output_dir / f{sql_path.stem}_report.json out_file.write_text(json.dumps(result, ensure_asciiFalse, indent2), encodingutf-8) print(fprocessed: {sql_path.name}, status: {result[status]}) if __name__ __main__: batch_check( input_dirPath(./sql_case), output_dirPath(./output), rule_path./rules/sql_static_rules.md, )这段脚本有几个工程点值得学习。第一它把失败任务记录成 JSON而不是让异常中断全部任务。第二采用同目录下.ddl.sql的命名约定来匹配表结构。第三设置了超时和重试降低偶发网络波动的影响。批量任务建议先跑 3 条实验确认输出格式稳定后再跑全量。输出目录里放 JSON 可以方便后续 diff因为回归测试最怕“这次报告和上次报告不一致但没人知道是哪条规则变了”。接口接入还有一个关键点不要把批量任务直接连到生产数据库执行。如果 SQL 文件本身来自生产库提取仍然有数据泄露风险。安全做法是只上传经过脱敏或模拟的表结构和 SQL 模板连接串只出现在受保护的测试环境脚本中。6. 资源占用与性能观察方法这类“测试提效 Skill”和图像模型部署不同不需要关注显存但还是要观察几个指标否则批量跑到一半会卡死或成本失控。最直接的费用指标是 token 消耗。一条很长、带大量 DDL 的 SQL 可能消耗几千 token批量几十条就是几十万 token这对 API 调用成本影响很大。建议观察每次请求返回的usage字段看prompt_tokens和completion_tokens各占多少。如果 DDL 太长可以只保留相关表的建表语句不要每次把整个库结构都塞进去。响应时间方面网页版对话通常以秒到十秒计API 接口可能更稳定。批量脚本里要记录每个文件的开始时间、结束时间、成功或失败原因。如果单个请求超过 180 秒通常不是模型慢而是上传内容过大或接口限流要拆分输入。内存占用和磁盘占用通常不会成为瓶颈。普通办公电脑跑一个批量请求脚本主要的资源消耗在进程和日志记录。建议先规划好输出目录大小因为大量 JSON 报告虽然单个很小但累积多了会占空间而且不便于搜索。按日期建目录是一种不错的选择。更加务实的观察方式是把“单条处理耗时”“平均耗时”“失败重试次数”输出成表格。这样你能判断到底是模型服务慢了还是规则文件太长导致每轮请求都在反复加载。观察维度建议关注点token 消耗是否因为 DDL 过大导致成本增长单次请求耗时是否超过接口超时限制批量并发数建议先 1稳定后逐步调大失败重试次数是否因接口限流或参数错误导致频繁失败输出报告大小是否导致后续人工阅读成本过高7. 常见问题与排查方法下面是这套玩法里最常见的 8 类问题按实际排查顺序整理成表。问题现象可能原因排查与解决方案执行claude命令提示无法识别工具路径没有加入环境变量检查安装目录把 bin 目录加入 PATH在 PowerShell 中执行Get-Command claude确认Skill 目录放好了但对话不生效目录名/触发词不对或工具没有索引到确认目录层级重启对话会话不要嵌套到其他目录里AI 检查 SQL 时漏掉一些规则规则文件没有传给模型或规则样例太少查看输入模板是否引用规则文件给规则加正反示例输出格式不稳定没有使用固定输出模板把报告格式也写入输入模板要求 AI 输出 JSON 或 Markdown批量跑一半卡住接口限流或单条 SQL 过长降低并发数给请求加超时与重试拆分超大 SQL 文件AI 修复建议不适合目标数据库版本没有告诉它数据库版本在输入模板中固定写清 MySQL/PostgreSQL 等版本报告太多人工看不过来没有按风险等级过滤在报告中增加“高风险优先复查”并只导出高风险列表给负责人误把内部 SQL 发给外部大模型未提前做数据合规评估使用脱敏数据或私有化模型涉及业务核心结构时先申请审批同一份 SQL 每次都返回不同结论模型温度过高把请求参数temperature调低比如 0.1 或 0.2如果遇到“报告结果忽好忽坏”尤其要检查规则库和输入模板是不是被聊天上下文覆盖了。Skill 的意义就在于所有内容都从固定文件读取避免这次用的规则和上次不一样。人工在对话里补充临时意见也要谨慎因为那份补充内容可能不会被记录到规则库里。SQL 类任务还有一个隐性坑AI 输出“建议增加索引”时并没有建索引的能力也不会告诉你建索引后对写入性能的影响。测试人员要把这些建议当成探索线索不要直接在生产库执行。最稳妥的验证方式是拿到测试库执行EXPLAIN观察实际执行计划。8. 最佳实践从“能用 AI 写脚本”到“把测试动作自动化”不是所有测试任务都需要做成 Skill也不是做出来的 Skill 都要立刻推广。我的建议是先挑一个最高频