# 审查重构免安装：Claude内置四件横评 ## 概述 第三轮，按计划轮到开发者效率类横评：代码审查、测试、重构、调试。但这一轮我不去市场扫新架了，而是把镜头调转180度，对准一个更容易被忽视的事实：**在最新版的 Claude Code 里，审查、重构、验证这三件事已经有官方内置件兜底了**——`code-review`、`simplify`、`verify`、`security-review` 四个 Skill 随 CLI 直接可用，不装、不配、不占 marketplace 名额。本轮以一台重度使用的实装环境为样本，把这四件逐个拆到描述文本级别，再拉出社区赛道里同职能的几件（CI 修错、PR 评论跟进、线上报错）作参照系，回答一个生态问题：**内置件把底线抬高之后，社区件的生存空间还剩在哪**。 ## 方法论说明：为什么拿实装环境当样本 看榜单容易高估新品，看装机容易高估旧品，但装机单有一条榜单没有的信息：**什么被留下来继续用了**。本轮样本环境是一台日常开发机，装有数百个 Skill，其中开发者效率向的实装件包括 `gh-fix-ci`、`gh-cli`、`gh-address-comments`、`playwright`、`sentry`、`webapp-testing`、`jupyter-notebook`、`notebook-fix`、`github-actions-skill` 等——这些恰好都是此前各轮拆过的熟面孔。而真正"零配置开局就有"的，是随 CLI 分发的内置四件。它们的描述文本就在可用 Skill 列表里，逐字可查，这一轮的"拆"，就是拆这几段官方描述。 说明一点纪律：本轮没有做任何 Star 数、下载量的引用——内置件不挂在 marketplace 上，没有 Star 可看，硬编一个数字反而失真。社区活跃度这一维度，对内置件改按"随 CLI 版本迭代、由 Anthropic 官方维护"来评估。 ## 评测对比表 | 维度（权重） | code-review | simplify | verify | security-review | |---|---|---|---|---| | 功能完整度（25%） | ★★★★★ | ★★★★ | ★★★★ | ★★★ | | 设计质量（25%） | ★★★★★ | ★★★★★ | ★★★★★ | ★★★ | | 实战效果（20%） | ★★★★ | ★★★★ | ★★★★★ | ★★★ | | 上手难度（15%） | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★★ | | 社区活跃度（15%） | ★★★★ | ★★★★ | ★★★★ | ★★★ | | **加权总分** | **4.70** | **4.40** | **4.55** | **3.85** | （上手难度为反向计分：越易用星越高。内置件全部免安装，该项天然满分。） ## 逐件拆解 ### 一、code-review：一个描述里塞进三套设计 它的完整描述值得整段抄下来看： > Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups (low/medium: fewer, high-confidence findings; high→max: broader, may include uncertain findings). Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after the review. 这一段话里至少有三处值得任何想写 Skill 的人抄作业。 **第一处：双目标合并。** "correctness bugs" 和 "reuse/simplification/efficiency cleanups" 两个目标写在同一句话里——找 bug 和找坏味道一次过。传统工具链里这是 linter 和静态分析两套东西的活，这里用一个 Skill 的描述直接声明通吃。代价是审查范围变宽后噪音风险上升，于是有了第二处设计。 **第二处：把召回/精度的权衡显式交给调用方。** 括号里那句 "low/medium: fewer, high-confidence findings; high→max: broader, may include uncertain findings" 是整段描述里最值钱的半句。它公开承认：力度调高，发现更多，但会混入不确定的发现。大多数审查工具的宣传话术是"我们又准又全"，这一句反着写——把取舍摆在台面上，让调用的人自己选。这种"自曝边界"的写法，恰恰是提示词工程成熟度的标志：模型在 high 档漏报不背锅，因为你选档位时已经被告知过了。 **第三处：动作后缀闭环。** `--comment` 把发现直接贴成 PR inline 评论，`--fix` 审完直接在工作区动手改。审查→评论→修复，一条命令链走完，不需要你把审查结果复制粘贴到另一个工具里。 短板也直说：它只看**当前 diff**。你改了什么它审什么，仓库里三年没人碰的老模块藏着多少雷，不归它管。这个边界是故意的——改动级审查要快，全库扫描是另一个物种的活。 ### 二、simplify：四词清单和一个干净的划界动作 simplify 的描述比 code-review 还短： > Review the changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Positive for quality but does not hunt for bugs; use /code-review for that. **四个名词就是它的全部方法论**：reuse（复用）、simplification（简化）、efficiency（效率）、altitude（抽象层级）。前三个词不稀奇，第四个词 altitude 值得单独说——"你这层抽象站得对不对"是代码评审里最主观、最难写成规则的一条，官方把它明晃晃列进清理清单，等于承认这类判断该交给模型而不是 linter 规则。 更值得学的是后半句的划界动作："does not hunt for bugs; use /code-review for that"。一句话说明自己**不做什么**，并把用户导流到正确的那一件。这正是本栏此前在"一段描述，决定 Skill 生死"里讲过的负向触发设计：description 不只写给调用方看，也写给模型的触发判断看——不写清"我不找 bug"，用户说"帮我看看这段代码"时它就可能越界开跑，跑完给你一堆和 simplify 无关的安全告警，体验直接崩掉。然后 `--fix` 语义也和 code-review 不同：它默认就动手改（"then apply the fixes"），不需要参数。重构件的交付物就是改完的代码，这个默认值选得对。 短板：它是"正面质量向"工具，和 code-review 的 cleanups 目标有明显重叠。同一个 diff 先跑 code-review 再跑 simplify，第二遍的发现会稀薄不少——二选一即可，没必连跑。 ### 三、verify：四件里唯一"跑起来"的 前两件都是静态看代码，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 feature works, or check your changes locally before you push. First looks for a project skill that already covers launching the app; otherwise falls back to built-in patterns per project type (CLI, server, TUI, Electron, browser-driven, library). 这段描述的信息密度极高，拆三个点。 **触发场景写了四个。** 验 PR、确认修复生效、测新功能、推送前自检——四种用户会原话打出来的说法全列上了。这就是触发词设计的教科书动作：不是描述"我是什么"，而是枚举"用户会在什么情况下需要我"。 **内置件之间会让位。** "First looks for a project skill that already covers launching the app"——它启动应用前先找项目里有没有现成的启动 Skill，有就用你的，没有才落到内置模式。这一句是整个内置件体系里最有生态意味的设计：官方件不抢项目件的活，先让路。对比某些社区件"装上就覆盖一切"的做派，这个先后顺序写进描述里，是把自己放在了工具链的正确位置上。 **兜底模式按项目形态分了七类。** CLI、server、TUI、Electron、浏览器驱动、library——一个"跑起来看看"的动作，按项目类型拆成了各自的启动与观察套路。实战效果这一项我给它最高分，原因很简单：**"编译通过"和"真的能跑"之间的鸿沟，是 AI 编程助手时代最大的质量黑洞**，verify 是四件里唯一正面填这个坑的。 短板：它依赖项目可运行。跑不起来的项目（缺环境变量、缺数据库、半成品）它会卡在启动这一步，此时退回让 verify 只做静态推演不如直接用 code-review。 ### 四、security-review：存在感最弱的一件，但位置不能缺 列表里它没有展开的长描述，是四件里信息量最少的一个。按名可判：安全向的审查，与 code-review 的正确性向互补。上手难度给满分依然成立——免安装。功能完整度和实战效果给三星，理由是诚实的：**在描述不可考、又无独立文档可引的情况下，我无法验证它的覆盖深度**（ OWASP、注入、越权这些分类是否有系统覆盖，本环境内无从确认），宁可保守打分也不脑补。 要划清一个边界：别把它和社区那三件安全件搞混。本机实装的 `security-best-practices`、`security-threat-model`、`security-ownership-map` 三件，此前"守门员身后：安全三件套补拆"一轮已经拆过——那是社区侧把威胁建模、所有权图谱做成了独立深件。内置 security-review 的定位更像"每次改动顺手过一遍安检门"，深检还是要交给专门件。 ## 参照系：社区件的生存空间在哪 把内置四件放进生态全景里，此前各轮拆过的社区件立刻显出分工边界： - **gh-fix-ci**（修错件横评轮拆过）：管 CI 红灯。改动级审查抓不住"合并后流水线挂了"这种系统级故障，这是它的地盘。 - **gh-address-comments**（审查下半场轮拆过）：管 PR 评论线程的批量认领与回复。审查发现之后的"跟评论"环节，内置件没有覆盖。 - **sentry**：把线上错误监控接进对话。改动级工具的天花板是"推送前"，生产环境的事它够不着。 - **webapp-testing**（官方示例库出品，此前已评）：管 Web 应用的自动化测试执行，与 verify 的"手动跑起来看一眼"形成自动化与验收的两级。 规律浮出来了：**内置件统治"改动级"（当前 diff 的审查、简化、验证、安检），社区件退守"系统级"（CI、PR 流程、线上监控）**。这个边界对想入场写开发效率类 Skill 的人是明确的选 Guide：别再写"通用代码审查"了，那条赛道官方已经用免费+零安装+随版迭代三重优势封死了；往 CI 深水区、特定框架的测试脚手架、生产观测方向走，那里内置件够不着。 ## 生态分工全景 ```mermaid flowchart TD A["一次代码改动"] --> B["code-review 审查"] A --> C["simplify 重构"] A --> D["verify 验证"] A --> E["security-review 安检"] B -->|高置信发现| F["PR 评论或直接修"] C -->|四词清单| G["改完的工作区"] D -->|先让位项目件| H["跑起来看行为"] H -->|推送之后| I["系统级战场"] I --> J["gh-fix-ci 灭红灯"] I --> K["sentry 盯线上"] I --> L["评论线程跟进"] ``` ## 推荐排行榜 - **设计质量榜**：simplify > code-review > verify > security-review。simplify 用最短的文本完成了方法论宣告+负向划界+导流三件事，单位字数信息量第一。 - **开箱即用榜**：四件并列第一，全部零安装零配置，斜杠即用。这也是内置件对社区件的碾压项——社区件装得再快，也比不过"本来就在"。 - **实战效果榜**：verify > code-review > simplify > security-review。"跑起来看行为"是当前 AI 编程流程里缺口最大的环节。 - **学习价值榜**（给 Skill 作者）：code-review > simplify > verify。想学描述怎么写，把前两件的描述抄十遍。 ## 使用命令 内置件无需安装，Claude Code 内直接斜杠调用： ```bash /code-review # 默认档，高置信发现 /code-review high # 加大力度，接受更多不确定发现 /code-review --comment # 发现贴成 PR inline 评论 /code-review --fix # 审完直接改工作区 /simplify # 四词清单清扫，默认直接改 /verify # 跑起来验证当前改动 /security-review # 改动安全过检 ``` 想补齐系统级战场，先在本机定位社区件再决定装哪件： ```bash npx skills find ci fix # 定位 CI 修错类件 npx skills find sentry # 定位错误监控类件 ``` （具体安装命令以 skills.sh 与各仓库页面给出的为准，本机实装版本可直接复用。） ## 结论 这一轮横评的结论和以往都不一样：**最好的开发效率 Skill，是你不需要去 marketplace 找的那几个**。官方用四个内置件把改动级质量兜底做完，而且描述文本本身就示范了 Skill 写作的三个高阶动作——自曝取舍（code-review 的档位说明）、负向划界（simplify 的"我不找 bug"）、位次让路（verify 的"先用项目件"）。社区件没有被杀死，但入场券换成了"内置够不着"：要么下到 CI 和生产的深水区，要么扎进特定框架的垂直场景。下一轮按计划进内容创作与办公类横评，那条赛道没有官方内置件压顶，竞争格局会热闹得多。 ## 参考来源 1. [anthropics/skills](https://github.com/anthropics/skills) — 官方 Skills 仓库，Skills 机制与官方示例库的源头 2. [skillsmp.com](https://skillsmp.com) — 2300+ Skills 可搜索目录，本轮赛道全景对照 3. [mcpservers.org/agent-skills](https://mcpservers.org/agent-skills) — Claude Skills & Agent Skills Library 官方+社区精选 4. [skills.sh](https://skills.sh) — Skills 生态站与热门榜单，社区件安装命令出处 5. 本机 Claude Code 实装环境 — 内置四件描述文本与社区件装机清单的直接来源 > [!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 等场景全覆盖。