团队级配置与共享

一个人的 AI 习惯，团队要统一

个人用 Claude Code 时，你有自己的偏好；但团队协作时，每个人都按自己的偏好调教 AI，很快会乱：A 让 AI 用 Vue，B 让 AI 用 React；A 缩进 2 格，B 缩进 4 格。

团队级配置就是治这个的：把团队的「标准做法」固化成共享配置，让所有成员、所有项目都用同一套规则。

---

团队级配置是什么

把个人的偏好，升级成团队共享的标准，通常放在仓库里：

• CLAUDE.md：项目的技术栈、约定、流程（前文讲过）
• 技能 / 插件目录：团队共享的能力资产
• 权限 / 工具策略：统一的安全边界

这些一起构成「团队怎么用 AI」的基线。

对 mcp-hub 来说，团队级配置至少要包含：可用的服务清单、接入规则、安全基线、成本预算、负责人。这些都应该共享，而不是每个人心里各有一本账。

---

为什么必须统一

不统一	统一
每个人一个样，AI 行为不可预测	全团队一致，可预期
新人来了从头摸索	clone 下来就有标准
交接困难、维护混乱	标准统一，好交接好维护

统一，是为了「可预期」和「好交接」。

对 mcp-hub 尤其如此：如果每个人本地各接各的服务、各记各的凭据，团队协作就无从谈起——mcp-hub 统一，团队才能共享。

---

怎么落地团队级配置

1. 放进仓库

把共享配置放进 Git 仓库，随项目分发，全员 clone 即得。

my-project/
  CLAUDE.md          # 项目约定
  .claude/
    skills/          # 团队技能
    commands/        # 团队斜杠命令
  mcp-hub/
    registry.yml     # 团队共享的服务清单
    SECURITY.md      # 安全与接入基线

对 mcp-hub：把 registry.yml（服务清单）和接入规范一起放进仓库，成员 clone 即得一份可用的 mcp-hub。

2. 明确定义「标准」

团队先坐下来定：技术栈、命名、流程、安全边界。写进配置，别靠口头。

对 mcp-hub：明确定义「什么样的服务能接入、要登记哪些字段、凭据放哪」，写进规范，别靠各人发挥。

3. 变更走流程

改配置走 PR、有记录、可回溯，别某个人悄悄改了影响全组。

---

一个可复制的服务清单

给 mcp-hub 的服务清单定一个统一结构，团队内共用：

# mcp-hub 团队服务清单
servers:
  - name: orders
    command: mcp-server-mysql
    env:
      DB_HOST: $ENV_DB_HOST   # 引用环境变量，不写明文
    tools: [query_orders]
    access: read-only
    owner: "@backend"

统一结构后，成员加新服务照着填，规范自然统一，也方便脚本校验。

---

团队级 vs 个人级

配置有层级，别搞混：

• 个人级（~/.claude/）：你自己的偏好
• 项目/团队级（仓库里的）：团队的标准
• 团队级优先于个人级：进到项目，以团队配置为准

个人偏好让位于团队标准，这是团队协作的代价，也是价值。

对 mcp-hub：个人可以在本地加「自己临时要用的服务」，但凡是进团队共享清单的，必须符合团队规范。个人级是「你的」，团队级是「大家的」，别混淆。

---

一个落地清单

• [ ] CLAUDE.md 写了技术栈、规范、流程？
• [ ] 核心技能放进仓库、全员可用？
• [ ] 安全/权限策略统一了？
• [ ] 变更走 PR、有负责人？
• [ ] mcp-hub 服务清单和接入规范进仓库了？

---

落地练习：把 mcp-hub 变成团队共享资产

这一节，让 mcp-hub 从「你的」变成「大家的」。

跟着这三步走：

1. 把 mcp-hub 的服务清单（registry.yml）和接入规范放进团队共享仓库
2. 统一清单结构（参考上面的 yaml），把每个服务的字段、凭据引用、负责人写全
3. 模拟一个新人 clone 下来，按 README 装好 mcp-hub，验证能直接 mcp-hub list 看到同一套服务

你会怎么判断做对了？——一个没碰过 mcp-hub 的同事 clone 下来后，装好就能看到和你一致的团队服务清单，并且清单结构统一、规范明确，就算过关。

卡住了怎么办？ 没有团队仓库？先用你自己的空仓库模拟。清单字段不全？先填「name / command / access / owner」四样核心的，其余后面补。新人装不起来？回上一节检查打包发布有没有做对。

---

常见坑：团队配置「躺在仓库里」，却没人真正统一使用

一个很真实的坑：团队把配置放进仓库了，但成员还是各用各的——本地各有各的偏好，仓库那份「形同虚设」。配置进了仓库 ≠ 团队真的用了。

要让团队配置真正生效：一是团队级优先于个人级，进项目就以团队为准；二是把仓库那份设为唯一来源（single source of truth），任何变更走 PR。mcp-hub 也一样——如果成员还在本地各记各的服务，仓库里的 registry 就只是摆设。统一不是「放了文件」，而是「大家都用它」。

---

小结

1. 团队级配置 = 把团队标准固化成共享配置，放进仓库
2. 目的：可预期、好交接、好维护
3. 落地：进仓库 + 明确定义 + 变更走流程
4. 团队级优先于个人级
5. mcp-hub 的团队化 = 服务清单与规范进仓库 + 全员真用它

下一节，讲 AI 协作下的代码评审规范。