概述：本期是开发者效率赛道的横向评测，聚焦「测试与调试」轴——代码审查与重构两个方向前几轮已被拆过，这期专看「证明代码真的能跑」的四件装备：Claude Code 内置的 verify、官方示例仓的 webapp-testing、社区件的 gh-fix-ci 与 notebook-fix。四件的 SKILL.md 原文均从本机装机直接读取（~/.claude/skills/ 与官方 example-skills 插件缓存），不含二手转述。核心发现一句话：这批件的分水岭不在功能多少，而在信源——静态读代码的件在退场，动态跑程序的件在接棒；而设计最强的一件，把「上下文经济学」直接写进了 SKILL.md 正文。
| Skill | 出身 | 功能完整度 (25%) | 设计质量 (25%) | 实战效果 (20%) | 上手难度 (15%) | 社区活跃度 (15%) | 加权总分 |
|---|---|---|---|---|---|---|---|
| webapp-testing | 官方示例仓 | ★★★★ | ★★★★★ | ★★★★ | ★★★ | ★★★★ | 4.2 |
| verify | Claude Code 内置 | ★★★ | ★★★ | ★★★★ | ★★★★★ | ★★★★ | 3.6 |
| gh-fix-ci | 社区件 | ★★★★ | ★★★★ | ★★★★ | ★★★ | ★★★ | 3.6 |
| notebook-fix | 社区件 | ★★ | ★★★ | ★★★ | ★★★★ | ★★ | 2.7 |
评分说明：本期不引用任何不可核实的 Star 数或下载量。五维中「社区活跃度」仅评可验证的流通信号——是否随官方插件渠道分发、是否进入本机这类第三方装机目录、是否有捆绑脚本等持续维护痕迹。SKILL.md 原文均为本机实测读取。
这是官方 example-skills 插件包里的浏览器测试件，一句话定位：用原生 Python Playwright 脚本测试本地 Web 应用。它的强不是功能列表长，而是它管住了模型写浏览器自动化时最常翻车的三个点：
第一，服务器生命周期。动态应用测试要先把 dev server 跑起来，模型自己起服务经常端口没就绪就开测。这件捆绑了 scripts/with_server.py，一条命令托管前后端两个服务，模型只需要写「纯 Playwright 逻辑」——SKILL.md 原话是「include only Playwright logic (servers are managed automatically)」，职责切得干干净净。
第二，猜选择器。模型最爱凭空捏 CSS 选择器，页面一渲染就落空。SKILL.md 里写死了「Reconnaissance-Then-Action」三步：先截图、抓 DOM、列出按钮，从渲染结果里确认选择器，再动手执行。
第三，时机。动态页面 JS 没执行完就去读 DOM，读到的永远是空壳。SKILL.md 用了一个 ❌/✅ 对照的 Common Pitfall 段落，并把 wait_for_load_state('networkidle') 标注为 CRITICAL。
短板：需要预装 Python Playwright 和 Chromium，环境成本是四件里最高的；纯静态小页面用它属于杀鸡用牛刀。
Claude Code 内置件，触发即「验证某个改动真的有效」。官方描述里最关键的是七个词：by running the app and observing behavior——运行应用、观察行为。它和代码审查件的分工非常清晰：code-review 看静态 diff 找 bug，verify 不看代码长什么样，只问「跑起来对不对」。适合三种场景：手动验证一个改动、确认一个功能可用、推送前做本地把关。
它的设计哲学是反「看起来改对了」：模型自己声称修好了不算数，要有运行时的观察证据。这在「AI 写完代码自信满满、一跑就崩」的现实里，恰好补的是最后一步。
短板：一次性实证——跑完观察完，证据不留痕。它不会沉淀出可复跑的测试代码，下次回归还得重新验。这正是它和 webapp-testing 的本质分工：verify 管单次兑现，webapp-testing 管测试资产化。
社区件，定位是修复 PR 上失败的检查：定位失败项→拉取 GitHub Actions 日志→摘出报错片段→给出修复计划→明确批准后才动手。它的 SKILL.md 是典型的「流程剧本」写法，几个设计点值得点名：
inspect_pr_checks.py 「Exits non-zero when failures remain so it can be used in automation」——退出码即状态，能被上层流水线接住。gh pr checks → gh run view --log → job logs API），一层层降级。短板：脚本调用写的是 python "<path-to-skill>/scripts/inspect_pr_checks.py"——占位符要靠人脑替换路径。对比 webapp-testing 加载时自动注入「Base directory for this skill」，这里差了一个工程细节。上手前必须 gh auth login 且带 workflow 权限，配置门槛不低。
Jupyter Notebook 专用修复件，检查五类固定问题：损坏的导入语句、markdown 单元格里的代码、JSON 编码、Python 语法、单元格格式。设计上有两个可取处：一是输出锚定——SKILL.md 直接内嵌了一段完整的预期输出示例（逐文件打 ✓/⚠/✗、最后给 Summary），模型照着这个格式输出，结果稳定可读；二是安全阀——修复前询问「Fix issues? (y/n)」，且自动备份 .bak。
短板也最明显：五类问题是封闭枚举，notebook 真正常见的病——kernel 状态错乱、依赖版本冲突、输出爆炸——它一概不治；没有捆绑脚本，修 JSON 结构全靠模型徒手改，大文件风险高；非英文 SKILL.md 在生态流通上天然吃亏。它更像一份个人装机的顺手工具，而非可推广的公共件。
四件里设计质量断层领先的是 webapp-testing，值得拆到段。它的 SKILL.md 大约 90 行，没有一句废话，每段都在解决「模型执行浏览器自动化时的已知失效模式」。
第一段：开头三条铁律。 原文只有三行——写原生 Playwright 脚本、有两个 helper 脚本可用、「Always run scripts with --help first」。最狠的是接下来这句：
「DO NOT read the source until you try running the script first and find that a customized solution is absolutely 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.」
这是整个 SKILL.md 的灵魂：禁止模型把大脚本读进上下文。脚本被明确定义为「黑盒」，用法靠 --help 自查。大多数 Skill 作者还在琢磨「怎么把指令写清楚」，这件已经在管「模型注意力的带宽」——脚本源码几千行塞进上下文，既烧 token 又稀释任务指令的权重。这一条是全生态最值得抄的写法，没有之一。
第二段：纯文本决策树。 入口分流用一个 ASCII 画的决定树：是不是静态 HTML？服务器起没起？两个问题分出三条路径——静态页直接读 HTML 拿选择器；动态页没起服务的走 with_server.py；已在跑的走「侦察后行动」。用纯文本而不是图，因为 SKILL.md 的读者是 LLM，缩进字符树比 mermaid 更稳。这棵树同时是一份「边界说明」：它明确告诉模型什么事不归这个技能管。
第三段：职责分离的示例代码。 给出的自动化脚本模板里只有 Playwright 逻辑，服务器管理全部外包给 helper。注释里写「Server already running and ready」——模型不需要理解服务什么时候算就绪，helper 保证端口通了才放行测试脚本。
第四段：Reconnaissance-Then-Action。 三步循环：截图+抓 DOM→从渲染结果识别选择器→执行动作。把「写自动化」从一次性猜测改成了观察驱动的循环，这是它实战效果稳定的根本原因。
第五、六段：陷阱标注与最佳实践清单。 Common Pitfall 用 ❌/✅ 对照，只讲一个最高频错误（没等 networkidle 就检查 DOM）；Best Practices 五条全是可执行的硬规则：黑盒用脚本、用同步 API、记得关浏览器、用语义选择器（text=、role=）、加显式等待。
第七段：渐进披露。 主文件末尾只挂三个 examples 文件名（元素发现、静态页 file:// 自动化、控制台日志采集），需要哪个读哪个。主文件保持精简，细节下沉到子目录——这是官方仓库反复示范的「渐进式披露」标准写法。
一句话总结它的设计公式：决策树管分流 + 黑盒条款管注意力 + 陷阱标注管翻车点 + 示例文件管细节。
webapp-testing 的执行决策流：
flowchart TD
A[用户任务] --> B{是静态HTML吗}
B -->|是| C[直接读HTML找选择器]
C --> D{选择器够用吗}
D -->|是| E[写Playwright脚本执行]
D -->|不够| F[按动态应用处理]
B -->|否| G{服务器已在跑吗}
G -->|否| H[with_server.py托管启动]
H --> I[侦察后行动]
G -->|是| I
I --> J[等待networkidle]
J --> K[截图并检查DOM]
K --> L[从渲染结果定选择器]
L --> M[执行动作]
调试测试件的三层供给结构：
flowchart TD
subgraph S1[内置层：随版本分发]
A[verify：运行观察实证]
B[code-review：静态diff找虫]
end
subgraph S2[官方示例层：插件渠道]
C[webapp-testing：Playwright测试资产]
end
subgraph S3[社区装机层：个人目录]
D[gh-fix-ci：远端CI红灯]
E[notebook-fix：笔记本修理]
end
B -.互为补充.-> A
C -.沉淀为测试.-> A
D -.远端事实源.-> A
verify / code-review：Claude Code 内置，无需安装。会话中直接 /verify、/code-review。
webapp-testing（官方示例仓分发）：
git clone https://github.com/anthropics/skills
# 将仓库中的 webapp-testing 目录整个复制到技能目录
cp -r <仓库内webapp-testing路径> ~/.claude/skills/
# 环境依赖
pip install playwright && playwright install chromium
使用：对 Claude 说「测试一下这个本地应用，验证提交表单后跳转正确」即可触发；或手动执行 python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_test.py。
gh-fix-ci（社区件，装入 ~/.claude/skills/gh-fix-ci/ 后）：
gh auth login # 需 repo + workflow 权限
python ~/.claude/skills/gh-fix-ci/scripts/inspect_pr_checks.py --repo "." --pr "<PR编号>"
notebook-fix：
/notebook-fix **/*.ipynb
本生态观察：调试测试轴的进化方向已经清晰——从「让模型读代码推测」走向「让模型运行程序取证」。内置的 verify 把实证变成默认动作，官方的 webapp-testing 把实证沉淀为资产，两者一纵一横，基本框定了这个赛道的正确形态。社区件的生存空间在夹缝里：管住官方不管的远端事实源（CI）和边角格式（notebook），但要想被广泛装机，得先补上 webapp-testing 那种工程细节——比如别再让用户自己替换 <path-to-skill> 占位符。
~/.claude/skills/gh-fix-ci/SKILL.md — 社区 CI 修复件原文，含捆绑脚本 inspect_pr_checks.py 的用法与边界声明~/.claude/skills/notebook-fix/SKILL.md — Jupyter 修复件原文，含五类问题清单与输出锚定示例/verify 与 /code-review 的官方描述文本，取自本机 Claude Code 会话内建清单[!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 等场景全覆盖。