腾讯开源 TeamAI：一人配置全员复用，用 Git 管理团队 AI 资产

不知道你有没有遇到过这种情况。

同事小张调好了一个 Cursor 的规则文件，写出来的代码质量肉眼可见地提升。你想找他 copy 一份，结果发现他的规则依赖好几个自定义 Skill，还有两三个 MCP 服务的配置，文件散落在项目的各个角落。折腾半天，最终还是自己从头写了一份。

更麻烦的是，这些配置的”保鲜期”很短。模型升级了，规则要调整；踩了个新坑，Prompt 要修改。每个成员都在自己维护一套，互不同步。有人调通了，其他人不知道；有人踩坑了，其他人接着踩。

这是几乎所有开始用 AI 编程的团队都会遇到的问题——工具是个人的，但团队需要的却是统一的。

腾讯云最近开源了一个内部自用的工具 TeamAI，专门解决这个问题。上线 GitHub 不久，Star 已经 5.6k。它做的事情可以一句话概括：像管理代码一样，管理团队的 AI 资产。

TeamAI 是什么

TeamAI 的口号是”Make Every Team AI Native”，让每个团队都成为 AI 原生团队。

它本质上是一个基于 Git 的团队 AI 协作工具：把团队使用的 Skill、工作规范、工具配置、项目知识，统一放进一个 Git 仓库，像管理代码一样做版本管理和评审，然后同步到每个成员各自使用的 AI 工具里。管理员配置一次，全团队自动生效。

兼容面是它比较有意思的地方。TeamAI 目前适配了 19 种 Agent，包括 Claude Code、Codex、Cursor、CodeBuddy、GitHub Copilot CLI、Kiro、Trae 这些主流工具。团队里有人用 Cursor、有人用 Claude Code、还有人用国产的 CodeBuddy，都不影响——大家共享同一套团队资产，各用各的工具。

真实团队很少只用一种工具，强行统一工具的阻力往往比解决问题本身还大。TeamAI 的思路是不动工具，只管资产。

核心设计：一个 Git 仓库装下团队的 AI 资产

先看它到底管什么。TeamAI 把团队的 AI 资产分成几类，全部装进一个 Git 仓库：

Skills 是团队的技能库，比如”提交代码前自动跑 lint 并修复格式”这类可复用的能力；Rules 是工作规范，约束 Agent 怎么写代码、怎么写提交信息；MCP 是工具接入的配置；Models 是模型服务的配置；Learnings 是团队沉淀下来的经验。

这套东西怎么协作？用的还是开发者最熟悉的 Git 流程。

某个成员觉得某个 Skill 写得不错，想分享给团队，TeamAI 会自动创建分支、发起合并请求，交给团队评审。其他人 review 之后合入主干，支持会话启动 Hook 的 Agent 会在新对话开始时自动拉取更新。整个过程不需要在群里喊一嗓子”配置更新了，大家手动替换一下”。

TeamAI 没有发明新的协作方式，它只是把代码协作里沉淀了几十年的 Git 流程，搬到了 AI 资产上。对开发团队来说，学习成本几乎为零——分支、合并请求、评审，闭着眼睛都会。

架构上，TeamAI 分三层。第一层是 Team Execution，让每个 Agent 按团队的方式工作，涵盖 skills、rules、hooks、MCP、models 这些基础资产；第二层是 Team Context（目前 beta），让 Agent 理解团队，包括 learnings、代码库图谱和团队 wiki；第三层是 Team Improvement（也是 beta），让每次执行都能反哺团队，追踪使用情况和会话记录。

三层连起来是一个闭环：规范执行 → 沉淀上下文 → 持续改进。目前稳定可用的是第一层，后两层还在打磨，尝鲜的话要有心理准备。

两个值得说的功能

模型配置统一下发

这个功能瞄准的是安全，也是管理者最容易忽视的问题。

团队里有人用官方 API，有人用各种来路不明的中转站，把内部代码片段发给了哪个模型、存到哪里，没人说得清。对涉及内部数据和知识的任务，这是实打实的风险。

TeamAI 的做法是让管理员统一配置符合团队安全要求的模型服务，统一下发。成员本地不用管模型接入，自然也不存在”选错模型”或”接错渠道”的问题。管理员在管控台改一次，全团队生效。

经验自动沉淀

这个功能瞄准的是更隐蔽的损失：经验的流失。

用 AI 编程的日常是这样的：今天遇到一个构建报错，折腾了半小时 Prompt 终于解决了；明天另一个同事遇到同样的问题，又折腾半小时。解法躺在聊天记录里，随着会话结束就消失了。

TeamAI 的做法是，当它检测到你在反复纠正 Agent、或者工具调用反复失败，会话结束时会提示你分享这次经验。Agent 把问题和解决方法整理成文档，存入团队仓库。下次团队里任何人处理类似任务时，Agent 可以自动检索这些已有经验作为参考。

踩一次坑，全团队以后都不用再踩。这件事在团队协作层面的价值，可能比任何单个 Prompt 的优化都大。

上手实测

TeamAI 的安装分两条路。

标准方式是 npm 全局安装：

npm install -g teamai-cli

然后管理员初始化团队仓库：

teamai init https://github.com/your-org/your-repo

团队成员加入时执行同样的 init 命令即可，默认把资源装到当前工作区目录；如果想在所有项目里都能用，加 --scope user 装到用户目录下。

更省事的方式是走 AI 工具安装。打开你正在用的 Agent，发一句”帮我安装 teamai skill”，之后就可以通过 /teamai 命令用自然语言交互。比如从零搭建：

/teamai Help me set up TeamAI for my team from scratch

或者分享一个 Skill 给团队：

/teamai Share my xxx skill with the team

装完之后日常基本不需要记命令，要做什么直接用自然语言说就行，Agent 会调用对应的 Skill 完成。对不熟悉 CLI 的成员，这个门槛足够低。

另外几点也顺带提一下。它支持 GitHub、GitLab、GitCode、CNB、TGit 以及私有 Git 服务，不绑定某一家平台；协议是 MIT，不绑定腾讯云，自托管完全没问题；官方还维护了一个 TeamAI Hub，提供生产级的 skills、rules 和 review agents 模板，新团队可以直接从模板起步，不用从零造轮子。

ClawPro 集成：团队规模再大一点时

如果团队更大、管理要求更高，TeamAI 也接入了腾讯云的智能体管理平台 ClawPro。

成员把自己本地的 Agent 接入 ClawPro 之后，管理员可以在管控台统一管理 Skill、MCP 等配置，再分发到所有已接入的 Agent。相当于在 Git 仓库之上又加了一层集中管控，适合对合规和审计有要求的组织。

这一步不是必需的。小团队用纯开源方案加自有 Git 仓库，已经能覆盖主要场景。

和现有方式比一比

把 TeamAI 放到现有做法旁边看，差异会更清楚。

目前大多数团队共享 AI 配置的方式，无非是把 .cursorrules 或者 CLAUDE.md 提交到项目仓库。这个方案能用，但有几个短板：配置跟着项目走，跨项目不通用；没有评审流程，谁都能直接改；只覆盖规则文件，管不到 Skill、MCP 和经验沉淀；模型配置更是完全管不着。

TeamAI 把这些补齐了：资产范围更全（Skill/规则/MCP/模型/经验），有完整的 Git 评审流程，跨项目同步，还能统一管控模型。代价是多了一层工具链的维护成本——团队需要有人扮演管理员的角色，仓库本身也需要像代码仓库一样持续维护。

它更适合已经认真使用 AI 编程工具、成员在 5 人以上的团队。个人开发者或者两三人的松散小团队，直接提交配置文件到仓库，可能还是更轻量的选择。

谁该试一试

回到开头的问题。团队用 AI 编程，真正的瓶颈往往不是工具不够强，而是每个人的 AI 都是一座孤岛：配置孤岛、经验孤岛、知识孤岛。

TeamAI 用开发者最熟悉的 Git 流程，把这些孤岛连成了一片。一人配置，全员复用；踩坑一次，全团免疫。再加上 MIT 开源、19 种 Agent 适配、不绑定任何云厂商，对想认真做团队 AI 协作的团队，值得一试。

项目地址：https://github.com/Tencent/teamai-cli/

如果你所在的团队已经在用，欢迎在评论区聊聊实际体验。