我今天从我的人工智能代理那里看到的最意想不到的单元测试是检查视频中的推送通知不能在其动画图表中的价格达到目标之前出现。一个单元测试。为一个视频。🤯 我需要一个 15 秒的宣传视频来宣传我的副项目 Petroly，一个燃油价格应用。Claude Code 顺利地写了一个 JavaScript 渲染器，重用了我应用的设计。我可以用简单的语言描述一个变化，观看结果并进行完善。我从未打开过视频编辑器。图表、通知、排序动画和过渡都在源代码中。我可以更改它们，查看差异并重新渲染。我们越是对其进行改进，我看到的可能性就越多：关于时序的测试、来自应用的翻译，甚至是带有透明边角的视频。一个视频。用代码编写。自己运行渲染器 在观看完成的视频之前，试着拖动它。你在下面看到的不是一个视频文件。你的浏览器运行着同样的渲染核心，生成视频。滑块的每个位置都向它请求一个新的 SVG 框架。更改语言、跳转到场景，或者打开 SVG 看看代码产生了什么。不是视频文件 拖动时间 你的浏览器正在运行着同样的 frame(t) 函数，渲染了广告。滑块的每个位置都向它请求一个新的 SVG。正在加载渲染器…… 正在加载帧…… 25 帧每秒 秒数 语言 显示此帧的 SVG 没有预渲染的图像。图表、通知、排序列表和二维码都是为你选择的确切时刻计算的。选择一种语言，复制、货币、数字格式和二维码目标会随之更改。视频是时间的函数 其核心概念很简单：frame(timeInSeconds) // → 该确切时刻的 SVG 字符串 在两秒时，函数绘制开头。稍后，它绘制价格图表越过目标并出现通知。再稍后，车站列表自己排序。每个位置、淡出和弹跳都是对 t 的一点算术。为了将其变成视频，渲染器请求 375 帧，15 秒内每秒 25 帧，并将其流式传输到 FFmpeg。将处理流程缩短为 writeToFfmpeg，循环看起来像这样：for ( let i = 0; i < DURATION * fps; i ++ ) { const pixels = await sharp (Buffer. from ( frame (i / fps))) . ensureAlpha () . raw () . toBuffer (); await writeToFfmpeg (pixels); } 时间 → SVG → RGBA 像素 → FFmpeg → 视频。sharp 将每个 SVG 转换为像素。FFmpeg 编码帧并添加配乐。如果通知应该稍后到达，那就是源中的一个数字。如果我想检查一个瞬间，我可以渲染出那个确切的帧。使用相同的输入，渲染器会生成相同的帧序列。创意部分是一场对话 第一轮渲染给了我一个反应的基础。从那里，过程显得出人意料的熟悉：查看结果，描述应该改变的内容，并回顾下一个版本。有些请求很小：让排序控制上的点击显示得更久一点，稍微向左移动，去掉多余的边框。其他请求则改变了整个场景的工作方式。清晰地展示选择。车站比较变得比普通的最便宜时间图表更有用。街道名称对演示的贡献不大，而且很难阅读。这些行现在使用应用自己的价格类别和颜色，从“非常便宜”到“非常贵”。给运动一个理由。一个可见的点击将排序从距离改为价格。其他行淡出，而最便宜的站点移动到最上面，勾选标记在行稳定后出现。你可以跟踪发生了什么以及原因。每个请求都变成了代码更改和新的预览。我可以并排比较版本，保留我喜欢的部分。Git 可以将渲染器及其预览一起保留。代理处理了实施。我仍然需要观看并评判。几种技术上正确的版本感觉过于繁杂。那部分需要我的眼光和品味。我的代理为视频编写了单元测试 这是让我感到意外的部分。在价格提醒场景中，推送通知不能在绘制的价格到达目标之前出现。代理将该序列转换成一个测试。省略设置和导入，想法可以用几行代码表达：test('警报在价格达到目标后跟随' , () => { const scene = SCENES.find((scene) => scene.kind === 'alert'); const targetReachedAt = scene.from + ALERT_AT; const before = frame(targetReachedAt - 0.1 ); const after = frame(targetReachedAt + 0.1 ); assert.doesNotMatch(before, / id="push-notification" / ); assert.match(after, / id="push-notification" / ); }); 渲染器根据绘制的价格和图表的动画时序计算 ALERT_AT。添加场景的开始时间就得到了目标到达的时刻。在此之前，没有通知。在此之后，有通知。自动化测试确保此序列在每次编辑后仍然有效。