← 返回文章列表

感謝微軟的贊助,但我可能再也不會使用 Azure 了

2026年8月31日 · 5 min read

首先,我想說一聲謝謝。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 模型前一定要三思。」

開發者 Leo Jing 在 Discord 上反映遭遇 $87,650 錯誤扣款且等待一個月未解決

當多個獨立團隊在同一系列模型上同時遇到五位數甚至六位數的幽靈帳單時,這不再是一個偶然的 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:卡在驗證死循環

除了雲端基礎設施,微軟桌面開發者生態的體驗同樣讓人心力交瘁。

我原本打算把我們的兩款應用程式——ScreenKitePilotCut——上架到 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 開發者帳戶。

為什麼離開是必要的風險管理

贊助額度在宣傳頁面上看起來很慷慨,但在實際業務中,隱藏的代價會徹底摧毀一個小團隊:

  1. 延遲計費讓正常開發變成了俄羅斯輪盤:當計費數據滯後數天甚至數週時,一旦遇到計量異常或失控調用,你根本無法及時止損。
  2. 支援團隊無法看清自己的帳單:當微軟計費支援稱對贊助帳戶使用情況「可見性有限」時,開發者沒有任何安全墊。
  3. 責任機制蕩然無存:遇到重大事故,你只會被困在長達一個月的模板化循環中。
  4. Partner Center 抹殺了平台優勢:如果驗證通道能夠悄無聲息地卡死幾週且找不到任何人工,免 EV 憑證的承諾就毫無價值。

作為開發者,我可以接受系統 bug,軟體總會出故障,API 也會有事故。但我作為創始人無法承受的是:系統 bug + 黑盒計費 + 長達 30 天無人問津的冷漠組合。

所以:感謝微軟提供的贊助,這是真心的,它確實幫我們度過了起步階段。

但往後走,我們將逐步全面撤出 Azure。這不是賭氣,而是最基本的生存風險管理。對於一家成長中的小公司來說,一個失控且無法解釋的雲端黑洞帳單,其潛在風險實在太大了。

我依然要求得到公正的處理:

  1. 為 Tracking ID 2607200040000130 指定一名明確的人工負責人;
  2. 提供 2026 年 7 月 28 日該筆扣費的具體資源、地域與計量明細;
  3. 全額撤回/退還針對 GPT-5.6 計費異常產生的 $44,530.72 帳單;
  4. 為我們已驗證的開發者帳號完成 Partner Center 審核放行。

最後兩天期限。如果依然沒有實質解決,我們將註銷開發者帳戶並徹底完成遷移。


如果你也在 Azure AI 贊助帳戶上遇到過突如其來的五位數異常暴扣,或者你的 Partner Center 開發者帳號也卡在「帳戶已驗證」的死循環裡,歡迎發郵件聯繫我 hello@realmikechong.com 或在 X (Twitter) 上聯繫 @realmikechong。我想看看還有多少開發者正在遭遇同樣的困境。