功能测试想自己把自动化跑起来，脚本会一点、页面一改就全红，覆盖率数字有了却说不清有没有拦住问题——三件事常常同时存在。再往下，用例在禅道里，脚本在另一套仓库里，任务又在第三个平台上。改一处，另外两处不知道。
这个专栏不教第二套框架，也不把「再招两个人把回归加满」当成答案。它讲一条可以跟着做完的链路：先有工作区，再写本地用例，按用例决定写接口脚本还是界面脚本，该有的脚本齐了才允许挂测试任务，任务只负责把已经生成的脚本编成一组跑完，收成一份报告。跑完之后如果要看「拦得住、稳不稳、跑多久、场景齐不齐」，再单独看四项度量。度量不回头改「能不能挂任务」。
命令在 Cursor、Claw 或 VS Code 里敲。点名了哪条命令，就只做那一件事。没点名，就按你仓库里缺的那一层送去下一跳，不会一次把用例、脚本、任务全写出来。文件放在哪个目录、斜杠从哪里出来，第 15 篇单独讲。
先记住这条顺序
没有 autotest/ → /autotest-init
路径旧了 → /autotest-update
↓
本地用例 → /autotest-testcase（--sync 才交到禅道、Jira 或其它系统）
↓
AUTO_SCOPE
api → /autotest-api 生成 → 执行 → 自愈最多 3 轮
ui / api+ui → /autotest-ui-web 先确认计划，再生成 → 执行
已有脚本红了 → /autotest-ui-heal
none → 结束，不挂任务
↓
覆盖率 100% 范围内该有脚本的都有了，并且已经同步出去
↓
本地任务 → 查询 / 新建 / 追加
↓
批量执行 → /autotest-task-execute 一份组合报告
↓
四项度量（可选）→ /autotest-metrics 不改变上面的门禁
api+ui 要接口脚本和界面脚本两边都齐，这条用例才算覆盖完成。none 表示这次不需要自动化，写完用例就停，不往任务上挂。
查任务随时可以。/autotest-task-query 只读本地列表，不建、不跑、不改脚本。
五个词，后面每篇都会用
| 词 | 在这条链路里指什么 |
|---|---|
| 工作区 | 仓库里的 autotest/。用例、脚本、任务都落在这里，不散落在聊天记录里 |
| AUTO_SCOPE | 一条用例要不要自动化、自动化沉在哪一面：api / ui / api+ui / none |
| 覆盖率 100% | 分母是需要自动化的用例。该有的脚本都在，才允许挂任务。不是「全部跑绿」，也不是代码行覆盖率 |
| 自愈 | 只改已经生成的测试脚本。接口脚本在 autotest/api/，界面脚本在 autotest/e2e/tests/。前端工程和后端工程不动 |
| 测试任务 | 本地列表 autotest/tasks/ 里的一条。它点名若干已经生成的脚本，建完不自动开跑 |
再补三条边界，避免后面学串：
- 同步是交出去。
--sync把本地用例推到禅道、Jira 或你点名的系统。不是从线上把用例拉回来当真源。 - 产品错了就记下来。 断言和契约一致、实现不对，记到用例的 bug 上，停止把这条愈绿。不放宽断言换一个绿勾。
- 执行任务的时候不修脚本。 自愈发生在生成阶段（接口最多 3 轮，界面在生成执行时就地修）。已经红着的界面脚本走专项自愈。批量执行只跑、只记、只出报告。
课程表
算上你正在看的这一篇，一共 16 篇。第 1 到第 14 篇顺着流程图走，每个 Skill 单独一节。菱形判定没有自己的命令，写进它所属的那一节，不另开一篇去讲第二套流程。第 15 篇不新增命令，只讲这些 Skill 在 Claw 和 VS Code 里怎么放、怎么叫。
| 篇 | 层 | 命令 | 这一篇你带走什么 |
|---|---|---|---|
| 0 | — | （本篇） | 顺序、五个词、从哪一篇进入 |
| 1 | 开篇 | 无 | 为什么按项目加人的测试跟不上现在的变更节奏 |
| 2 | L0 入口 | autotest |
没点名命令时，只被送到下一跳 |
| 3 | L1 工作区 | /autotest-init |
建出 autotest/ 和 registry.yaml |
| 4 | L1 工作区 | /autotest-update |
只刷新前后端路径 |
| 5 | L2 用例 | /autotest-testcase |
本地用例、AUTO_SCOPE、--sync |
| 6 | L3 脚本 | /autotest-api |
接口脚本的生成、执行、分类、最多 3 轮自愈 |
| 7 | L3 脚本 | /autotest-ui-web |
先看页面、确认计划，再生成界面脚本 |
| 8 | L3 自愈 | /autotest-ui-heal |
已经红了的界面脚本，先分类再改 |
| 9 | L4 门禁 | 无单独命令 | 什么叫覆盖率 100%，为什么通过率不挡挂任务 |
| 10 | L5 任务 | /autotest-task-query |
只看本地任务列表 |
| 11 | L5 任务 | /autotest-task-create |
把多个已生成脚本收成一条任务 |
| 12 | L5 任务 | /autotest-task-attach |
往已有任务追加脚本，不删已经列入的 |
| 13 | L6 执行 | /autotest-task-execute |
按任务批量跑，写一份组合报告 |
| 14 | 度量 | /autotest-metrics |
四项指标，以及它们为什么不能代替门禁 |
| 15 | 宿主 | 无新命令 | 同一份 Skill 在 Claw 里怎么用，在 VS Code 里怎么加 |
界面脚本的 Playwright 写法（页面对象、定位、报告）放在第 7 篇里讲。它是 /autotest-ui-web 的生成细则，不单独占一条斜杠命令，也不另开一条链路。
第 1 篇 · 为什么要先把测试收成一条链路
没有命令。先把立场说清楚，后面才不会把每个 Skill 学成孤立的脚本生成器。
你会看到三笔账：时间账（回归越跑越长）、信任账（绿了仍不放心）、记忆账（缺陷关了，用例和脚本没有一起补上）。AI 把开发吞吐抬高之后，按项目加人、靠专人跟着改脚本，这三笔账会一起变贵。
学完能回答：研发可以自己把交付所需的测试执行跑完；测开要做的是把方法收成命令、门禁和边界。功能测试没有因此消失。这一篇不宣布测试失业，也不开始建目录。
第 2 篇 · 入口路由 autotest
对话里只说「给这个仓库补上自动测试」，没有点名 /autotest-init 或别的命令时，走这一篇。
它做的唯一事情是分流：没有工作区就去 init；路径已经对不上就去 update；还没有用例就去 testcase；看 AUTO_SCOPE 决定去接口还是界面；脚本已经红了并且人要修，就去 ui-heal，不重新生成一遍；要看任务就只查询；明确说要跑，才去执行；要看四项数字，才去度量。
你已经把命令打全的时候，不经过这篇。点名了哪条，就做哪条。
第 3 篇 · /autotest-init
仓库里还没有 autotest/registry.yaml。这一篇只创建落点：cases/、api/、e2e/、tasks/、sync/，再加上一份 registry，记下能找到的前端目录和后端目录。找不到就留空，并在对话里说明，不编造路径。
目录已经在，命令会停。它不刷新路径，不写用例，不建任务。已有资产被覆盖，是这一篇要防的事。
第 4 篇 · /autotest-update
前后端目录挪了，registry 里的路径在仓库中已经不存在。这一篇重新扫描，只改 registry 的前端和后端字段，并列出删掉的、新写入的、没变的路径。
用例、接口脚本、界面脚本、任务列表保持原样。没有 registry 时它会停，改走第 3 篇。
第 5 篇 · /autotest-testcase
工作区就绪，这次变更还没有本地用例。用例写在 autotest/cases/，每条带上 auto_scope 和 scenario。
auto_scope 四选一：api、ui、api+ui、none。scenario 四选一：normal（正常）、boundary（边界）、concurrency（并发）、consistency（一致）。脚本和任务都等这一步有了结果再分流。none 写完即结束。
加上 --sync，才把本地用例交到禅道、Jira 或其它系统，并留下 autotest/sync/manifest.yaml。不加这个参数，用例只留在本地。这一篇不生成脚本，不建任务，也不去扫线上已有用例。
第 6 篇 · /autotest-api
用例的 auto_scope 是 api 或 api+ui。按用例在 autotest/api/ 生成脚本，执行，失败先分类。
分类只有四种：contract（路径、字段和契约不符）、assertion（断言写错）、data（缺数据）、product（断言与契约一致，实现不对）。前两种才改脚本再跑，最多 3 轮。data 只提示补数据。product 记 bug 并停止。同一类失败、没有新证据，剩下的轮次也不再改。
不改前端工程，不改后端工程。通过率可以汇报，不作为能不能往下走的条件。api+ui 还要等界面脚本齐了，这条用例才算覆盖完成。
第 7 篇 · /autotest-ui-web
用例的 auto_scope 是 ui 或 api+ui。顺序和接口不同：先用页面快照写出计划，并写下判断（下一步动作、控件、主路径有没有盖住、定位风险）。计划没确认，停在计划上，不生成脚本。
确认之后才按 Playwright 把脚本写到 autotest/e2e/tests/。登录、进页、准备数据分开写，断言对业务结果。失败同样先分类，再决定能不能就地改这次生成的脚本。分类是：locator、wait、assertion、data、auth、product。产品行为不对就记 bug。同一分类、没有新证据就停。
环境里有判断服务的密钥、仓库里也已经有对应客户端时，判断来源记为 jev；否则由这条命令按同一组字段填写，来源记为 agent。不编造一套不存在的接口。
第 8 篇 · /autotest-ui-heal
界面脚本已经在仓库里，而且跑红了。这一篇不新造用例，也不从零再生成一遍。找不到脚本文件就停，缺的是脚本本身时回到第 7 篇。
先写分类，分类集合与第 7 篇相同。允许改的只有 autotest/e2e/tests/ 里已经生成的脚本。product 不改断言。这一篇也不借自愈去挂任务。
和第 6 篇的差别：接口自愈嵌在生成命令里，最多 3 轮；界面如果是生成当时就失败，第 7 篇可以就地修；脚本早已生成、后来又红了，走这一篇。
第 9 篇 · 覆盖率 100%
没有单独命令。账本是 autotest/coverage.yaml。
分母：auto_scope 不是 none 的用例。api 要有接口脚本，ui 要有界面脚本，api+ui 两边都要有。分子齐了，比例才是 1。none 不进分母，也不挂任务。
挂任务还要多一个条件：用例已经同步到禅道、Jira 或其它系统。两个条件都在，才进入第 11、12 篇。缺脚本就回去补脚本，缺同步就回去 --sync。
通过率不挡这一步。发版可以另要求通过率；生成和自愈过程里会碰到真实 bug，那些红是结果，不是没做完。代码行覆盖率、第 14 篇的四项数字，都不参与这道门。
第 10 篇 · /autotest-task-query
看 autotest/tasks/ 里已经有哪些任务、每条列入了哪些脚本、有没有组合报告。给了任务编号就只看那一条。
没有任务文件时，汇报「当前没有任务」，不会因此去建工作区或新建任务。这一篇不写文件，不跑脚本。建任务之前、开跑之前，都先用它看一眼，避免同名再建一条。
第 11 篇 · /autotest-task-create
把若干已经生成的脚本收成一条本地任务，写入 autotest/tasks/<id>.yaml。脚本路径必须已经在 autotest/api/ 或 autotest/e2e/tests/，至少一条。没有现成脚本就停，先走第 6 或第 7 篇。
同名任务已经在列表里，就停，改走第 12 篇追加。建完不执行。任务是一份名单，不是开跑按钮。
第 12 篇 · /autotest-task-attach
任务已经在列表里，还有新的已生成脚本要放进去。新路径追加到名单末尾。已经在名单上的路径留着，不重复写，也不删除。
列表里没有这条任务，就停，改走第 11 篇。同样不跑脚本，不改脚本内容，不改前后端工程。
第 13 篇 · /autotest-task-execute
点名一条任务，按名单逐个跑，把每条的通过或失败收进 autotest/tasks/reports/<id>.md，任务状态写成已完成。
脚本文件缺失，记为失败，继续下一条。失败只记录：不改脚本，不进入接口自愈，也不进入界面专项自愈，不改前后端工程，不在这一步新生成脚本。要修，回到第 6 或第 8 篇，修完再决定要不要重新跑。
第 14 篇 · /autotest-metrics
任务跑完之后可选。写入 autotest/metrics.yaml，四项都要有当前值，没有数据就明确留空，并带上目标：
| 指标 | 在看什么 |
|---|---|
| 缺陷发现率 | 自动化拦住的、线上能感知的缺陷，占同期全部线上缺陷的比例 |
| 稳定性 | 近 30 天通过率，以及是否连续失败。低于 95% 或连续 3 次失败，这条用例在发版时暂停；95%～98% 仍可跑，只是盯着 |
| 执行效率 | 全量要跑多久、等待多久、环境多久能就绪 |
| 场景覆盖密度 | normal / boundary / concurrency / consistency 各自齐到什么程度 |
脚本齐套的覆盖率单独报一行，标明它才是挂任务的门禁。这四项不否决已经挂上的任务，也不用来填「覆盖率是不是 100%」。没有缺陷账本就不编数字。不在这一篇里自愈，也不改脚本。
第 15 篇 · 在 Claw 里用 Skill，在 VS Code 里加入 Skill
前面的命令要先被宿主看见，敲出来才会进对应的 SKILL.md。这一篇不改链路顺序，不生成用例，也不跑脚本。操作步骤仍以仓库里的 .cursor/skills/autotest-*/SKILL.md 为准。换宿主时复制目录，不改里面的步骤。
三处落点：
| 宿主 | 项目里放哪 | 怎么调用 |
|---|---|---|
| Cursor | .cursor/skills/<name>/SKILL.md。要做成斜杠命令时，再放一份 .cursor/commands/<name>.md |
聊天里输入 / 加技能名，或用 @ 把该技能附进这次对话 |
| Claw（OpenClaw） | 工作区 skills/<name>/SKILL.md。这台机器上的智能体都要用，放 ~/.openclaw/skills/<name>/ |
/skill <name>，或该技能注册成自己的斜杠命令。改完文件后开一轮新会话 |
| VS Code（GitHub Copilot） | .github/skills/<name>/SKILL.md。也认 .agents/skills/、.claude/skills/。只给自己用、不进仓库，放 ~/.copilot/skills/<name>/ |
聊天输入框打 /，选中技能。配置入口是 Chat 里的 Configure Chat，再打开 Skills |
name 用小写字母、数字和连字符，并且必须和上一级目录名一致。对不上时，VS Code 会静默不加载。
在 Claw 上，工作区的 skills/ 优先于 ~/.openclaw/skills。本专栏这些命令要显式点名，不让模型看对话自己套用，就在 frontmatter 里写 disable-model-invocation: true，同时保持 user-invocable: true，这样 /skill autotest-init 仍然可用。本地目录可以直接装进去：
openclaw skills install ./.cursor/skills/autotest-init --as autotest-init
装到当前工作区的 skills/。要给这台机器上的智能体共用，加上 --global，落到 ~/.openclaw/skills。一条命令一个目录，不要把整条链路塞进同一个 SKILL.md。
在 VS Code 里，打开聊天，输入 /skills 进入配置；也可以在 Configure Chat 的 Skills 页选 New Skill (Workspace)，位置选 .github/skills/。已经有 Cursor 那份时，把 .cursor/skills/autotest-init 整目录复制到 .github/skills/autotest-init，确认里面的 name: autotest-init 和文件夹名相同。聊天里输入 /autotest-init 能看见它，才算加成功。个人技能放 ~/.copilot/skills/，不提交进仓库。
斜杠列表里没有这些命令时，先做完这一篇，再回到第 3 篇。Skill 放进去之后，判定和产物仍按第 2 到第 14 篇，不因为换了宿主就多做一步。
你从哪一篇进入
不必每次都从第 1 篇读到第 15 篇。先对一下自己卡在哪一层。
| 你现在的情况 | 从这里读 | 先不要跳到 |
|---|---|---|
| 还没想清楚为什么要这么拆 | 第 1 篇 | 直接生成脚本 |
仓库里没有 autotest/ |
第 3 篇 | 用例和任务 |
| 前后端目录已经挪了 | 第 4 篇 | 把用例和脚本全部重写 |
| 这次变更还没有用例 | 第 5 篇 | 任务和度量 |
| 用例写了，要接口脚本 | 第 6 篇 | 用界面命令去包接口 |
| 用例写了，要界面脚本 | 第 7 篇 | 计划没确认就生成 |
| 界面脚本早先是绿的，现在红了 | 第 8 篇 | 删掉重生成当修复 |
| 脚本齐不齐、能不能挂任务 | 第 9 篇 | 用通过率或四项度量代替 |
| 只想看有哪些任务 | 第 10 篇 | 查询时顺手建一条 |
| 要把多个脚本编成一组 | 第 11 篇，已有同名则第 12 篇 | 建完就当已经跑过 |
| 要一份把这些脚本合在一起的报告 | 第 13 篇 | 边跑边改脚本 |
| 对话里没点名命令 | 第 2 篇 | 指望一次对话写完全部资产 |
| 跑完了，想看拦得住不、稳不稳 | 第 14 篇 | 用这四项去决定能不能挂任务 |
| 斜杠里没有这些命令，或要换到 Claw、VS Code | 第 15 篇 | 还没放进宿主就从第 3 篇开始生成 |
零基础从第 3 篇和第 5 篇开始，先有目录和一条本地用例。已经会写 Selenium、Playwright 或接口脚本的，从你卡住的那一层接，不必把前面的命令重做一遍。用例和脚本没齐，不进入任务和度量。
这个专栏不讲什么
- 不把通过率当成挂任务的条件。
- 不在写用例、写脚本、建任务时去扫线上用例，再把线上的当成本地真源。
- 不在批量执行时自愈，也不用自愈去改前端或后端工程。
- 不把
AUTO_SCOPE=none的用例挂进任务。 - 不并行再讲一套「审查打分、五端矩阵、漂移阈值」当作第二条主链。那些不是这条斜杠链路的步骤。
跟做时仓库里会长出什么
走完主链，而不是只读完标题，仓库里应能指认这些文件：
autotest/
registry.yaml 第 3 篇创建，第 4 篇只改路径
cases/ 第 5 篇
sync/manifest.yaml 第 5 篇，且带了 --sync
api/ 第 6 篇
e2e/plans/ 第 7 篇，计划与判断
e2e/tests/ 第 7 篇生成，第 8 篇只修已有文件
coverage.yaml 第 6、7 篇写入，第 9 篇解释门禁
tasks/TASK-*.yaml 第 11、12 篇
tasks/reports/ 第 13 篇
metrics.yaml 第 14 篇，可选
