小红帽的灰灰狼1. 从“每人一套私房配置”到“团队共享池”：我们为什么折腾这件事
1.1 开发团队里Claude Code“各自为战”的三个典型症状
我们Evol团队最开始用Claude Code，完全是个人行为。有人从命令行起家，有人从VS Code插件入坑，还有人一开始在Codex和Claude Code之间反复横跳，最后才定下来用它。工具本身没问题，真正的问题出在“每个人都在用自己的方式使用它”。
第一个症状是提示词风格不统一。同一个需求，A同事喜欢让Claude先输出方案再动手，B同事直接粘贴代码块要求无脑改，C同事把一堆上下文塞进去让Claude自行判断。结果就是：同一个任务，三个人让Claude干出来的东西风格天差地别，代码格式、注释习惯、命名方式全靠当天心情。代码审查的时候，看谁的产出都得重新适应一套隐含约定。
第二个症状是环境配置重复造轮子。新同事入职，光是装好Claude Code、配好API密钥、接上公司内部的MCP服务、写好CLAUDE.md规则，就得折腾大半天。老同事换新电脑，那些藏在 ~/.claude/ 里的配置、自建的skills、积累的commands，没有一份能找回来。每个人都像在孤岛上盖房子，盖完就失忆。
第三个症状最隐蔽，但代价最高：成员经验无法沉淀。有人踩过MCP服务端口冲突的坑，研究出了一种稳定的连接方式，但这套解法只存在他的本地文件里；有人写了一个特别好用的代码审查skill，也只自己默默用。团队层面完全没有机制把这些“个人智慧”变成“集体资产”。
1.2 共享池的目标拆解：不做管控，做“开箱即用的好默认值”
在动手之前，我们内部先对齐了一个关键认知：共享池不是为了管控谁，而是为了把默认值做好。
我当时给团队画的边界是这样的：
- 统一行为基线：通过CLAUDE.md，把团队约定好的代码风格、提交流程、安全红线写清楚，让Claude不管接谁的指令，底线动作是一致的。
- 复用工具资产：把大家验证过好用的MCP服务器、skills、自定义commands收进公共池，一个人踩坑踩出来的经验，全组直接受益。
- 收敛权限与密钥：账号、API Key、内部服务地址不再散落在个人笔记和各处配置里，统一走环境变量注入，从源头避免“密钥随手提交进Git”的事故。
- 降低新人上手门槛：新同学加入后，跑一条初始化命令就能拥有一套和团队完全一致的Claude Code工作环境，这也是我觉得收益最快见效的部分。
当然，我们也明确了“不做什么”——不搞一刀切。谁有特殊的本地模型需求、谁需要调试某个私有MCP、谁想保留自己的个人提示词，这些都可以存在个人配置里，共享池只负责提供“合理的默认值”。这个边界定下来之后，后面四周的推进阻力小了很多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 共享池的地基：Claude Code配置分层和我们选择的仓库结构
2.1 三级配置体系：全局、项目、团队各管什么
动手建池之前，得先搞懂Claude Code的配置加载逻辑。它大体上分三层：
- 全局用户级：存在
~/.claude/（Windows上是%USERPROFILE%\.claude\），对你机器上的所有项目生效，包括用户级CLAUDE.md、全局skills、全局MCP配置、权限设置。 - 项目级：存在项目仓库内的
.claude/目录里，跟随代码仓库走，适合放只属于该项目的规则、专用的MCP配置。 - 外部指令文件：项目根目录或子目录里的
CLAUDE.md，Claude启动时会自动读取，用来传递项目背景、技术栈约定等上下文。
我们要做的“团队共享池”，本质上就是把“全局用户级”里的公共部分抽出来，放到一个单独的Git仓库里统一维护，再通过脚本分发到每个成员机器的 ~/.claude/ 下。项目级的 .claude/ 交由各项目组自行管理，但我们会提供一份模板作为起步参照。
这么设计的原因很直接：大部分团队的共性诉求——代码规范、通用的MCP连接、基础的开发skills——都是跨项目的，放在全局用户级最合适，一次分发全员生效。
2.2 共享仓库的目录结构与初始化脚本
我们最终落地的共享池仓库目录长这样：
code复制claude-code-team-config/
├── README.md
├── init.sh # macOS / Linux 初始化脚本
├── init.ps1 # Windows PowerShell 初始化脚本
├── claude/
│ ├── settings.json # 全局设置：权限模式、hooks、MCP公共配置
│ ├── CLAUDE.md # 团