# 拆claude-api：自家说明书成管家 ## 概述 本期是开发者效率线的第三次例行观察，主题锁定「代码审查/测试/重构/调试」四段式产线。拆解范围是当前 Claude Code 环境里实际在编的效率件：code-review、simplify、verify、run，以及本期主角 claude-api。核心发现有两个：一是效率线的竞争已经从「帮你写代码」整体后移到「改完代码之后」，审查、重构、实测三段全部编制化；二是整条产线最容易被忽略的位置，恰恰是「帮你写对接代码」的 API 管家件——它的触发规则设计（TRIGGER/SKIP 双清单 + 版本迁移表）值得所有想自己写 Skill 的开发者抄作业。本文所有引用均来自本机在编 Skill 的触发描述原文，读者可在自己的环境里直接核对复现。 ## 本期主角为什么是它 过去两轮观察里，效率线的镜头一直对着「写」和「查」：写码件卷提示词，读码件卷理解力，审查件卷发现率。但一个日常事实被系统性低估了：大量开发者的时间不花在写业务代码上，而花在**对接**上——接一个 SDK、调一次缓存、把旧模型 ID 换成新模型 ID。这类活的特点是：知识点密度高、版本变化快、错了不报编译错只报运行时行为错。 claude-api 这个 Skill 的官方触发描述原文如下（节选）： > Build, debug, and optimize Claude API / Anthropic SDK apps. Apps built with this skill should include prompt caching. Also handles migrating existing Claude API apps between Claude model versions (4.5 → 4.6, 4.6 → 4.7, retired-model replacements). 三句话，信息密度极高，逐句拆： **第一句「Build, debug, and optimize」**——三个动词把管辖范围一次性圈死。注意它没有说「answer questions about the API」，也就是说它的自我定位不是文档查询件，而是**施工件**：从搭建、调试到优化全程接管。这是它和纯文档类 Skill（比如此前观察过的对家说明书件 openai-docs）在定位上的本质分野——文档件管「查」，施工件管「干」。 **第二句「should include prompt caching」**——这半句是最容易被略过、实际最值钱的。它把「提示词缓存」写成了**默认义务**而非可选项：凡是经手搭建的应用，产出物必须内置缓存设计。这等于把一条性能优化的最佳实践，从「开发者记得就用」升级成了「出厂标配」。写 Skill 的人应该注意到这个模式：**把行业里最常被遗忘的最佳实践，直接焊死在 Skill 的义务清单里**，比写十段注意事项都管用。 **第三句是版本迁移表**——「4.5 → 4.6, 4.6 → 4.7, retired-model replacements」。把当前支持的迁移路径直接白纸黑字写进触发描述，有两个效果：一是模型换代时 Skill 不需要猜，二是这段描述本身成了「保质期标签」，用户一眼能看出这份说明书的新鲜度。 ## 触发规则的双清单设计 claude-api 描述里最值得照抄的，是它的 TRIGGER/SKIP 结构： > TRIGGER when: code imports `anthropic`/`@anthropic-ai/sdk`; user asks about the Claude API, Anthropic SDK, or Managed Agents; users add/modify/tunes a Claude feature (caching, thinking, compaction, tool use, batch, streaming)... > SKIP: file imports `openai`/other-provider SDK, filename like `*-generic.py`, `*-py`... provider-neutral code, generic programming/ML. 用一张流程图表达这套路由逻辑： ```mermaid flowchart TD A["用户请求进来"] --> B{"代码里有Anthropic SDK"} B -->|有| C["TRIGGER接管"] B -->|没有| D{"在调Claude特性"} D -->|缓存或压缩或工具| C D -->|没调| E{"写成对家中立代码"} E -->|是| F["SKIP让路"] E -->|不是| G["保持沉默"] ``` 这个设计解决的是 Skill 生态的老大难问题：**误触发**。单清单（只写什么时候激活）的 Skill，遇到边界场景只能靠猜；双清单把「什么时候让路」也写成显式规则——文件里 import 了对家的 SDK、或者文件名带 `-generic` 后缀（作者显然遇到过「通用工具文件被误判」的实际案例，否则不会专门写一条文件名规则）、或者代码刻意写成了供应商中立的抽象层，三种情况全部主动退出。 对想自己写 Skill 的读者，这里有一个可直接复用的模式：**TRIGGER 写「特征」而不是「关键词」**。这份描述没有写「when user says Claude」，而是写「code imports anthropic」——代码特征比用户措辞稳定得多。用户可能说「帮我调下缓存」，也可能说「这个响应太贵了」，但 `import anthropic` 永远长一个样。 ## 产线四段横评 主角之外，本期把效率线在编的另外四件放在同一张桌子上对账。先看总表： | Skill | 赛道 | 功能完整度 | 设计质量 | 实战效果 | 上手难度 | 触发精准度 | |-------|------|-----------|---------|---------|---------|-----------| | code-review | 代码审查 | ★★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★ | | simplify | 重构 | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★ | | verify | 测试验收 | ★★★★ | ★★★★★ | ★★★★★ | ★★★ | ★★★★★ | | run | 调试现场 | ★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★★ | | claude-api | API 对接 | ★★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★★ | 说明：本期五件全部为在编件，无下载量与外部热度数据可比，故以「触发精准度」替代社区活跃度维度；评分基于描述设计的完备度与本机实测观察，供参考。 ### code-review：一个出口两条路 描述原文的关键句：「Review the current diff for correctness bugs and reuse/simplification/efficiency cleanups (low/medium: fewer, high-confidence findings; high → 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 after the review.」 两个设计点。其一是**置信度档位**：low/medium 档只报高置信发现，high 档扩大覆盖、容忍不确定项。这把「审查报告的噪音/召回权衡」做成了用户可选参数，而不是替用户做决定——审查件最容易翻车的点就是满屏疑似误报，档位化是成熟的处理。其二是**双出口**：`--comment` 把发现贴成 PR 行内评论（对外输出），`--fix` 直接把修复落到工作区（对内消化）。一个审查件同时打通「报」和「修」，意味着「审查→修复」之间不需要人工搬运，这是它功能完整度拿到满分的理由。短板也在这里：`--fix` 落盘之后与 simplify 的职责产生了一小段重叠区，两个件的边界靠用户自觉。 ### simplify：只做减法的偏科生 描述原文：「Review the changed code for reuse, simplification, and efficiency, and then apply the fixes. Performance is a ranking signal...」——注意结尾半句：「it does not hunt for bugs; use /code-review for that.」 这半句是本期五件里**最克制的一句设计**。重构件的天职是改结构，但改结构的手和查 bug 的眼如果长在同一件上，用户就说不清「这次改动到底是重构引入的还是审查漏掉的」。simplify 主动把自己钉死在「只管简化、不查虫」，并且把查虫的活显式指回 code-review——这是一条写进描述里的**分工协议**。产线思维到这个程度，设计质量维度不给五星说不过去。短板是它默认直接动手（apply the fixes），对想先看方案再落盘的用户，需要靠参数或人工拦一道。 ### 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, or check that a feature works...」 四件效率件里，verify 是唯一把「跑起来看行为」写成方法论的。它的设计哲学和静态审查件正相反：**不读码下结论，让运行时举证**。测试维度里最贵的从来不是写用例，而是「改完之后到底验证没验证」——大量事故的根因是开发者肉眼确认了 diff 就合了。verify 把「观察行为」设为完成定义，实测效果维度给五星。上手难度三星的原因也在于此：它要求环境真能跑起来，没有可运行环境的仓库（纯库、纯配置类）它就使不上劲。 ### run：verify 的前置半件 描述原文：「Launch and drive this project's app to see a change working. Use when asked to run, start, or screenshot the app, or to confirm a change works visually. For bugs, manual tests, or end-to-end checks, use the verify skill instead.」 run 和 verify 是一对刻意切开的双件：run 管「把应用跑起来、开到能看到变化的地方」，verify 管「确认变化符合预期」。注意 run 描述里的最后一句——遇到 bug、手工测试、端到端检查，**显式让位给 verify**。和 simplify 指回 code-review 一样，这又是一条描述内分工协议。本期五件里有三件（run、verify、simplify）都带着「什么时候去找隔壁」的让位条款，这不是巧合，是在编效率件正在形成**互相引用的分工网络**的信号。run 本身功能较薄（三星），但薄得有道理：它是现场设备，不是质检员。 ## 效率线全图 把五件放在一条产线上看位置： ```mermaid flowchart TD S["Diff成形"] --> R["code-review查虫"] R -->|报给PR| P["行内评论出口"] R -->|落盘修| F["--fix改动进工作区"] F --> Y["simplify重构收尾"] Y --> V["verify跑起来举证"] V --> Q["run现场开到出问题处"] Q --> Z["security-review安全把关"] A["对接类需求进来"] --> C["claude-api单开一条线"] C --> D["缓存出厂标配"] C --> E["版本迁移对表"] ``` 值得注意的空位：这条产线上「安全」只有 security-review 一个名字在编，且无细分件；调试维度的深度排查（性能剖析、内存泄漏类）也还没有对应在编件。效率线的下一段编制化，大概率发生在这两个位置。 ## 安装与使用 五件均为在编件，无需安装，斜杠直接调用： ```bash # 审查当前 diff（默认低噪音高置信档） /code-review # 审查并把发现贴成 PR 行内评论 /code-review --comment # 审查并把修复直接落到工作区 /code-review --fix # 只做重构简化，不动 bug /simplify # 跑应用确认改动真的生效 /verify # 单纯把项目跑起来看效果 /run # API 对接类需求无需显式调用 # 代码 import anthropic SDK 时自动接管 ``` claude-api 的使用方式特别说明：它没有斜杠入口，触发完全靠描述里的特征规则——`import anthropic` / `@anthropic-ai/sdk`、或者你提到缓存、上下文压缩、工具调用、批处理、流式这些 Claude 特性时自动上岗。想验证它是否在编，新建一个 `import anthropic` 的文件再提需求即可观察到接管行为。 ## 推荐排行榜 **设计质量榜**（描写其他 Skill 作者该学谁）： 1. claude-api —— 双清单触发 + 义务化最佳实践 + 保质期标签，三项模式全部可迁移 2. simplify —— 一句「不查虫」的克制胜过十段功能堆砌 3. verify —— 把「观察行为」写成完成定义 **新手优先装榜单**（本批全部在编免安装，按日常收益排）： 1. verify —— 防「肉眼确认就合并」事故的第一道闸 2. code-review —— 档位化噪音控制，大 diff 场景收益最大 3. claude-api —— 凡是要接 Claude 能力的项目，缓存和版本迁移两处几乎必赚 **最被低估榜**： 1. run —— 名字太朴素，实际是 verify 和截图确认的现场基座 2. claude-api —— 人人盯着写码件，没人注意对接件省下的才是整块时间 ## 写给自己的 Skill：三条可抄的作业 最后把本期拆出的设计模式收拢，供动手写第一个 Skill 的读者直接套用： 1. **特征触发优于关键词触发**。学 claude-api 写「when code imports X」，别写「when user mentions X」——措辞千变万化，import 语句只有一个长相。 2. **给最佳实践上强制**。学「should include prompt caching」的写法，把你的领域里最常被忘掉的那件事（安全头、错误重试、时区处理）写成产出物的默认义务，而不是可选建议。 3. **写让位条款**。学 simplify 和 run，在描述末尾加一句「本件不做 X，用 Y 代替」。单件说明自己的边界，整个 Skill 网络才不会在边界上互相踩脚。 ## 参考来源 1. 本机 Claude Code 在编 Skill 实测（2026-10-03）——本文引用的 code-review、simplify、verify、run、claude-api 触发描述均为本地在编件描述原文，读者可在自己的环境中通过斜杠命令与技能列表逐条核对 2. [Anthropic 官方 Skills 仓库](https://github.com/anthropics/skills) — 官方维护的 Skill 集合入口，在编件的官方出处所在 3. [skillsmp.com](https://skillsmp.com) — Skills 聚合目录，可用于对照第三方效率件的同类设计 4. [mcpservers.org/agent-skills](https://mcpservers.org/agent-skills) — Claude Skills 与 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 等场景全覆盖。