规模一上来，就得「治理」
当 AI 能力（Agent、技能、流水线）被多个项目、多个团队使用时，最大的风险不是「做不出」，而是失控：各项目乱改共享配置、重复造轮子、没人负责、权限混乱。
治理就是管住这些：让复用在有序的前提下发生。这一节讲多项目复用与治理。
治理要解决的三件事
| 问题 | 治理手段 |
|---|---|
| 重复造轮子 | 抽共享、统一复用 |
| 没人负责 | 明确负责人、owner |
| 权限混乱 | 收敛权限、分级管理 |
三件事管住，规模化才不会变成「放大混乱」。
对 deploy-bot 三件事对应：
- 重复造轮子：多项目别各造部署机器人，统一用 deploy-bot 模板
- 没人负责：deploy-bot 必须有 owner，改坏了有人管
- 权限混乱：谁能改 deploy-bot、谁能触发生产部署，都得收拢分级
复用：统一入口，别各搞一套
复用不是「谁想要谁去复制」，而是统一的共享入口：
共享库（团队统一维护）
├─ 技能
├─ 模板
└─ 配置
← 各项目从这里「引用」，不自己复制
改一处、处处受益，是共享库的核心价值。
对 deploy-bot：它的部署脚本、流水线模板、规范配置都放统一的共享入口，各项目从这里引用，而不是各自复制一份。团队给 deploy-bot 加安全规则，所有项目一起生效。
治理：明确责任
每个共享资产要有负责人（owner）：
- 谁维护这个技能/模板？
- 变更走什么流程？
- 出问题找谁？
技能「代码审查」 owner：张三
- 变更走 PR，需 owner 审核
- 质量问题找 owner
有 owner，资产才有人管、才不腐烂。
对 deploy-bot，owner 尤其要紧——它管着部署，是高风险资产：
deploy-bot owner：张三（部署负责人）
- 所有 deploy-bot 模板 / 流水线 / 规范变更走 PR，需 owner 审核
- 生产部署问题第一时间找 owner
- owner 负责 deploy-bot 的安全门禁和回滚预案
没有 owner 的 deploy-bot，改坏了没人管、出问题没人担责。
治理：收敛权限
多项目场景，权限更要收敛：
- 谁能用：按角色/团队分级
- 谁能改：共享资产只有 owner/核心成员能改
- 谁能部署：生产环境收紧
普通成员：能用技能、能查
核心成员：能改共享技能
负责人：能部署到生产
权限跟着角色和风险走，够用就好。
对 deploy-bot 的权限分级：
普通成员：能看 deploy-bot 的部署日志和状态
项目成员：能给自己的项目配置项目层差异
核心/owner：能改 deploy-bot 通用模板、门禁
生产负责人：能触发 production 部署、做最终确认
谁的权限给到哪一级，清清楚楚，生产最严。
一个治理落地清单
- [ ] 共享资产有统一入口，不各复制？
- [ ] 每个资产有明确 owner？
- [ ] 变更走流程（PR + owner 审核）？
- [ ] 权限分级、生产收敛？
- [ ] 有废弃清理机制（过时资产下线）？
对 deploy-bot 过一遍：
- [ ] deploy-bot 模板在统一入口，各项目引用不复制？
- [ ] deploy-bot 有明确 owner 和联系方式？
- [ ] 改 deploy-bot 走 PR + owner 审核？
- [ ] staging/production 部署权限分级、生产最严？
- [ ] 有废弃模板清理机制，旧版本下线？
常见坑：deploy-bot 没有 owner，出问题没人负责
多项目治理里最典型的坑，是共享资产「有复用、没责任」——大家都能用，但没人是 owner。
真实场景：deploy-bot 被三个项目共用，但没定 owner。某天某个项目改了共享部署脚本，把 staging 部署逻辑改坏了。B、C 项目一起遭殃。你想追责，发现「谁都能改，谁都不负责」，最后只能全员排查、拖很久才定位。
为什么：没有 owner = 没有「管」的人。改动没人把关、质量没人负责、问题没人兜底，共享资产很快就「腐烂」。
怎么破：deploy-bot 这种高风险共享资产，必须指定 owner，且把「变更走 PR + owner 审核」「出问题找 owner」写进规范。owner 不一定是一个人维护全部，但他对「deploy-bot 改没改坏、安全门禁在不在」负最终责任。
小结
- 规模一大就要治理：复用、责任、权限三件事
- 复用：统一入口，改一处处处受益
- 责任：每个资产有 owner，走变更流程
- 权限：分级 + 收敛，生产最严
下一模块进入「生产级实战」。