让编程 Agent 自测界面并推送手机报告

编码代理改完页面，留下一句「测试全过」，并不足以让人放心。Kiteline 的做法是把真实浏览器检查写进默认启用的 skill：让代理用 Playwright 操作页面，再把步骤截图和测试结果发到手机。

这篇值得看的地方，是它把测试执行、失败处理和报告阅读串成了一条流程。但原文展示的是一套实现方案，没有给出缺陷检出率或团队效率的对照数据，不能直接推导出「代理已经能可靠验收自己的代码」。

代理说测试通过，还缺什么证据

作者认为，编码代理可能放宽断言、只覆盖顺利完成的流程，或者吞掉错误。因此，UI 修改完成后，还应该打开真实浏览器，按用户的操作路径检查。

Kiteline 是一个开源桌面应用，支持 Mac、Windows、Linux，配有 iPhone、iPad 和 Apple Watch 客户端，用来跟踪 Claude Code、Codex 等编码代理的会话。它安装的 skill 是一份指令文件，加上几个 CLI 命令，把浏览器验证变成代理工作流的一部分。

真正有用的交付，是测试结果之外还能看到操作过程。

这里也要分清：浏览器自动化依然依赖代理选择测试路径、编写断言。它增加了可检查的证据，却没有消除漏测。

怎样接入，才能少折腾项目

代理完成 Web 功能或修复，或者用户要求「test it」时，会优先使用项目已有的 Playwright，并把结果输出为 JSON。

如果项目没有 Playwright，就使用 e2e-setup 在 Kiteline 自身目录下创建的共享工作区，不向用户项目添加文件。机器已经安装 Chrome 或 Edge 时，会把它作为 Playwright 的浏览器通道使用，省去下载浏览器。

默认视口为 390×844，桌面站点则使用 1440×900。执行结果交给 report，转换成图片并发送到当前会话。对于 Python Playwright 等非 Playwright Test 运行方式，也可以提交一个小型 manifest，包含测试、状态、耗时，以及每个步骤的一张截图。

这套 skill 支持 Claude Code、Codex、OpenCode、DeepSeek Harness，也能安装到通过 Remote-SSH 连接的机器上。

失败处理是其中更关键的约束：代理要先判断测试错了还是功能错了；功能有问题就改代码，不能靠放宽断言或删除步骤让测试变绿。最终只发送最后一次运行的报告。

这个规则方向正确，但原文没有说明如何强制执行，也没有展示完整测试案例。它目前首先是一条行为指令。

手机报告为什么要重新排版

把桌面 HTML 报告直接塞进手机，通常很难快速阅读。Kiteline 将报告按 390 CSS 像素宽度布局，再以 3 倍比例截图，让文字在手机上保持正常大小。

报告先给一张概览卡，列出是否通过、测试数量、耗时和各项失败原因；随后每个测试按顺序展示步骤，每一步配一张截图。过长的测试会接到下一张卡，全页截图则只保留顶部。

每份报告最多九张图片，包括一张概览和八张测试卡，每次并行渲染三张。程序先读取渲染后的 DOM，测量卡片高度，再逐张截图。本机保留最近 20 份完整 HTML 报告，命令会打印保存路径。

这些细节解决的是阅读成本，同时也带来取舍：页面下方可能被裁掉，长流程也受到图片数量限制。手机报告适合快速检查，有疑点仍要回到完整报告。

我的判断

我赞同把重复要求固化为 skill。它默认开启，也能在 Settings 中关闭，用户不用每次提醒代理「记得打开浏览器测试」。相比每个项目临时写提示词，这种做法更容易保持一致。

但相比项目里持续维护的 Playwright 测试，它仍缺少原文未交代的部分：测试路径由谁审核，哪些回归场景必须覆盖，失败记录怎样保留。

同一个代理写代码又验收代码，仍可能重复自己的理解偏差。

只发送最后一次报告，能减少手机通知噪声，也会隐藏中间失败过程。原文没有对照数据证明这套方案比现有测试流程更可靠，因此更适合把它看作补充验收证据的工具。

Kiteline 表示，截图与报告在用户电脑上生成，再直接发送到手机；它不使用用户的 API keys，也不修改代理设置。桌面端采用 AGPL-3.0，iPhone 应用在 App Store 上名为 Kiteline。团队若考虑二次开发，许可证也需要纳入评估。

能拿来做什么

• 给前端任务补一份具体的验收路径，例如打开页面、填写表单、提交并检查结果，让代理按步骤操作和截图，减少只验证顺利流程的情况。
• 项目已有 Playwright 时，优先复用现有配置和测试约定；临时验证才考虑独立工作区，避免形成两套长期分叉的环境。
• 让代理处理失败时保留原断言，明确说明问题出在功能还是测试，并提交修复依据，不能只接受最后的绿色结果。
• 用手机报告快速检查页面状态和操作结果；遇到长页面、截图裁剪或步骤过多时，再查看完整 HTML 报告。