微软开始给工程师的AI用量设预算：AI-first也要算Token账

据外媒援引微软内部沟通，公司正为工程师使用部分AI工具设置预算。一名高管明确提醒，微软追求的并非“tokenmaxxing”——也就是把模型调用量尽可能堆高——但公司仍要成为一家“AI-first”企业。

这件事容易被解读成“连微软也用不起AI”。现有证据并不支持这个结论。更准确的判断是：微软正在把内部AI使用从推广期带入成本核算期。员工有没有用，已经不是唯一指标；这些调用是否缩短开发周期、减少故障，才是管理层接下来要问的问题。

微软限制的不是AI战略，而是无差别调用

从已披露的信息看，微软没有放弃让工程师使用AI，也没有否定GitHub Copilot等产品的价值。变化出现在使用方式上：部分团队开始面对预算约束，模型调用不再被默认视为近乎无限的内部资源。

目前仍有几个关键信息没有公开，包括预算按个人还是团队分配、覆盖哪些模型、超额后能否申请，以及限制针对GitHub Copilot、内部代理工具还是更广泛的模型服务。缺少这些细节，就不能把“设预算”直接写成“全面收紧”。

但管理逻辑已经很清楚。生成式AI的成本不同于传统办公软件。员工打开一次文档工具，边际成本很低；调用大模型却会持续消耗推理资源。上下文越长、模型越强、代理执行步骤越多，成本通常越高。

GitHub Copilot在2021年开放技术预览，2022年推出每月10美元的个人付费方案。早期产品强调的是固定订阅和使用便利，用户很少需要理解Token成本。此后，行业逐步引入高级模型额度、请求次数和不同模型的计费差异，原因正是固定席位费无法完全覆盖波动的推理开销。

订阅价格与微软内部核算也不是一回事。员工拿到一个Copilot席位，并不意味着公司已经一次性买下所有模型调用。席位费可以把价格包装得简单，但底层算力仍按实际消耗发生，尤其是长上下文、复杂代码库检索和多步骤代理任务。

从“人人都用”转向“用完有什么结果”

这次调整真正重要的地方，不是微软少发了多少Token，而是AI项目的考核口径正在变化。

过去两年，大企业推广生成式AI时，常用活跃人数、调用次数和覆盖岗位衡量进展。这种办法适合产品导入期：先让员工尝试，再寻找稳定场景。问题是，调用量只能证明工具被打开过，不能证明交付速度和软件质量真的改善。

这与企业上云后的FinOps管理颇为相似。云计算刚普及时，开发者可以快速创建服务器，企业随后才发现：资源开通容易，闲置实例、重复存储和失控账单同样增长。于是，标签、配额和成本归属成为标准管理动作。

AI正在重走这条路。所谓“量入为出”，并非退回人工开发，而是要求每笔推理成本找到对应的业务结果。微软既是模型和Copilot产品的卖方，也是拥有大量工程师的买方。它开始管理内部用量，至少说明AI提供商同样无法绕开单位经济性。

这也解释了为什么“微软用不起AI”是个夸张标题。预算管理往往出现在一项技术准备扩大使用时，而不是只有业务失败时才出现。真正偏负面的信号，应当是大范围取消工具、停止部署，或者无法证明核心场景有效。目前披露的信息还没有到这一步。

工程师会更谨慎选模型，管理者要拿出产出证明

最先感到变化的会是工程师和研发负责人。

如果预算执行严格，工程师不会再默认每项任务都调用能力最强、成本最高的模型。补全简单代码、生成测试、解释报错，可以交给更便宜的模型；跨仓库分析、架构修改和复杂代理任务，才有理由消耗高级额度。模型选择将从个人偏好变成团队成本决策。

研发负责人面对的问题更直接：是否继续为整个团队配置高级AI工具，不能只看员工“爱不爱用”。他们需要回答几项可核验的问题：

• 代码审查等待时间有没有缩短；
• 测试覆盖率提高后，线上故障是否减少；
• AI生成代码带来了多少返工和安全审查；
• 同一项任务使用不同模型，成本和完成质量相差多少。

预算也可能带来副作用。开发工作很难像流水线一样精确计量，一些高价值探索在早期看不到稳定回报。如果团队为了避免超额而减少试验，微软可能省下推理费用，却错过真正有效的新工作方式。因此，限额是否允许弹性申请，比“有没有预算”更能反映公司对AI的真实态度。

接下来最该观察的变量有两个：微软是否把预算与开发效率指标挂钩，以及高级模型额度是否继续收紧。如果公司只限制调用、不衡量结果，预算会变成新的行政负担；如果低价值请求被便宜模型接管，高价值任务仍能获得算力，这套制度反而可能让AI开发工具更快进入常规采购。