从 Prompt 到 Memory：团队 AI 经验的资产化管理

前阵子看到一个数字。

微软一个核心业务部门，给几千名工程师开通了 AI 编程工具，打算靠 AI 把开发效率拉起来。结果四个月后财务拉账单，全年 AI 算力预算已经归零。实际支出超预期三倍以上。没有审批漏洞，没有恶意刷量。就是几千人正常用，没设额度上限。

技术圈讨论的角度各有不同。但有一个问题几乎没人追问：这四个月的预算烧完了，团队的知识库多了什么？

代码也许有一些，但大部分和 AI 的交互不是最终产物，是过程。一段反复调试的 Prompt、一套跑通后被忘记的 Skill 配置、一份调了十几轮才稳定的 Memory。这些东西在哪？在那个工程师的个人 AI 账号里。他离职那天，它们跟着账号一起走了。

生产者留下了，产物没留下

企业的技术资产大多有明确的存放位置。代码进 Git，文档进知识库，设计稿进协作平台。每类资产都有路径、有权限、有交接流程。

AI 时代的产出物是个例外。

一个运营同事花两周调试出一套 Prompt，能把竞品分析从三小时压到二十分钟。这套 Prompt 在哪？大概率在她的 AI 工具聊天记录里。一个后端工程师写了一套 Skill，能自动跑完代码审查并输出结构化意见。配置在哪？本地某个 JSON 文件里，和项目代码混在一起。还有一个产品经理，几个月让 AI 记住了团队命名规范、接口风格、用户画像偏好。这套 Memory 是上百次对话喂出来的。换个人接手，Memory 得从头再训。

换个角度看，这是一种知识蒸馏。只是对象不是模型，是人。

优秀员工和普通员工的差距，很多时候不是知识面，是判断力。知道什么场景该用什么模型、Prompt 怎么写才能一次出对、Skill 怎么编排才高效。这些东西在过去是隐性经验，在脑子里。但现在不一样了——这些经验被写进了 Prompt，封装进了 Skill，喂进了 Memory。每一段调试过的指令，就是专业判断的浓缩。

问题在于：蒸馏完的产物，团队没接住。

成本不可见，资产就无法归因

如果产出物留不住是第一个问题，那第二个问题是：很多团队根本不清楚费用流向。

月初充值的额度，月底还剩多少，这是最常见的粒度。哪个项目消耗最大？谁拿着高性能模型跑简单的文本摘要？不清楚。月底账单最多看到总数，看不到明细。当 AI 调用变成日常行为、多个项目并发运行时，手工统计就彻底失灵。

回头看微软那个案例，「没设额度上限」只是表象。更深的问题是：消费没有实时跟踪，成本没有归因到项目和人员，预算消耗速度没有人能提前感知。

从治理视角设计调用链路

要在团队内部构建一套治理机制，可以从三个层级切入设计。

身份注入。 调用链路的入口处将使用者身份、所属项目、调用意图等元信息注入请求上下文。无论底层接入哪个模型，统一签发带身份标签的派生凭证，后续所有追踪基于此凭证。类似云平台 IAM 的临时凭证思路——签发有限权限、有限生命周期的凭证，而非直接暴露主账号 Key。

实时计量。 每次调用在返回结果的同时完成 Token 计数和成本估算。关键设计是将「账单口径」和「估算口径」分开维护。估算口径允许少量误差，但延迟控制在秒级，用于实时预警和用量看板；账单口径追求精确，T+1 对齐 Provider 结算数据，用于财务核算。

策略执行。 基于前两层的身份和计量数据，在调用链路中插入策略点：项目预算阈值告警、单成员日消耗上限、低成本模型自动降级、异常激增自动熔断。这些策略作为中间件实现，不需要侵入业务代码。

更重要的是，这套架构天然具备资产沉淀的基础。当每一次 Prompt 调用、每一次 Skill 编排、每一次 Memory 写入都被记录和归因时，「谁创造了什么、它是否有效、被复用了多少次」就不再是一个需要事后手工收集的问题。系统运行时，资产目录自然生长。

Prompt、Skill、Memory——这些东西能不能像代码一样被入库、归档、复用？当它们从个人账号中解放出来，成为团队可追溯的技术资产，企业为 AI 花的钱才算真正完成了从「消耗」到「积累」的闭环。