V2EX 上有个帖子我印象很深。作者说他们团队十几号人混用 Claude Code、Cursor、Codex，老同事本地攒了一套 CLAUDE.md、自定义 skills、环境变量，新人入职，AI 基本是台空白出厂车。同一个坑，AI 会带着每个人再踩一遍。
即使把 rules/skills 丢进共享 Git 仓，合并后没人记得 pull。
这场景你熟不熟悉？不是个例。腾讯 2026 年 8 月开源了个工具，想解决这个问题。
它到底干了什么
一句话：Git 驱动的团队 AI 协作基础设施。
核心逻辑很简单：push → review & merge → pull。SessionStart 自动触发，一次配置多工具同步。
它管的东西包括：Skills、Rules、Docs、Hooks、MCP 配置。支持分发到 10+ AI 工具------Claude Code、Codex、Cursor、CodeBuddy、WorkBuddy、Gemini CLI、Windsurf 等等。
截至2026年8月，不支持 OpenCode 和 GitLab 自托管。
但真正有意思的是它的三层知识体系。
自动经验共享------捕捉"摩擦信号"：打断 AI、纠正 AI、拒绝工具调用、模型反复重试。高分触发自动总结踩坑经验。这个设计思路挺聪明，把"踩坑"变成"团队财产"。
团队知识召回------用 BM25 + 图谱增强排序（简单说就是按相关度排序，越贴近当前问题的经验越先被拿出来），默认关闭需显式启用。
代码知识图谱 ------teamai import 解析源码为结构化图谱。
智猩猩（专注 AI 硬科技的媒体）团队分享过一个实际场景：在 WorkBuddy 调好的 Skill，换 Codex 就得重配。teamai-cli 想解决的就是"工作习惯带不走"的问题。
一句话对比：传统知识库管"人看"，它管"AI 用"。
为什么不用 git submodule
读者自然会问：teamai-cli 本质是"把配置放 Git 仓"，那我自己用 git submodule 嵌进项目不就行了？
这个问题问得好，也是我一开始的疑问。先给 submodule 说句公道话：如果团队只用 Claude Code ，把共享仓库 submodule 进项目 .claude/skills/ 是能直接用的------Claude Code 原生扫描项目级 skills 目录，不需要复制。这条路的小坑只在"新人克隆时记得带 --recursive"。
但多数团队的场景是混用多种工具，问题就来了：
每个工具的"项目级配置目录"都不一样。Claude Code 认 .claude/skills，Cursor 认 .cursor/rules，Codex 认 .agents/skills。一个 submodule 只能挂在一个目录里，没法被三种工具同时原生读到。要同时喂给三个工具，你得各自建目录、各写配置，甚至手动转换格式。
MCP 和 Hooks 更麻烦------Claude Code、Cursor、Codex 三者的配置格式互不兼容，同一个文件没法直接复用。
teamai-cli 把这事自动化了：teamai pull 一步到位------把 skills 复制到各工具自己的目录，注入 hooks，写 MCP 配置，SessionStart 自动触发。
一句话：git submodule 负责把代码拿到本地，工具约定决定能不能读到；多工具场景，就需要分发层（teamai-cli/symlink）把资源投递到各工具的识别目录。
分发解决了，质量呢
这是我最想说的部分。
Git 能回答"谁改了什么"，不能回答"规则本身是否该被执行"。
有个用户提了 Issue harness------给 rules/skills 做效果评测。他的原话是："没有任何量化手段证明这些下发内容真的让 AI 编码更好。"
他提的提案是用消融实验（对照测试：去掉某部分，看效果差异）：注入 vs 不注入 rules/skills，公式 Δ = 通过率(注入) − 通过率(不注入)。
连用户自己都在质疑"下发的内容到底有没有用"。
更实际的问题是：自动共享的错误经验，全队一起错得更快。
一个同事踩了坑，写了条错误经验，teamai-cli 自动共享给全队。全队 AI 一起用错误经验。分发效率越高，错误传播越快。
对策不是不用，而是：关键规则需要独立复核，把分发和质量分开。MR 只是代码审查，不是质量验证。
快速上手
安装：npm install -g teamai-cli
两种模式：
- 团队仓库模式 ：
teamai init <仓库地址>（GitHub/TGit/CNB） - 单仓库模式 ：
teamai init .（业务仓库即团队仓库，知识部分进 main 的.teamai/）
推送与评审：teamai push → 自动开分支 + MR → 评审合并。
自动同步：各成员会话启动时 SessionStart hook 自动 teamai pull，无需手动。
可选增强：teamai recall enable 开启团队知识召回（默认关闭）。
查看状态：teamai status。
开源地址：https://github.com/Tencent/teamai-cli
适合谁用，不适合谁用
适合：
- 混用多种 AI 工具（Claude Code + Cursor + Codex）的团队
- 新人多、需要快速统一 AI 配置的团队
- 注重知识沉淀，希望把个人踩坑变成团队财产的团队
不适合：
- 单一工具小团队（配置管理成本大于收益）
- 需要 GitLab 自托管/Gitea 的团队(目前不支持)
- 需要支持 OpenCode 等小众工具的团队
- 想要图形界面的团队（目前只有 CLI）
实用建议：
- 先定义边界，再推送给全队。哪些 rules 是强制的，哪些是建议的，哪些是不能下发的。
- 关键规则需要独立复核机制。自动共享 ≠ 自动正确。
- 当"分发层"用，别当"知识库" 。目前没有权限管理、没有浏览体验、没有讨论区。
说到底，teamai-cli 解决了一个真实痛点：团队 AI 配置的分发。但它没解决另一个更难的痛点：分发出去的内容到底有没有用。
工具能把文件装到 AI 工具能读到的地方，但装进去什么内容，还是得人来把关。
你所在的团队有类似的 AI 配置不一致问题吗？评论区聊聊。
本文首发于公众号「保持清醒的坐标系」，更多 AI 编程与技术实践内容欢迎关注。