Simon Willison 在 shot-scraper 1.10 里加了一个新命令：shot-scraper video。

它读取一个 storyboard.yml，按里面写好的步骤打开网页、点击按钮、填写表单、等待结果，再用 Playwright 把这段 Web 应用流程录成视频。

有意思的地方不在“又多了一个录屏工具”。它更像是在回答一个很实际的问题：编码 Agent 说自己把功能做完了，开发者怎么更快确认它真的跑通了？

过去常看的证据是 diff、测试结果、终端日志。现在多了一个东西：Agent 可以顺手生成一段可播放的 Demo。对 UI、后台管理、数据工具这类功能来说，看 30 秒视频，往往比读一页说明更快。

storyboard.yml 解决的是“演示不可复现”

Willison 展示的 Demo 来自 Datasette 一个仍在开发中的分支。

视频里演示了两件事：从粘贴的 CSV、TSV 或 JSON 创建新表；向已有表批量插入行。这里要注意，Datasette 的这个新建表能力在原文里还是开发中功能，不是正式发布功能。

shot-scraper video 的输入是 YAML 剧本。剧本里可以写本地服务启动命令、目标 URL、视口尺寸、等待条件、点击、填充文本、暂停和页面跳转。示例命令还用了 --auth JSON 文件注入 cookie，并通过 --mp4 导出视频。

这让演示从一次性录屏，变成一份可读、可改、可复跑的工程资产。

对比项手工录屏shot-scraper video
操作来源人手点击YAML 剧本驱动浏览器
结果形态视频文件视频 + 可复现步骤
适用场景任意屏幕内容Playwright 支撑的 Web 应用流程
对 Agent 的价值需要人接手录制Agent 可按说明生成 Demo
现实限制难维护、难复跑不等于完整测试覆盖

它和 Playwright Test、Cypress 这类端到端测试有相近之处，但目的不同。

E2E 测试更关心断言、回归和稳定性。shot-scraper video 更偏向“给人看”：让审查者快速理解功能路径。它不是测试的替代品，而是测试报告之外的一层证据。

对使用编码 Agent 的开发者，比较直接的动作是：以后让 Agent 改完 Web 功能，不只交 diff，也交一个 storyboard.yml 和生成的视频。尤其是后台表单、数据导入、管理界面这类流程，最适合这样做。

Agent 能生成 Demo，前提是工具说明写给机器看

这次示例里的 datasette-bulk-insert-storyboard.yml，是 GPT-5.5 xhigh 在 Codex Desktop 中生成的。

Willison 给它的提示大致包括几步：查看 Datasette 分支变化；进入 shot-scraper 仓库运行 uv run shot-scraper video --help；启动本地 Datasette 服务；针对演示数据库录制新功能 Demo。

这条链路里，最关键的不是模型名字，而是 --help。

Willison 认为，一个 CLI 的 --help 如果写得足够清楚，就像把 SKILL.md 直接打包进工具。Agent 不需要猜这个命令怎么用，可以先读帮助，再调用工具。

这对维护 CLI、自动化测试工具、内部开发平台的人很有提醒意义。过去 --help 主要写给人看。现在它还可能是 Agent 使用工具的入口。

更现实的改法也很具体：

  • 把常用命令参数写完整，不只写参数名。
  • 给出最小可运行示例，而不是只放抽象描述。
  • 明确输入文件格式、输出位置和错误边界。
  • 让 Agent 能从 --help 里推导下一步，而不是到处翻文档。

不过，不能把这件事理解成“作者退出了开发”。

Willison 明确提到，代码和文档很多由 GPT-5.5 xhigh 生成，但他通过审查文档发现冗余、不一致和混乱之处，再要求调整设计。YAML 格式也主要由编码 Agent 定义，但他让 Agent 使用 Pydantic 来定义和校验格式，方便审查。

这才是比较健康的 Agent 用法：机器负责推进大量实现，人负责判断边界、删掉坏设计、把接口收紧。

真正该看的是 Demo 能否进入代码审查流程

shot-scraper video 能落地，也不是只靠大模型。

它依赖 Playwright 的底层能力变化。Willison 早年试过类似功能，但当时 Playwright 生成的视频更偏调试用途，会带上不适合作为产品 Demo 的浏览器 chrome。后来这个问题改善了，但仍有启动阶段白帧等细节阻碍。

关键变化出现在 Playwright 1.59。它加入新的 screencast 机制，让录制过程有更细粒度的控制。

但当时还有一个问题：生成视频固定为 800px 宽。直到 playwright-python 1.61.0 发布，解除这个限制后，Willison 才完成 shot-scraper video。

所以这件事给出的信号很清楚：Agent 工作流要真正好用，不能只看模型能力。它还需要自动化框架、可验证配置、格式校验和足够清楚的工具说明。

接下来最该观察的，不是它能不能支持更多视频玩法，而是这套模式会不会进入日常代码审查：

观察点如果成立，会发生什么如果不成立，问题在哪里
PR 是否附带 Demo 视频审查者先看功能路径，再看代码细节视频仍停留在临时展示材料
Agent 是否能稳定生成 storyboard开发者把录制步骤交给 Agent人还要大量修录制脚本
CLI --help 是否足够可执行工具更容易被 Agent 调用Agent 继续靠猜，失败率高
Demo 是否和测试配合视频证明路径，测试守住边界happy path 被误当成交付完成

我更在意最后一项。

Demo 很容易展示 happy path。它能证明“这条路径跑通了”，但不能证明产品已经可靠。异常输入、权限问题、并发状态、安全边界，仍然要靠测试和审查。

更合理的用法，是把视频当成审查入口，而不是验收终点。

如果一个 Agent 改完功能后，能同时交出代码、测试、storyboard.yml 和 Demo 视频，开发者的判断成本会下降很多。不是因为它更会表演，而是因为它给了人一条可检查的证据链。

这也是 shot-scraper video 最值得看的地方：它把“相信 Agent 做完了”，往“检查 Agent 做到了”推了一步。