<!-- title: 验证件禁跑测试：效率位四闸取证 -->

# 验证件禁跑测试：效率位四闸取证

## 概述

本轮换一个打法：不看星榜，不对着市场目录排名，而是对一台每天都在真实干活的开发机做取证——把「开发者效率位」上实际驻扎的四件 Skill 逐个开膛。样本覆盖流水线四个闸口：审查闸的 `gh-address-comments`、验证闸的 `verify`（Claude Code 2.1.161 内置）、调试闸的 `gh-fix-ci`、安全审查位的 `security-best-practices`。两枚烟枪先扔在桌上：第一，验证件的宪法第一条是「**禁止跑测试**」；第二，安全件的正文结尾留着另一个 Agent 宿主的名字「codex」。这四件在星榜上几乎 invisible，却卡住了日常开发最脏的四个工位——这正是本期想说的：效率竞争的真空白带，不在聚光灯下。

## 评测对比表

| Skill | 功能完整度 25% | 设计质量 25% | 实战效果 20% | 上手难度 15% | 社区活跃度 15% | 四维折算总分 |
|---|---|---|---|---|---|---|
| verify | ★★★★★ | ★★★★★ | ★★★★ | ★★★ | ⚠️无法计分 | **4.4** |
| gh-fix-ci | ★★★★ | ★★★★★ | ★★★★ | ★★★ | ⚠️无法计分 | **4.1** |
| security-best-practices | ★★★★ | ★★★★ | ★★★ | ★★★★ | ⚠️无法计分 | **3.7** |
| gh-address-comments | ★★★ | ★★★★ | ★★★ | ★★★★★ | ⚠️无法计分 | **3.6** |

说明：本轮样本全部取自本机装机清单（路径见文末），拿不到公开的 Star / 下载量数据，社区活跃度一栏无法计分，总分按其余四维折算。这个「无法计分」本身就是本期发现的一部分——真正驻扎在开发机效率位上的件，大多不是星榜明星。

## 主体拆解

### 一、gh-address-comments：审查的下半场，全文不到二十行

市面上的代码审查件都在抢「当审查者」，这件管的是没人愿意做的下半场：**审查意见回来之后怎么办**。它的 SKILL.md 短到可以在一分钟读完，三步走：

1. 跑 `scripts/fetch_comments.py`，把当前分支对应 PR 的所有评论和 review threads 拉出来；
2. 「Number all the review threads and comments and provide a short summary of what would be required to apply a fix for it」——把意见全部编号，逐条给出修复成本摘要；
3. 问用户要修哪几条，选中才动手。

设计上最值钱的是第二步。它不替作者做决定，而是把「处理审查意见」从一团糊成一页的评论区，变成一张可点选的清单：每条意见的修复代价被提前算好，处置权留在人手里。PR 审查意见常常一半是有效反馈、一半是口嗨和误读，件自己不猜，让作者勾选。

短板也明白：无状态，一轮一结；不区分意见优先级；依赖 `gh` 已认证。功能完整度只有三星，但上手难度拿满——装上就能用，零配置。

### 二、gh-fix-ci：调试闸的教科书，边界写在明面上

SKILL.md 标题叫「Gh Pr Checks Plan Fix」，八步工作流：验认证 → 定位 PR → 拉失败 check 的 Actions 日志 → 摘出失败片段 → 给用户出修复计划 → **批准后才动手** → 改完建议复跑 `gh pr checks` 确认。四处理性设计值得抄：

**边界宣言。** 「If `detailsUrl` is not a GitHub Actions run, label it as external and only report the URL. Do not attempt Buildkite or other providers; keep the workflow lean.」只管 Actions，Buildkite 明写不做。大多数件死于贪大，这件把「不做什么」写成了正文。

**双路兜底。** 优先跑捆绑脚本 `inspect_pr_checks.py`，它「handles gh field drift」——gh CLI 版本一升级字段就漂，脚本先扛；扛不住走手动 fallback：`gh pr checks --json` 字段被拒，就「rerun with the available fields reported by gh」。对第三方 CLI 的不稳定性做了防御性工程。

**退出码当 API。** 脚本「Exits non-zero when failures remain so it can be used in automation」——红灯没清零就非零退出，外层自动化可以直接拿它当闸门串联。

**松耦合协作。** 开头一句「If a plan-oriented skill (for example `create-plan`) is available, use it; otherwise draft a concise plan inline」——先探测环境里有没有计划类 Skill，有就用，没有就退化成内联计划。这是 Skill 之间互相发现的标准写法，不硬依赖。

短板：外部 CI（非 Actions）只贴 URL 不诊断；起步需要 `gh auth login` 且要 repo + workflow 两个 scope，新手容易卡在认证。

### 三、verify：本期主角，一个用禁令写成的宪法

这是四件里唯一随 Claude Code 本体分发的内置件（取证路径在 `bundled-skills/2.1.161/` 下），也是设计最狠的一件。它的核心论点一句话：「**Verification is runtime observation.**」验证是运行时观察，别的都不算。

于是它开篇就是三条禁令：

- 「**Don't run tests. Don't typecheck.**」跑测试证明的是你能跑 CI，不是改动有效。不做热身、不做「求个安心」、改完也不做回归扫——时间全部拿去把应用跑起来。
- 「**Don't import-and-call.**」`import { foo }` 然后 `console.log(foo(x))` 是你自己写的单元测试，「The app never ran」。
- 测试文件在 diff 里是「作者的证据，不是表面」——只测代码的 PR 直接判 SKIP，一行说明。

这套禁令对抗的是模型的确认偏误：跑绿一堆测试会产生「改好了」的错觉，而 verify 把证据标准钉死在「用户会看到什么」上。支撑机制有四层：

**表面枚举表。** 改动到达 CLI 就敲命令截屏、到达 API 就发请求看响应、到达 GUI 就 xvfb/Playwright 驱动加截图、是库就走公共导出包边界。六行表格把「去哪观察」变成查表题而不是猜谜题。

**取证协议下沉到仓库。** 动手前先 `ls .claude/skills/` 找 `verifier-*`——那是仓库自带的证据采集协议，能让评审者回放你看到的东西；没有 `verifier-*` 就借用 `run-*` 的构建原语；都没有就冷启动，硬性 timebox 十五分钟，卡住判 BLOCKED 并附一段 `/run-skill-generator` 提示词，把这次冷启动配方沉淀成新的 verifier。验证经验会变成仓库资产，这是生态里少见的「越用越厚」设计。

**探针强制。** 报告格式里 🔍 标记代表探针——「At least one. A Steps list that's all ✅ and no 🔍 is a happy-path replay」。主动喂脏输入：新 flag 就传空值、传两遍、和冲突 flag 组合；改了错误处理就触发相邻的错误路径。探针哪怕没打穿也要记录一行「🔍 传空 `--from` → 干净报错，exit 2」，告诉作者哪些脏路径已被覆盖。

**判决不对称。** 四态：PASS / FAIL / BLOCKED / SKIP，「No partial pass」，「**When in doubt, FAIL.**」——假 PASS 让坏代码上线，假 FAIL 只多花一次人工复核。这是把 reviews 的风险模型直接写进了判决规则。

实战扣一星的原因：它要求改动存在可达的运行表面，纯逻辑库、没起不来的环境会频繁落在 BLOCKED；上手需要会驱动终端、请求、截图三套工具。

### 四、security-best-practices：把安全知识做成文件名可寻址的库

这件的骨架是一个知识库：`references/` 目录按 `<language>-<framework>-<stack>-security.md` 命名，先识别项目的前后端语言与框架，再「read ALL reference files which relate to」——按需加载，不把全部安全知识塞进上下文。前端后端要分别加载，未指明前端框架时还要兜底读 `javascript-general-web-frontend-security.md`。

工作模式三档：默认跟着参考文档写安全代码；日常写码时当被动哨兵，只标记最高危问题；用户点名要报告时，产出写进 `security_best_practices_report.md` 的完整报告——按严重度分节、发现带数字编号、关键条目附一句影响陈述、引用代码必须带行号。修复纪律也细：一次只修一条，注释里写明依据的最佳实践和不做会怎样，警惕「不安全的代码被别处依赖着」这种回归——「Avoid breaking the user's project as this may make them not want to apply security fixes in the future」是难得的人间清醒。

还有一条务实的 Override 政策：项目文档明确要绕过某条最佳实践时，「you MAY report it to the user, but do not fight with them」。以及通用建议里对 TLS / secure cookie / HSTS 的克制（开发期别拿缺 TLS 报漏洞，HSTS 配错会锁死用户），都是踩过坑的口吻。

然后是本期最大的一枚烟枪：正文结尾一句——「not generally recommended for the scope of projects being reviewed by **codex**」。这份安全考卷是为另一家 Agent 宿主写的，移植进本机 skills 目录时没清干净指纹。功能无损，但它提醒所有想搬运 Skill 的人：换宿主，先全文搜原宿主名。

### 工位地图

```mermaid
flowchart TD
    A["改动写完"] --> B["PR 审查闸"]
    B --> B1["gh-address-comments<br/>意见编号 用户点选"]
    B1 --> C{"意见要改吗"}
    C -->|要改| D["修复提交"]
    C -->|不改| E["回复说明"]
    D --> F["验证闸 verify"]
    F --> F1["到表面观察<br/>禁跑测试"]
    F1 --> G{"判决"}
    G -->|PASS| H["送 CI"]
    G -->|FAIL| D
    H --> I{"CI 红灯"}
    I -->|是| J["gh-fix-ci<br/>只管 Actions"]
    J --> K["出计划 批准后改"]
    K --> H
    H --> L["安全闸<br/>security-best-practices"]
    L --> M["编号报告 分级"]
    M --> N["一次修一条"]
```

verify 内部的判决机器单独一张：

```mermaid
flowchart TD
    A["改动入站"] --> B["定位表面"]
    B --> C{"有运行表面吗"}
    C -->|无| D["SKIP 一行说明"]
    C -->|有| E["找 verifier 技能"]
    E --> F{"十五分钟<br/>起得来吗"}
    F -->|起不来| G["BLOCKED 附生成器提示"]
    F -->|起来| H["走最小路径"]
    H --> I["至少一个探针"]
    I --> J{"存疑吗"}
    J -->|是| K["FAIL 附原始输出"]
    J -->|否| L["PASS 附观察清单"]
```

## 从四件里抄得到的六条写法

1. **双路兜底**：捆绑脚本优先，手动命令垫底，且写明「字段被拒就按报错里的可用字段重试」——对着不稳定的第三方 CLI，防御性写法比聪明的写法耐用。
2. **退出码当 API**：让脚本在「失败未清零」时非零退出，Skill 就能被外层自动化和 CI 串联，不再只是聊天窗里的台词。
3. **禁令式宪法**：模型的本能（跑测试求安心）要用明文禁令对抗，verify 的三条 Don't 比十条建议都管用。
4. **表面枚举表**：把「改动会到达哪」写成查表题，定位观察点不靠模型现场发挥。
5. **文件名寻址知识库**：安全知识按 `<语言>-<框架>-<栈>` 切片按需加载，上下文只付当前栈的价钱。
6. **换宿主先清指纹**：`codex` 残字就是反面教材，移植件记得全文搜原宿主名。

至于重构闸：本机这个位置被内置的 simplify 占着，此前专栏已单独拆过，本轮不再重复。也就是说四个闸里，审查有两件分兵（人给的 + 安全红线），验证和调试各一件重装，重构位一内置了事——脏活有人干，体面的活反而没 competition，这是装机位和市场榜单最大的倒挂。

## 安装与使用

```bash
# gh 系两件：装进用户级 skills 目录，依赖 GitHub CLI 认证
gh auth login   # 勾选 repo + workflow 两个 scope
# 触发话术：“看看当前 PR 挂了哪些 check” / “把 PR 上的 review 意见编号列出来”

# verify：Claude Code 内置（本次取证环境随 2.1.161 打包），无需安装
# 触发：改动完成后输入 /verify，或直接说“验证一下这个改动”

# security-best-practices：整目录放入用户级 skills
# ~/.claude/skills/security-best-practices/
# 配套 references/<语言>-<框架>-<栈>-security.md 知识库
# 触发话术：“按安全最佳实践把这个项目审一遍，出报告”
```

## 分维度排行榜

- **设计最讲究**：gh-fix-ci——双路兜底、退出码语义、边界宣言、Skill 间松耦合，四招全是可以直接抄进自家 SKILL.md 的成品动作。
- **最反直觉**：verify——「验证不是跑测试」一句话推翻大多数人（和大多数模型）的默认动作，且用判决不对称性把风险模型写进了件里。
- **最省心**：gh-address-comments——零配置、零依赖心智，装上就能处理审查意见。
- **争议最大**：security-best-practices——知识库设计一流，但 codex 残字让出身成谜，用户自己权衡。

## 结论

星榜衡量的是「多少人装了它」，装机位衡量的是「干活时它在不在场」。本轮四件的共同点是：没有一件在追「更聪明的审查」或「更强的重构」，它们全部收缩到一个窄闸口，把范围边界、失败路径、审批位置写死在 SKILL.md 里。效率件的下一段竞争不在功能数量，在边界清晰度——以及，换宿主的时候记得把前任的名字擦掉。

## 参考来源

1. `~/.claude/skills/gh-address-comments/SKILL.md` — 本机装机原文，三步工作流与 fetch_comments.py 引用
2. `~/.claude/skills/gh-fix-ci/SKILL.md` — 本机装机原文，八步工作流、Buildkite 边界宣言、inspect_pr_checks.py 说明
3. `bundled-skills/2.1.161/.../verify/SKILL.md` — Claude Code 2.1.161 随包内置件原文，三条禁令、表面枚举表、判决规则
4. `~/.claude/skills/security-best-practices/SKILL.md` — 本机装机原文，references 命名法、三档模式、报告与修复纪律及 codex 残句

（注：本轮取证环境不开放外部网络检索，以上为本机直接读取的原始文件；未引用任何未经核实的市场数据。）

> [!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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)