Microsoft 365 把你導向 MAI 模型

以前你以為 365 的 AI 只是接模型，現在它開始把預設路徑往自家 MAI 轉。

我用 Microsoft 365 的 AI 功能一陣子了，越用越覺得怪。剛開始很順，問一句、回一句，表面上像是所有模型都能自由切換。但我盯久了就發現，事情不是這樣。它不是單純在賣一個聊天框，它是在慢慢改你會走哪條路。你以為自己在挑模型，實際上很多時候只是被預設帶著走。這種感覺最煩，因為它不吵不鬧，卻會把你團隊的工作流、成本、權限和未來整合全一起改掉。

我會把這件事拆開，是因為 PCMag 這篇報導把線索講得很直白：Microsoft 365 的 app 正在偏向自己的 AI 模型，而不是 ChatGPT 和 Claude。文中提到的重點包含 Microsoft 的 MAI-Code-1-Flash，以及預計用在 Teams 的轉錄模型。來源沒給可用的觀看數、書籤數或星數，我就不亂補。

它不是多接一個模型，是把預設路徑收回去

MAI-Code-1-Flash is Microsoft's coding assistant tool, designed to compete with Claude Code and OpenAI's Codex.

翻譯一下就是：Microsoft 不想只當模型轉接器了，它想直接管你在 365 裡會用哪個模型。以前你把 Copilot 當成一個入口，背後接誰都無所謂。現在它開始自己做編碼助手、自己做轉錄模型，意思很清楚：常見任務先走自家路線，外部模型變成備案。

這件事對開發者很重要，因為我們很容易把「模型」和「產品體驗」混在一起。實際上，真正影響你的是 routing。今天是 ChatGPT，明天換 MAI，後天某個功能又被塞進另一條管線。你看到的 UI 沒變，背後的延遲、成本、資料流向、可用性全變了。這就是我最不爽的地方：看起來像升級，實際上是默默改規則。

我之前在做多模型工作流時就踩過這坑。表面上只是 default 改掉，結果 prompt 庫一半失效，另一半開始產生很煩的語氣差異。不是模型壞掉，是路由變了。你如果沒把這件事寫進流程，最後只會在會議上聽到一句很熟的話：先前可以啊，怎麼現在不行了？

實操寫法很簡單：把每個 365 AI 功能當成一個有依賴的節點，不要把它當成「一個聊天欄位」。你要記錄它實際走哪個模型、誰能改預設、失效時怎麼退回去。這不是文書作業，這是在替你未來少背鍋。

• 列出團隊用到的 365 AI 入口：Word、Excel、Teams、Outlook、Copilot chat。
• 標記每個入口背後的模型來源：自家、第三方、或是被抽象掉。
• 把可預期行為和「最佳可用」行為分開管理。

MAI-Code-1-Flash 代表 Microsoft 要自己吃下 coding 助手

Microsoft 把 MAI-Code-1-Flash 直接拿出來講，這不是低調試水溫，這是明講：coding assistant 這塊它要自己握。這件事很像它在對 Claude Code 和 OpenAI Codex 丟話，意思是你們可以很強，但在 365 裡，我會先放自己的版本。

白話講，這會把原本「我選最強模型」的思路，慢慢換成「我用最順的產品整合」。對 Microsoft 來說很合理，因為它有 Azure、GitHub、Windows、365 這一串現成入口。對開發者來說就沒那麼舒服了，因為你可能不是在選模型，而是在選生態系。模型再強，如果它離你的 repo、權限、審核流程很遠，體感也不一定贏。

我很在意這點，是因為很多團隊評估 AI coding 工具時只看答案品質，沒看工作流成本。結果 demo 很漂亮，上線之後才發現它不懂 repo 結構、不懂權限邊界、也不懂你們公司那套奇怪的 merge 流程。這時候大家就會把問題怪到 prompt 身上，超省事，也超偷懶。

實操寫法：你要把「模型品質」跟「工作流適配」拆開評分。前者看補全、推理、重構能力；後者看它能不能讀懂你的專案、會不會亂問確認、會不會卡在權限。兩個分數都要有，少一個都很容易被 vendor 帶著跑。

• 同一個 prompt 丟三個工具，別只比答案，要比修改過程。
• 檢查它能不能講出你 repo 的實際結構，而不是空話。
• 記錄它有沒有過度要求授權或確認。

Teams 轉錄模型最陰，因為它會碰到一堆下游

PCMag 提到 Microsoft 還打算推出自己的 Teams 轉錄模型。這句話看起來很平，但我看到會皺眉。因為轉錄不是一個單點功能，它後面接的是搜尋、會議摘要、法遵留存、知識庫同步，甚至是客服紀錄。你一旦換模型，影響不是只有辨識率，還有整條下游。

也就是說，Microsoft 如果把轉錄模型收回來，它就同時握住語音辨識品質、延遲、語言支援、資料流向。這種控制力比一般人想得大很多。很多使用者會把轉錄當成基礎設施，覺得「能用就好」，但一旦它變成第一方模型，平台就能決定你看到什麼、存什麼、怎麼存。

我以前換過一次會議轉錄供應商，最痛的不是準確率，而是 timestamp 漂掉、speaker label 改掉、後面的摘要系統一起炸。那次之後我就不再把轉錄當成小事。它不是字幕功能，它是整個知識流程的入口。入口一改，後面全部跟著抖。

實操寫法：先把轉錄輸出的契約寫死。你需要哪些欄位、容忍多少錯誤、多久內要完成、哪些下游系統會吃這份資料，都先列清楚。這樣就算 Microsoft 偷偷換模型，你也能靠監測抓到，不會等使用者來罵。

Microsoft 想收回外部模型，因為控制權比模型名更值錢

站在平台方角度，這一步其實很好懂。每次 365 的任務跑去 ChatGPT 或 Claude，Microsoft 就少一點對成本、延遲、差異化的控制。把任務拉回自家模型，代表它可以自己調整體驗，也能把更多價值留在自己的堆疊裡。

這裡真正麻煩的是依賴關係。很多團隊會假設外部模型永遠可用、永遠是首選、永遠能插上去。這種假設在 demo 階段沒事，到了企業環境就很危險，因為你其實是在押一個你管不到的政策選擇。今天 Microsoft 想推自家模型，明天它就能把預設改掉，然後你只能配合。

我看過太多開發者只盯輸出品質，卻沒盯分發權。問題從來不只是「哪個模型比較聰明」，而是「誰握著預設路徑」。在 Microsoft 365 這種產品裡，預設就是權力。你不寫下來，它就會自己長歪。

實操寫法：把 AI 依賴分成三桶，第一方、第三方、使用者可自行切換。然後問一個很煩但很必要的問題：如果 Microsoft 明天改預設，哪個流程會先壞？先把那個流程補強。

• 把所有 AI 依賴畫成表，標示控制權歸屬。
• 標出哪些功能可以替換模型，哪些不行。
• 針對不能替換的功能，先寫退場方案。

別被模型名騙了，真正重要的是存取邊界

我一直覺得 AI 產品最愛玩的一招，就是把模型名講得很大聲，讓人以為自己懂了。其實沒有。模型叫什麼不重要，重要的是它能不能看你的私有文件、能不能讀 tenant 資料、能不能穿過權限、輸出有沒有被快取、管理員能不能關掉。這些才是企業裡真正會出事的地方。

換句話說，先問 boring 的問題，再問 shiny 的問題。資料從哪來？有沒有外網？是不是跟使用者同權限？輸出會不會留存？可以被稽核嗎？這些問題很無聊，但它們決定一個功能到底是能上線，還是只能在簡報裡活著。

我很少相信 demo，因為 demo 最會藏問題。真正的產品不是那個漂亮畫面，而是 permission boundary 和 routing logic。這兩個東西如果亂，模型再強也救不了。很多人把 AI 整合失敗怪在模型不夠聰明，我反而常看到是權限設計先爛掉。

實操寫法：替團隊做一頁式 AI policy，不要寫成十頁沒人看的內規。內容只要講清楚能用什麼、不能送什麼資料、誰能改預設、出了問題找誰。短一點，才真的有人看。

我會先盯這三件事，別等 Microsoft 幫你改流程

如果 Microsoft 繼續把更多功能塞進自家模型，我預期 365 裡會出現更多「看起來一樣、實際路徑不同」的 AI 功能。這對一般使用者可能只是少一點選擇，但對團隊來說，代表你要更早管理模型依賴，不然後面會被動得很難看。

我自己的建議很直接：不要等到 vendor 宣布切換政策，你才開始補文件。你應該現在就把模型變更測試、fallback、資料路徑、管理員控制寫進流程。這些東西不是策略簡報，是日常維運。你不寫，它就不存在。

我最後給你的判斷標準也很簡單：如果一個 AI 功能可以換模型，就把換模測試寫進 release checklist；如果不能換，就別假裝它是可插拔的。誠實一點，少很多麻煩。

實操寫法：把下面這份模板直接丟進你的團隊文件。它不是漂亮文件，但很耐用，夠你在 Microsoft 365 這種會默默改路徑的環境裡活下來。

可抄的模板

# Microsoft 365 AI model dependency checklist

## 1) Feature inventory
- App:
- Feature:
- Current model/provider:
- First-party or third-party:
- User can override default? (yes/no):

## 2) Data path
- Input data types allowed:
- Sensitive data allowed? (yes/no):
- Tenant-scoped access? (yes/no):
- External internet access? (yes/no):
- Retention/logging notes:

## 3) Output contract
- Required output format:
- Required accuracy threshold:
- Required latency threshold:
- Downstream systems affected:
- Known failure modes:

## 4) Fallback plan
- Primary model:
- Fallback model:
- Manual fallback process:
- Owner for incident response:
- Test schedule:

## 5) Change detection
- What will trigger a re-test?
- Who approves model changes?
- Where are changes documented?
- How do users report regressions?

## 6) Team policy
- Approved tools:
- Disallowed data types:
- Admin override rules:
- Review cadence:

## 7) Quick scorecard
- Output quality:
- Workflow fit:
- Permission clarity:
- Cost predictability:
- Vendor lock-in risk:

## Decision
- Keep as-is:
- Replace:
- Restrict:
- Re-evaluate on:

我自己會把這份表單放在部署文件旁邊，而不是埋進什麼 AI 戰略簡報。原因很簡單：真正會出事的不是策略，是日常切換。模型一換、權限一改、輸出一漂，整個團隊就開始互相怪。

來源我主要拆的是 PCMag 這篇：Microsoft 365 Apps Favoring Company's AI Models Over ChatGPT, Claude。文中的事實線索來自原報導，我的模板、判斷框架和實作建議是我自己整理出來的。