不是不会用 Claude Code，是团队的 AI 开发环境没对齐

团队里如果有 10 个人都在用 Claude Code，真正难的，通常不是谁更会写提示词，而是这 10 个人手里的 Claude，到底是不是同一种工作方式。

很多团队刚把 AI 编程引进来时，第一反应都是兴奋。

能生成代码了，能查文件了，能顺着上下文继续写了，看起来好像开发效率一下子就上来了。可真用上一两周，问题就开始往外冒。

• 有人的 Claude 知道项目还停在 JDK 8，写代码很克制。
• 有人的 Claude 不知道，顺手就把 var、List.of() 塞进来了。
• 有人已经接了内部 MCP，查表结构、跑 SQL、看监控一条龙。
• 也有人还在聊天窗口里来回复制上下文，效率跟手工时代差不多。
• 新人入职时更麻烦，没人说得清到底要装什么、配什么、遵循什么流程，最后每个人本地都长成了自己的样子。

这时候你会慢慢反应过来，团队遇到的问题，不是会不会用 Claude，而是 AI 开发环境根本没对齐。

以前没有 Docker 的时候，开发机环境一人一套，能跑起来全靠缘分。今天把 Claude Code 引进团队，如果还是靠每个人手工去装 Skill、配 MCP、补上下文、记流程，那本质上只是把过去的坑，从 JDK、Maven、hosts，换成了另一批新名字而已。

Claude Plugin 真正解决的，就是这件事。

问题不在会不会用，在每个人手里的 Claude 都不一样

个人开发者用 Claude Code，最多是习惯不同。但一进团队协作，问题立刻就变了。

你会发现，表面上大家都在用同一个工具，实际上每个人拿到的却是不同版本的“团队知识”和“工具能力”。

很多团队会把这个问题误判成“提示词水平不够”，于是开始写长文档、做培训、整理提问范式。这些当然不是没用，但它解决不了根。

文档是静态的，人的执行是漂移的。真正能让团队稳定下来的，从来不是“大家注意一下”，而是把规范变成默认会生效的东西。

这一点，做过几年工程的人都很有体感。代码规范靠喊，是喊不住的；接口约定靠口头，也守不久。最后真正有用的，都是那些已经进了基础设施、会自动运行的部分。

AI 协作也一样。

Claude Plugin 解决的，不是装几个插件，而是分发一套开发环境

如果把 Claude Plugin 理解成浏览器插件，其实有点把它看轻了。

它更像一个团队级的分发容器。你往里放的，不只是几个零散工具，而是一整套 AI 开发环境：默认上下文、可调用工具、标准工作流、自动化约束，最后都能跟着一起发出去。

这里需要先分清两个概念：Plugin 和 Marketplace。

Plugin 是能力的载体，一个 Plugin 里最核心的通常是下面四样东西：

而 Marketplace 是这些 Plugin 的分发目录。它的作用更像 npm registry 或者 apt 源——不是定义插件本身，而是告诉 Claude Code：”这个团队有哪些插件可用，去哪里拿它们。”

先看一个最小化的 Marketplace 配置。这个 marketplace.json 放在仓库的 .claude-plugin/ 目录下：

{
  “name”: “team-dev-tools”,
  “owner”: {
    “name”: “TeamLead”,
    “email”: “lead@company.com”
  },
  “plugins”: [
    {
      “name”: “core”,
      “description”: “团队核心开发插件”,
      “version”: “1.0.0”,
      “source”: “./plugins/core”,
      “commands”: [
        “./plugins/core/commands/project-init”,
        “./plugins/core/commands/sdd-workflow”
      ],
      “hooks”: {
        “Stop”: [
          {
            “hooks”: [
              {
                “type”: “command”,
                “command”: “node ${CLAUDE_PLUGIN_ROOT}/hooks/log-audit.mjs”
              }
            ]
          }
        ]
      },
      “strict”: false
    }
  ]
}

注意几点关键设计：

• source 指向插件文件的实际位置，可以是相对路径、GitHub 仓库、npm 包等多种来源
• commands 是官方字段名（不是 skills），对应的就是团队沉淀的工作流命令
• strict: false 表示由 marketplace 条目来完整定义插件内容，插件自身不需要单独的 plugin.json
• ${CLAUDE_PLUGIN_ROOT} 是安装后的插件目录引用，因为插件安装时会被复制到本地缓存

这段配置真正传出去的，不只是一个 JSON，而是一套默认行为：

• 项目初始化该怎么做。
• 复杂需求是不是要先走 Spec。
• 会话结束后有没有审计留痕。

团队成员拿到的是 Claude 的能力边界、默认上下文和执行流程，都被一起对齐了。一个人自己装好，这只是个人效率工具。十个人都装好，它才开始像团队基础设施。

先别急着谈能力，先把 Plugin 里的四样东西分清

很多人第一次看 Plugin，会把注意力放在“能挂多少东西进去”。但真正有价值的，不是数量，而是你把什么经验沉淀进去了。

Commands：把团队经验变成能复用的工作流

在 Claude Plugin 的体系里，团队沉淀的工作流叫 Command（命令）。你可能在其他地方见过 “Skill” 这个叫法——本质上它们是同一件事：把团队已经验证过的方法，封成一个能被稳定触发的动作。在 marketplace 配置里，官方字段名统一是 commands。

一个典型目录大概会长这样：

commands/
├── project-init/
│   ├── command.md
│   ├── scripts/
│   │   ├── check-structure.js
│   │   └── analyze-project-smart.js
│   └── references/
│       ├── claude-md-rules.md
│       └── spec-templates/
├── sdd-workflow/
│   └── command.md
├── backend-framework-guide/
│   └── command.md
└── code-generation-tools/
    ├── command.md
    └── assets/
        └── code-generator.jar

它的价值，主要在三点。

第一，触发条件是声明式的，不再靠人记。比如什么情况下必须先做需求拆解，什么情况下要先读项目规范，直接写进命令的描述里。

---
name: sdd-workflow
description: |
  当用户需要以下操作时，务必使用此命令：
  - “实现 xxx 功能” / “开发 xxx” / “新增 xxx”
  - “修复 xxx bug”（涉及多模块的复杂 bug）
  - 用户提出任何涉及代码修改的开发需求时
---

第二，流程是标准化的。同样是做一个复杂需求，有的同事喜欢先写，有的同事喜欢先拆。Command 的价值，就是把”先拆问题、再建 Spec、再实现、再验证”这种已经被证明更稳的路径固化下来。

第三，知识可以按需加载。常用规则留在命令主文件里，长文档和模板放到 references/，真正需要时再读，不把上下文窗口白白烧掉。

这里最容易被低估的一点是，Command 不是为了让 Claude 显得更聪明，而是为了让它在团队里更稳定。对团队来说，稳定往往比偶尔惊艳更重要。

MCP Servers：把企业内部工具真正接进来

Claude 如果只能聊天，在团队场景里其实还差半截。

MCP 的价值，在于让 Claude 不再只是围着你贴上去的上下文打转，而是能直接去系统里拿一手信息。

在 Plugin 中配置 MCP Server，使用的是 command + args 格式：

"mcpServers": {
  "toolbox": {
    "command": "npx",
    "args": ["-y", "@anthropic-ai/toolbox-mcp@latest"]
  }
}

如果你的团队有自研的 MCP Server，也可以直接指向本地脚本：

"mcpServers": {
  "internal-tools": {
    "command": "node",
    "args": ["${CLAUDE_PLUGIN_ROOT}/servers/toolbox-server.mjs"]
  }
}

注意这里用了 ${CLAUDE_PLUGIN_ROOT} 变量——因为 Plugin 安装后会被复制到本地缓存目录，硬编码路径会失效。

接上之后，很多动作就闭环了。

比如一个老系统的慢查询问题。以前的动作链通常是这样的：先找开发要 SQL，再问 DBA 表结构，再去监控平台翻指标，最后几个人在群里对着截图猜。接上 MCP 之后，Claude 至少能把“查结构、看数据、核指标”这部分先走完。

效率提升是一方面，更关键的是，全团队面对的是同一套数据源、同一套工具入口。这种一致性，比单点提效更值钱。

Hooks：把本来靠自觉的动作，变成自动发生

凡是团队协作里靠“记得做”的事情，最后都不太稳。

Hook 的意义，就是把这些动作从口头约定，变成自动触发。它有点像给 AI 工作流补了一层很轻的工程约束。

"hooks": {
  "Stop": [
    {
      "hooks": [
        {
          "type": "command",
          "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/langfuse/langfuse_hook.mjs"
        }
      ]
    }
  ]
}

上面这个例子，是在会话结束时自动记录审计日志。放到企业环境里，这种动作就很有现实意义，因为很多团队真正开始把 AI 编程用进日常后，都会碰到一个迟早绕不过去的问题：出了事，怎么追溯 AI 到底做过什么。

除了审计，Hook 还适合做这些事：

Hook 的价值不在“自动化很酷”，而在于它能减少团队流程对个人习惯的依赖。团队一旦上规模，这件事会越来越重要。

CLAUDE.md：给 Claude 一个稳定的项目大脑（项目级配置，不属于 Plugin）

严格来说，CLAUDE.md 不是 Plugin 的组件，而是项目级配置。它放在项目根目录，Claude Code 启动时自动读取。但 Plugin 和 CLAUDE.md 经常配合使用——Plugin 分发工具和流程，CLAUDE.md 定义项目约束，两者加在一起才是完整的团队 AI 环境。

很多团队已经知道要给 Claude 喂上下文，但经常还是靠每次开场手工补一遍。短期能用，长期很累，而且非常容易漏。

如果把项目约束放进 CLAUDE.md，Claude 启动时就能自动读到：

## Context
- 技术栈：Spring MVC 4.3.7 + MyBatis + JDK 1.8（不是 Spring Boot）
- 构建：mvn compile -DskipTests

## Rules
- 不能用 var、List.of()（JDK 8 不支持）
- 代码变更必须关联 @spec 标注

这种文件看起来朴素，但它解决的恰恰是老系统里最容易踩的坑。

真正让项目频繁翻车的，往往不是那些大家都知道的大原则，而是那些没人会再特意重复、但一旦漏掉就会出问题的前置约束。比如不是 Spring Boot，比如 JDK 还停在 1.8，比如构建命令和默认套路不一样。

做老项目做久了，对这种细节会有一种近乎本能的敏感。因为你知道，很多返工不是因为代码不会写，而是因为前提一开始就错了。

放进真实团队再看，为什么最后都得进私有仓库

如果只是自己玩，一个本地目录加一个 marketplace.json 基本就够了。

但团队只要认真用，迟早会走到私有仓库这一步。原因很简单，因为团队要的从来不只是”能安装”，还包括”能治理”。

通常会有三类需求一起冒出来：

• 同一套 Command 要跨多个项目复用。
• 插件能力要有版本，能灰度，也能回滚。
• 里面会带内部地址、Hook 脚本、工具配置，不适合公开。

这时候，最自然的做法，就是把整套 Marketplace 放进企业 Git 仓库：

企业 GitLab: gitlab.company.com/team/claude-plugins.git

claude-plugins/
├── .claude-plugin/marketplace.json    ← Marketplace 目录文件
├── plugins/
│   └── core/                          ← 核心 Plugin 目录
│       ├── commands/
│       │   ├── project-init/
│       │   │   └── command.md
│       │   ├── sdd-workflow/
│       │   │   └── command.md
│       │   └── backend-framework-guide/
│       │       └── command.md
│       └── hooks/
│           └── langfuse/
│               └── langfuse_hook.mjs

团队成员安装的方式，不是手动 git clone，而是通过 Claude Code 内置的命令：

方式一：手动添加 Marketplace

# 在 Claude Code 里执行，添加 Marketplace
/plugin marketplace add https://gitlab.company.com/team/claude-plugins.git

# 然后安装需要的 Plugin
/plugin install core@team-dev-tools

方式二（推荐）：项目自动发现，团队成员无感安装

这是官方提供的团队级分发机制。在项目的 .claude/settings.json 中配置 extraKnownMarketplaces，团队成员信任项目时，Claude Code 会自动提示安装对应的 Marketplace：

{
  “extraKnownMarketplaces”: {
    “team-dev-tools”: {
      “source”: {
        “source”: “url”,
        “url”: “https://gitlab.company.com/team/claude-plugins.git”
      }
    }
  }
}

甚至可以指定默认启用哪些 Plugin：

{
  “enabledPlugins”: {
    “core@team-dev-tools”: true
  }
}

为什么这个很重要？因为从这一刻开始，新人 clone 项目、信任目录后，Claude Code 会自动引导他装好团队标准的 AI 开发环境。不需要再发文档、不需要口头通知、不需要运维介入。

这和发布应用、维护基础组件，其实已经是同一种思路了。

一个更稳妥的版本管理方式，大概会是这样：

main        -> 稳定版，团队默认使用
  |- v1.0.0 -> 第一个正式版本
  |- v1.0.1 -> 热修复
  \- dev    -> 维护者开发分支
      \- feat/new-command

Marketplace 还支持发布渠道的概念——通过指向同一仓库的不同分支，可以给不同团队分配稳定版和尝鲜版：

// 稳定版 Marketplace：指向 stable 分支
{
  “name”: “stable-tools”,
  “plugins”: [{
    “name”: “code-formatter”,
    “source”: { “source”: “url”, “url”: “https://gitlab.company.com/team/plugins.git”, “ref”: “stable” }
  }]
}

// 尝鲜版 Marketplace：指向 latest 分支
{
  “name”: “latest-tools”,
  “plugins”: [{
    “name”: “code-formatter”,
    “source”: { “source”: “url”, “url”: “https://gitlab.company.com/team/plugins.git”, “ref”: “latest” }
  }]
}

它的好处也很实际。

• 新 Command 有问题，可以直接回滚到上一个 tag。
• 新 MCP 先在一个项目灰度，稳了再推广。
• 谁能改这套团队能力，可以通过仓库权限管起来。

如果团队有更严格的合规要求，管理员还可以在托管设置中用 strictKnownMarketplaces 限制只允许安装指定来源的 Marketplace，防止团队成员随意添加未审核的外部插件源。

团队真把 AI 用进日常之后，最后比拼的通常不是谁提示词写得更花，而是谁能把这套环境维护得像正式基础设施一样稳。

如果你现在要搭一套团队 Plugin，先从最小闭环开始

讲原理很容易飘，落到手上其实没那么复杂。一个最小可用版本，先把下面几步走通就够了。

第一步，先把插件仓库建起来

mkdir team-claude-plugins && cd team-claude-plugins
git init
mkdir -p .claude-plugin

这一步没什么花样，关键是从第一天起，就把它当成团队资产，而不是某个同事电脑里的私人配置。

第二步，把 marketplace.json 立住

{
  "name": "team-name",
  "owner": {
    "name": "Your Name",
    "email": "you@company.com"
  },
  "plugins": [
    {
      "name": "core",
      "description": "团队核心开发插件",
      "version": "1.0.0",
      "source": "./plugins/core",
      "strict": false,
      "commands": [
        "./plugins/core/commands/project-init",
        "./plugins/core/commands/sdd-workflow"
      ],
      "hooks": {
        "Stop": [
          {
            "hooks": [
              {
                "type": "command",
                "command": "node ${CLAUDE_PLUGIN_ROOT}/hooks/log-audit.mjs"
              }
            ]
          }
        ]
      }
    }
  ]
}

第一次做，别一上来就想把所有能力塞满。先把最关键的两三个命令挂进去，比如项目初始化、复杂需求工作流，就已经足够产生明显效果了。MCP 和 Hook 可以后面逐步加。

第三步，先做一个最值得复用的 Command

很多人容易一开始就铺太大，一口气做七八个 Command，最后每个都半成品。更稳的做法是，先抓住团队里最常见、最值得标准化的那个动作。

比如新人入职引导：

mkdir -p plugins/core/commands/hello-team

创建 plugins/core/commands/hello-team/command.md：

---
name: hello-team
description: |
  团队入门命令，新成员入职时使用。
  当用户说”我第一天””帮我了解项目”时触发。
---

# Hello Team

## 执行步骤

1. 读取项目根目录的 CLAUDE.md，了解技术栈
2. 列出关键模块结构
3. 指向团队参考文档和开发规范
4. 给新人一条 30 分钟上手路径

为什么建议先做这种 Command？因为它的收益最实在。以前靠老同事带半天，现在至少可以先把 70% 的标准信息稳定交给 Claude。对新人轻松，对带教的人也轻松。

第四步，推到企业仓库，打出第一个版本

git add .
git commit -m "feat: init team plugin v1.0.0"
git remote add origin gitlab.company.com/team/claude-plugins.git
git push -u origin main
git tag v1.0.0
git push origin v1.0.0

这一步的意义，不只是备份代码，而是让团队开始按“发版”的方式维护 AI 能力。

第五步，让团队成员用同一套方式安装

团队成员有两种方式获取这套 Marketplace：

方式一：手动添加

在 Claude Code 里直接执行：

/plugin marketplace add https://gitlab.company.com/team/claude-plugins.git
/plugin install core@team-name

方式二（推荐）：项目自动发现

把 Marketplace 信息写进项目的 .claude/settings.json，团队成员信任项目后自动提示安装：

{
  “extraKnownMarketplaces”: {
    “team-name”: {
      “source”: {
        “source”: “url”,
        “url”: “https://gitlab.company.com/team/claude-plugins.git”
      }
    }
  },
  “enabledPlugins”: {
    “core@team-name”: true
  }
}

做完这一步之后，后面不管是新增 Command、更新 Hook，还是调整 MCP，维护者只需要推送仓库更新，团队成员执行 /plugin marketplace update 就能同步。不再需要一轮轮口头通知：”你这里再手工配一下。”

这就是为什么它表面上像插件，实际更像基础设施。

团队再大一点，就别让所有人都装同一包

团队继续往前走，很快又会碰到另一个问题：不是每个角色都需要同样的 AI 能力。

后端开发、测试、项目经理，关心的东西本来就不一样。你把所有 Command、所有工具全塞进一个 Plugin 里，最后只会越来越重，也越来越乱。

更合理的做法，是按角色拆分。一个 Marketplace 里可以包含多个 Plugin，每个 Plugin 面向不同角色：

{
  "name": "team-name",
  "plugins": [
    {
      "name": "developer",
      "description": "开发人员插件",
      "source": "./plugins/developer",
      "strict": false,
      "commands": [
        "./plugins/developer/commands/project-init",
        "./plugins/developer/commands/sdd-workflow",
        "./plugins/developer/commands/code-generation-tools",
        "./plugins/developer/commands/backend-framework-guide"
      ]
    },
    {
      "name": "tester",
      "description": "测试人员插件",
      "source": "./plugins/tester",
      "strict": false,
      "commands": [
        "./plugins/tester/commands/verify-python-env"
      ]
    },
    {
      "name": "pm",
      "description": "项目经理插件",
      "source": "./plugins/pm",
      "strict": false,
      "commands": [
        "./plugins/pm/commands/jarvis"
      ]
    }
  ]
}

安装时，每个人只装自己角色的 Plugin：

# 开发人员
/plugin install developer@team-name

# 测试人员
/plugin install tester@team-name

# 项目经理
/plugin install pm@team-name

这样分的好处很直接。

• 开发拿到的是编码、架构和工具链能力。
• 测试拿到的是环境校验和自动化测试能力。
• PM 用的是协作和流程管理相关的能力。

每个人只装自己真正需要的那部分，Plugin 才不会慢慢变成一个失控的大杂烩。

说到底，Plugin 只是把规范变成会执行的东西

回头看开头那些问题，其实都能落回到 Plugin 体系里。

如果非要把这件事压成一句话，我更愿意这样说：Claude Plugin 的价值，不是让团队多几个工具，而是让 AI 开发环境第一次变成可安装、可升级、可治理的团队基础设施。

这背后的思路，其实和 Docker 统一运行环境、ESLint 统一代码风格没什么本质区别。都是把原来写在文档里的规范，变成真正会生效的东西。

技术团队做久了，慢慢都会明白一件事。光靠“大家注意一下”，事情是跑不稳的。真正能长期运转的，最后都不是口头共识，而是基础设施里的默认行为。

AI 编程走到团队阶段，也一样。

它最后拼的，还是工程能力，还是治理能力，还是那些看起来不那么热闹、但决定事情能不能落地的手艺和分寸感。

本文基于 Venus Agent Skills 项目的实践经验整理，Plugin Marketplace 配置参考了 Claude Code 官方文档。文中涉及的 marketplace.json 结构、Command 机制、Hook 配置均来自真实项目。