企业官网建设流程全解析

功能测试想自己把自动化跑起来，脚本会一点、页面一改就全红，覆盖率数字有了却说不清有没有拦住问题——三件事常常同时存在。再往下，用例在禅道里，脚本在另一套仓库里，任务又在第三个平台上。改一处，另外两处不知道。

这个专栏不教第二套框架，也不把「再招两个人把回归加满」当成答案。它讲一条可以跟着做完的链路：先有工作区，再写本地用例，按用例决定写接口脚本，还是写 Web、App、PC、小程序里的哪一种界面脚本。该有的脚本齐了才允许挂测试任务，任务只负责把已经生成的脚本编成一组跑完，收成一份报告。跑完之后如果要看「拦得住、稳不稳、跑多久、场景齐不齐」，再单独看四项度量。度量不回头改「能不能挂任务」。

命令在 Cursor、Claw 或 VS Code 里敲。点名了哪条命令，就只做那一件事。没点名，就按你仓库里缺的那一层送去下一跳，不会一次把用例、脚本、任务全写出来。文件放在哪个目录、斜杠从哪里出来，第 21 篇单独讲。

先记住这条顺序

没有 autotest/ → /autotest-init 路径旧了 → /autotest-update ↓ 本地用例 → /autotest-testcase（--sync 才交到禅道、Jira 或其它系统） ↓ AUTO_SCOPE api → /autotest-api 生成 → 执行 → 自愈最多 3 轮 ui / api+ui → 先看 ui_client，再写这一种界面 web /autotest-ui-web app /autotest-ui-app pc /autotest-ui-pc miniprogram /autotest-ui-miniprogram 小程序 四种都是：先确认计划，再生成 → 执行 已有脚本红了，按同一种端自愈： web /autotest-ui-web-heal app /autotest-ui-app-heal pc /autotest-ui-pc-heal miniprogram /autotest-ui-miniprogram-heal none → 结束，不挂任务 ↓ 覆盖率 100% 范围内该有脚本的都有了，并且已经同步出去 ↓ 本地任务 → 查询 / 新建 / 追加 ↓ 批量执行 → /autotest-task-execute 一份组合报告 ↓ 四项度量（可选）→ /autotest-metrics 不改变上面的门禁

api+ui要接口脚本和ui_client指明的那一种界面脚本都齐，这条用例才算覆盖完成。一条用例只对应一种界面：Web、App、PC 或小程序，不默认四种一起补。none表示这次不需要自动化，写完用例就停，不往任务上挂。

查任务随时可以。/autotest-task-query只读本地列表，不建、不跑、不改脚本。

五个词，后面每篇都会用

再补三条边界，避免后面学串：

1. 同步是交出去。--sync把本地用例推到禅道、Jira 或你点名的系统。不是从线上把用例拉回来当真源。
2. 产品错了就记下来。断言和契约一致、实现不对，记到用例的 bug 上，停止把这条愈绿。不放宽断言换一个绿勾。
3. 执行任务的时候不修脚本。自愈发生在生成阶段（接口最多 3 轮，界面在生成执行时就地修）。已经红着的界面脚本，走和那一端对应的专项自愈。批量执行只跑、只记、只出报告。

课程表

算上你正在看的这一篇，一共 22 篇。第 1 到第 20 篇顺着流程图走，每个 Skill 单独一节。菱形判定没有自己的命令，写进它所属的那一节，不另开一篇去讲第二套流程。第 21 篇不新增命令，只讲这些 Skill 在 Claw 和 VS Code 里怎么放、怎么叫。

Web 的 Playwright 写法放在第 7 篇里讲。App、PC、小程序各占一篇，生成前同样先确认计划。小程序的英文名是miniprogram。每种界面再配一条同名的 heal，只修那一端已经生成的脚本。四种界面不是四条链路，入口仍按ui_client只送去其中一条。

第 1 篇 · 为什么要先把测试收成一条链路

没有命令。先把立场说清楚，后面才不会把每个 Skill 学成孤立的脚本生成器。

你会看到三笔账：时间账（回归越跑越长）、信任账（绿了仍不放心）、记忆账（缺陷关了，用例和脚本没有一起补上）。AI 把开发吞吐抬高之后，按项目加人、靠专人跟着改脚本，这三笔账会一起变贵。

学完能回答：研发可以自己把交付所需的测试执行跑完；测开要做的是把方法收成命令、门禁和边界。功能测试没有因此消失。这一篇不宣布测试失业，也不开始建目录。

第 2 篇 · 入口路由autotest

对话里只说「给这个仓库补上自动测试」，没有点名/autotest-init或别的命令时，走这一篇。

它做的唯一事情是分流：没有工作区就去 init；路径已经对不上就去 update；还没有用例就去 testcase；看AUTO_SCOPE决定去接口还是界面，界面再按ui_client去 Web、App、PC 或小程序里的一条；脚本已经红了并且人要修，就去这一端对应的 heal，不重新生成一遍；要看任务就只查询；明确说要跑，才去执行；要看四项数字，才去度量。

你已经把命令打全的时候，不经过这篇。点名了哪条，就做哪条。

第 3 篇 ·/autotest-init

仓库里还没有autotest/registry.yaml。这一篇只创建落点：cases/、api/、ui-web/、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。auto_scope含ui时再写ui_client，四选一：web、app、pc、miniprogram（小程序）。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还要等ui_client对应的那一种界面脚本齐了，这条用例才算覆盖完成。

第 7 篇 ·/autotest-ui-web

ui_client是web，并且auto_scope是ui或api+ui。顺序和接口不同：先用页面快照写出计划，并写下判断（下一步动作、控件、主路径有没有盖住、定位风险）。计划没确认，停在计划上，不生成脚本。

确认之后才按 Playwright 把脚本写到autotest/ui-web/tests/。登录、进页、准备数据分开写，断言对业务结果。失败同样先分类，再决定能不能就地改这次生成的脚本。分类是：locator、wait、assertion、data、auth、product。产品行为不对就记 bug。同一分类、没有新证据就停。

环境里有判断服务的密钥、仓库里也已经有对应客户端时，判断来源记为jev；否则由这条命令按同一组字段填写，来源记为agent。不编造一套不存在的接口。ui_client不是web时，这一篇停，改走第 8、第 9 或第 10 篇。

第 8 篇 ·/autotest-ui-app

ui_client是app。测的是手机应用，不是浏览器页面。先看当前界面，写出计划并确认，确认之后才把脚本写到autotest/app/tests/。计划没确认，停在计划上。

失败先分类，分类与第 7 篇相同。技术类失败只改autotest/app/tests/里这次生成的脚本。product记 bug 并停止。不改 App 工程本身。

第 9 篇 ·/autotest-ui-pc

ui_client是pc。测的是桌面客户端。同样先确认计划，再把脚本写到autotest/pc/tests/。计划没确认，不生成。

失败先分类。技术类只改autotest/pc/tests/里这次生成的脚本。product记 bug 并停止。不改桌面工程本身。

第 10 篇 ·/autotest-ui-miniprogram

ui_client是miniprogram，也就是小程序。命令用这个英文名，避免和 Web、App 混在一个 Skill 里。先确认计划，再把脚本写到autotest/miniprogram/tests/。计划没确认，不生成。

失败先分类。技术类只改autotest/miniprogram/tests/里这次生成的脚本。product记 bug 并停止。不改小程序工程本身。

四种界面共用同一套次序：先计划，后生成，失败先分类。差别只在被测端和脚本目录。一条用例标了哪种ui_client，就只走对应的那一篇。生成当时的技术类失败，可以在第 7 到第 10 篇里就地改这次生成的脚本。脚本早已生成、后来又红了，走下面四条里对得上的那一条，不在生成命令里重来一遍。

第 11 篇 ·/autotest-ui-web-heal

Web 脚本已经在autotest/ui-web/tests/里，而且跑红了。这一篇不新造用例，也不从零再生成。找不到 Web 脚本就停，缺的是脚本本身时回到第 7 篇。

先写分类，分类集合与第 7 篇相同。允许改的只有autotest/ui-web/tests/里已经生成的脚本。product不改断言。App、PC、小程序的红脚本不在这一篇里改。

第 12 篇 ·/autotest-ui-app-heal

App 脚本已经在autotest/app/tests/里，而且跑红了。找不到 App 脚本就停，缺的是脚本本身时回到第 8 篇。

先分类，再决定改不改。允许改的只有autotest/app/tests/里已经生成的脚本。product不改断言，也不改 App 工程。

第 13 篇 ·/autotest-ui-pc-heal

PC 脚本已经在autotest/pc/tests/里，而且跑红了。找不到 PC 脚本就停，缺的是脚本本身时回到第 9 篇。

先分类。允许改的只有autotest/pc/tests/里已经生成的脚本。product不改断言，也不改桌面工程。

第 14 篇 ·/autotest-ui-miniprogram-heal

小程序脚本已经在autotest/miniprogram/tests/里，而且跑红了。找不到小程序脚本就停，缺的是脚本本身时回到第 10 篇。

先分类。允许改的只有autotest/miniprogram/tests/里已经生成的脚本。product不改断言，也不改小程序工程。

四条 heal 的边界相同：只修这一端已经生成的脚本，不新造用例，不借自愈去挂任务。同一分类、没有新证据就停。

第 15 篇 · 覆盖率 100%

没有单独命令。账本是autotest/coverage.yaml。

分母：auto_scope不是none的用例。api要有接口脚本。ui要有ui_client那一种界面脚本，不是四种都要有。api+ui两边都要有：接口，加上这一种界面。分子齐了，比例才是 1。none不进分母，也不挂任务。

挂任务还要多一个条件：用例已经同步到禅道、Jira 或其它系统。两个条件都在，才进入第 17、18 篇。缺脚本就回去补对应的那一种，缺同步就回去--sync。

通过率不挡这一步。发版可以另要求通过率；生成和自愈过程里会碰到真实 bug，那些红是结果，不是没做完。代码行覆盖率、第 20 篇的四项数字，都不参与这道门。

第 16 篇 ·/autotest-task-query

看autotest/tasks/里已经有哪些任务、每条列入了哪些脚本、有没有组合报告。给了任务编号就只看那一条。

没有任务文件时，汇报「当前没有任务」，不会因此去建工作区或新建任务。这一篇不写文件，不跑脚本。建任务之前、开跑之前，都先用它看一眼，避免同名再建一条。

第 17 篇 ·/autotest-task-create

把若干已经生成的脚本收成一条本地任务，写入autotest/tasks/<id>.yaml。脚本路径必须已经在autotest/api/、autotest/ui-web/tests/、autotest/app/tests/、autotest/pc/tests/或autotest/miniprogram/tests/，至少一条。没有现成脚本就停，先走第 6 篇，或第 7 到第 10 篇里对得上的那一条。

同名任务已经在列表里，就停，改走第 18 篇追加。建完不执行。任务是一份名单，不是开跑按钮。

第 18 篇 ·/autotest-task-attach

任务已经在列表里，还有新的已生成脚本要放进去。新路径追加到名单末尾。已经在名单上的路径留着，不重复写，也不删除。

列表里没有这条任务，就停，改走第 17 篇。同样不跑脚本，不改脚本内容，不改被测工程。

第 19 篇 ·/autotest-task-execute

点名一条任务，按名单逐个跑，把每条的通过或失败收进autotest/tasks/reports/<id>.md，任务状态写成已完成。

脚本文件缺失，记为失败，继续下一条。失败只记录：不改脚本，不进入接口自愈，也不进入四条界面专项自愈，不改被测工程，不在这一步新生成脚本。要修，回到第 6 篇，或第 11 到第 14 篇里对得上的那一条，修完再决定要不要重新跑。

第 20 篇 ·/autotest-metrics

任务跑完之后可选。写入autotest/metrics.yaml，四项都要有当前值，没有数据就明确留空，并带上目标：

脚本齐套的覆盖率单独报一行，标明它才是挂任务的门禁。这四项不否决已经挂上的任务，也不用来填「覆盖率是不是 100%」。没有缺陷账本就不编数字。不在这一篇里自愈，也不改脚本。

第 21 篇 · 在 Claw 里用 Skill，在 VS Code 里加入 Skill

前面的命令要先被宿主看见，敲出来才会进对应的SKILL.md。这一篇不改链路顺序，不生成用例，也不跑脚本。操作步骤仍以仓库里的.cursor/skills/autotest-*/SKILL.md为准。换宿主时复制目录，不改里面的步骤。

三处落点：

name用小写字母、数字和连字符，并且必须和上一级目录名一致。对不上时，VS Code 会静默不加载。

在 Claw 上，工作区的skills/优先于~/.openclaw/skills。本专栏这些命令要显式点名，不让模型看对话自己套用，就在 frontmatter 里写disable-model-invocation: true，同时保持user-invocable: true，这样/skill autotest-init仍然可用。本地目录可以直接装进去：

openclaw skillsinstall./.cursor/skills/autotest-init--asautotest-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 到第 20 篇，不因为换了宿主就多做一步。

你从哪一篇进入

不必每次都从第 1 篇读到第 21 篇。先对一下自己卡在哪一层。

零基础从第 3 篇和第 5 篇开始，先有目录和一条本地用例。已经会写 Selenium、Playwright、App、桌面或小程序脚本的，从你卡住的那一端接，不必把前面的命令重做一遍。用例和脚本没齐，不进入任务和度量。

这个专栏不讲什么

• 不把通过率当成挂任务的条件。
• 不在写用例、写脚本、建任务时去扫线上用例，再把线上的当成本地真源。
• 不在批量执行时自愈，也不用自愈去改前端或后端工程。
• 不把AUTO_SCOPE=none的用例挂进任务。
• 不并行再讲一套「审查打分、五端矩阵、漂移阈值」当作第二条主链。那些不是这条斜杠链路的步骤。

跟做时仓库里会长出什么

走完主链，而不是只读完标题，仓库里应能指认这些文件：

autotest/ registry.yaml 第 3 篇创建，第 4 篇只改路径 cases/ 第 5 篇 sync/manifest.yaml 第 5 篇，且带了 --sync api/ 第 6 篇 ui-web/plans/ 第 7 篇，Web 的计划与判断 ui-web/tests/ 第 7 篇生成 app/tests/ 第 8 篇 pc/tests/ 第 9 篇 miniprogram/tests/ 第 10 篇，小程序 coverage.yaml 第 6 到第 10 篇写入，第 15 篇解释门禁 tasks/TASK-*.yaml 第 17、18 篇 tasks/reports/ 第 19 篇 metrics.yaml 第 20 篇，可选