每天精通一个 claude code skill -- playwright-cli

每天精通一个 Claude Code Skill —— Playwright CLI

今天我们来认识一个新的 Claude Code Skill：Playwright CLI。

这个 Skill 主要用来提升 Claude Code 在前端开发中的表现。平时我们让 Claude Code 写后端代码时，它通常可以自己写测试用例，然后通过接口测试、单元测试等方式检查代码是否正常。但前端不太一样。前端除了逻辑和接口，还涉及页面布局、组件位置、按钮状态、弹窗时机、视觉层级等问题。很多时候，Claude Code 改完前端代码后，只会关注功能有没有接上、接口有没有调用成功，却不一定会注意页面是否美观。比如按钮位置偏了，组件跑到不合适的位置，某个弹窗在错误阶段出现，或者页面整体看起来不协调。这些问题如果只靠代码检查，很难发现。

这时候，Playwright CLI 就很有用了。

它可以让 Claude Code 像真实用户一样操作浏览器，比如点击按钮、填写表单、切换页面、触发弹窗等。同时，它还可以生成前端页面截图，让 Claude Code 不只是“读代码”，而是能够真正“看到页面”。这样一来，它就可以根据页面截图判断界面是否异常，并进一步优化前端效果。

name: playwright-cli
description: Automate browser interactions, test web pages and work with Playwright tests.
allowed-tools: Bash(playwright-cli:*) Bash(npx:*) Bash(npm:*)

入门级玩法

Playwright CLI 最基础的用法，就是让 Claude Code 进行前端自动化测试。

比如我们可以让它模拟用户完成一整套操作流程：打开页面、登录系统、填写表单、点击提交、查看结果。这个过程本质上就是一次完整的用户行为测试。相比只检查代码，它更接近真实用户的使用场景。它还有一个非常实用的能力：截图。Claude Code 可以在关键步骤自动截取页面，并把截图保存到项目文件夹里。这样我们就可以直接查看每一步的页面效果，判断流程是否正常、组件是否显示正确、页面是否有明显问题。

这个能力可以引申出一个很常见的用途：写操作手册。如果一个系统包含多个复杂业务场景，手动截图会非常麻烦。你需要自己一步一步操作页面，再一张图一张图保存，最后整理到文档里。使用 Playwright-cli 后，我们可以让 Claude Code 自动模拟这些流程，并在关键节点生成截图。

比如：

1. 打开系统首页。
2. 进入某个业务模块。
3. 填写表单信息。
4. 点击提交按钮。
5. 查看结果页面。
6. 保存每一步截图。

这样一套流程下来，操作手册需要的素材就基本准备好了。后续我们只需要检查截图是否正确，再把它们整理到文档中即可。

更重要的是，Claude Code 自己也可以通过这些截图理解页面状态。它不再只是根据代码猜测页面长什么样，而是可以直接看到最终渲染效果。这样它就能更容易发现一些前端问题，比如组件错位、按钮层级不明显、表单区域太拥挤、弹窗显示时机不对等。

进阶玩法

Playwright CLI 默认只是截图，但我们可以继续把它用得更细。比如在生成操作手册截图时，我们可以让 Claude Code 对关键按钮、输入框、点击区域进行视觉标注。也就是在截图中加上高亮边框、箭头、步骤编号等元素，让用户一眼就知道当前步骤应该看哪里、点哪里。

比如我们可以要求它：在截图中用红色或橙色边框标出当前操作区域；用箭头指向关键按钮或输入框；在页面上标注“步骤 1”“步骤 2”“步骤 3”；每张图只突出一个核心操作，避免信息太乱；标注样式保持统一，方便后续整理成操作手册。

这样生成出来的截图，就不只是普通页面截图，而是更接近正式文档里的操作引导图。用户看起来会更直观，文档的可读性也会更强。

除了写操作手册，Playwright CLI 还可以用来辅助前端自检。比如我们可以让 Claude Code 在修改页面后，自动跑一遍核心流程，然后截图检查页面效果。如果发现按钮位置异常、弹窗错误出现、页面内容溢出，或者某个组件显示不完整，就让它回到代码里继续修改。这个过程相当于给 Claude Code 增加了一层“视觉反馈”。

以前它写前端，更多是靠代码和经验判断。现在有了 Playwright CLI，它可以通过浏览器真实渲染结果来检查自己的代码。对于复杂前端页面来说，这个能力非常有价值。我的直观感受是，Playwright CLI 不只是一个自动化测试工具。它更像是给 Claude Code 加了一双“眼睛”。尤其是在前端开发、操作手册、业务流程截图、页面异常检查这些场景里，它能明显减少人工反复测试和截图的成本。

如果说后端代码更适合用测试用例来验证，那么前端页面就更需要“可视化检查”。Playwright CLI 正好补上了这一块能力。

一些小坑

不过，Playwright CLI 也不是完全没有成本。首先，它的很多操作是通过 Bash 指令完成的。也就是说，它不像普通的 Markdown 提示词那样，只是让 Claude Code 读取一段规则，而是会在任务过程中不断执行命令、启动浏览器、操作页面、生成截图。

这会带来一个很明显的问题：token 消耗可能会更高。

因为 Claude Code 需要一边执行命令，一边读取运行结果，还要根据页面状态继续判断下一步操作。如果流程比较长，或者中途出现报错，它可能会反复跑命令、修问题、再截图。这样一来，整体消耗可能会比普通代码修改高不少。

其次，截图文件也需要注意管理。

Playwright CLI 在测试过程中会生成很多截图。如果没有提前规划好保存目录和命名规则，这些图片可能会比较乱。尤其是在不同会话、不同测试场景下生成的截图，很容易出现“东一张、西一张”的情况。后面再想整理操作手册或者回看测试结果，就会比较麻烦。所以，如果后续经常使用这个 Skill，最好提前约定好截图保存规则。比如按照业务场景、测试流程、步骤编号来命名，并统一保存到固定目录里。

整体来说，Playwright CLI 很适合用来做前端自动化测试、页面截图和操作手册素材生成。但它更适合“有规划地使用”，而不是每次都随手跑。只要把命令执行和截图管理这两个点处理好，它在前端开发中的价值会非常明显。