现在让 AI 写代码，已经不算新鲜事了。Claude Code、Codex、Cursor 这类AI Agent，一句需求丢过去，几分钟就能把功能连同单元测试一起交上来。
但交上来的这些代码，谁确认过真的能用？
单元测试是AI自己写的，写什么测什么，自己出题自己答。页面渲染没渲染，接口通了没通，下单流程走不走得完，这些事单测管不着。很多团队现在的做法还是老一套，开发自测两下，测试同学手工点一遍，点不过来就赌它没问题。
AI 把写代码的速度提上去了，验证这道工序没有跟上。代码越交越快，欠下质量账越攒越多。
最近我在 GitHub 上翻到一个AI 自动化测试的项目：TestSprite-cli ，挺有意思，分享给大家。
TestSprite CLI 是个啥？
TestSprite 是西雅图一家做 AI 测试的创业公司，主业是云端自动化测试平台。今年 6 月 11 号，他们把平台的命令行入口开源了出来，就是 testsprite-cli。这个项目，记住几个关键信息即可。
- Apache-2.0 协议，TypeScript + Node 实现
- 4300+ star，197 fork
- 最新版本 v0.14.0，10 月 6 号发布，仓库 10 月 7 号还有提交
- 官网还宣传从 URL 到首批 50 到 100 条端到端用例约 10 分钟，以及 10 万开发者在用。这类口径没法核验，听听就行。
它干的事很简单，一句话概括：就是当你的AI Agent改完代码后，CLI 会打开真实运行的应用，像一个真人用户那样把功能走一遍，坏了就拿回一份完整的失败报告，交给Agent自己修。
官方给这类工具起的位置叫验证层，verification layer。写代码的环节 AI 化了，验证环节也得 AI 化，而且要接在 AI 自己手里。
0 代码写测试，一条用例是一个 JSON
用 Playwright 写一条登录校验，你得找选择器、配等待、写断言，几十行起步，选择器一变还得回来改。在这个工具里，一条测试是一个计划文件，描述你要保证的行为。
{
"projectId": "prj_abc123",
"type": "frontend",
"name": "Login rejects an empty password",
"planSteps": [
{
"type": "action",
"description": "Navigate to /login and submit the form with an empty password"
},
{
"type": "assertion",
"description": "Verify an inline error says the password is required"
}
]
}
整个文件里没有一行浏览器代码。action 和 assertion 都是自然语言描述，上传后云端把它变成真实点击、真实导航、真实请求，跑在云端的真浏览器和真 API 上。README 里有一句原话很直接，Not a mock。
前端走这条路。后端测试走 Python，在云端沙箱里直接跑测试函数，沙箱预置了 requests、pytest、numpy、scipy 这些常用库。后端用例之间还能编排依赖，造数据、用数据、收尾清理这几类用例按顺序串起来，变量往下传。前后端在一个套件里一起管。
不想自己写第一批用例，还有生成这条路。test plan generate 让平台探索你的应用或者读你上传的 API 文档，起草一批用例放在服务端等你审，看中哪条收哪条。
跑挂了，能自动生成失败详情包
测试跑挂了，最烦的是排查。截图在 A 系统，日志在 B 系统，DOM 是三天前抓的，拼在一起看半天，发现看的已经是两个版本的东西。
这个工具的失败报告设计得讲究。test failure get 拉下来的是一整个包，失败步骤、前后相邻的步骤、截图、DOM 快照、测试源码、根因假设、建议修复的位置，全在里面。所有材料共享同一个 snapshotId，CLI 明确拒绝把两次运行的数据拼在一起。
这个设计明摆着是给 AI 读的。Agent有个拿手好戏，拿着缝合的上下文一本正经地推理，把证据钉死在同一次运行里，它就只能对着真实现场说话。人读这份包也一样省事，排查一个失败不用再跨三个系统翻材料。
整条路径循环
AI每次改完代码，先问一个问题，这个行为套件里覆盖了吗。
没覆盖就 test create，用一个新的计划文件描述新行为。已经覆盖就 test rerun，把现有用例重放一遍，确认没改坏。挂了就 test failure get 拿失败包，修完重跑。每一次通过都存进长期套件，覆盖面跟着项目一起长。
云端那一层是故意做成黑盒的。Agent只描述意图、读结果，不需要知道测试是怎么被驱动的，只看真人用户会遇到什么。
一条命令，接进Claude Code、Codex
这是 setup 命令干的事。
npm install -g @testsprite/testsprite-cli
testsprite setup
setup 验完 API key，会探测你项目里在用哪些AI Agent，把一套现成的 skill 文件落进仓库。官方支持 8 类主流Agent，Claude Code、Codex、Cursor、Cline、Windsurf、Antigravity、Kiro、Copilot。
skill 里写的是硬规矩，我读的时候印象很深。功能完成后就会自动跑一次验证，不许攒到收尾放大招。允许跳过的场景收得极窄，纯文档改动、纯构建配置、缺凭证，其余都要跑。每个功能至少一次跑到通过，才许说做完了。
这些规矩针对的就是许多AI Agent的老毛病，标完 done 就收工。装上 skill 之后，Claude Code 或 Codex 写完功能，会自己去建测试、跑测试、读失败包、修完重跑，整段不需要人介入。
平台侧另有一个 MCP Server 给 IDE 用，同一个验证引擎的另一条入口，走哪条看习惯。
本地起的服务也能测
前面的例子默认应用已经部署了。本地开发时应用跑在 localhost，云端够不着，它的解法是隧道。
testsprite project create --type frontend --name "My local app" --local 3000
testsprite test run <test-id>
跑测试时 CLI 自动开一条隧道，控制面走 WSS，数据面走 TLS，把本机回环地址接到云端测试机，免费档也能用这条通道。计费按次，前端重跑一次 0.5 积分，后端 0.2。本机不部署就能拿到云端真实浏览器跑出来的结果，这个体验对前端同学很友好。
接进 CI
--wait 模式下跑挂的用例，会在 GitHub PR 的检查页逐条标注，一条失败一行，汇总表追加到 job summary。--report junit 输出 JUnit XML，现有流水线怎么接就怎么接，不挑 CI。
几个要留神的点
- 测试怎么被驱动的过程看不到。云端黑盒是设计选择，对使用者意味着排障只能依赖失败包给的材料，想自己插一脚调试做不到
- 后端测试在沙箱里跑，不能 import 你项目的代码，纯 HTTP 接口测试没问题，要连本地数据库、依赖项目内模块的场景就不合适
- 平台是收费生意，CLI 是开源入口。跑起来按积分计费，量大了要掂量成本。
- AI 生成的用例质量仍要人把关，断言写得太松，跑一万遍也是绿
我的几条建议
1、天天让编程Agent交活的，装上让它自己验收
两条命令的成本，免费档就能跑。Agent写完自己过一遍真实浏览器，比你手工点省事，也比完全没人点强。
2、做测试开发的，把它的设计拆开看
自洽失败包、稳定的 JSON 输出契约、写给Agent的验证纪律 skill，这三个设计都值得抄。特别是第一件，怎么给 AI 喂一口干净的排障上下文，往后所有测试工具都得回答这个问题。
3、管质量的，盯住回归套件只增不减
它把每次通过的用例都存进长期套件，这正是回归资产该有的长法。AI 交活越快，这种只涨不清零的验证资产越值钱。
写在最后
这个项目最让我在意的一点，是它把「谁说做完了」从一句口头承诺变成了一道可执行的工序。AI说 feature complete 的时候，以前靠人去戳穿，现在有一条命令替你去戳。
当然，工具本身大家可用可不用。TestSprite 走云端积分计费，这套模式会劝退一部分团队，不合适就不必硬上。但文章里那几个设计思路是通用的，给 AI 喂自洽的排障上下文、把验证纪律写成 skill 立成硬规矩、让通过用例存进只增不减的回归套件，这些搬进自己的工具和流程里照样成立。
推荐一个开源项目，不是让大家都要去用它。把这些思路学走，用回自己的项目里，这才是看开源项目该带走的东西。
地址放这了。
GitHub 👉 github.com/TestSprite/…
官网 👉 www.testsprite.com/
觉得有用，欢迎转给团队里天天收 AI 代码的同学。
