为什么要先把测试收成一条链路-育师

专栏第 1 篇。没有命令。先把立场说清楚，后面每一篇 Skill 才不会被学成孤立的脚本生成器。

周一的站会常常是这样：研发说模型已经把这个迭代的接口和页面都改完了，昨晚还用编程智能体搭了一条新的智能体流程，下午试用，方向不对今晚就删。测试打开三处——禅道里一份上季度的用例，仓库里一批去年还能跑的脚本，平台上一个名叫「全量回归」的任务。三处对不上。页面上一个按钮换了位置，脚本红一片。有人提议再招两个人，把回归加满。

加人能多排两轮手工。它赶不上两件已经发生的事：AI 编程把变更压进一天，智能体按天生成、按天扔掉。测试还按「每个项目配几个人跟着点、跟着改脚本」在排。两条曲线不在一个数量级上。

所以这个专栏先把测试收成一条链路，再谈生成脚本。同一次变更的用例、脚本、任务和报告落在同一处，用 AI 在当天发现问题、当天把该测的跑完。每一步只做一件事，做完才知道下一步缺什么。

AI 编程现在有多快

一个会用编程智能体的研发，同一天里可以让模型读仓库、改接口、改页面、补上调用，本地跑起来，再把几个小改动一起合进去。过去要排进一个迭代的重构——目录重铺、交互换皮、接口成批生成——现在常常压进一周，赶的时候压进一两天。变更的单位从「这个版本」变成「今天合进去的那一批」。

你听到的	测试当天要面对的量
先让模型出一版，能跑再说	接口和页面可以在同一天一起改完
今天合并了十几个小改动	按「全部再点一遍」排，当天排不完
需求就是聊天记录和一版演示	等文档齐了再写用例，这批改动已经又变了
再开一个编程智能体并行改	人还在看上一处 diff，下一处已经合进来了

单个稳定产品上，测试部按项目排人仍然成立。多仓库并行、模型在写代码、方向说扔就扔，这三件事叠在一起时，按项目加人的产能跟不上变更。要补上的是一条默认会在当天发生的闭环。

智能体正在按天扔掉

日抛是现在很多智能体产品的节奏：一条工作流、一个工具页、一套提示词和工具调用，上午生成，下午给几个人试用，方向不对，第二天目录就删了。文档来不及写，测试部的迭代日历还停在上周。

试用当天，创建、回车、权限、工具有没有调对，这些问题已经发生在用的人身上。两周后的全量回归排上时，这个智能体可能已经不在仓库里。留下的如果只有一份还没排期的计划，这一天等于没有测过。

测试要跟日抛发生在同一天。这次变更写进用例；该自动化的，当天生成脚本并跑；跑红了，当天分清是脚本坏了，还是产品坏了。产品坏了就留下 bug。方向如果明天扔掉，留下的是这一天的证据。

有的智能体明天就会删，不必为它建一套长期回归。那种变更在用例上标成不自动化，写完即停。值得留下的，才进入脚本和任务。这个判断要在当天做出。排期若还停在上周，方向已经扔了。

测试用 AI 加快发现，也加快把测试跑完

编程侧已经在用模型写代码。测试侧用同一类能力做两件赶时间的事。

快速发现问题。对着这次 diff、页面和接口，让模型先把行为写成用例，再生成脚本跑一遍。失败当天分类。路径、字段、定位或断言写错，改已经生成的测试脚本再跑。断言和约定一致、实现不对，当场记成 bug，留在这次结果里。合入当天就能看见这个问题。

快速测试。一次变更按用例决定测接口、测一种界面，或两边都测。界面按 surface 只走桌面 Web、App、PC、小程序里的一种。H5 会停并点名自己的命令，不用 Web 脚本去包。脚本齐了就在本地跑完，拿到报告。全量「再点一遍」留到发版再看。日抛的智能体等不到那一轮。

规格先写在 OpenSpec 里。proposal.md、design.md、specs/、tasks.md定下这次做什么，Skill 再按这份规格去建工作区、写用例、生成脚本。同一份 Skill 可以放进 Claw，也可以放进其它能调用 Skill 的工具。换工具不改步骤。

快要有落点。模型一个下午可以写出一仓库互相指不上的文件，发现得快，散得也快。链路把速度关在固定次序里：先用例，再脚本；红了只改测试脚本；产品问题留下来；任务只跑已经生成的脚本。AI 用在发现和执行上，用例、脚本、报告仍能在目录里指认。

维护税从半天变成一周

测试同学对「脚本会坏」并不陌生。以前研发改一个控件、挪一条路由、换一处文案，定位器红一片，平台上的任务要重跑，还要花时间分清：是产品变了，还是脚本脆。线性脚本扛过这笔税，自动化平台也扛过。平台把「在本地改脚本」换成「在平台上改用例，再等执行队列」，税还在，只是换了地方交。

模型写码之后，一周里可以做完过去要排一个迭代的重构：目录重铺、交互换皮、接口成批生成。专人跟着修脚本、跟着改平台用例，队列会堵住。研发要么干等，要么绕开。把自愈放进链路，是承认脚本会坏，并且规定坏了之后谁可以改哪一类文件、改到什么程度必须停。接口脚本在生成执行里最多修 3 轮。已经红了的桌面 Web 脚本走/autotest-ui-heal，只改autotest/ui/tests/里已有的文件。产品行为不对的时候，结果里留下失败，断言保持原样。

变更体量	靠人跟着改的下场
局部控件、局部文案	花半天能改完，团队还扛得住
一周内大面积重构	专人改脚本和平台用例跟不上，门禁会被绕开

三笔账

周报里往往同时有三句话：回归越来越贵；流水线是绿的，线上仍能炸出本该拦住的洞；缺陷单关了，下个迭代还在同一处摔。这是三本不同的账。

账	你以为买到了	实际常买到
时间账	更多回归轮次	夜间全量、白天排队。跑得更长，仍说不清这次变更该测哪一层
信任账	更多绿勾	绿说明这批脚本这次跑过了。它不说明该有的脚本已经齐，也不说明产品行为是对的
记忆账	更多已关闭的缺陷单	单子会关。用例和脚本如果没有同一条补上的出口，下次还在原处摔

再招两个人把回归加满，时间账可以暂时多跑几轮，人还是跟着改，长期更贵。信任账几乎不动：绿勾变多，齐套和真实缺陷仍写在同一列里。记忆账几乎不动：缺陷关了，用例和脚本仍散在三处。

智能测试先改这三本账的记法。执行机器可以再换一台，记法不变，三笔账还是原来的三笔。

记法换成这样：

时间。一次变更先按 PR 或规格写用例，再决定写接口、写桌面 Web、两边都写，或这次不自动化。不把「全部再点一遍」当成唯一安排。
信任。能不能进入下一步，看范围内脚本齐不齐。通过率留给发版。生成和自愈过程里发现的真实问题留在结果里。
记忆。用例、脚本、任务、报告都落在仓库的autotest/里。补一次测试，能指着目录说清补的是哪一层。

只再生成一堆脚本，链路还是断的

自动化擅长把已经写好的步骤重复跑。模型也很会在一次对话里写出很多文件。文件多，仍然回答不了这几句：

工作区在不在，前后端路径还指不指得对。
用例写在本地。本课程不把用例交到外部系统。
这条用例要测接口、测桌面 Web、两边都测，还是这次不需要自动化。
红了是脚本写错，还是产品行为不对。写错可以改已经生成的测试脚本。产品错了就记下来，停止把这条改绿。
范围内该有的脚本齐了没有。齐了，才把它们收成一条任务。
跑任务的时候只跑、只记、只出一份报告。修脚本是另一站的事。

这六句没有固定顺序时，脚本越多，越不知道哪一份算数。生成得快，散得也快。先收成链路，就是让这六句按固定次序发生，每一步做完留下能指认的文件，下一步只看上一步缺了什么。

顺序就这一条：

没有目录就先建 路径旧了只刷新路径 本地用例 按用例写接口脚本，或写桌面 Web 脚本 已有 Web 脚本红了，走 `/autotest-ui-heal` 该有的脚本齐了，覆盖率才算到 编成一组，跑出一份报告 跑完可以再看四项度量，度量不改「能不能挂任务」

这次不需要自动化的用例，写完就停。查外部任务、建外部任务不在本课程，不发起请求。

谁来跑，谁来维护

负责	做到什么程度
研发	按命令完成这次变更的用例、脚本、任务和执行	点名哪条命令，就只做那一件事。缺哪一层，就补哪一层
测开	把「怎样算走对了」收成 Skill、门禁和边界	维护命令，使每层的判定稳定。不替每个仓库把页面点一遍

测试执行由研发在命令里完成。测开维护的是方法：什么时候该停，什么文件允许改，什么数字不能拿来挡下一步。

功能测试还在。有的变更要人看产品、做探索，判断结果是「这次不自动化」，链路就在用例处结束。大模型测评、智能体测评、性能专项仍要专人做，它们不在这条链路里。这条链路解决的是：交付所需的那一层测试执行，有一条可以重复走的路。

读完应能说清的四句

AI 编程把变更压进一天，智能体按天生成、按天扔掉。测试用 AI 在同一天发现问题、把该测的跑完。按项目加人、靠专人跟着改脚本，时间账、信任账、记忆账会一起变贵。
脚本要落在固定目录里，并且先有用例，再决定写接口，还是写桌面 Web。
研发自己发命令。测开维护命令、门禁和边界。
能不能进入下一步，看该有的脚本齐不齐。真实 bug 留在结果里。通过率是发版要看的数字。