本文由 莫潇羽@源码七号站(www.fuyuan7.com)撰写,转载请注明出处。

快速摘要

一句话结论:Anthropic 把自家维护的 Claude Code 官方插件目录开源到了 GitHub,仓库名叫 claude-plugins-official,目前 Star 数已经突破 2.6 万。 这个仓库里聚集了 30 多个由 Anthropic 内部团队亲自维护的内部插件,以及十几个经过审核的第三方外部插件,涵盖了 LSP 语言智能、PR 审查、功能开发流水线、遗留代码迁移、Hook 自动化、MCP 工具集成等几乎所有日常开发场景。安装一行命令搞定:/plugin install <插件名>@claude-plugins-official,装好就能用,不用重启。

如果你之前只是把 Claude Code 当成"会写代码的命令行助手",这一波更新之后,它实际上是变成了一个可以按需扩展、可以团队共享、可以按项目定制的开发平台。想看完整拆解,往下翻,我从插件机制原理一路聊到 claude-code-setup、feature-dev、hookify、code-modernization 这几个最值得装的官方插件怎么用,以及踩过的坑。

一、Claude Code 为什么需要一个插件市场

要把"官方插件目录"这件事讲清楚,得先回到一个最朴素的疑问:Claude Code 已经能在终端里写代码、跑命令、看仓库了,还要插件干嘛?

我自己折腾下来的体会是,Claude Code 这种"代理式编程工具",它的下限取决于模型本身,上限完全取决于你怎么调教它。同样一台机器,同样一个 Claude Code,在 A 同事手里能自动跑测试、自动写 commit、自动审查 PR,在 B 同事手里就只能问一句答一句,差距可以到一个数量级。

为什么会这样?因为在没有插件之前,所有的"个性化"都散落在四五个地方:

• 你自己写在 ~/.claude/ 下面的一堆斜杠命令(slash commands)
• 你为不同项目调试出来的 CLAUDE.md 规则文件
• 你手工配在 hooks.json 里的几条自动钩子
• 你在 .mcp.json 里串起来的几个 MCP 工具
• 还有你自己写的、不知道怎么命名的几个子代理(subagent)文件

这套东西的问题不在于"难配",而在于根本没法复用、没法分享、没法版本管理。同事问你一句"我也想用你那套",你打开自己的目录看一眼,发现自己都说不清当初哪一步先做、哪一步后做、哪个文件是必须的、哪个是历史遗留。换个新项目,所有东西重来一遍。

这就是经典的"works on my machine"困局,只不过这次困住的不是后端服务,而是 AI 工具链。

Anthropic 在 2025 年 10 月份首次推出 Claude Code 插件机制的时候,核心解决的就是这个事:把斜杠命令、子代理、Skill、Hook、MCP 服务器这五种扩展点打包到一起,做成一个标准结构的目录,起一个名字、写一个清单文件、发布到一个"市场"里,别人一条命令就能装上,跟手机装 App 一样。

但插件机制本身只是一个"包装规范",真正让普通用户用起来轻松的,是有一个官方维护的、质量过关的插件目录摆在那里,让你不用满 GitHub 翻、不用担心装到带后门的代码。这个目录,就是今天要拆的 claude-plugins-official。

我后来发现,Anthropic 把"目录"这件事看得很重。官方文档里特别强调了一点:插件本质上是可以在你的机器上以你的权限执行任意代码的高权限组件。换句话说,一个不可信的插件,理论上是可以在你机器上写文件、读取你的 token、上传你的代码的。所以官方目录的核心价值不是"全",而是"信得过"——里面的内部插件直接由 Anthropic 团队自己开发维护,外部插件也必须通过质量和安全审核才能进入。

理解了这个背景,你就明白为什么 claude-plugins-official 上线没多久就冲到 2 万多 Star——它不只是一个仓库,它是 Claude Code 这个生态的官方应用市场。

Claude Code 扩展机制的演进时间线

顺手把 Claude Code 这一套扩展能力的演进时间线梳理一下,大家心里会更有数:

从这条线索能看出来一个非常清晰的产品节奏:先把单个能力做成,再把这些能力封装到一个可分发的单元里。插件机制本身不是一个"功能",而是一个"封装格式"——它的价值在于把前面四种能力(MCP / Subagent / Hook / Skill)以及最早的 Slash Command 统一起来,变成可以一键安装、可以版本管理、可以审计的标准包。

典型使用场景:不只是个人工具

我跟几位国内做工程效率(DevX)团队的朋友聊过,他们对插件机制的兴趣点比"个人开发者"高得多。原因很简单:工程效率团队最大的痛点就是"经验难以复制"。

举几个真实场景:

• 新人入职第一天——以前要给新人配半天环境、给他塞一堆 Slack 截图说"这个项目你要先这样、再那样",现在做成一个公司内部 marketplace,新人 /plugin install 一下,整套规则、命令、Hook 全部到位
• 代码风格强制对齐——一个团队 20 个人,以前各写各的 prompt,代码风格五花八门。把审查规则做成 code-review 插件,大家用的标准就完全一致
• 关键流程不可绕过——比如"production 分支必须先跑安全扫描才能 merge",做成 Hook 插件强制装到 project 级,绕都绕不开
• 开源项目维护者发挥——以前你写一个流行的 Python 库,新用户用 Claude 接你的库总是写错。现在你可以发布一个"用 XX 库的最佳实践"插件,装上之后 Claude 写出来的代码就符合你的设计意图

换个角度看,插件机制让"AI 编程"这件事从个人体验上升到了基础设施。它的杀伤力不在"我多了几个命令",而在"我和我的团队能用同一个 AI 编程标准"。

二、claude-plugins-official 项目全貌

把仓库 clone 下来看一眼,目录结构非常简单,核心就两个文件夹:

claude-plugins-official/
├── .claude-plugin/
│   └── marketplace.json     # 整个市场的清单文件
├── plugins/                 # Anthropic 内部团队开发的插件
│   ├── claude-code-setup/
│   ├── feature-dev/
│   ├── hookify/
│   ├── code-modernization/
│   ├── code-review/
│   ├── pr-review-toolkit/
│   ├── commit-commands/
│   ├── frontend-design/
│   ├── security-guidance/
│   ├── code-simplifier/
│   ├── typescript-lsp/
│   ├── pyright-lsp/
│   ├── rust-analyzer-lsp/
│   ├── gopls-lsp/
│   ├── clangd-lsp/
│   ├── csharp-lsp/
│   ├── jdtls-lsp/
│   ├── kotlin-lsp/
│   ├── lua-lsp/
│   ├── php-lsp/
│   ├── ruby-lsp/
│   ├── swift-lsp/
│   ├── claude-md-management/
│   ├── plugin-dev/
│   ├── skill-creator/
│   ├── mcp-server-dev/
│   ├── explanatory-output-style/
│   ├── learning-output-style/
│   ├── session-report/
│   ├── math-olympiad/
│   ├── ralph-loop/
│   ├── example-plugin/      # 给开发者参考的示例
│   └── ...
└── external_plugins/        # 第三方合作伙伴的插件
    ├── asana/
    ├── context7/
    ├── discord/
    ├── firebase/
    ├── github/
    ├── gitlab/
    ├── greptile/
    ├── imessage/
    ├── laravel-boost/
    ├── linear/
    ├── playwright/
    ├── serena/
    ├── telegram/
    ├── terraform/
    └── ...

内部插件 / 外部插件

我把它整理成一张表会更直观:

内部插件大致可以分成四个大类:LSP 语言智能类(12 个,覆盖 TypeScript/Python/Go/Rust/Java/C#/Swift 等主流语言)、编程工作流类(code-review、feature-dev、code-modernization、code-simplifier、commit-commands、pr-review-toolkit、frontend-design 等)、Claude Code 自身配置与插件开发类(claude-code-setup、claude-md-management、plugin-dev、skill-creator、mcp-server-dev)、以及输出风格与专项能力类(explanatory-output-style、learning-output-style、security-guidance、session-report、math-olympiad)。

外部插件这一部分,目前主要是各种第三方平台的官方集成,比如 GitHub、GitLab、Linear、Asana、Firebase、Playwright、Terraform、Discord、Telegram 这种,本质上是把这些平台官方维护的 MCP 服务器打包成了 Claude Code 插件。这样你不用自己折腾 MCP 配置文件,装一下就能让 Claude Code 直接对接这些平台的 API。

一个插件的标准目录结构

每个插件本身也是一个目录,内部结构非常规范:

plugin-name/
├── .claude-plugin/
│   └── plugin.json        # 插件元数据(必需)
├── commands/              # 斜杠命令(可选)
├── agents/                # 专业子代理(可选)
├── skills/                # 技能定义(可选)
│   └── some-skill/
│       └── SKILL.md
├── hooks/                 # 钩子配置(可选)
├── .mcp.json              # MCP 服务器配置(可选)
└── README.md              # 文档

这个布局之所以重要,是因为它把"扩展 Claude Code 的所有方式"统一收口到了一个文件夹里。plugin.json 是清单文件,告诉 Claude Code "我这个插件提供了哪些斜杠命令、哪些子代理、哪些技能、哪些钩子、哪些 MCP 服务"。Claude Code 安装的时候只要读这个 manifest,就知道该把每个组件放到哪里去。

莫潇羽@源码七号站(www.fuyuan7.com)在做整理的时候特意注意了一下,目录里只有 .claude-plugin/plugin.json 这一个文件是必需的,其余的目录都是可选的。最极端的情况下,一个插件可以只包含一个斜杠命令,也可以只包含一个 MCP 服务器配置。这就让"插件"这个概念变得非常轻量,小到一行命令、大到一整套工作流,都可以是一个插件。

安全提醒(必读)

仓库 README 里有一句话写得非常重,我把它单独拎出来:

⚠️ 在安装、更新或使用任何插件之前,请确认你信任这个插件。

为什么这么强调?因为插件在你的机器上是以你自己的用户权限运行的——它可以读你的文件、可以调用你的命令行工具、可以发起网络请求。一个写得有恶意的插件,理论上可以做的事情远不止"帮你写代码"。

所以选插件的时候有几条原则我自己一直在守:

• 优先用 plugins/ 下的内部插件,它们直接由 Anthropic 团队维护
• 外部插件优先选大公司官方提交的,比如 GitHub、GitLab 这种,本身就有官方背书
• 遇到陌生作者的插件,先 clone 下来,看一眼 plugin.json 和它实际包含的命令、Hook,确认里面没有奇怪的网络调用再装
• 企业环境下用 strictKnownMarketplaces 这种托管设置来限制员工能添加的 marketplace

claude-plugins-official 的价值就是把"信任成本"前置到了 Anthropic 这边,你装内部插件不用担心被坑。

marketplace.json:整个市场的清单文件

仓库根目录的 .claude-plugin/marketplace.json 是这个市场的"总目录"。每一个插件在这个文件里都有一条记录,大致长这样:

{
  "name": "claude-plugins-official",
  "owner": {
    "name": "Anthropic"
  },
  "plugins": [
    {
      "name": "feature-dev",
      "description": "Guided feature development with codebase understanding and architecture focus.",
      "source": {
        "source": "directory",
        "path": "plugins/feature-dev"
      },
      "category": "workflow"
    },
    {
      "name": "github",
      "description": "Official GitHub MCP server for repo management.",
      "author": { "name": "GitHub" },
      "source": {
        "source": "url",
        "url": "https://github.com/github/github-mcp-server.git",
        "sha": "..."
      },
      "category": "vcs"
    }
  ]
}

source 字段有两种形式:directory 表示插件代码就在仓库内部(几乎所有内部插件都是这样),url 表示从另一个 git 仓库拉(外部插件常用这种方式,因为合作伙伴在自己的仓库里维护代码)。指定了 sha 的 URL 源会被锁在那个 commit 上,这是为了防止上游突然改东西破坏用户的环境。

这个机制有几个直接影响:

• 外部插件不会被随意更新——锁在 sha 上,作者要更新,得提 PR 改 sha,过审才会进
• 新增插件门槛清晰——不管你是内部还是外部,都要在 marketplace.json 里登记
• 下游可以自建分发——你完全可以 fork 这个仓库,改 marketplace.json 加入自己的插件,变成"内部市场",同事 marketplace add 你的 fork 就好

官方市场 vs 社区市场

Anthropic 维护了两个公开的 marketplace,区分一下:

社区市场是只读镜像,要往里加插件得通过提交表单。整体定位是"低门槛大水池"——量大、新东西多,但质量参差不齐,使用前要更小心地审一下源码。官方市场是"精选橱窗",量少但每一个都信得过。

我自己的策略是:个人开发机器上两个都加,日常优先用官方市场的,看到社区市场有什么新东西就去仓库读一下代码再决定。企业内部机器只加官方市场加自己公司的私有市场,社区市场默认不开。

三、把五种扩展机制掰开揉碎讲清楚

要真正理解一个插件能做什么,得先理解 Claude Code 的五种扩展机制分别是什么、各自适合做什么事。市面上很多介绍把这几个概念混在一起讲,看完更糊涂。这里我尽量用人话讲一遍。

Slash Commands(斜杠命令)

一句话:你自己定义的命令快捷键,以 / 开头,你主动喊它,它才会跑。

这是最早出现、也是最好理解的扩展机制。你写一个 markdown 文件放进 commands/ 目录,文件名就是命令名,文件内容就是这个命令对应的提示词(prompt)。

举个例子,如果我在 commands/code-review.md 里写:

---
description: 自动审查当前分支相对于 main 的所有改动
---

请审查当前分支相对于 main 分支的所有改动:
1. 找出潜在的 Bug
2. 检查代码风格是否符合项目规范
3. 评估性能问题
4. 列出每个问题的严重程度

那么在 Claude Code 里输入 /code-review,它就会自动把这段提示词加载到对话里。对于那种"我每天都要重复 20 遍的固定指令",做成斜杠命令是最划算的。

斜杠命令本质上是显式调用——你不喊,它就不动。

Subagents(子代理)

一句话:专门干某一类活儿的"专家分身",由 Claude 主动调度。

子代理是单独的 Markdown 文件,放在 agents/ 目录下,每个文件定义一个有特殊系统提示词、特殊工具权限的"小 Claude"。

举个例子,在 agents/security-reviewer.md 里,你可以定义一个"安全审查员"角色,它的系统提示词里写明:"你是一位资深安全工程师,只关注 SQL 注入、XSS、命令注入、敏感信息泄露这几类问题,不要管代码风格"。它的工具权限里只允许读文件、不允许写文件。

当主 Claude 接到一个复杂任务,比如"审查这整个 API 模块的安全性",它会自动判断:"哎,这个事情让 security-reviewer 来干比较合适",然后派生一个子代理出去,在一个独立的上下文里把这件事做完,做完再把结果汇报回主对话。

子代理最大的好处是保护主上下文——它做事情用的 token 在自己的上下文里,做完把结论返回来,主 Claude 的上下文窗口不会被一堆中间细节污染。

Skills(技能)

一句话:Claude 自动加载的"工作手册",根据语境自己决定要不要用。

Skill 是 2025 年 10 月份和插件机制同期推出的新概念。每一个 Skill 是一个目录,核心是里面的 SKILL.md 文件:

skills/
└── pdf-processor/
    ├── SKILL.md          # 描述+触发条件+具体做法
    ├── reference.md      # 可选的参考文档
    └── scripts/          # 可选的脚本

SKILL.md 里有一段 description,描述这个 Skill 在什么场景下用。Claude 在对话过程中会自动比对当前任务和所有可用 Skill 的描述,一旦匹配上,就把对应的 SKILL.md 加载进上下文,按里面的流程走。

跟斜杠命令比,Skill 的优势是自动触发。你不用记得"我要用 PDF,得敲 /pdf-processor",你只要说"帮我处理一下这个 PDF",Claude 自己就会找到 PDF 相关的 Skill 加载进来。

跟子代理比,Skill 是给主 Claude 用的工作手册,不会派生新进程,也不会占用额外的对话轮次。

Skill 这一层有个不太被讨论的细节:它支持懒加载。SKILL.md 文件的 description 字段会常驻在 Claude 的"可用工具列表"里,但具体内容只有真正用到的时候才加载。这意味着你可以装 50 个 Skill 而不会显著增加 token 占用。

Hooks(钩子)

一句话:在 Claude Code 的关键生命周期事件上挂"自动脚本",事件触发自动跑。

Hook 是最"工程化"的扩展机制,它跟 AI 智能没什么关系,纯粹是确定性的控制。它支持的事件类型有:

Hook 的配置方式有两种,一种是经典的 hooks.json,在里面用正则匹配 + 命令调用;另一种是新出的 prompt 类型,可以让一段自然语言提示词去决策"这次调用要不要拦截"。

Hook 在 Claude Code 整个工具链里非常关键,因为它给了你否决权——AI 再聪明,你也可以用 Hook 把"在 production 分支上不能 force push"这种铁律死死锁住。

MCP Servers(外部工具集成)

一句话:让 Claude 通过标准协议接入任意外部工具/数据源。

MCP 全称 Model Context Protocol(模型上下文协议),是 Anthropic 在 2024 年 11 月推出的标准协议。简单理解:它是 AI 工具界的 USB-C——之前每个工具厂商都要自己写一套对接 LLM 的接口,有了 MCP 之后,大家都按一个协议来,Claude(以及任何支持 MCP 的客户端)就可以无差别接入。

在插件里配 MCP 很简单,一个 .mcp.json 文件:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

装了这个插件之后,Claude 就能直接在对话里调用 GitHub 的 issue、PR、仓库搜索这些能力。

五种机制的关系

我画一张图把它们的位置标清楚:

graph TB
    A[一个 Claude Code 插件] --> B[Slash Commands<br/>你主动调用的命令]
    A --> C[Subagents<br/>Claude 调度的专家]
    A --> D[Skills<br/>Claude 自动加载的工作手册]
    A --> E[Hooks<br/>生命周期上的自动钩子]
    A --> F[MCP Servers<br/>外部工具/数据接入]

    B -.->|显式触发| G[主 Claude 对话]
    C -.->|主 Claude 派生| G
    D -.->|描述匹配自动加载| G
    E -.->|事件触发| G
    F -.->|工具调用| G

一个插件可以同时包含五种机制——这才是插件机制最强的地方。比如一个"前端开发助手"插件可以同时打包:/component-scaffold 这个斜杠命令、一个 frontend-design Skill、一个 ui-reviewer 子代理、一个保存时自动跑 prettier 的 Hook、再加一个 Playwright MCP 服务器。一条命令装上,五种能力全部到位。

五种机制怎么选

如果你自己要写一个扩展,该选哪种机制?我整理了一张决策对照表:

理解了这五种机制,你就知道为什么后面要讲的那些插件能做出这么花的功能——它们都是把这五块东西按场景组合而已。

四、claude-code-setup:让 AI 自己分析你的项目并给出推荐

讲完底层机制,来看官方推荐的"第一个该装的插件"——claude-code-setup。这个插件在社交媒体上传播得非常广,因为它解决了一个非常痛的问题:插件这么多,我哪知道哪些适合我这个项目?

工作原理

claude-code-setup 把自己定位成一个"automation recommender"(自动化推荐器),核心做的事情是:

• 扫描你当前仓库的 package.json、pyproject.toml、Cargo.toml、go.mod 等等清单文件
• 识别你项目的语言、框架、依赖关系
• 看一眼目录结构,推断这是 React 项目、Django 项目、还是后端微服务
• 检查 .git、CI 配置、有没有数据库迁移文件、有没有认证相关代码

它的内部判断逻辑大致是这样的:

flowchart TD
    A[读 package.json/pyproject.toml 等] --> B{项目类型?}
    B -->|React/Vue/Next| C[前端项目]
    B -->|FastAPI/Django/Express| D[后端服务]
    B -->|Python ML 库| E[ML/数据项目]
    B -->|混合| F[全栈项目]

    C --> G[推荐 Playwright MCP<br/>frontend-design Skill<br/>typescript-lsp]
    D --> H[推荐 security-guidance<br/>pyright-lsp/jdtls-lsp<br/>测试相关 Hook]
    E --> I[推荐 context7<br/>pyright-lsp<br/>notebook 相关工具]
    F --> J[组合推荐]

    G --> K[输出推荐清单]
    H --> K
    I --> K
    J --> K

然后基于这些信息,从前面提到的五个维度给你写一份"推荐配置清单":

推荐结果范例(示意,不是真实输出)
├── MCP 服务器:Playwright(因为检测到 React + e2e 测试)
├── Skill:frontend-design(因为有 UI 组件目录)
├── Hooks:
│   ├── PostToolUse 自动跑 prettier
│   ├── PreToolUse 拦截 production 分支上的 force push
│   └── Stop 时强制要求跑测试
├── Subagents:
│   ├── security-reviewer(因为检测到 auth 模块)
│   └── accessibility-checker
└── Slash Commands:
    ├── /test
    └── /pr-review

最关键的一点:它是只读的。这个插件在分析阶段不会改你任何文件,所有的建议都是"建议",最终装不装、改不改,都要你点头才会落地。

实际怎么用

装完之后,触发方式非常自由,可以用斜杠命令,也可以直接用自然语言告诉 Claude:

帮我看看这个项目应该装哪些自动化

recommend automations for this project

我现在的项目需要哪些 hooks?

Claude 接到这种意图,会主动加载 claude-code-setup 这个插件提供的 Skill,然后开始分析你的代码库,几分钟后给出一份带说明的清单。

我个人推荐两个使用时机:

• 新建项目第一天——立刻装上,让它根据你这个项目的形态推荐基础配置,不要等到三个月后 ~/.claude/ 已经被你乱配一堆才回头收拾
• 接手别人项目——尤其是接手一个你完全不熟的代码库时,让它扫一遍,顺便告诉你这个项目大概是个什么形态,有什么 Claude Code 能帮上忙的地方

安装命令

/plugin install claude-code-setup@claude-plugins-official

如果你只能在所有官方插件里挑一个装,我建议就是它。因为它会帮你判断剩下那些插件该不该装,相当于一个"插件领路人"。

一个真实的推荐输出长什么样

为了让大家有个直观感觉,我用一个虚拟的 React + Express 全栈项目让它跑了一遍,得到的推荐报告大致结构如下(关键信息已做泛化处理):

项目识别
├── 主语言:TypeScript(覆盖率 78%)、JavaScript(15%)、CSS(7%)
├── 前端框架:React 18 + Next.js
├── 后端框架:Express + Prisma ORM
├── 测试框架:Vitest + Playwright
├── CI:GitHub Actions
└── 关键发现:
    ├── 检测到认证逻辑(jsonwebtoken、bcrypt)
    ├── 检测到数据库 migration 目录
    └── 检测到 e2e 测试目录

推荐配置(按优先级)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[强烈推荐]
- typescript-lsp:让 Claude 写的代码贴合你项目的类型
- security-guidance:检测到 auth 逻辑,强烈建议
- frontend-design:有 React 组件目录
- playwright(外部插件):已有 Playwright e2e,可以让 Claude 跑

[推荐]
- commit-commands:CI 配置完善,一键 push + PR 体验最好
- feature-dev:多模块项目,结构化开发受益大
- pr-review-toolkit:适合团队 reviewer

[建议配 Hook]
- PreToolUse:拦截 main 分支上的 force push
- PostToolUse:写完 .ts 文件自动跑 prettier
- Stop:Claude 想结束前,提醒检查测试是否通过

整份报告看下来就是一份非常清晰的"开机配置单"。它不会替你装,但它会告诉你为什么这些值得装——这一点比任何"必装清单"都更有价值,因为它是基于你这个具体项目的形态推荐的,不是"通用最佳实践"。

五、feature-dev:把功能开发拆成 7 阶段流水线

第二个我用得最多的官方插件是 feature-dev。它做的事情用一句话讲:强制你在"写代码"之前先想清楚,在"提交"之前先审查清楚。

它解决了什么痛点

平常用 Claude Code 开发新功能,大家的流程一般是这样:

你: "帮我加一个 OAuth 登录功能"
Claude: "好的,我看一眼代码结构,然后开始改..."
[几分钟后 Claude 改完了]
你: "嗯...好像有点问题,而且跟我现有的认证逻辑没对齐"
[来回拉扯五六轮]

问题出在哪?Claude 太勤快了,你一说它就开始动手,没有想清楚之前就开始改。当任务规模超过两三个文件的时候,这种"问一句答一句"的模式效率反而低,因为它根本来不及搞清楚你这个代码库的现有约定。

feature-dev 把这个流程强行结构化成 7 个阶段:

flowchart LR
    A[1. Discovery<br/>需求发现] --> B[2. Codebase Exploration<br/>代码库探索]
    B --> C[3. Clarifying Questions<br/>澄清问题]
    C --> D[4. Architecture Design<br/>架构设计]
    D --> E[5. Implementation<br/>具体编码]
    E --> F[6. Quality Review<br/>质量审查]
    F --> G[7. Summary<br/>总结回顾]

每一个阶段都要等你"放行"它才会进入下一阶段。

三个核心子代理

feature-dev 部署了三个专门的子代理,各司其职:

第 2 阶段的玩法特别值得说一下:它会并行启动 2-3 个 code-explorer 子代理,每个负责一个不同的侧面。一个去找类似的现有功能、一个去理清架构模式、一个去找你这个项目里的关键抽象。三份报告并行返回,主 Claude 综合一份摘要给你。

第 4 阶段的玩法更狠:并行启动 2-3 个 code-architect,分别从"最小改动"、"干净架构"、"务实平衡"三个角度独立设计方案,然后做对比给你看。我用过几次,出来的对比表非常清晰:

方案 A:最小改动
- 改动文件:3 个
- 风险:低
- 缺点:跟现有的认证抽象重复,以后维护成本高

方案 B:干净架构
- 改动文件:8 个,新增 3 个抽象
- 风险:中
- 缺点:工作量大,需要改测试

方案 C:务实平衡(推荐)
- 改动文件:5 个,复用现有 AuthMiddleware
- 风险:低
- 缺点:命名稍微妥协

第 6 阶段的质量审查也是并行的:三个 code-reviewer 子代理同时跑,一个看代码质量、一个找 Bug、一个检查是否符合项目规范。每个发现都带置信度评分,默认只有置信度大于 80 的才推给你,有效过滤掉那种"为了找问题而找问题"的低质量反馈。

七个阶段实际跑起来什么感受

光看流程图不够具体,我把每个阶段的实际产出物讲一下:

第 1 阶段 Discovery(需求发现)

你输入需求,Claude 不会直接动手,先问你几个澄清问题。如果你只说"加个 OAuth",它可能会问:用哪个 provider(Google/GitHub/微信)?要不要保留账号密码登录作为后备?要不要做关联绑定?

第 2 阶段 Codebase Exploration(代码库探索)

并行的 code-explorer 子代理们同时跑,产出一份"现状报告":

• 现有的认证逻辑在哪几个文件
• 数据库里 users 表的字段
• 已有的 session/token 处理方式
• 项目里可能受影响的接口列表

第 3 阶段 Clarifying Questions(澄清问题)

基于探索结果,Claude 会再问一轮更具体的问题:"我看到你已经有 jsonwebtoken,要复用现有的 JWT 生成逻辑,还是 OAuth 流程用独立的 token 体系?"

第 4 阶段 Architecture Design(架构设计)

并行的 code-architect 出方案对比。每个方案会包含:

• 改动文件清单(精确到行号区间)
• 数据流图
• 关键抽象的命名
• 测试策略

第 5 阶段 Implementation(编码实现)

你选定方案之后才开始写代码。Claude 会按照之前商定的方案,一步步地改文件,中间会给你看进度。

第 6 阶段 Quality Review(质量审查)

三个 code-reviewer 子代理并行跑。每个发现会带置信度评分,默认只有置信度大于 80 的才推给你,有效过滤掉那种"为了找问题而找问题"的低质量反馈。

第 7 阶段 Summary(总结回顾)

给你一份"这次到底改了什么、改了为什么、还有什么没做"的总结报告。可以直接作为 PR 描述用。

整套流程跑下来大概 15-40 分钟(取决于代码库大小),比起"边写边救火"的传统模式,前期看似花时间多,但实际上把后期的反复修改时间砍掉了大半。

适合什么场景,不适合什么场景

我自己摸索出来的经验:

适合:

• 涉及多个文件、多个模块的功能新增
• 架构决策不太清楚的场景
• 不熟悉的代码库里第一次动手
• 团队协作场景,要给同事一份可读的实现说明

不适合:

• 改一个 typo、改一个配置值——杀鸡用牛刀
• 重命名变量这种纯机械操作
• 跨整个数据层的大重构——超出单个功能的范围,要拆成多个 feature

安装命令

/plugin install feature-dev@claude-plugins-official

使用方式可以带需求一起调用,也可以空跑让它问:

/feature-dev 添加基于 OAuth 的用户授权流程

/feature-dev

六、hookify:用人话生成 Hook 配置

聊到 Hook,大部分开发者的第一反应是"配置太繁琐,懒得搞"。莫潇羽@源码七号站(www.fuyuan7.com)自己第一次手写 hooks.json 的时候就被搞傻了——正则表达式、事件类型、命令调用、退出码,一套下来要查半天文档。

hookify 这个插件,就是把"写 Hook"这件事彻底用自然语言重写了一遍。

核心做法

hookify 不再用 JSON,改成用带 YAML frontmatter 的 markdown 文件来定义 Hook 规则。一个规则文件长这样:

---
name: block-dangerous-rm
enabled: true
event: bash
pattern: rm\s+-rf
action: block
---

⚠ 检测到危险的 rm 命令!

这个命令可能会删除重要文件,请先确认路径,并确保你有备份。

frontmatter 里面规定了几个核心字段:name(规则名)、enabled(是否开启)、event(监听哪种事件)、pattern(正则匹配)、action(warn 警告但允许,还是 block 直接拦截)。

下面的 markdown 内容就是规则触发时展示给 Claude 看的提示信息——这一点非常巧妙,因为 Claude 看到这段话之后,会按里面的指引去调整自己的行为。

自然语言生成规则

更绝的是你根本不用手写这个 markdown 文件。你只要用人话告诉 hookify 你想要什么:

/hookify 当我执行 rm -rf 命令的时候警告我

/hookify 别在 TypeScript 文件里写 console.log

/hookify 提交之前必须先跑测试

它会自动帮你生成对应的 markdown 配置文件,放到项目根目录的 .claude/hookify.{规则名}.local.md 下,立即生效,不需要重启 Claude Code。

支持的事件类型主要有四种:

三个实战范例

范例 1:拦截危险的 git 操作

---
name: block-force-push-main
enabled: true
event: bash
pattern: git\s+push.*--force.*main
action: block
---

🚫 检测到在 main 分支上 force push!

这是一个高风险操作,会覆盖远程历史。请改用 `--force-with-lease`,
并且最好开一个新分支提交。

范例 2:阻止往 TypeScript 文件里写 console.log

---
name: warn-console-log-ts
enabled: true
event: file
pattern: console\.(log|debug|info)\(
action: warn
---

🐛 检测到 console 调试语句

提交前别忘了清理这些调试代码,正式日志请用 logger.

范例 3:Claude 想结束对话时强制要求跑测试

---
name: must-run-tests
enabled: true
event: stop
action: warn
---

📋 结束前请确认:

- 是否已经跑过测试?
- 是否已经更新文档?
- commit message 是否符合规范?

高级玩法:prompt 类型的智能 Hook

普通的 Hook 是基于"正则匹配"的——pattern 命中就触发,简单粗暴。但 Claude Code 现在还支持一种更高级的形式:用一段自然语言提示词来做决策,叫 prompt 类型 Hook。

它的写法大致是这样:

---
name: smart-migration-check
enabled: true
event: PreToolUse
type: prompt
prompt: |
  当前 Claude 准备执行的操作是:$TOOL_INPUT

  请判断:这个操作是否会修改数据库迁移文件、是否会破坏现有的迁移历史。
  如果是,返回 block,并解释原因;如果不是,返回 approve。
timeout: 30
---

跟正则匹配相比,这种 Hook 的优势是支持复杂的语义判断。比如"是否会破坏数据库迁移历史"这种事情,你用正则根本写不出来,但用一段自然语言提示词就能让另一个轻量 Claude 实例帮你判断。

它的代价是每次触发会消耗一点点 token(因为要跑一次模型推理),所以不要把 prompt Hook 挂在 high-frequency 事件上。挂在"提交前"、"执行 destructive 命令前"这种低频但要慎重的事件上最合适。

一些用 hookify 时的小细节

我自己用下来踩到过几个坑,顺手记一下:

• 正则别写得太复杂——hookify 默认用 Python 的 re 模块匹配,过于复杂的正则会拖慢 Hook 的响应速度
• event: all 不要随便用——它会监听所有事件,Hook 数量一多性能会下降,指定具体的 event 类型(bash/file/stop/prompt)
• .claude/hookify.*.local.md 默认放在项目根目录,如果你想让规则跟着仓库走、被同事复用,就把 .local 去掉,变成 .claude/hookify.{name}.md,然后 commit 到 git
• 规则可以手动开关——/hookify:list 看全部规则,/hookify:configure 进入交互界面开关

安装命令

/plugin install hookify@claude-plugins-official

装好之后就可以用自然语言写规则了。

七、code-modernization:遗留代码迁移流水线

最后一个重量级插件是 code-modernization。这个插件主要面向企业开发场景——把 COBOL、老旧 Java/C++、单体 Web 应用这种"动一下就出血"的遗留系统,迁移到现代技术栈。

它针对的核心难题

遗留代码迁移项目失败率非常高,失败的原因往往不是"目标技术选错了",而是步骤被跳过。最常见的两种死法:

• 不理解就动手——还没看懂业务规则就开始重写,新系统跑起来发现一堆边界条件对不上
• 不审计就上线——没有一套能捕捉"行为漂移"的测试体系,新老系统跑出来结果不一致,但没人发现

code-modernization 的设计思路是把整个迁移过程强行拆成一条流水线,每一步必须有产出物,下一步基于上一步的产出物继续做。

六阶段流水线

flowchart LR
    A[1. assess<br/>评估] --> B[2. map<br/>依赖映射]
    B --> C[3. extract-rules<br/>抽取业务规则]
    C --> D[4. brief<br/>迁移方案]
    D --> E[5a. transform<br/>逐模块迁移]
    D --> F[5b. reimagine<br/>从规则重建]
    E --> G[6. harden<br/>安