第三轮，按计划轮到开发者效率类横评：代码审查、测试、重构、调试。但这一轮我不去市场扫新架了，而是把镜头调转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 |
（上手难度为反向计分：越易用星越高。内置件全部免安装，该项天然满分。）
它的完整描述值得整段抄下来看：
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 的描述比 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 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。
列表里它没有展开的长描述，是四件里信息量最少的一个。按名可判：安全向的审查，与 code-review 的正确性向互补。上手难度给满分依然成立——免安装。功能完整度和实战效果给三星，理由是诚实的：在描述不可考、又无独立文档可引的情况下，我无法验证它的覆盖深度（ OWASP、注入、越权这些分类是否有系统覆盖，本环境内无从确认），宁可保守打分也不脑补。
要划清一个边界：别把它和社区那三件安全件搞混。本机实装的 security-best-practices、security-threat-model、security-ownership-map 三件，此前"守门员身后：安全三件套补拆"一轮已经拆过——那是社区侧把威胁建模、所有权图谱做成了独立深件。内置 security-review 的定位更像"每次改动顺手过一遍安检门"，深检还是要交给专门件。
把内置四件放进生态全景里，此前各轮拆过的社区件立刻显出分工边界：
规律浮出来了：内置件统治"改动级"（当前 diff 的审查、简化、验证、安检），社区件退守"系统级"（CI、PR 流程、线上监控）。这个边界对想入场写开发效率类 Skill 的人是明确的选 Guide：别再写"通用代码审查"了，那条赛道官方已经用免费+零安装+随版迭代三重优势封死了；往 CI 深水区、特定框架的测试脚手架、生产观测方向走，那里内置件够不着。
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["评论线程跟进"]
内置件无需安装，Claude Code 内直接斜杠调用：
/code-review # 默认档，高置信发现
/code-review high # 加大力度，接受更多不确定发现
/code-review --comment # 发现贴成 PR inline 评论
/code-review --fix # 审完直接改工作区
/simplify # 四词清单清扫，默认直接改
/verify # 跑起来验证当前改动
/security-review # 改动安全过检
想补齐系统级战场，先在本机定位社区件再决定装哪件：
npx skills find ci fix # 定位 CI 修错类件
npx skills find sentry # 定位错误监控类件
（具体安装命令以 skills.sh 与各仓库页面给出的为准，本机实装版本可直接复用。）
这一轮横评的结论和以往都不一样：最好的开发效率 Skill，是你不需要去 marketplace 找的那几个。官方用四个内置件把改动级质量兜底做完，而且描述文本本身就示范了 Skill 写作的三个高阶动作——自曝取舍（code-review 的档位说明）、负向划界（simplify 的"我不找 bug"）、位次让路（verify 的"先用项目件"）。社区件没有被杀死，但入场券换成了"内置够不着"：要么下到 CI 和生产的深水区，要么扎进特定框架的垂直场景。下一轮按计划进内容创作与办公类横评，那条赛道没有官方内置件压顶，竞争格局会热闹得多。
[!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 等场景全覆盖。