<!-- title: 报错之后：修虫六件横评 -->

# 报错之后：修虫六件横评

## 概述

Skills 生态走到第三轮，开发者效率这个大方向里，代码审查和测试都已经有专文交代，唯独「调试」这块地一直空着。本期补上：只盯**报错之后**的那段流水线——线上报警了谁接、CI 红了谁修、notebook 炸了谁管、修完谁来验收。入选六件：内建三兄弟 `verify` / `code-review` / `simplify`，加上修虫三件 `gh-fix-ci` / `notebook-fix` / `sentry`。与前几轮抓 GitHub 门牌不同，本期素材来自一台真实 Claude Code 宿主的实装清单——能看到的是「装进机器之后、真正参与触发的那一行描述」，这恰是 SKILL.md 里最值钱的 frontmatter 字段。核心发现一句话：**调试没有王者件，只有流水线上的工位件；单件都不完美，串起来才闭环。**

## 方法论：为什么本期拆的是「装进机器的那一行」

前两轮横评，拆的是 GitHub 上 SKILL.md 的原文；本期换了个更刁的视角——拆宿主加载后的实装清单。区别在哪？一个 Skill 发布时写得天花乱坠，装进 Claude Code 之后，真正决定它「什么时候被叫起来」的，是 frontmatter 里那行 `description`。本机清单里，`code-review` 的描述塞了两句话、三个档位、两个开关参数；而 `gh-fix-ci`、`notebook-fix`、`sentry` 在清单里是**裸名上架**——连一行描述都没有，触发全靠名字里的关键词命中。这个差别本身就值得单独一篇，先记下。

另外交代边界：内建三件的描述行是宿主原文，可以逐词拆；修虫三件本机清单未载描述行，功能按其名字语义与同类件的常见实现推断，**不做逐行硬拆**——拿不准的宁可不说，这是本期底线。星级为定性评分（本机实装观察 + 设计分析），未引用任何第三方计数。

## 评测对比表

| Skill | 功能完整度 25% | 设计质量 25% | 实战效果 20% | 上手难度 15% | 社区活跃 15% | 加权综合 |
|---|---|---|---|---|---|---|
| code-review | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★ | **4.4** |
| gh-fix-ci | ★★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★ | **3.9** |
| verify | ★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★ | **3.9** |
| simplify | ★★★ | ★★★★ | ★★★ | ★★★★★ | ★★★★ | **3.7** |
| sentry | ★★★★ | ★★★ | ★★★ | ★★★ | ★★★ | **3.3** |
| notebook-fix | ★★★ | ★★★ | ★★★ | ★★★★ | ★★ | **3.0** |

## 六件逐个看

### 1. code-review —— 合并前的防虫网（综合第一）

内建件，零安装。它的描述行是六件里工程化程度最高的，值得整段引出来：

> Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups at the given effort level (low/medium: fewer, high-confidence findings; high→max: broader coverage, may include uncertain findings). Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree.

拆到词：第一句划边界——只看**当前 diff**，不翻全仓库，这决定了它的运行成本可控；第二句给了 `low/medium/high` 三档「查得多准 vs 查得多广」的旋钮，并诚实标注 high 档「可能包含不确定的发现」；最后给 `--comment`（发到 PR 行内评论）和 `--fix`（直接改工作区）两个出口。**一个 Skill 的触发描述里同时写清范围、档位、副作用边界和两个参数出口，这在整个生态里都属罕见**——大多数社区件的描述还停留在「Helps you write better code」这种空话级别。短板：它只防不修，diff 之外的存量虫一律不管。

### 2. gh-fix-ci —— CI 红灯专修（实战最狠）

`gh-*` 系列的一员（同门还有 `gh-address-comments`、`gh-cli`），分工明确：CI 挂了，拉日志、定位失败用例、给出修复。它排在综合第二，靠的是「事件驱动」的准触发——红灯本身就是最强触发信号，不需要用户组织语言描述问题。亮点：把「读 CI 日志」这个最磨人的活整个吞掉，日志几十屏的滚动输出正是模型耐心比人强的场景。短板有二：一是裸名上架，描述行缺失意味着「CI 黄了但措辞不像 fix-ci」时可能漏触发；二是它默认「测试错了」，偶尔真实情况是测试本身写错，修虫修成了改题——用的时候要在指令里留一句「先判断是代码错还是测试错」。

### 3. verify —— 修完之后的验收员（上手零成本）

内建件。描述行原文：

> Verify that a code change actually does what it's supposed to by running the app and observing behavior. Use when asked to verify a PR, confirm a fix works, test a change manually, check that a feature works, or look at local changes before pushing.

它的设计亮点是那串 `Use when...` 场景清单——verify PR、确认修复有效、手动测试、检查功能、push 前过目，五个触发场景一口气列全，这是「场景清单式门牌」的标准范本。**在调试流水线里它是缺了会出事的一环**：修虫件说「修好了」，谁去真跑一遍？verify 的存在价值就是把「改完 = 修好」这个危险等式拆掉。短板：它要真跑应用，遇到没有本地运行环境的仓库（纯库、重依赖、要云服务）会直接力竭，描述行里也没写这种边界场景的降级策略。

### 4. simplify —— 重构位的扫地僧

内建件，描述行最有意思的一句是结尾：

> Review the changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Quality only — it does not hunt for bugs; use /code-review for that.

「Quality only — it does not hunt for bugs; use /code-review for that.」——这是**让路式门牌**的活教材：一句话把自己的职责边界（只管质量不管虫）和邻件分流路径（找虫去找 code-review）都写死了。内建件之间靠描述行互相避让、避免双重触发，这个设计在生态里并不常见，多数社区件巴不得描述写得越宽越好、什么都接。局限：simplify 与 code-review 的第二职责（cleanups）故意重叠——一个只报告、一个直接动手，重叠是有意的分工而不是设计事故，但使用者很容易混淆该叫哪个，这是内建家族共同的认知成本。

### 5. sentry —— 流水线最上游的哨兵

唯一盯**线上**的一件。Sentry 本身是主流错误监控平台，这个 Skill 的角色是把线上报警台接进宿主：错误聚合、堆栈、影响面摆在对话里，让调试从「用户截图报错」升级为「哨兵直接递卷宗」。它站的位置最上游——线上错误 → 定位 → 修复的链条，没有它，前面几件全都在等人工喂料。短板实在：上手门槛三颗星不冤——要有 Sentry 账号、项目接入、凭据配置，三道门做完才能用；描述行缺失的问题它同样有。适合已经有 Sentry 存量接入的团队，零基础团队先别从它入手。

### 6. notebook-fix —— 最窄但无人竞争的缝

名字即定位：修 Jupyter notebook 的错。notebook 是种特殊的报错现场——报错藏在 cell 输出里、状态依赖执行顺序、修复后还要重跑验证，通用修虫件在这种场景经常水土不服。它窄到生态里几乎没有同类竞品（本期视野内未见第二个专攻 notebook 修虫的件），这是「缝隙件」的典型生存策略：不做全能修虫，只占一个别人看不上的工位。社区活跃度给两颗星是六件最低：小众场景 + 裸名上架 + 本机清单零描述，三重边缘化。但如果你日常就是和数据 notebook 打交道，它可能是六件里唯一每天都叫得动的。

## 调试流水线全景

六件不是互斥选项，是一条链上的六个工位：

```mermaid
flowchart TD
    A["线上报错"] -->|sentry 哨兵| B["递上错误卷宗"]
    C["CI 红灯"] -->|gh-fix-ci 接单| B
    D["notebook 报错"] -->|notebook-fix 接单| B
    B --> E["定位根因"]
    E --> F["动手修复"]
    F --> G["跑测试回归"]
    G -->|不过| E
    G -->|通过| H["verify 真跑验收"]
    H -->|行为不对| F
    H -->|行为对了| I["simplify 打扫"]
    I --> J["code-review 闸门"]
    J -->|打回| F
    J -->|放行| K["合并收工"]
```

顺着链读一遍会发现：**「报错之后」根本不是一个技能点，是六个技能点的接力**。生态里那些号称「一站式修 bug」的大而全件，反而不如这条单件接力链可靠——每一段的职责边界都写在明面上。

## 安装与使用

```bash
# 内建三件：无需安装，Claude Code 直接可用
/verify          # 修完后验收：真跑应用看行为
/code-review     # 合并前找虫：可加 --fix 或 --comment
/simplify        # 质量打扫：只管整洁不管虫

# 修虫三件：通用安装法——克隆仓库后拷入个人技能目录
mkdir -p ~/.claude/skills
cp -r <仓库>/skills/gh-fix-ci   ~/.claude/skills/
cp -r <仓库>/skills/notebook-fix ~/.claude/skills/
cp -r <仓库>/skills/sentry      ~/.claude/skills/

# 或走插件市场渠道（本机即通过 anthropic-agent-skills 市场分发官方件）
# 在 Claude Code 会话内执行 /plugin 浏览已配置的市场
```

## 分维度排行榜

- **新手最快上手**：verify > simplify > code-review（内建零配置，会打斜杠就会用）
- **单点火力最猛**：gh-fix-ci（红灯事件驱动，触发最准）
- **流水线不可或缺**：verify（没有验收的修复都是口头承诺）
- **设计最值得抄**：code-review（范围 + 档位 + 参数出口的描述写法）
- **最独门缝隙**：notebook-fix（无竞品，但天花板也低）
- **最值得团队预装**：sentry（前提是线上监控已接 Sentry）

## 结语

本期最大的收获不是「哪件最强」，而是那条链：防虫在前（code-review）、修虫在中（gh-fix-ci / notebook-fix）、哨兵在上游（sentry）、验收和打扫在后（verify / simplify）。六件里有三件是内建、三件裸名上架，也印证了一个生态趋势——**调试这类高频刚需，正在从社区件市场回流到宿主内建**；社区件的机会只剩 notebook-fix 这样的窄缝。给你的行动建议：先把三个内建斜杠用熟（今晚就能用），再按自己报错最常出现在哪一层（线上 / CI / notebook）挑一件外装，最后照着那条链补齐缺的工位。

## 参考来源

1. [anthropics/skills](https://github.com/anthropics/skills) — 官方 Skills 仓库，官方件与示例件的源头，本期内建件设计的对照系
2. [anthropics/claude-code](https://github.com/anthropics/claude-code) — Claude Code 宿主仓库，内建 skills 与插件机制所在
3. [skillsmp.com](https://skillsmp.com) — Skills 聚合市场，2300+ 件的可搜索目录，本期「修虫件是否存在竞品」的检索入口
4. [mcpservers.org/agent-skills](https://mcpservers.org/agent-skills) — Agent Skills Library，官方与社区件精选目录
5. [skillsdirectory.com](https://www.skillsdirectory.com) — 带安全扫描评级的 Skills 目录
6. [skills.sh](https://skills.sh) — Skills 生态榜单站，观察件热度变化的入口
7. 本机实装环境：`~/.claude/skills/`（gh-fix-ci、notebook-fix、sentry 实装目录）与 `~/.claude/plugins/marketplaces/anthropic-agent-skills/`（官方件分发渠道），内建三件描述行引自宿主加载后的原文

> [!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)
