公众号：@鸢飞鱼游 | 专栏：AI as Dasein | 📧 winson_dasein@163.com

> 本内容版权归@鸢飞鱼游所有，未经允许任何单位或个人也可使用（若有帮助，欢迎署名）、复制或以任何其他方式使用本文全部或部分。

AI 团队资产治理框架

一、核心哲学

1.1 唯一铁律

> 资产沉淀不下来的头号原因，不是缺纪律，是对所有资产用了同一种分发方式。

把"能装的"和"只能连的"混为一谈，让所有东西都走"本地安装+手动拼装"这条路，是一切低效和分叉的根源。先把资产分好类，再选分发方式，80% 的沉淀难题会自动消解。

1.2 三个底层认知

1.3 核心公式

资产分类（能装的 vs 只能连的）
  × 分发方式选择（依赖安装 vs 共享服务）
  × 治理机制（版本锁定 + 漂移检测 + 联邦发现）
  = AI 团队能力的组织级复用

二、完整执行流程

Phase 1：资产盘点与分类

目标：搞清楚团队里到底有哪些 AI 资产，哪些值得投入精力管理。

Step 1.1：用三条标准筛资产

一个东西能被当作资产来经营，必须同时满足三条：

只满足第一条的（比如某次一次性的 prompt 调试记录）是消耗品，不是资产。别在消耗品上花治理精力。

检验标准：能同时勾选三条的才进入资产清单。

Step 1.2：按优先级给资产排座次

资源有限时，先做 P0，再做 P1。P0 做不好，后面的全白搭。

关键认知：Eval 尤其反直觉——有价值的评测集，装的是那些能把好答案和坏答案区分开的用例。一个所有模型都能过、或者都过不了的用例，信息量为零。

检验标准：输出一份团队资产清单，每项标注类型、优先级、当前状态（散落/已集中/已服务化）。

Phase 2：分发方式选择——最关键的一步

目标：为每类资产选择正确的分发方式，这是整个框架最核心的决策点。

Step 2.1：做二分类——能装的 vs 只能连的

这是这篇文章最核心的判断框架：

判断方法：问自己一个问题——"这个东西，能不能在本地独立跑起来，不依赖任何共享服务？"
- 能 → 能装的，用依赖方式分发
- 不能 → 只能连的，用服务方式分发

Step 2.2：处理混用错误

大部分团队的卡点，是把"只能连的"错当成"要装的"来处理。典型症状：

检验标准：检查资产清单中的每一项，确认它被归入了"安装"或"连接"两个类别之一，没有遗漏。

Phase 3：跨团队协作设计

目标：多组共存时，设计能力流动的架构，避免合并陷阱。

Step 3.1：识别是否需要联邦

如果你的团队只有一个人或者一个小组，跳过这个 Phase。出现以下情况时进入：
- 有 2 个以上的专业小组（前端组、后端组、客户端组等）
- 各组有自己的领域知识库和专属工具
- 组间需要互相调用能力

Step 3.2：执行联邦三原则

联邦的目标：让能力流动，不是让所有东西归到一处。

检验标准：每个组有明确的命名空间前缀、有至少一个对外暴露的接口、有跨组调用能力的实际案例。

Phase 4：防分叉治理

目标：让中心版本永远比本地副本好用，从根本上消除分叉动机。

Step 4.1：理解分叉的根因

人为什么在本地魔改而不推回中心？答案很朴素：在本地随手改一刀的摩擦力，比把改动提交回中心的摩擦力更低。 人都是走阻力最小的路。

治理方向不是喊纪律，而是翻转这个摩擦力的对比。

Step 4.2：执行四个防分叉杠杆

Step 4.3：给中心版本配"监护人"

中心版本会落后，往往是因为它本身是个没人管的死物。必须做到：
- 每个资产有明确的负责人（不是"大家都可以改"）
- 有自动化校验（CI 回归门禁，不符合标准的提交自动拒绝）
- 有评测兜底（Eval 套件，每次变更自动跑回归）

检验标准：资产清单中每一项都有明确的负责人、自动化校验配置、评测覆盖。

Step 4.4：漂移检测实操

对于"能装的"资产，版本漂移是主要风险。推荐三层防线：

发布策略：影子流量 → 金丝雀 5% → 全量发布，配合一键回滚。

Phase 5：工具选型与落地

目标：按资产层次选对工具，不自己造轮子。

Step 5.1：分发层工具——解决"能装的资产怎么一键复用"

Step 5.2：知识联邦层工具——解决多组知识库统一检索

Step 5.3：Prompt 与 Eval 层工具

Step 5.4：治理层工具

选型原则：难点从来不在单个工具，在于有没有先把资产分好类、划好权责，再让合适的工具各就各位。

Phase 6：执行路线图

目标：从当前状态到理想状态的可落地路径。

Step 6.1：立即可做（0-2 周）

• [ ] 用 Phase 1 的三条标准筛一遍团队资产，输出资产清单
• [ ] 用 Phase 2 的二分类框架，把每项资产标记为"能装的"或"只能连的"
• [ ] 为 P0 资产（Eval + 知识库）指定负责人
• [ ] 锁定所有模型的版本 ID，不使用别名

Step 6.2：短期建设（2-6 周）

• [ ] 为 P0 Eval 建立至少一套 Golden Dataset，包含能把好答案和坏答案区分开的用例
• [ ] 把"只能连的"资产部署为共享服务（知识库检索服务、数据访问工具）
• [ ] 引入声明式配置（APM 或类似工具），统一管理"能装的"资产
• [ ] 在 CI 中添加评估回归门禁

Step 6.3：中期架构（6-12 周）

• [ ] 建立 Prompt Registry，实现版本化 + 权限分离 + 审批工作流
• [ ] 部署端到端可观测性（OpenTelemetry + Langfuse/类似工具）
• [ ] 如果有多组，建立联邦发现层和命名空间体系
• [ ] 部署漂移检测，设置自动告警

Step 6.4：长期治理（3-6 个月）

• [ ] 构建联邦共享上下文层
• [ ] 建立治理委员会，定期审查策略变更
• [ ] 实现"回推比本地改更省事"的完整体验
• [ ] 让中心版本永远是最好用的那一版

检验标准：团队中任何一个新成员，能在 30 分钟内从零配齐所有 AI 资产并跑通第一个任务。

三、常见陷阱与避坑指南

四、场景适配指南

五、质量检验清单

完成治理方案设计后，逐项检查：

• [ ] 所有资产都用三条标准筛过了？
• [ ] 每项资产都标注了优先级（P0-P3）？
• [ ] 每项资产都归入了"能装的"或"只能连的"？
• [ ] "能装的"有版本化依赖管理方案？
• [ ] "只能连的"已部署为共享服务？
• [ ] P0 资产（Eval + 知识库）有负责人？
• [ ] 多组场景有命名空间和联邦发现层？
• [ ] 有 CI 评测回归门禁？
• [ ] 有漂移检测和告警机制？
• [ ] 新成员 30 分钟内能配齐所有资产跑通任务？

六、执行原则

1. 分发方式先于工具选型。先搞清楚每类资产该怎么流转，再去选工具。工具是手段，架构决策才是核心。
2. P0 不做，后面白搭。Eval 和知识库是地基，没有地基的 skill 和 agent 只是空中楼阁。
3. 架构优于纪律。一处更新处处生效靠的是把资产做成依赖或服务，不是靠反复提醒团队成员回推。
4. 联邦优于合并。跨组协作的目标是让能力流动，不是让所有东西归到一处。
5. 可见的漂移好过不可见的漂移。不要试图消灭分叉，让它浮出水面，变成可处理的信息。
6. 从小处开始。先盘点一个小组的资产、跑通一个"能装的"+一个"只能连的"的完整流程，再推广到全团队。