# 先侦察，再行动：官方测试类 Skill webapp-testing 逐段拆解
## 概述
## 一、选题动机：测试/调试赛道，是 Skill 最难写的一档
代码审查类 Skill 输出的是「意见」，错了也就是废话几句；测试类 Skill 输出的是「可执行的验证」，错一步就是假绿、漏测、误报。这决定了测试类 SKILL.md 的写法和别处完全不同：它必须教会模型一整套**操作纪律**，而不是一段人设。
## 二、评测对比表
| Skill | 形态 | 功能 | 设计 | 实战 | 上手 | 社区 | 加权 |
|-------|------|------|------|------|------|------|------|
| webapp-testing（官方） | 教学+脚本包 | ★★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★ | **4.10** |
| skill-creator（官方，参照） | 元工具 | ★★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★★ | **4.35** |
| x64dbg-mcp-server | 调试器接线 | ★★★★ | ★★★ | ★★★★ | ★★ | ★★★ | **3.30** |
| PawWork_ZhuaZhua | 浏览器交互代理 | ★★★ | ★★★ | ★★★ | ★★★★ | ★★ | **3.00** |
| reverify | 校验型逆向 | ★★★ | ★★★★ | ★★★ | ★★ | ★★ | **2.95** |
（reverify 设计分给到四星而总分垫底，是这个赛道的典型画像：理念领先，门槛劝退。下面展开。）
## 三、主拆 webapp-testing：190 行教会模型「先看再点」
### 3.1 定位与文件结构
webapp-testing 隶属 anthropics/skills 官方示例库，目录三件套：`SKILL.md`、`scripts/with_server.py`（服务生命周期托管）、`examples/`（三个示例脚本：元素发现、静态 HTML 自动化、控制台日志捕获）。frontmatter 的 description 是标准的「干什么+什么时候用」双句式：Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.——五个动词短语把触发场景铺满，这是官方描述工程的基本操作，上期已讲透，这期只看正文。
### 3.2 开篇第一句：不造框架，给方法论
> To test local web applications, write native Python Playwright scripts.
全文第一句就定调：测试本地 Web 应用，就是**写原生 Playwright 脚本**。没有 DSL、没有封装层、没有「先配置再使用」的仪式。对比社区里大量 Skill 热衷于发明一套配置文件和自研指令格式，官方的选择是：把所有领域知识压进写法纪律里，产物仍然是普通脚本——任何人都能 review、能改、能脱离 Skill 单独跑。这是判断一个 Skill「教学型」还是「平台型」的分水岭，webapp-testing 毫不含糊地站在教学型一边。
### 3.3 黑盒脚本与上下文经济学：全篇唯一的大写禁令
紧跟着出现的是全文最值得抄的一段：
> **Always run scripts with `--help` first** to see usage. DO NOT read the source until you try running the script first and find that a customized solution is abslutely necessary. These scripts can be very large and thus pollute your context window. They exist to be called directly as black-box scripts rather than ingested into your context window.
三件事：先跑 `--help` 再说；**不许读脚本源码**，除非跑过之后确认必须定制；理由写得明明白白——「这些脚本可能非常大，会污染你的上下文窗口，它们存在的意义就是作为黑盒被调用，而不是被吞进上下文」。
这是官方罕见的把「上下文经济学」写进 SKILL.md 明面：Skill 的资源脚本不是给模型读的文档，是给模型**调**的工具。顺带一提，这句里 abslutely 拼错了（应为 absolutely）——官方示例也有 typo，说明这类文件是工程师手写的操作经验，不是精修文案。这种粗糙反而让人放心：它优先的是「模型照着做不会错」，而不是「人类读起来漂亮」。
`with_server.py` 的用法示例进一步落实黑盒原则：单服务 `--server "npm run dev" --port 5173 -- python your_automation.py`，双服务再挂一个 `--server`。示例里特意注明「自动化脚本里只写 Playwright 逻辑，服务已被托管」——模型不需要理解进程管理，只需要拼参数。
### 3.4 ASCII 决策树：把分支逻辑画给模型看
SKILL.md 正中嵌了一棵 ASCII 决策树：
```
User task → Is it static HTML?
├─ Yes → Read HTML file directly to identify selectors
│ ├─ Success → Write Playwright script using selectors
│ └─ Fails/Incomplete → Treat as dynamic (below)
└─ No (dynamic webapp) → Is the server already running?
├─ No → Run: python scripts/with_server.py --help ...
└─ Yes → Reconnaissance-then-action: ...
```
两个分支点（静态还是动态？服务起了没有？）、每条路径的出口都指向具体动作。把「如果…那么…」写成树而不是散文，是给 LLM 写操作文档的高杠杆技巧：散文里两个条件组合四种情况，模型容易漏岔；树里每片叶子就是一个可执行动作，没有记忆负担。社区 Skill 里敢用 ASCII 画决策树的不多——大多担心「不美观」，但这份文件的目标读者是模型，不是设计评审。
### 3.5 侦察-行动模式：这是全文的灵魂
动态应用的路径被命名为 **Reconnaissance-Then-Action**（侦察后行动），四步：导航并等待 networkidle → 截图或检查 DOM → **从渲染后的状态里识别选择器** → 用发现的选择器执行动作。
为什么值得单开一节？因为它是把「防幻觉」焊死在流程里。模型写前端自动化最大的翻车点，是读完源码就**凭空推断**选择器——源码里的 class 和运行时 DOM（被框架改写、被 hydration 变更、被 CSS-in-JS 加工后）经常是两回事。侦察模式的本质是禁止「从源码推理」，强制「从运行时取事实」：先截图、先 dump DOM，用看到的真实结构写脚本。这一段没有任何「你必须小心」的叮嘱，只有步骤顺序——**顺序本身就是纪律**。
配套的示例代码同样在做教学：
```python
page.goto('http://localhost:5173')
page.wait_for_load_state('networkidle') # CRITICAL: Wait for JS to execute
browser = p.chromium.launch(headless=True) # Always launch chromium in headless mode
```
注意注释的位置：`# CRITICAL` 和 `# Always launch... in headless mode` 不是给人看的说明，是直接钉在代码行上的指令。模型抄示例的概率远高于读散文的概率——把指令放进必抄的示例里，触发率最高。
### 3.6 ❌/✅ 反例：两行讲完一个天坑
Common Pitfall 一节只有两行：
> ❌ **Don't** inspect the DOM before waiting for `networkidle` on dynamic apps
> ✅ **Do** wait for `page.wait_for_load_state('networkidle')` before inspection
单页应用渲染完成前 dump DOM，拿到的是空壳——这是 Playwright 新手第一天就会踩的坑，也是模型复现率最高的错误。官方没有写一段「关于等待策略的深入探讨」，就两行，成对出现，错误在前正确在后。教学设计里这叫「对比反例」，信息密度远高于正面陈述。
### 3.7 Reference Files：三层渐进披露的收口
结尾的 Reference Files 指向 `examples/` 三个脚本：元素发现、静态 HTML 自动化、控制台日志捕获——每个名字就对应一类子任务，正文不展开，用到再读。这正好凑齐官方在 skill-creator 里定义的三层加载体系：元数据常驻 → 正文触发时进上下文 → 资源按需加载。webapp-testing 的正文不到两百行，三层职责切得干净利落，是可以直接当模板临摹的结构。
### 3.8 短板
也要说清边界：其一，它只管「本地 Web 应用」，面对生产环境或需要登录态的远端测试没有着墨；其二，Playwright 之外（例如已有 Cypress/Jest 资产的项目）完全不管迁移；其三，`with_server.py` 源码被黑盒化后，端口占用、启动失败的排错只能靠 `--help` 输出猜——省上下文的代价是排障信息变薄。这些不算缺陷，是「教学型」的取舍边界，但选型前该知道。
## 四、同赛道三面孔：校验、接线、交互
## 五、贯穿论点：把事实校验写进流程，而不是写进叮嘱
把四件放在一起，测试/调试赛道的设计收敛点清晰可见：
```mermaid
flowchart TD
A[模型产出: 推理/假设/脚本] --> B{有没有事实校验环节?}
B -->|无| C[凭源码猜选择器
凭日志猜根因
凭经验猜二进制]
C --> D[假绿 / 漏测 / 误报]
B -->|有| E[webapp-testing: 渲染后DOM为准]
B -->|有| F[x64dbg-mcp: 断点内存为准]
B -->|有| G[reverify: 二进制本体为准]
B -->|有| H[PawWork: 人类选中为准]
E & F & G & H --> I[以运行时事实修正动作]
```
四个产品用四种「事实源」解决同一个问题：模型会说谎，运行时不会。写 SKILL.md 的人该带走的方法论是——**当你想写「务必小心 X」时，改成设计一个让 X 无法发生的步骤顺序**。webapp-testing 用 networkidle 前置消灭空 DOM 陷阱，比十句 MUST 都管用。
## 六、推荐排行榜
- **最值得临摹的 SKILL.md**：webapp-testing——黑盒脚本声明、ASCII 决策树、侦察-行动、❌/✅ 反例、示例内联指令，五个可迁移模式一次看全
- **最硬核**：x64dbg-mcp-server——把真调试器接进 Agent，上限最高门槛也最高
- **理念最超前**：reverify——「AI 提假设、工具给事实」是逆向场景的正解
- **今天就能用上**：webapp-testing——装上就能给本地项目写冒烟测试
## 安装命令
```bash
# webapp-testing（官方示例库，拷入技能目录即装）
git clone https://github.com/anthropics/skills
cp -r skills/webapp-testing ~/.claude/skills/
# 或用技能 CLI 搜索确认
npx skills find webapp-testing
# 对照组三者（均为社区仓库，自行评估后使用）
git clone https://github.com/duty1g/x64dbg-mcp-server
git clone https://github.com/2akouwu/reverify
git clone https://github.com/Player-YN/PawWork_ZhuaZhua
```
## 参考来源
> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。
