如何利用智能体上下文提高Playwright测试覆盖率
我不懂如何演奏乐器，所以显然我把它做成了一个应用。事实上，我家人人都能唱歌或演奏乐器，而我是那个格格不入的人。
我知道你在想什么，“谁会在乎？有了 AI，你几乎可以构建任何东西。” 我更兴奋的是我选择用来与我的代理一起构建这个应用的技术。具体来说，我使用了构建该应用的代理会话的上下文来查找并修复其 Playwright 测试中最重要的漏洞。
我是怎么做到的。
步骤 1：安装 Entire
Entire 捕获了由代理生成的代码背后的提示、转录、工具调用和决策，通过轻量级检查点将该底层上下文无缝连接到您的 Git 提交。
在 macOS：
brew tap entireio/tap
brew install --cask entire
查看这些 说明 以在您的操作系统上安装。
步骤 2：创建项目
我创建了一个空目录（或者您可以让您的代理来完成此操作）
mkdir music-app
cd music-app
步骤 3: 启用 Entire
在将任何工作交给代理之前，我直接在存储库中初始化了 Entire，因为我想捕获我的代理会话：
entire enable -y
您也可以针对特定的代理进行定位（我个人使用 Codex）：
entire enable -y --agent codex
这设置了 Entire 依赖的后台钩子，用于捕获代理活动，将该会话上下文直接绑定到过程中生成的提交。
步骤 4：将模糊的想法转化为计划
我并不是从一个严格的技术规格开始，而是直接分享了我的初步想法：
I'm not entirely sure about the app i want to build..but i want to build a music app that enables me to play instruments even though idk how..this should use computer vision and it should be able to work with real instruments or just like "air" instruments as in there's no instrument there..but i am moving fingers and sounds are being made..and it should like im making real music. idk if this should be sonic pi..but i know i should use media pipe for it. lets start working on a plan together
共同合作，该代理帮助将其细化为“Air Jam”概念：一个浏览器应用，MediaPipe 跟踪手势，自定义手势引擎解释它们，Tone.js 处理音频输出。
希望它也能作为学习工具，我接着进行了：
can it still show keys and chords etc..like still be a learning tool in some way
这增加了一个关键的新维度。除了作为有趣的新奇之外，该应用现在可以渲染音符，高亮显示活跃的音阶和和弦音，并最终分解正在演奏的音乐理论。
为了确定这一点，我让代理记录一切：
ok lets put this plan into a markdown file
它生成了 PRODUCT_PLAN.md，详细阐述了愿景、架构、开发阶段、MVP目标和明确的成功标准。
第一阶段专注于奠定基础：
- 引导浏览器应用程序。
- 请求摄像头访问权限并显示镜像视频。
- 集成 MediaPipe Hand Landmarker。
- 绘制手部关键点和置信度信息。
- 定义八根虚拟弦。
- 检测指尖穿过一根弦。
- 触发基本合成器音符。
- 添加滤波、滞后和音符冷却。
- 测量追踪速率和手势到声音的延迟。
最重要的是，它定义了一个明确的退出条件：故意的动作能够可靠地产生对应的声音，且误触很少。
步骤 5：设置原子代理提交
我更喜欢保持提交粒度小，这在代理需要触及代码库多个部分时尤其有帮助。为了强制执行这一点，我添加了一个仓库规则：
also in an agents.md write a rule that says every time we make a change to a file, make a commit
由于我不想立即提交该配置更改，我很快澄清：
no dont make any commits..just add the note
从那时起，代理在构建功能时创建了整洁、专注的提交。得益于 Entire，每一次提交都与创建它的确切会话上下文保持关联。
步骤 6：构建阶段 1
有了路线图，我们直接进入实现：
lets start with phase 1..gesture to sound experiment
代理人系统地组装了基础：
- 网络摄像头访问
- MediaPipe 手部追踪
- 八根虚拟弦
- 手势转音符
- Tone.js 音频
- 力度敏感音符
- 手势平滑和冷却
- 地标和弦可视化
- 免摄像头音符按钮
- 实时性能诊断
就这样，它就工作了。我可以挥动手指穿过虚拟弦，演奏出一个完全功能的空中竖琴。
步骤 7：生成 Playwright 测试
在扩展应用之前，我想要一个强大的浏览器测试套件来保护我们已经构建的内容。我保持需求广泛：
write some playwright tests
代理生成了五个通过的 Playwright 测试，覆盖：
- 初始界面
- 免摄像头的笔记按钮
- 启动和停止合成摄像头
- 摄像头权限错误
- 移动布局
在纸面上，一切都很顺利。但通过的测试套件并不自动意味着你在测试真正重要的东西。因为我自己没有编写代码或设计测试架构，我并不完全相信这五个测试实际上保护了核心用户体验。
步骤 8：启动新的代理会话
此时，我的原始会话已经消耗了大约 87% 的上下文窗口。
我通常会避免在代理的上下文变得非常拥堵时继续推送它们。这会让它们进入我所说的“愚蠢区域”。虽然代理在技术上保留了对话历史，但其优先处理关键细节的能力开始下降。
我通常的做法是压缩历史或启动一个新会话。我在这里选择了全新的开始，这并不是为这篇文章准备的分阶段设置，而是在花费较长时间进行规划、构建、调试和测试后的自然下一步。
步骤 9：将测试与原始意图进行比较
虽然新代理可以轻松读取代码，但我想让它使用 Entire 在我们之前的规划、实施和测试会话中捕获的丰富上下文来评估应用程序。
我将此提示传递给它：
look at the existing Playwright tests and compare to my entire sessions and checkpoints. Do they actually test the main user experience from beginning to end, or do they only test separate pieces of it? Tell me what important behavior is still untested, and show me what you found in the sessions that led you to that conclusion.
代理打开了 Playwright 套件，并与我们之前的 Entire 检查点进行交叉引用。Codex 总结了其发现：
我们测试了摄像头。我们测试了音符。但我们从未测试过移动手实际上会播放一个音符。
事情就这样了。它实际上并没有测试挥动手是否会播放一个音符，而这是该应用的根本目的。
深入研究该套件后揭示了原因：
- 摄像头测试使用了合成视频，但 MediaPipe 模拟始终返回零只手。它证明了视频馈送可以切换，但从未实际将手部数据通过系统传递。
- 音符测试通过直接点击 UI 按钮触发音频。它们证明了音符可以发声，但跳过了测试被追踪的指尖穿过虚拟弦时是否会触发一个音符。
Entire 为代理提供了具体的历史背景来支持这一认识：
- 原始规划检查点明确要求故意的运动必须产生恰好一个声音。
- 实现检查点将核心功能定义为围绕完整的摄像头-手势-音符反馈循环。
- 测试编写检查点显示，最初的五项测试范围仅限于基本 UI、按钮、摄像头切换、错误和布局。
步骤 10：添加缺失的 Playwright 测试
随着差距被暴露，我给出了最终指令：
generate tests for the missing gap
代理更新了 MediaPipe 模拟以提供逼真的 21 点手部坐标，模拟食指指尖在虚拟弦上扫过。
新测试验证了：
- MediaPipe 成功返回了被跟踪的手部。
- 指尖穿过了目标弦。
- 对应的 C4 音符被激活。
- 音符计数器恰好增加了一次。
- 手势结束后的稳定阶段未产生重复触发。
- 手势循环过程中未发生隐藏的浏览器错误。
这使我们的测试套件从五项增加到六项。除此之外，第六项测试不仅仅是增加数量，它直接映射回我们在最初规划会议中设定的成功标准。
什么使这个测试真正更好？
轻易伪造一个 bug 或添加一个肤浅的断言来编造一个好故事是很容易的，但这里并非如此。这个测试从根本上更好，因为它：
- 保护主要的用户旅程。
- 端到端地锻炼整个组件栈，而不是孤立地进行。
- 直接反映我们最初的成功定义。
- 使用确定性的合成地标，使其能够在没有物理摄像头的情况下在 CI 中可靠运行。
- 通过验证一个手势恰好产生一个音符来确保严格的可靠性。
需要明确的是，它并不能保证真实世界的 MediaPipe 模型会捕获每一种手部类型，或者音频会通过用户的扬声器实际播放。这些需要专门的冒烟测试或硬件测试。但它 确实 证明，当逼真的手部坐标到达应用时，整个手势到音符的管道会完美执行。
我不使用 Entire 来保存我的聊天记录并稍后滚动查看。相反，我把它交给我的代理，以便它作为历史证据来做出更好的工程决策。
请注意，我手写了其中的一部分，但对于大部分内容，我让我的代理查看我的会话上下文并将其变成一篇博客。因为我还有其他工作要做，我正在努力赶上进度！！
