<!-- title: 从报错到复现：调试赛道七件横评 -->

# 从报错到复现：调试赛道七件横评

## 概述

开发者效率赛道的四个经典环节——规格、重构、测试、调试——前三者在此前轮次均已拆过，唯独「调试」至今没有一个叫 `debug` 的同名专件。本期横评补上这块真空：评测对象不是从市场榜单临时抓的，而是本机 Claude Code 实装技能清单里的七件排障相关技能——官方自带的 `/run`、`/verify`、`/code-review`、`/simplify`，以及承包「故障进口端」的 `sentry`、`pcap-analyzer`、`notebook-fix`。核心发现有二：其一，官方没有造大而全的调试器，而是把调试拆成一条流水线，每件只认领一段，再用描述里的互斥条款把边界焊死；其二，故障信号各有格式，进口端天然碎片化，被社区件分头接管。

需要先交代本轮的方法边界：评测文本全部取自本机技能注册表中的一句话官方描述（原文引用，非转述），本轮未做网络热度核对，因此「实战效果」与「社区活跃度」两个维度不做星级评分，权重转移到其余三个可依据文本判断的维度上。凡是描述之外拿不准的信息，本文一律不写。

## 评测对比表

| Skill | 功能完整度 25% | 设计质量 25% | 上手难度 15% | 实战效果 20% | 社区活跃度 15% |
|-------|------|------|------|------|------|
| /verify | ★★★★☆ | ★★★★★ | ★★★★★ | –（未实测） | –（随官方分发） |
| /code-review | ★★★★☆ | ★★★★★ | ★★★★★ | – | – |
| /run | ★★★☆☆ | ★★★★☆ | ★★★★★ | – | – |
| /simplify | ★★★☆☆ | ★★★★☆ | ★★★★★ | – | – |
| sentry | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ | – | – |
| pcap-analyzer | ★★★☆☆ | ★★★☆☆ | ★★★★☆ | – | – |
| notebook-fix | ★★☆☆☆ | ★★★☆☆ | ★★★★☆ | – | – |

说明：前三列是基于描述文本的编辑判断——功能完整度看描述覆盖的场景宽度，设计质量看触发词与边界条款的工程水平，上手难度看零配置可用性。后两列留白，因为本轮没有抓取安装量与更新数据，打星就是编造。

## 调试流水线全景

```mermaid
flowchart LR
    subgraph IN["故障进口端"]
        SENTRY["sentry 线上错误"]
        PCAP["pcap-analyzer 网络包"]
        NBFIX["notebook-fix 笔记本"]
    end
    subgraph REPRO["复现与验证"]
        RUN["run 启动应用"]
        VERIFY["verify 行为验证"]
    end
    subgraph LOCATE["定位与清理"]
        CREV["code-review 正确性"]
        SREV["security-review 安全面"]
        SIMP["simplify 清理"]
    end
    SENTRY --> RUN
    PCAP --> RUN
    NBFIX --> RUN
    RUN --> VERIFY
    VERIFY --> CREV
    VERIFY --> SREV
    CREV --> SIMP
```

这张图是本文的主论点：没有一件技能叫「调试」，但七件技能首尾相接，覆盖了从故障信号进来到代码恢复干净的全过程。官方件占住了中段的「复现—验证—定位—清理」，社区件占住了进口端——因为线上错误、网络包、损坏的笔记本各有各的格式，没有任何一件官方技能能通吃。

## 逐件拆解

### 1. /verify —— 流水线的验收员

描述原文：*「Verify that a code change actually does what it's supposed to by running the app and observing behavior. Use when you need to verify a PR, confirm a fix works, test a change manually, check that a change works in your app, or review code changes before visual confirmation」*。

它的定位是「行为验证」而非「代码阅读」——关键词是 **by running the app**：不看 diff 猜对错，而是把应用跑起来观察实际行为。这正是调试流水线里最容易被省略的一环：多数开发者改完代码看一眼编译通过就提交，verify 把「确认修复真的生效」变成一个独立可触发的动作。

触发词设计上有两处值得学。第一是场景枚举足够宽：verify PR、确认修复、手动测试、改动前预览全部列出，覆盖了用户可能脱口而出的各种说法。第二是它和 `/run` 的兜底关系写进了描述：*「or when the user asks to run/start/screenshot the app」*——用户想跑应用但没被 run 接住的请求，verify 兜底。两件技能之间不留触发真空。

短板在于它对运行环境有隐含要求：应用得跑得起来。一个连启动都失败的项目，verify 无用武之地——这正是它必须和 `/run` 组队的原因。

### 2. /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)」*。

这是官方描述里工程密度最高的一句。三层信息：审查对象限定为 **current diff**（不扫全库，避免跑偏）；审查目标包含正确性 bug 和质量清理两类；最关键的是 effort level 参数的语义直接写进描述——low/medium 给少而确定的问题，high 给广而可能误报的覆盖。这等于把召回率/精确率的权衡做成了用户可见的旋钮，而不是藏在提示词里的黑箱。

参数设计同样在描述里：*「Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after the review」*。审查结果三种出口——只报告、贴到 PR、直接改工作区——全部由命令行参数控制。工具描述即使用文档，这是描述工程学的教科书案例。

### 3. /simplify —— 边界写得比功能还好的清理工

功能本身朴素：复用、简化、效率、altitude 四类清理，改完应用。真正值得拆的是它描述里的第二句：*「Quality only — it does not hunt for bugs; use /code-review for that」*。

一句负向条款，把两件技能的管辖边界焊死。没有这句话，用户说「帮我看看这段代码」，模型要在 simplify 和 code-review 之间猜；有了这句话，质量清理走 simplify、找 bug 走 code-review，路由零歧义。此前轮次拆过社区 Skills 的撞名与描述排他问题，官方这两件给出了同款问题的标准答案：**与其把一件技能做大，不如把两件的边界说清**。对想写自己第一件 Skill 的读者，这一句比任何教程都有参考价值——写完正向触发词，再问自己一句「哪些请求不该路由到我」，写进描述。

### 4. /run —— 流水线的发动机

描述原文：*「Launch and drive this project's app to see a change working. Use when asked to run, start, or screenshot a browser, terminal, TUI, Electron, browser-driven, or API app」*。

它的设计亮点是**按应用形态枚举触发词**：browser、terminal、TUI、Electron、API 六种形态写死在描述里。用户不会说「帮我驱动我的 TUI」，但会说「帮我启动终端应用看看」——枚举形态等于枚举了用户的说法。它还处理了「项目技能优先」的细节：先找项目里已有的启动技能，找不到再用通用逻辑。

单独看它只是个启动器；放到流水线里它是前置条件——verify 要观察行为，先得有东西在跑。评分上功能完整度只给三星，因为描述里没有提到失败场景（端口占用、依赖缺失）的处理，这些恰恰是启动环节最高频的故障。

### 5. sentry —— 线上故障的进口端

官方件管本地流水线，进口端归社区。sentry 技能把 Sentry 的错误监控接进会话：线上报错不再要去网页后台翻，而是作为上下文直接喂给模型，配合 `/code-review` 形成「线上报错 → 定位 diff → 修复」的闭环。

设计质量只给三星，是因为它天然依赖外部凭据：Sentry 的项目配置、认证状态都不在技能掌控内，上手难度明显高于零配置的官方四件。但它代表了一个重要的生态位判断——**调试的起点往往不在本地**，故障信号进口端是官方件覆盖不到、社区件正好补位的真空带。

### 6. pcap-analyzer —— 网络层的显微镜

pcap 在本机以三件套形式出现：analyzer（分析）、generator（生成）、modifier（修改）。分析件是调试用件：给一个抓包文件，协议解析、异常流量定位交给模型。它的存在说明一个容易被忽略的事实：调试的故障域不止代码本身——「接口突然超时」这类问题，代码审查看不出答案，得看线上包。

上手友好度不错：输入是一个标准格式的 pcap 文件，自然语言触发即可。短板同 sentry 类似：它是单点工具，抓包本身（tcpdump/wireshark 环节）仍在技能覆盖之外。三件套的组合倒是提供了完整链路——生成测试流量、分析、再修改重放，这是进口端里少见的成套设计。

### 7. notebook-fix —— 长尾故障域的补丁

最轻量的一件：修复 Jupyter notebook 的执行故障。单看存在感不强，但它和 `encoding-check`（编码检查）一起，代表着调试赛道的第三种形态——**不是流水线的一段，而是某个特定故障域的专杀件**。数据科学工作流的报错格式、字符编码问题，通用流水线处理起来事倍功半，专杀件用最小的描述成本换精确路由。这类技能的写法也最值得新手模仿：一个明确的故障域，一段「何时用我」的描述，完事。

## 可直接复制的三个描述设计

从这七件的描述文本里，能提炼三条立刻可抄的写法：

**一、负向条款收尾。** simplify 的 *「it does not hunt for bugs; use /code-review for that」* 是范本格式：先说我不做什么，再指路给谁。任何与邻居技能有模糊地带的描述，都应该有这句话。

**二、参数语义进描述。** code-review 把 effort level 的精确/召回权衡写成 *「fewer, high-confidence findings」对「broader coverage, may include uncertain findings」*。用户不用读文档就知道调高会怎样——因为模型读得懂描述，会替你解释。

**三、按用户说法枚举，不按技术分类枚举。** run 枚举的是「browser / terminal / TUI」这些用户嘴里的词，而不是「GUI / CLI」这种技术二分法。触发词的本质是匹配用户语言，不是展示架构知识。

## 推荐排行榜

**零配置开箱榜**：/verify > /code-review > /simplify > /run——四件全部随 Claude Code 内置，装好即用，其中 verify 和 code-review 的描述成熟度最高。

**设计范本榜**：/code-review > /simplify > /verify > /run——code-review 的参数化描述是全场最佳；simplify 靠一句边界条款跻身第二。

**进口端实用榜**：sentry > pcap-analyzer > notebook-fix——按故障信号的出现频率排，线上错误远多于抓包分析和 notebook 损坏；有网络排障需求的团队可将 pcap 三件套位次提前。

**给想入场调试赛道的开发者**：本地中段流水线已被官方四件占满，别再造「调试器」；进口端仍有真空——日志格式归一化、错误堆栈降噪、性能火焰图解读，都是「故障信号有格式、官方件没认领」的方向。

## 参考来源

1. [Claude Code 本机技能注册表](https://code.claude.com/docs/en/skills) — 本文七件技能的官方描述原文，取自 2026-09-06 本机会话实装清单；/verify、/code-review、/simplify、/run 的引文均为注册表原文
2. [anthropics/skills 官方仓库](https://github.com/anthropics/skills) — 本机 example-skills 插件（docx、pptx、skill-creator 等）的来源仓库，官方件设计模式的背景参考；本轮未重新抓取
3. [skills.sh 生态站](https://skills.sh) — Skills 生态热门榜单站点，进口端社区件（sentry、pcap 系列）的背景定位参考；本轮未重新抓取

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