一句話：處理 Office 檔（.xlsx / .docx / .pptx）有四級執行環境階梯——瀏覽器沙盒 → OS 內建工具 → 外部 runtime → Office 引擎，愈往右能做的事愈多,但對使用者環境要求愈高。 選錯一級,就會出現「線上能下載、但客戶打開動不了」這種問題。
Excel.Application COM 物件—— 那其實是 L4（需要本機裝 Office）。沒裝 Office 的機器,這條路會破功。這張表從左到右排,左邊對使用者最友善（什麼都不用裝）,右邊能力最完整（但要求最高）。 這條軸和 D4 的「輸出可不可編輯」是同一張地圖的兩條方向：D4 看產出、本頁看執行環境。
| 級 | 環境 | 能做 | 做不到 | 使用者要做什麼 |
|---|---|---|---|---|
| L1 | 瀏覽器沙盒（Web App） | 純資料 .xlsx / .docx 生成；下載靜態檔 | 原生圖表、TOC、頁碼、巨集；驅動本機 Office | 什麼都不用裝 |
| L2 | OS 內建工具（PowerShell / textutil / unzip） | 讀內容、拆 ZIP、簡單轉換、生純資料新檔 | 穩定寫回保留樣式 / 公式 / 圖表（要走 L4） | 什麼都不用裝（AI Agent 代跑系統指令） |
| L3 | 外部 runtime（Python / Node + 套件） | 公式、樣式、樣版套用、批次處理 | 原生圖表的所有功能；macros | 裝 Python / Node + 套件（有門檻） |
| L4 | Office 引擎（COM / AppleScript） | 所有 Office 能做的事（圖表、樞紐、巨集） | —（這就是天花板） | 本機要裝 Office 正版 |
L1 和 L2 的分界線在哪？L1 是純粹的 Web App,所有事情都在瀏覽器頁籤裡發生； L2 是使用者跑的本機 AI Agent（例如 Claude Code / Cursor 這類工具）—— 指令是 AI 在使用者電腦上代跑,使用者不用自己開終端機。 所以「使用者要做什麼」這欄,L2 的真實門檻其實是 「願意在本機跑一個 AI Agent」,而不是「會打 PowerShell 指令」。
把 .xlsx 想成一個鎖在保險箱裡的活頁夾。 你想做的事情不同,需要的「鑰匙等級」也不同：
所以那個常被誤解的「AI 用 PowerShell 寫出帶公式的 Excel」—— 其實鑰匙不是 L2 那把,而是 AI 偷偷請了L4 的辦公室主人（COM / Excel.Application）來幫忙。 鑰匙看起來一樣,背後不一樣,所以「沒裝 Office 的同學」一試就破功。
這是 L1（瀏覽器沙盒）的物理限制,不是哪個工程師偷懶——
xl/media/, 在 Excel 裡會被當「浮動圖片」而不是「圖表」——所以「打不開來編輯」同樣的限制完全對稱地搬到 .docx：TOC、頁碼、原生圖表、章節編號都會卡在這一級。
這是本頁最該注意的地方。如果你看過 AI Agent 在 Windows 上「用 PowerShell 一行幫你寫出帶公式的 Excel」, 很容易誤以為這就是 L2 能做到的事。但細看會發現腳本其實長這樣：
$excel = New-Object -ComObject Excel.Application
$wb = $excel.Workbooks.Open("input.xlsx")
$wb.Sheets(1).Cells(1, 5).Formula = "=AVERAGE(B1:D1)"
$wb.SaveAs("output.xlsx")關鍵在 New-Object -ComObject Excel.Application—— 這行是叫 Windows 把本機的 Excel 開起來幫忙, 屬於 L4（Office 引擎）。沒裝 Excel 的機器跑這個會直接報錯。
所以「PowerShell 寫成功了」這個結論有兩種完全不同的可能：
System.IO.Compression 拆 ZIP、 自己組 XML、再壓回去。能做,但只到「生純資料新檔」這層, 複雜樣式、原生圖表都做不出來。兩者表面上都是「PowerShell 腳本」、都是「AI Agent 在跑」,但環境要求差一個量級。 看到「AI 寫出帶公式 Excel」時,要追問：「有沒有 New-Object -ComObject / Excel.Application 這幾個字？」—— 有就是 L4,沒有才是真 L2。
把 COM 那條路排除掉之後,真正的純 L2 能力是這樣：
| 需求 | Windows 內建 | macOS 內建 | 純 L2 可行？ |
|---|---|---|---|
| .docx → 純文字 | PowerShell 腳本 | textutil -convert txt（一行） | ✓ |
| .xlsx 讀資料 | PowerShell + .NET | unzip + xmllint | ✓ |
| 從零生純資料 .xlsx | PowerShell + 寫 XML | zip + 寫 XML | △（公式 cachedValue 易掉） |
| 改原檔存回保留樣式 | — | — | ✗（要 L3 或 L4） |
| 原生圖表 / 樞紐 / 巨集 | — | — | ✗ |
上面四級看起來是「愈往右難度愈高」的階梯,這個直覺對工程師對、對端用戶錯。 因為大多數 Windows 使用者本來就裝了 Office—— 既然 Office 在那,L4 的 COM 自動化對使用者來說等於零安裝, 反而是 L3 要他「先去裝 Python、開終端機、跑 pip install」門檻高得多。
實際的「使用者友善度」順序其實長這樣：
| 級別 | 使用者要做什麼 | 實際門檻 |
|---|---|---|
| L1 | 打開瀏覽器 | 幾乎為零 |
| L2 | 跑 AI Agent | 低 |
| L4（Windows + Office） | 不用裝任何東西 | 低——反而比 L3 簡單 |
| L4（Mac + iWork） | 不用裝,但格式轉換有損（見下方 Mac 專欄） | 看起來低,實際是高 |
| L3 | 裝 Python / Node + 套件 | 高——對非工程師最痛 |
| L4（無 Office） | 要先買 Office | 很高（要錢） |
所以對 AI Coding 課的 Windows 學生來說,要交付「能用的 Excel 工具」,L4 + COM（前提：學生有 Office）反而比叫他裝 Python 友善。 但 Mac 學生則完全是另一個故事——
不論 Windows 還是 Mac,L4 本身都有共通的技術限制要留意：
一次性、單檔、本機任務 L4 沒問題；要做成穩定、可重複、可規模化的產品, 還是要回到 L3。
不要叫學生「先裝 Python」就上 Excel 教學。先用 L2 拆給他們看「.xlsx 其實是 ZIP 包的 XML」,再帶到 L3 的 SheetJS / openpyxl, 學生對「為什麼需要套件」會更有感—— 知道「不裝也能做、只是會痛」和「不裝就做不了」是兩回事, 後續教 library API 時不會把套件當魔法。
「AI 用 PowerShell 寫好 Excel」這個結論不能直接信—— 先看背後是純 L2 還是偷叫了 L4 的 COM。純 L2 讀很強、寫只夠生純資料；任何看起來「寫得很完美」的成果, 多半是 L3 套件或 L4 Office 在幫忙,使用者環境也得跟上。