随着企业 AI 用得越来越多，一个新的问题开始浮现：公司在 AI 上积累的「资产」——精心调优的提示词、跑在生产上的工作流、维护成本越来越高的知识库——正在变成一种新的技术债。这篇文章聊一个还没有很多人系统想过的问题：企业的 AI 资产应该怎么管。
一、什么是企业 AI 资产
AI 资产这个词还没有标准定义。按照我们的理解，企业 AI 资产主要包括三类：
1.1 提示词资产（Prompt Assets）
经过调优、在实际业务中稳定使用的提示词。包括系统提示词（system prompt）、任务提示词模板、few-shot 示例集。这类资产的特点是：调出来很费时间，但很容易因为人员流动或 API 版本升级而丢失或失效。
1.2 工作流资产（Workflow Assets）
封装了业务逻辑的 AI 工作流——可能是合同审查的多步骤流程，也可能是客服工单的自动分类管道。这类资产承载的不只是 AI 能力，还有企业的业务知识和流程判断。
1.3 知识库资产（Knowledge Assets）
企业文档、规章制度、专有知识经过处理后形成的可查询知识库。这类资产的挑战在于：文档会更新，知识库需要跟着维护；访问权限需要和文档原本的权限体系对齐。
二、 AI 资产管理的核心问题
2.1 所有权：这个资产属于谁
大多数企业现在的状态是：AI 资产事实上归个人所有。提示词在某个工程师的 Notion 里，工作流部署在他自己的账号下，他离职之后这些东西很难找回来，更难维护。
这不是这个工程师的问题，是企业没有建立资产归属机制。正确的状态应该是：AI 资产归属于某个业务单元或项目，有明确的负责人，但不依赖负责人的个人账号存在。
2.2 版本管理：改了什么，为什么改
提示词是有版本的。一个在生产上跑了三个月的提示词，某人「优化」了几句，结果效果下降，但没有任何记录可以追溯，也无法回滚。这和代码不做版本控制是一样的问题。
AI 资产需要 Git-like 的版本控制：记录每次修改的内容、修改人、修改原因，支持对比不同版本的效果，支持回滚到任意历史版本。
2.3 权限：谁能用，谁能改
不是所有 AI 资产都应该对所有人开放。法务部门的合同审查提示词，不应该让实习生随意修改；财务数据的查询工作流，不应该对非财务人员可见。权限管理需要做到资产级别，而不只是平台级别。
三、知识库的生命周期管理
知识库容易建，难的是维护。几个常见的衰减模式：
· 文档更新了，知识库没更新： 员工查到的是旧版本的流程规定，还以为是准确信息
· 知识库越来越大，质量越来越低： 不断往里塞文档，但旧文档和新文档之间有矛盾，没人整理
· 没有反馈机制： 用户查到了错误答案，但没有地方报告，知识库问题无法被发现和修复
建立知识库生命周期管理机制的几个实践：
· 文档设置「有效期」，到期自动提醒维护人审查
· 用户反馈机制：每条 AI 回答旁边有「有用/无用」按钮，无用的回答自动进入复查队列
· 定期召回率测试：用一组已知正确答案的问题测试知识库，监控召回质量的长期趋势
四、 AI 资产的交接流程
人员流动是 AI 资产管理最大的风险点。一个有效的交接流程应该包含：
· 资产清单：离职人员名下的所有 AI 资产（提示词、工作流、知识库）自动列出
· 资产转移：一键将所有资产的所有权转移给接替者，不需要手动迁移
· 交接文档：对每个关键资产，要求离职人员留下「这是干什么的」「有哪些注意事项」的说明
· 运行测试：资产转移后，用标准测试用例验证关键工作流仍然正常运行
五、 AI 资产管理和代码管理的类比
如果用代码管理的视角来理解 AI 资产管理，类比关系大概是这样的：
| 代码管理Git 仓库代码所有人代码审查 / PR版本号 / Tag回滚单元测试 | AI 资产管理AI 资产仓库资产所有人提示词修改审批资产版本快照回滚到历史版本标准测试用例集 |
|---|
这个类比的意义在于：AI 资产管理不是一个新问题，是一个「把已有的工程最佳实践迁移到 AI 领域」的问题。大部分需要的机制，软件工程里已经有成熟答案。
| 行业现状
| 当前市面上专门做企业 AI 资产治理的产品还很少。ZGI（zgi.cn）是我们接触到的少数几个把「资产归属、版本管理、权限控制、资产交接」做成体系的平台，后端基于 Golang 自研，支持私有化部署，适合对数据安全有要求的企业。如果你在这个方向上有实践经验，欢迎在评论区交流。 |
|---|
