大家好，我是 Kevin，来自西班牙，是开源测试工具 TWD 的维护者之一。我的中文还写不了这么长的文章，所以本文借助 AI 翻译。
上周，一个 Agent 在我的仓库里提了一个 Pull Request。改了 11 个文件，新增 3 个测试，全部通过。
那你到底该检查什么？
你可以读 diff，也可以读测试文件，看它断言了什么。但这两样告诉你的，都是 Agent 以为自己做出了什么。它们都不能告诉你，真正使用这个功能的人会看到什么，而有意思的问题恰恰藏在这个差距里。
我加了一个标签。一分钟后，Pull Request 下面多了一条评论：
Recording: 3 clip(s), one per test this branch added.
（录制：3 个视频，这个分支新增的每个测试各一个。）
三段短视频，对应这个分支新增的三个测试。我不到一分钟就看完了，了解到的比读了五分钟 diff 还多。
绿勾变得廉价了
二十年来，一个通过的测试大致可以说明「有人认真想过这件事」。人先写测试，再写代码，直到测试通过。测试承载的是另一个人的意图，至少也是同一个人在另一天的意图。
当 Agent 既写代码、又写证明这段代码的测试时，这种分离就不存在了。测试不再是独立的检查，而是同一个模型的观点，说了两遍。
这并不意味着测试没有价值。它让测试从证据变成了声明。证据不需要再核实，声明需要。
我找到的最便宜的核实方式，就是看着它跑一遍。
测试文件告诉你它断言了什么，而不是它看起来什么样
下面这个测试能通过，却没有证明任何有用的东西：
const el = await screenDom.findByRole("button", { name: "Add project" });
twd.should(el, "be.visible");
按钮存在，而且可见。测试是绿的。
但也有可能：这个按钮压在了标题上；它所在的空状态渲染在了首屏之外；或者点它根本没有反应，因为还没人要求它做什么。这些情况都和一次绿色的运行完全兼容，而在测试文件里一个都看不出来。
你没法靠更仔细地读代码发现它们，只能靠亲眼去看。
是确定性的，不是演示
让它真正有用、而不只是装饰的关键区别：视频是由测试运行产生的，而不是由人录的。
演示视频是一场表演。有人在自己的电脑上、在恰好能跑通的那一刻把应用走了一遍，视频保存的那一秒就开始过时。半年后，它展示的是一个已经不存在的界面，却没人注意到，因为没人会重新录。
测试录屏就是产生那个绿勾的同一次执行，被录了下来。重新跑一遍测试，就得到新的视频。行为变了，视频也跟着变；或者测试失败，根本没有视频。它不可能和代码脱节，因为它就是代码在运行。
正因为如此，它可以放心地附在 Pull Request 上，也可以放心地保留下来。
让视频能看下去的节奏细节
我第一次尝试录制测试时，得到的视频几乎是一闪而过。测试以毫秒为单位运行，忠实地录下一个很快的测试，结果根本没法看。这也是为什么大多数类似的尝试最后都悄悄放弃了。
twd-cli 不是事后把视频放慢，而是在执行时控制节奏：
npx twd-cli run --record --test "checkout flow"
帧以全速采集，停顿落在刚刚发生了变化的地方。默认每个操作之间间隔 300ms，可以用 --record-pace 调整：
npx twd-cli run --record --record-pace 500 --test "checkout flow"
控制运行节奏和放慢视频文件，区别比听起来更大。放慢的视频从头到尾都一样拖沓；控制了节奏的运行则有节拍：点击，停一拍，然后是结果。你跟得上。
每个匹配的测试输出一个文件，以测试名命名：
twd-artifacts/
todos-adds-a-todo.mp4
todos-marks-a-todo-done.mp4
在 CI 中，只录变化的部分
每个 Pull Request 都录制整套测试，只会产生一堆没人打开的存档。真正会被人看的做法，是只录制这个分支新增或修改过的测试：
uses: BRIKEV/twd-cli/.github/actions/record@v1.8.0
with:
changed-since: ${{ github.event.pull_request.base.sha }}
这个 action 会安装 ffmpeg、执行录制、把视频作为 artifact 上传，并返回视频数量和一个 URL，你可以把它们放进 Pull Request 的评论里。参数说明见 twd.dev/recording#r…。
一个 Pull Request 上有三个视频，是评审的帮手。四百个视频，就成了数据保留的问题。
它到底是给谁的
看不懂测试的人。 产品负责人看 15 秒就能说出「这不是我想要的」。对着测试文件，他们说不出这句话，而且也不会告诉你他们看不懂。他们只会点「批准」。
半年后的你。 改变这个行为的 Pull Request 里有一段视频。要回答「这里以前是什么样的」，它比任何代码考古都快。
下午五点的你。 评审 Agent 的产出是一种新的、而且确实很累的工作。瓶颈不再是代码写得多快，而是你实际能检查多少。在我试过的方法里，按每秒注意力能获得的信息量来算，视频是最高的。
成本是什么
一个标签，或者一个参数。录制需要 ffmpeg 8 或更高版本，twd-cli 会在启动浏览器之前检查它，所以你得到的是一个明确的报错，而不是一个损坏的文件。
在我的仓库里，它是 Pull Request 上的一个 record 标签，等 Agent 完成工作之后再加上。不是自动的，因为不是每个改动都值得录视频，而决定这件事的人是我。
这就是全部的取舍：一分钟的 CI 加一分钟的观看，换掉「反正是绿的，扫一眼 diff 就批准」。
如果你对 TWD 感兴趣，可以看看 GitHub 仓库 BRIKEV/twd，欢迎 star 和反馈。你们现在是怎么评审 AI 写的代码的？欢迎在评论区聊聊。
