感谢微软的赞助，但我可能再也不会使用 Azure 了
首先，我想说一声谢谢。Microsoft for Startups（微软创业扶持计划）的赞助确实帮到了我的公司 RockieStar，帮我们把产品真正发布了出去。额度是真的，Azure 算力也是真的。
但我可能还是会选择离开。
这不是意气用事，也不是在发脾气。而是因为在 7 月的一天，Azure 在 单日 24 小时内向我们收取了 $44,530.72 美元。我花了一整月的时间去追问这笔费用到底是怎么来的，而 Azure 支持团队没有任何人能给出一个解释。
对于一家独立软件公司来说，一笔无法解释的 4.4 万美元单日账单绝不是什么小插曲。如果按这种单日扣费速度持续一个月，那就是 134 万美元——足以让我破产十年。
谁也解释不清的 4.4 万美元单日账单
在 2026 年 7 月 28 日，我们的微软创业扶持赞助订阅在一天内产生了 $44,530.72 的账单，关联的模型是 GPT-5.6 Sol。
- 工单追踪 ID (Tracking ID):
2607200040000130 - 订阅 ID (Subscription ID):
2d119d2f-c7e5-4c7a-8d78-ba25d66087ef
我不会坐在这里断言我们的实际使用量就是零。那笔钱也许确实包含了真实的使用量。问题在于：我根本无从得知。
Azure 的赞助计费延迟极其严重。费用数据根本不是实时更新的，往往在几天甚至几周后才姗姗来迟。当你终于在 Cost Management 控制台看到暴涨的曲线时，木已成舟。你根本无法去熔断或阻止一个你完全看不见的失控计费。
更荒谬的是，当我向 Azure 计费支持部门提交工单时，微软自己的支持工程师竟然承认：他们对赞助订阅的具体使用情况**“可见性有限（limited visibility）”**。
想想看这有多可怕：微软给一家初创团队开出了近四万五千美元的单日账单，但他们自己的计费部门却看不到到底是什么资源产生了这笔费用。他们打印出了一张连自己都看不懂的账单。
这并不是第一次（上次我们自掏腰包买单）
这甚至不是 Azure 计费系统第一次在没有任何预警的情况下突然开出意外账单。
去年底，我们在 Azure 上测试了 Anthropic Claude 模型。我们把模型接入系统并用于开发调试。在大约一到两周的时间里，Azure 控制台里显示的费用始终是 $0。因为仪表盘一片风平浪静，我们自然以为这部分调用要么被赞助额度覆盖，要么包含在免费额度中。
然而，没有任何前兆，微软直接发出了一张正式发票：
- 发票编号 (Invoice):
G133459410 - 金额: $1,764.06 CAD（加元）
- 计费周期: 2025 年 12 月 1 日 – 31 日（2026 年 1 月 9 日出账）
- 账户目录: Default Directory
因为我们账号后台绑定了信用卡，微软在发票开出后两个工作日内直接自动划扣。这 $1,764.06 CAD 完全由我自掏腰包支付。
每一次都是同样的剧本：没有实时监控，没有主动预警，控制台显示一切正常，随后就是一笔冷不防的直接划扣。如果只是一千多加元，忍痛掏钱也就罢了；但当它演变成一天 4.4 万美元时，这对初创团队就是致命的灭顶之灾。
社区里的普遍遭遇
这绝不是只发生在我一个人身上的偶发 bug。只要去翻翻 Azure 官方 Discord 和开发者社区，就会发现到处都有团队在抱怨 GPT-5.6 和 Azure AI 模型的严重计费异常——实际扣费与他们自己的调用日志完全对不上：
许多开发者眼睁睁看着云账单失控爆炸，却没有任何救济途径。就在上周，开发者 Leo Jing 在 Discord 社区发帖提醒所有人，他们的团队被错误扣费了近六位数：
“大家使用 Azure AI 模型时务必当心。Azure 存在严重的过度计费（overcharging）问题，而且到目前为止想拿到退款基本是不可能的。上个月我们被错误收取了 $87,650 美元，我们已经等了一个月，没有任何解决方案。在使用 Azure AI 模型前一定要三思。”
当多个独立团队在同一系列模型上同时遇到五位数甚至六位数的幽灵账单时，这不再是一个偶然的 edge case，而是一个客观存在的平台级系统风险。
支持团队：长达 30 天的复制粘贴与沉默
一位支持工程师在 8 月 4 日接手了我们的工单。他们解释说因为内部某个项目重组被关停，导致工单交接出现了延迟。
从那之后，在整整一个月的时间里，我们在 8 月 4 日、5 日、7 日、13 日、18 日、22 日和 25 日 收到了七封一模一样、几乎逐字相同的敷衍邮件：
“案件已升级，我们正在等待内部团队的回复。有任何进展我们会及时通知您。”
我真的不在意这些回复究竟是出自人工、外包人员还是自动客服机器人。用 AI 也好，用什么工具都行，核心在于：根本没有人解决问题。
没有人说明到底由哪个内部团队负责，没有人给出包含 Token 数量、地域或接口的具体使用明细，也没有人撤回或退还那笔 $44,530.72 的扣款。整整一个月，音讯全无。
8 月 25 日，我再次明确询问究竟是哪个团队在跟进，并说明如果到 8 月 28 日（星期五）仍没有实质答复，我们将不得不把服务全部迁出 Azure。
今天已经是 8 月 31 日，依然一片死寂。
萨提亚·纳德拉（Satya Nadella）多年来一直在强调建立负责任和有共情心的企业文化。但在这一张工单上，我看不到任何担当，也看不到对一家突遭 4.4 万美元账单冲击的小团队的任何同理心。连续一个月复制粘贴“我们已升级工单”，那不叫客户支持，那只是应付关单的障眼法。
Windows 应用商店与 Partner Center：卡在验证死循环
除了云端基础设施，微软桌面开发者生态的体验同样让人心力交瘁。
我原本打算把我们的两款应用——ScreenKite 和 PilotCut——上架到 Microsoft Store。
对于独立开发者来说，Windows 应用商店本应是最理智的选择：走旁加载（Sideloading）意味着每年必须购买昂贵且繁琐的 EV 代码签名证书，还要防止 Windows SmartScreen 弹出吓唬用户的风险警告；而走微软商店由官方签名则能免去这笔每年几百上千美元的证书税。我看到 OpenAI 的 Codex 桌面客户端也通过微软商店分发，以为这条路已经非常成熟了。
然而，这又是一堵令人绝望的高墙。
我们的 Partner Center 开发者账户此前早已完成了全部验证。但大约两周前当我们准备提交新版本时，后台却要求重新提交验证材料，并承诺会在 “1 个工作日内处理完成”。
两周过去了，产品发布页面依然卡在 Submission 1 草稿 状态：
“在您的账户通过验证之前，您无法提交到应用商店。”
“提交审核”按钮一直处于置灰禁用状态。我在 Partner Center 开了支持工单，石沉大海，没有任何人回复。为了让一个本就已经通过验证的开发者账号正常发布更新，我白白消耗了 20 多个小时。
苹果的 App Store 和 Google Play 同样不完美，但它们绝不会把一个老开发者锁在承诺“1 个工作日”却拖了两周、且人工客服完全失联的绝境里。这根本不像一个面向开发者的成熟平台，反而像极了一个孩子没写完的半成品作业。
如果在接下来的两天内验证问题依然得不到解决，我将直接彻底注销整个 Windows Partner Center 开发者账户。
为什么离开是必要的风险管理
赞助额度在宣传页面上看起来很慷慨，但在实际业务中，隐藏的代价会彻底摧毁一个小团队：
- 延迟计费让正常开发变成了俄罗斯轮盘赌：当计费数据滞后数天甚至数周时，一旦遇到计量异常或失控调用，你根本无法及时止损。
- 支持团队无法看清自己的账单：当微软计费支持称对赞助账户使用情况“可见性有限”时，开发者没有任何安全垫。
- 责任机制荡然无存：遇到重大事故，你只会被困在长达一个月的模板化循环中。
- Partner Center 抹杀了平台优势：如果验证通道能够悄无声息地卡死几周且找不到任何人工，免 EV 证书的承诺就毫无价值。
作为开发者，我可以接受系统 bug，软件总会出故障，API 也会有事故。但我作为创始人无法承受的是：系统 bug + 黑盒计费 + 长达 30 天无人问津的冷漠组合。
所以：感谢微软提供的赞助，这是真心的，它确实帮我们度过了起步阶段。
但往后走，我们将逐步全面撤出 Azure。这不是赌气，而是最基本的生存风险管理。对于一家成长中的小公司来说，一个失控且无法解释的云端黑洞账单，其潜在风险实在太大了。
我依然要求得到公正的处理：
- 为 Tracking ID
2607200040000130指定一名明确的人工负责人； - 提供 2026 年 7 月 28 日该笔扣费的具体资源、地域与计量明细；
- 全额撤回/退还针对 GPT-5.6 计费异常产生的 $44,530.72 账单；
- 为我们已验证的开发者账号完成 Partner Center 审核放行。
最后两天期限。如果依然没有实质解决，我们将注销开发者账户并彻底完成迁移。
如果你也在 Azure AI 赞助账户上遇到过突如其来的五位数异常暴扣，或者你的 Partner Center 开发者账号也卡在“账户已验证”的死循环里，欢迎发邮件联系我 hello@realmikechong.com 或在 X (Twitter) 上联系 @realmikechong。我想看看还有多少开发者正在遭遇同样的困境。