多工具用户的两难

重度 AI 编程工具用户几乎都是「多栖动物」：主力 Claude Code 写复杂任务，Cursor 做快速迭代，Codex 跑并行批处理，偶尔还试试新出的工具。每个工具都有自己的配置体系——Claude 的 Skills 在 ~/.claude/skills/，Cursor 的 Rules 在项目 .cursor/ 下，各家格式还略有差异。

于是每次攒出一个好 Skill，都面临灵魂拷问：要不要为每个工具各移植一遍？ 移植意味着格式适配、路径适配、后续每次更新改 N 处。大多数人的现实选择是：只在主力工具里用，其他工具「以后再说」——于是好配置被锁死在单一工具里。

teamai-cli 解决的就是这个「移植税」：你只维护一份 Skills 包，它负责同步到 20+ 款工具的对应目录。 支持 Claude Code、Codex、Cursor、CodeBuddy IDE、WorkBuddy、Gemini CLI、Windsurf、Trae、Aider、Amp、OpenClaw 等。

实战：一个 Skill 的多工具旅程

用一个真实例子走一遍流程。假设你写了一个「代码审查 Skill」——让 AI 按团队规范做 review。

第一步，在任一工具里开发调试。 用 Claude Code 的 SKILL.md 规范写好技能，在自己常用的工具里调试到满意。这步和你平时攒 Skill 没有任何区别。

第二步，push 进团队仓库。 teamai push 提交，走审核合并。此刻它成为团队资产。

第三步，其他成员的 N 个工具自动获得。 团队里用 Cursor 的同事 pull 之后，这个 Skill 出现在 Cursor 的对应配置位置；用 Codex 的同事在 Codex 里同样可见。没有人写过一行移植代码。

第四步，更新时只改一处。 三个月后审查规则有变，你在源头更新 Skill、push、合并——所有成员的所有工具，在下次会话启动（SessionStart Hook 自动 pull，见日常使用篇）时全部更新。

这就是「一份维护，多处生效」的完整闭环。

格式差异谁来抹平

各工具的配置格式并不完全相同，teamai-cli 在中间做了适配层。对使用者来说只需记住一条原则：按目标内容组织，不按工具组织。 你的仓库结构应该是：

TeamAi-Backend/
  skills/
    code-review/       # 技能按「能力」组织
    api-design/
    sql-optimization/
  rules/
    code-style.md      # 规范按「领域」组织
    git-workflow.md
  docs/
    architecture.md
  mcp/
    servers.json       # MCP server 统一配置

而不是 claude-skills/、cursor-rules/ 这种按工具分的目录——后者会把「同一份知识的多工具副本」的问题原样带进仓库。工具映射这件事交给 teamai 的同步机制去做。

哪些内容适合进共享仓库，哪些不适合

多工具同步放大了配置的价值，也放大了放错东西的成本。一份实操分类：

适合进团队仓库：

  • 通用 Skills（代码审查、文档生成、测试策略）——所有工具都用得上
  • 团队规范（代码风格、Git 流程、架构约定）——统一是它们存在的意义
  • MCP Server 配置——团队共用内部服务的接入方式
  • 项目文档摘要——任何 AI 工具干活都需要背景

不适合进的：

  • 个人偏好配置（某个人的自定义提示词风格）——用 --scope user 的用户级模式放本地
  • 含敏感凭证的配置——仓库再私有也不是密钥管理器，凭证走专门方案
  • 只对单一工具有意义的深度定制——放该工具的原生配置里，避免污染共享层

与各工具原生机制的配合

teamai-cli 不替代各工具的原生配置机制，而是在其之上做统一分发。以 Claude Code 为例：团队 Skills 由 teamai 同步到 skills 目录，你个人的临时实验 Skill 仍然可以本地自建——两者共存，团队层和个人层各管各的。

这个分层和本站反复出现的「资产分层」思想一致：Grok Bot 额度分层讲算力分层，这里的配置管理讲共享层与个人层分离——共同点是让每一层只承载它该承载的东西。

FAQ：多工具同步的高频疑问

Q：支持哪些工具？我用的在列表里吗？ Claude Code、Codex、Cursor、CodeBuddy IDE、WorkBuddy、Gemini CLI、Windsurf、Trae、Aider、Amp、OpenClaw 等 20+ 款。判断自己是否被覆盖，装好后跑 teamai list 看分发结果最直接——它列出配置实际装进了本机哪些位置。

Q：同一个 Skill 在两个工具里表现不一致，是谁的问题？ 先排除同步没到位（teamai status 确认本地与远端一致），再检查该工具的个人层配置——团队层和个人层共存时，工具原生目录里残留的旧配置会影响行为。确认是团队层的问题就走 push 流程修源头，而不是在个人层打补丁。

Q：个人实验中的 Skill 会被误同步给全团队吗？ 不会。本地自建的实验配置与 teamai 分发的团队层各管各的，只有显式 teamai push 之后才进入团队仓库、走审核流程。实验成果成熟一个 push 一个。

Q：某工具用不上团队某个 Skill，能单独关掉吗？ 能。teamai skill exclude add <技能名> 把它加进个人排除清单，pull 时不再同步——个人偏好不污染团队共享配置，反悔也只是 remove 一条记录的事。

多工具场景避坑清单

  • 目录按能力组织，别按工具组织：skills/、rules/ 而不是 claude-skills/、cursor-rules/——按工具分目录会把「多副本」问题原样带进仓库，适配层的价值直接归零。
  • 敏感凭证永远不进仓库：MCP Server 配置需要凭证时，仓库只放结构不放密钥——仓库再私有也不是密钥管理器。
  • 单一工具的深度定制留在原生配置里：只对某个工具有意义的配置进共享层，等于给其他工具的用户分发一份无效文件，配置噪音从这里开始累积。
  • 迁移前先备份本地原目录：存量配置收口进仓库之前，各工具的原始目录先备份——迁移手滑的恢复成本，比一次备份大得多。
  • 排除清单要定期回看：skill exclude 加多了容易变成黑洞——被排除的技能后来更新成你需要的版本时，记得 remove 回来。

迁移现存配置的操作路径

已有多工具存量配置的团队，迁移按这个顺序最省力：

  1. 盘点：各成员列出自己 ~/.claude/skills/、各工具配置目录里的存量内容
  2. 去重合并：多人重复攒的同类 Skill，合并成最优版本——这本身就是一次有价值的团队讨论
  3. 入库：统一命名后 push 进团队仓库
  4. 切换：各成员 pull 接管，本地原目录备份后清理
  5. 收口：约定「新 Skills 一律走 teamai 分发」，旧路径不再生长

迁移是一次性成本，此后所有工具的配置维护收敛到仓库一处。多工具用户的「移植税」，从此不用再交。