为什么 Skills/Rules 需要「治理」这个词
个人用一个 Skill，改改删删无所谓。但团队共享的 Skills/Rules 是另一回事——它们直接影响每个成员、每次 AI 会话的产出质量。想想这些真实场景：
- 半年前写的某个 Skill，现在没人说得清它为什么这么设计，也不敢删
- 两个功能重叠的 Skills 同时存在，AI 有时用这个有时用那个，行为不稳定
- 某人更新了代码规范 Rule，但只改了自己的本地文件，其他人毫不知情
- 一个 Skill 里引用的外部依赖变了，全团队 AI 产出悄悄劣化，没人知道原因
这些问题有一个共同名字：配置腐化。 antidote 是把 Skills/Rules 当软件资产一样治理——版本化、可追溯、有生命周期。teamai-cli 的 Git 基座让这套治理成为可能，本篇讲怎么把治理落地。
Skills 的治理结构
一个 Skill 的标准生命周期
起草（个人本地调试）
→ 入库（teamai push + 变更说明）
→ 审核（MR/PR，至少一人 review）
→ 生效（合并后全团队同步）
→ 维护（issue 跟踪问题、迭代更新）
→ 退役（skill exclude 或删除，Git 历史留存）每个环节都有对应动作。关键是入库和退役两端：
入库时写好三样东西——描述（这个 Skill 解决什么问题）、适用范围（哪些工具/场景）、变更说明（为什么这么设计）。teamai skill show <技能名> 能看到的描述质量，直接决定三个月后同事们敢不敢用、会不会用。
退役要显式做——发现某个 Skill 不好用了，别只是自己不用（它还在团队配置里影响别人）。两条路径：个人层面 teamai skill exclude add 排除；团队层面走 push 删除流程，让所有人都知道这个技能退役了以及为什么。Git 历史保证了「删了还能找回」，所以删错的成本远低于腐化的成本。
重名与冲突的预防
团队 Skills 多起来后，最常见的脏数据是功能重叠：两个人各自写了一个「SQL 优化」技能。预防手段很简单但需要执行：入库前先 teamai list 查重，有相近的先讨论是合并还是改名区分。AI 面对两个功能重叠的 Skills 时行为不可预测——这不是理论风险，是日常翻车源。
Rules 的治理要点
Rules（编码规范、工作流约定）和 Skills 的治理逻辑一致，但有两个特殊点：
Rules 变更需要更强的通知机制。 Skill 更新通常是增量能力，漏更新影响小；Rule 是约束性规范，团队里一半人用新版一半人用旧版，产出就开始分裂。实操建议：重要 Rule 变更走「push + 群公告」双通道，变更说明里写清「影响哪些行为」。
Rules 要区分层级。 团队级规范（代码风格、安全红线）进共享仓库统一分发；项目级细则（某个服务特有的约定）放项目配置里。层级混了，跨项目成员会被无关约束干扰。Cursor 用户可以把这个理解成 Cursor Rules 的 user/project 分层——同样的思想，teamai 把它扩展到了全工具、全团队。
用 Git 历史做「考古」
版本化的隐性价值在出问题时才显现。当团队发现「AI 最近生成的 API 代码风格变了」，排查路径是：
# 看 rules 目录的变更历史
git log --oneline -- rules/
# 看某次变更的具体内容
git show <commit>
# 定位到某人某天的某次 Rule 更新三十秒定位变更源头，git revert 一键回退。没有版本化时，同样的排查是群聊考古：「谁最近改过规范吗？」——然后无人应答。
治理节奏建议
- 每次 push 前自查：描述、适用范围、变更说明三样齐不齐
- 每月一次仓库巡检：
teamai list过一遍，冻结没人用的、合并重叠的 - 每季度一次结构复盘：Skills/Rules 的目录组织是否还合理，是否该拆分或重组
- 变更永远小步走：一次一个逻辑变更，Git log 才可读
生命周期命令速查表
把生命周期各环节和对应命令对上号，治理就有了抓手：
| 环节 | 动作 | 命令/载体 |
|---|---|---|
| 起草 | 个人本地调试 | 各工具本地目录自建，暂不进仓库 |
| 入库 | 提交变更 | teamai push（附变更说明） |
| 审核 | 人工 review | GitHub PR / TGit/CNB MR |
| 生效 | 全团队同步 | teamai pull 或 SessionStart Hook |
| 维护 | 排查与迭代 | git log --oneline -- <目录>、git show <commit> |
| 退役（个人层） | 不再同步某技能 | teamai skill exclude add <技能名> |
| 退役（团队层） | 显式删除 | push 删除流程，git revert 可回退 |
表里两条 Git 命令值得单独记：git log --oneline -- <目录> 只看指定目录的变更历史，Rules 考古靠它起步；git show <commit> 展开某次变更的具体内容，是「产出风格为什么变了」排查的终点站。
治理 FAQ
Q：Skill 的描述写到什么程度算合格？
teamai skill show <技能名> 能看到的字段就是别人决策的依据——至少覆盖三件事：解决什么问题、适用哪些工具或场景、有什么前置条件。同事靠它判断「这个技能和我的任务相关吗」，描述含糊等于这个技能不存在。
Q：发现两个功能重叠的 Skills 已经入库了，怎么处理？ 按退役流程处理其一：确认保留哪个，另一个走 push 删除并在变更说明里写明原因（Git 历史可找回）。关键是别拖——AI 面对重叠 Skills 的行为不可预测，拖一天就多一天不稳定产出。
Q：误删了团队还在用的 Skill 怎么办？
Git 历史是安全网：git revert 撤销那次删除，或从历史 commit 恢复文件再 push 回去。这正是「退役要显式做」的底气——删错的成本远低于腐化的成本。
Q：skill exclude 和删除 Skill 有什么区别？ exclude 是个人层的「我不看」：仓库里技能还在，其他人照常同步。删除是团队层的「它退役了」：走审核流程，影响所有人。自己用不上某技能用 exclude；技能本身有问题、对团队有害，走删除流程。
Q：Rule 变更怎么让团队真正感知到？ 双通道：push 走 Git 流程保证配置落位，群里同步一句「改了什么、影响哪些行为」保证认知到位。约束性规范的变更，只做前者会分裂（一半人新规则一半人旧规则），只做后者会漂移（认知到了配置没到）。
治理的终点：规范即代码
把视角拉高：Skills 是「AI 怎么做事」，Rules 是「AI 遵守什么约束」，它们的治理最终指向同一个目标——团队的工程实践以代码形态存在，可以被 review、被版本化、被自动化分发。这就是「规范即代码」（Policy as Code）思想在 AI 编程时代的具体化。
治理做好了，还能往上长一层：不同角色看到不同的配置子集——前端工程师不需要后端的部署 Skills。这就是角色与权限机制，见下一篇文章。