前几轮的横评把开发者链路扫得很密：查文档层有四件、审查到调试有七件、编排层挤满新面孔。但把这条链路摆到时间轴上看，会发现一个微妙的空位——审查（review）之后、调试（debug）之前，代码要经过的那道「验证」工序，反而没人单独盘过。这一层的 Skill 回答的是一个问题：Claude 改完代码，谁来确认它真的能跑？
本期不从榜单出发，而是从一台真实开发机的装机目录出发，横评验证层的四件代表作品：
| 代号 | 身份 | 一句话定位 |
|---|---|---|
| webapp-testing | 官方示例件（anthropics/skills 仓库） | 用 Playwright 驱动浏览器做 E2E 验证 |
| verify | Claude Code 内构件 | 把项目跑起来，观察行为验证改动 |
| gh-fix-ci | 社区/装机件 | CI 红了之后读日志、定位、修 |
| security-review | Claude Code 内构件 | 合并前的安全验证闸门 |
评分说明：内构件没有独立的社区维度（随 Claude Code 版本发布），社区活跃度按可得性与更新载体折算；所有评分为设计分析与真机体验的主观综合，不引用无法核实的下载量数字。
| 维度（权重） | webapp-testing | verify | gh-fix-ci | security-review |
|---|---|---|---|---|
| 功能完整度（25%） | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★☆☆ |
| 设计质量（25%） | ★★★★★ | ★★★★☆ | ★★★☆☆ | ★★★☆☆ |
| 实战效果（20%） | ★★★★☆ | ★★★★☆ | ★★★☆☆ | ★★★☆☆ |
| 上手难度（15%） | ★★★★☆ | ★★★★★ | ★★★★☆ | ★★★★★ |
| 社区活跃度（15%） | ★★★★☆ | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
| 加权总分 | 4.20 | 4.00 | 3.15 | 3.30 |
定位：anthropics/skills 官方仓库里的示例件之一，教 Claude 用 Playwright 测试 Web 应用。它和 docx、pdf、skill-creator 同属官方示范序列，官方用它演示「一个测试类 Skill 应该怎么写」。
设计拆解。这个 SKILL.md 值得写的不是功能，而是三个教科书级的设计决策：
触发词写场景不写名词。它的 description 不是「Playwright 测试工具」，而是围绕「测试 Web 应用」「验证前端行为」这类用户会说出口的任务句式设计。用户说「帮我确认这个表单提交后有没有报错」，命中率远高于关键词堆砌。这是验证层和查文档层最大的写法差异：文档层的触发靠名词（库名、API 名），验证层的触发靠动词短语（确认、验证、跑一遍）。
渐进披露到脚本层。SKILL.md 正文保持薄，把环境准备（Playwright 安装、浏览器内核下载这类重复且易错的操作）下沉到配套脚本，正文只负责指挥「什么时候调哪个脚本」。这正是前面拆解过的三层渐进披露模式在测试场景的落地：元数据常驻、正文按需、脚本执行。
先检查再启动的防呆。官方版本里有一步很关键的约束：先确认开发服务器是否已在运行，避免自己再起一个端口冲突的实例。这与之前提炼过的「防呆写作七式」同源——测试类 Skill 的最大事故不是测不出来，而是把被测对象搞挂。
短板：它假设被测对象是 Web 应用，纯后端、CLI、批处理任务完全不在射程内；对 Playwright 之外没有降级路径，环境装不起来就整体失效。
适合：有 UI 的项目、改动后需要点一遍关键路径的场景。不适合：无界面服务、需要长仿真环境的集成测试。
定位：Claude Code 自带件，无需安装。官方给它的触发描述非常克制：「验证一个代码改动是否真的符合预期，方式是把应用跑起来、观察行为」。这十几个字值得逐词读。
设计拆解：
短板：验证的深度取决于 harness 能否真的把项目跑起来——对需要数据库、外部依赖、长启动时间的项目，「跑起来」这步本身就可能失败；且它不做浏览器级交互验证，遇到前端深水区要交给 webapp-testing。
适合：改动后那句「这回真的行了吗」。不适合：需要构造复杂前置数据的验证。
定位：装机目录中的 CI 修复件，围绕 gh CLI 工作：CI 挂了之后拉取失败日志、定位失败用例、尝试修复并重新触发。
设计拆解：它的重要性常被低估——它是验证闭环里唯一处理「验证失败之后」的件。webapp-testing 和 verify 都回答「行不行」，只有它回答「不行怎么办」。从设计上看，它把「读日志」这个最耗 token 的动作做成了核心能力：失败日志往往成千上万行，Skill 的价值在于教 Claude 只取失败 job 的尾部、抓首个断言错误、向上追溯到第一个失败的测试，而不是整本吞下。
短板：三个。其一，它工作在远端，反馈回路以分钟计，调试体验远差于本地件；其二，「修复」的边界难控——CI 红的原因可能是代码、可能是环境、也可能是 flaky test，Skill 对这三者的分辨依赖模型自觉；其三，对非 GitHub 生态（GitLab CI、Jenkins）完全无能为力。
适合：PR 流程里 CI 反复红的团队，尤其是「本地好好的、一上 CI 就挂」的环境差异类问题。不适合：本地优先的工作流。
定位：Claude Code 内构件，对当前改动做安全审查——注入、越权、敏感信息泄漏这类发布前必须过一遍的检查。
设计拆解：它被放进「验证层」而不是「审查层」是有意的分类争议。常规 code-review 回答「代码对不对」，security-review 回答「代码坏起来会怎样」——这是两种不同的注意力分配：前者找与意图的偏差，后者主动构造攻击者视角。把它排在验证回路的最后一环而非与 code-review 并列，是因为安全问题的修复成本随合并时间指数上升。
短板：作为通用内构件，它没有业务上下文——不知道你的鉴权模型、不知道哪个字段是敏感数据，误报和漏报都靠人兜底。重度安全团队仍需要自己写带业务知识的专属安全 Skill。
适合：每个 PR 合并前的例行闸门。不适合：替代渗透测试与专业审计。
四件拼起来是一条完整的验证流水线，注意失败路径全部回到「改动」节点：
flowchart TD
A["代码改动 diff"] --> B["verify: 跑起来看行为"]
A --> C["webapp-testing: 浏览器E2E"]
B --> D{"行为符合预期?"}
C --> D
D -->|否| E["回到改动"]
D -->|是| F["推送并触发CI"]
F --> G["gh-fix-ci: 读日志定位修复"]
G --> H{"CI绿?"}
H -->|否| E
H -->|是| I["security-review 安全闸"]
I -->|存在高危| E
I -->|通过| J["合并"]
这张图揭示了验证层的本质：它不是四个工具，是一条有回边的循环。前三件各管一段反馈速度——本地秒级、浏览器十秒级、CI 分钟级——越靠前的环越便宜，验证的艺术就是让问题在尽量靠左的环里暴露。
# verify / security-review：Claude Code 内置，无需安装
# 会话内直接斜杠调用：
# /verify
# /security-review
# webapp-testing：来自官方仓库，手动安装到用户级技能目录
git clone https://github.com/anthropics/skills /tmp/anthropic-skills
cp -r /tmp/anthropic-skills/example-skills/webapp-testing ~/.claude/skills/
# 也可以用 skills.sh 生态的 CLI 检索安装（以其实际用法为准）
npx skills find webapp-testing
# gh-fix-ci：确认本机已装 gh CLI 并完成 gh auth login
gh auth status
对比四件的 SKILL.md 写法，能提炼出验证类 Skill 与其他类别的分野：触发靠动词短语（验证、确认、跑一遍）而非名词；正文必须包含失败路径（测出问题之后去哪），否则只是个只进不退的单行道；环境准备一律下沉脚本，正文保持薄。前几轮横评覆盖了看代码的层（审查）、看文档的层（查文档）、管流程的层（编排），本期补上的这一层，是唯一一个以「证伪自己」为目标的层——这也是它最值得单独一篇的原因。
[!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 等场景全覆盖。