开发者效率赛道的四个经典环节——规格、重构、测试、调试——前三者在此前轮次均已拆过，唯独「调试」至今没有一个叫 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 | ★★☆☆☆ | ★★★☆☆ | ★★★★☆ | – | – |
说明：前三列是基于描述文本的编辑判断——功能完整度看描述覆盖的场景宽度，设计质量看触发词与边界条款的工程水平，上手难度看零配置可用性。后两列留白，因为本轮没有抓取安装量与更新数据，打星就是编造。
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
这张图是本文的主论点：没有一件技能叫「调试」，但七件技能首尾相接，覆盖了从故障信号进来到代码恢复干净的全过程。官方件占住了中段的「复现—验证—定位—清理」，社区件占住了进口端——因为线上错误、网络包、损坏的笔记本各有各的格式，没有任何一件官方技能能通吃。
描述原文：「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 组队的原因。
描述原文：「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、直接改工作区——全部由命令行参数控制。工具描述即使用文档，这是描述工程学的教科书案例。
功能本身朴素：复用、简化、效率、altitude 四类清理，改完应用。真正值得拆的是它描述里的第二句：「Quality only — it does not hunt for bugs; use /code-review for that」。
一句负向条款，把两件技能的管辖边界焊死。没有这句话，用户说「帮我看看这段代码」，模型要在 simplify 和 code-review 之间猜；有了这句话，质量清理走 simplify、找 bug 走 code-review，路由零歧义。此前轮次拆过社区 Skills 的撞名与描述排他问题，官方这两件给出了同款问题的标准答案：与其把一件技能做大，不如把两件的边界说清。对想写自己第一件 Skill 的读者，这一句比任何教程都有参考价值——写完正向触发词，再问自己一句「哪些请求不该路由到我」，写进描述。
描述原文：「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 要观察行为，先得有东西在跑。评分上功能完整度只给三星，因为描述里没有提到失败场景（端口占用、依赖缺失）的处理，这些恰恰是启动环节最高频的故障。
官方件管本地流水线，进口端归社区。sentry 技能把 Sentry 的错误监控接进会话：线上报错不再要去网页后台翻，而是作为上下文直接喂给模型，配合 /code-review 形成「线上报错 → 定位 diff → 修复」的闭环。
设计质量只给三星，是因为它天然依赖外部凭据：Sentry 的项目配置、认证状态都不在技能掌控内，上手难度明显高于零配置的官方四件。但它代表了一个重要的生态位判断——调试的起点往往不在本地，故障信号进口端是官方件覆盖不到、社区件正好补位的真空带。
pcap 在本机以三件套形式出现：analyzer（分析）、generator（生成）、modifier（修改）。分析件是调试用件：给一个抓包文件，协议解析、异常流量定位交给模型。它的存在说明一个容易被忽略的事实：调试的故障域不止代码本身——「接口突然超时」这类问题，代码审查看不出答案，得看线上包。
上手友好度不错：输入是一个标准格式的 pcap 文件，自然语言触发即可。短板同 sentry 类似：它是单点工具，抓包本身（tcpdump/wireshark 环节）仍在技能覆盖之外。三件套的组合倒是提供了完整链路——生成测试流量、分析、再修改重放，这是进口端里少见的成套设计。
最轻量的一件：修复 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 三件套位次提前。
给想入场调试赛道的开发者：本地中段流水线已被官方四件占满，别再造「调试器」；进口端仍有真空——日志格式归一化、错误堆栈降噪、性能火焰图解读，都是「故障信号有格式、官方件没认领」的方向。
[!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 等场景全覆盖。