腾讯开源teamai-cli：用Git把AI使用经验变成团队共享资产

很多团队都面临一个尴尬现状：订阅了企业级AI服务，配备了充足的账号，但真正产生价值的往往只有那么一两个「AI专家」。其他人要么用不起来，要么重复踩坑。问题并不在于模型能力不够，而在于团队中那些宝贵的AI使用经验——什么场景该调用什么Skill、哪些规则需要补充、哪些MCP工具适合接入业务——这些经验往往只存在于个人的本地配置里，下一位同事接手时又要从头摸索一遍。腾讯近期开源的teamai-cli，正是为了解决这个团队AI落地的断层问题。

传统的企业知识分享方式在AI时代显得力不从心。发到群里的经验容易被刷走，放进知识库需要主动查询才生效，组织一次全员分享也无法保证每个人的Agent都能照着执行。更关键的是：人知道了，不等于Agent下次能用上。当后端同事花了一下午终于让AI理解「数据库变更必须经过迁移脚本」这条规则后，另一位接手类似需求的同事，第二天大概率还要再纠正一遍。团队需要的不是更多的文档或培训，而是一条能把个人经验转化为团队资源、再注入到每个Agent工作环境的完整链路。

Git原生：最小认知成本的协作范式

teamai-cli的核心设计是把AI使用经验放进一个共享的Git仓库，用「push提交→审核合并→pull同步」的流程分发到每位成员的Agent。对于研发团队而言，这套协作逻辑几乎没有学习门槛——代码怎么协作，AI资源就可以怎么协作。成员提交资源时，工具会自动创建分支和PR/MR；审核环节由人判断这是个人习惯还是项目规范、适用边界在哪里、会不会与已有规则冲突；通过审核的经验再由其他成员pull拉取，支持Hook的工具还能在会话启动时自动触发同步。最有价值的设计在于：它给经验共享加上了一个明确的审核节点，「我这里好用」需要经过判断才能升级成「大家都该用」。

差异化分发与安全审核

一个团队里前端、后端、测试、运维不需要一模一样的技能集合。teamai-cli提供了按角色、按标签、按来源三种分发维度：角色映射到namespace，不同角色同步不同技能；用标签筛选出自己真正需要的那部分资源；还可以订阅其他团队或公开仓库的技能来源。落地实践中，团队资源库可以丰富，但每个人的工作环境应该保持克制——把所有内容一股脑发给所有人只会让维护成本越来越高。同时需要注意的是，按角色筛选资源不能等同于企业权限控制，技能分发解决的是「给Agent什么工作方法」，业务授权解决的才是「允许它操作什么」，两者不应混为一谈。对于Hooks和MCP配置，审核时不能只查YAML格式——需要确认命令执行逻辑、外部服务连接范围、最小够用的权限以及出问题时的回滚路径。当配置会影响整支团队的Agent时，它理应得到与代码变更相称的审查。

从摩擦中发现经验，从数据中识别改进方向

teamai-cli有一个值得关注的设计：根据会话中的摩擦信号提示用户沉淀经验。当用户纠正AI、拒绝工具调用或AI反复重试失败时，系统会提示这部分经验值得保留；而单纯很长、过程却很顺利的会话则不会触发提示。这个思路的逻辑是：顺利完成的任务可能只是模型本身就会，摩擦点往往暴露了项目中没有被写清楚的知识。「这个字段不是库存，是可售库存」「接口失败后不能直接重试会重复创建单据」——这些散落在对话里的业务约束，如果只存在个人会话里，换一个人接手就会重新踩坑。官方提供的Dashboard可以展示成员会话状态、干预次数和Token用量，但数据解释需要谨慎：干预次数多可能说明使用者更认真地检查结果，干预次数少也可能只是没有发现错误。不建议把Dashboard变成「谁用得少谁效率高」的排行榜，它最值得回答的问题是「哪里需要改进」而不是「谁看起来更好看」。

团队AI落地的差距，最终会体现在经验能不能留下来。teamai-cli把注意力从「一个人如何调度多个Agent」转移到了「不同人的Agent如何共享同一套经过验证的工作经验」这个更务实的问题上。对于想落地的团队，建议先选择一个项目、几条高频经验和明确的审核人，把共享流程跑起来。不必一开始就建设庞大的技能库，先验证一件事：今天一个人花两小时解决的问题，明天另一位同事能不能少踩一次坑？如果答案是能，团队的AI投入就开始产生持续积累的价值。