近日看到一组数据，不知该说是离谱还是意料之中。

微软的一个核心业务部门，为数千名工程师开通了 Claude Code，期望借助 AI 大幅提升开发效率。然而四个月后财务部门拉出账单——全年 AI 算力预算已经归零。实际支出超出预算三倍有余。既不存在审批漏洞，也没有人为恶意刷量。仅仅是几千名员工正常使用，没有设置额度上限。

这件事在技术圈引发了多种角度的讨论。有人分析架构，有人谈管理责任。但有一个问题几乎没有人从工程侧追问：这四个月的预算烧完了，团队到底沉淀下了什么？

代码可能留下了一些，但大多数与 AI 的交互并非最终产物，而是过程中的痕迹。一段反复调试的 Prompt、一套跑通后被遗忘的 Skill 配置、一份调了十几轮才稳定的 Memory。这些成果放在哪里？在工程师的个人 AI 账号里。当他离职那天，这些资产也随账号一同消失。

Prompt、Skill、Memory：三类无人管理的新型生产资料

企业的数字化资产通常都有明确的存储位置。代码存放在 Git，文档归入 Confluence，设计稿进入 Figma。每类资产都有路径、有权限、有交接流程。

然而，AI 时代的产出物却是个例外。

一位运营同事花费两周时间调试出一套 Prompt，能将竞品分析从三小时压缩到二十分钟。这套 Prompt 在哪里？很可能保存在她的 AI 工具聊天记录中。一位后端工程师编写了一套 Skill，能够自动完成代码审查并输出结构化意见。配置在哪里？在本地某个 JSON 文件里，与项目代码混在一起。还有一位产品经理，花了几个月让 AI 记住了团队命名规范、接口风格、用户画像偏好。这套 Memory 是上百次对话训练出来的。换个人接手，AI 对这些背景一无所知，Memory 必须从头重新训练。

换个视角看，这其实是一种知识蒸馏过程。只不过蒸馏的对象不是模型，而是人。

优秀员工与普通员工之间的差距，往往不在于知识广度，而在于判断力。知道这个场景该用什么模型、Prompt 怎么写才能一次出对、Skill 怎么编排才高效、路由策略如何在成本与效果之间取得平衡。这些能力在过去很难被提炼，因为它们属于隐性经验。但如今情况不同了——这个人把经验写进了 Prompt，封装进了 Skill，喂进了 Memory。每一段调试过的指令，本质上就是专业判断的浓缩。

问题在于：蒸馏后的产物，团队并未接住。

不仅是流失，更根本的问题在于不可见

如果产出物留不住是第一个问题，那么第二个问题是：很多团队压根不知道钱花在了哪儿。

月初充值的额度，月底还剩多少——这是最常见的粒度。哪个项目消耗最大？谁在用顶配模型跑简单的文本摘要？不清楚。一张月底账单最多只能看到总数，看不到明细。

传统技术管理面对「按 Token 计费、调用量按秒波动」的 AI 服务，天然对不上口径。偶尔拉一次账还能应付。但当 AI 调用变成日常行为——多个项目、多个模型并发运行——手工统计就彻底失灵了。

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

一条可行的技术链路

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

身份注入层。 在调用链路的入口处，将使用者身份、所属项目、调用意图等元信息注入请求上下文。无论底层模型是什么 Provider，网关统一签发带身份标签的派生凭证，后续所有追踪均基于此凭证。这一步可以类比腾讯云 CAM 的临时密钥机制——签发一个有限权限、有限生命周期的凭证，而不是直接暴露主账号 Key。

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

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

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

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