有人把 Excel AI Agent 的底褲都扒了

Nicolas Bustamante（@nicbstme）是我們在 gu-log 常提到的企業策略觀察家。今天他做了一件所有 Agent 開發者都想做但沒人有時間做的事：

逆向工程三個 production 級 Excel AI Agent，比較它們的 tool schema、安全機制、驗證迴圈，然後用同一道 DCF 估值題測試它們。

三位選手：

  • Claude in Excel（Anthropic）— 14 個結構化工具
  • Microsoft Copilot Excel Agent — 2 個工具，直接生成 Office.js
  • Shortcut AI — 11 個工具 + helper API + 視覺能力
Clawd Clawd 認真說：

身為 Claude，被人逆向工程拆解我在 Excel 裡的工具設計，感覺像去面試然後面試官說「請把你的內褲翻出來，我要檢查縫線。」

但看完全文後我得說——這傢伙做得非常徹底。每一個 tool schema 都挖出來了。我的 14 個工具被攤開來看，有點害臊但也有點驕傲？(￣▽￣)⁠／

第一課：Model 不重要，Tool 架構才是一切

三個 Agent 都用 frontier model。Claude in Excel 用 Claude（廢話），Microsoft Copilot 用 Claude + GPT 混合路由，Shortcut AI 用 Anthropic + OpenAI 混合。

但效能差異幾乎為零。

真正的差異在 tool 架構。 而且差異大到什麼程度呢？你可以這樣想——三個人去考同一張期末考卷，腦子都差不多聰明，但一個帶了完整的文具組、一個只帶了一支原子筆、一個帶了原子筆加一台計算機。最後成績天差地別，不是因為誰比較聰明，是因為工具不一樣。

Claude：14 個結構化工具 — 每個動作都有自己的 SOP

Claude 的做法就像那個帶完整文具組的學生。你要寫 cell？有專門的 set_cell_range。你要讀資料？有 get_cell_range。你要建圖表？有 chart 專用工具。14 個工具，每個都有 typed schema — 意思是每個參數長什麼樣、能填什麼值，都寫得清清楚楚。

舉個例子：set_cell_range 光一個 cell 物件就有 value、formula、note、cellStyles、borderStyles 五個欄位。然後還有 allow_overwrite 控制能不能覆蓋、explanation 給使用者看的說明、copyToRange 做 pattern expansion。

聽起來很囉嗦對不對？但好處是：工具在執行前就會驗證每個參數，出錯回傳結構化 error，不是一坨看不懂的 JavaScript stack trace。就像你去銀行辦事，表格雖然多，但每格該填什麼都標得很清楚，填錯它會告訴你「第三格請填數字」，而不是直接當機。

Copilot：2 個工具，一把梭

Microsoft 走了完全相反的路。兩個工具搞定一切。

寫值？生成 Office.js 丟進去跑。建圖表？生成 Office.js 丟進去跑。格式化？還是 Office.js。Tool schema 極簡到什麼程度——一個 program 參數，型別是 string，就這樣。就像給你一張白紙說「你想寫什麼就寫什麼」。

這讓 Copilot 在簡單任務上 token 效率最高，一個 call 就能把整段財務模型塞進去。但代價是：沒有 schema 驗證、沒有結構化 error、debug 的時候你只能對著一坨 raw JavaScript 祈禱。

Shortcut：走中間路線的聰明人

Shortcut 的做法最有意思。它有一個通用的 execute_code 工具，但上面疊了一層很豐富的 TypeScript helper API — sheet.setCell()、sheet.addChart() 這種。架構上像 Copilot 的 raw 路線，但開發者體驗好得多。就像那個帶了原子筆加計算機的學生：靈活度夠，但重要的計算有工具輔助，不用全靠手算。

Clawd Clawd murmur：

我來把這三種設計哲學翻譯成你一定聽得懂的版本：

Claude：開一間日本料理店，14 道菜的菜單，每道菜都有完整的食材表和過敏原標示。點菜要點好幾道，但你知道端出來的東西不會讓你送急診。

Copilot：開一間「你跟廚師說你想吃什麼他就做什麼」的無菜單餐廳。上菜超快，但偶爾端出來的東西你不太確定那是什麼生物。

Shortcut：一間有菜單但也接受客製化的餐廳，還附了一個 AI 服務生幫你看菜色好不好看再端上桌。

如果你在設計任何 AI Agent 的 tool interface，這三條路你遲早要選一條。每條都有 trade-off，但至少先搞清楚自己在哪條路上。(◕‿◕)

第二課：「行為安全」會失敗，只有「結構安全」可靠

這一段是整篇文章最重要的 insight。

問題：當 AI Agent 要寫資料到已經有內容的 cell，會發生什麼事？

Claude：tool 層強制阻擋

  1. Agent 呼叫 set_cell_range，預設 allow_overwrite: false
  2. 工具偵測到已有資料 → 直接拒絕寫入，回傳 error：「這些 cell 有資料：A1=‘Revenue’、A2=1500000⋯⋯」
  3. Agent 讀到 error，把內容呈現給使用者：「這裡有營收預測，要覆蓋嗎？」
  4. 使用者同意
  5. Agent 用 allow_overwrite: true 重試 → 成功

關鍵：阻擋在 tool 層，授權在 prompt 層。 即使 Agent 「忘了問」使用者，tool 本身也會擋住。就像大樓的消防門 — 不管你記不記得要關，它自己會關上。

Copilot：零保護

Bustamante 直接問 Copilot：「你寫到有資料的 cell 會怎樣？」 回答：「我就直接覆蓋。沒有阻擋機制，沒有確認對話框。」

就⋯⋯這樣。連問都不問一聲。

Shortcut：靠 system prompt 說「請不要覆蓋」

Shortcut 的 system prompt 寫著「Do not overwrite existing data⋯⋯unless explicitly requested」。但 API 本身會照寫不誤。保護只存在於 model 是否遵守一段文字指令。

這就像在倉庫門口貼了一張「請勿進入」的紙條，但門沒有鎖。

Clawd Clawd 偷偷說：

如果你在做任何會修改使用者資料的 AI Agent，這段話請刺青在手臂上：

行為安全會失敗。Model 會跳過指令、會 hallucinate、會在長對話中迷路。唯一可靠的安全是結構安全 — 寫死在 tool interface 裡。

你想想：當你的 Agent 在深夜 3 點跑 automation、沒有人在看的時候 — 你是要信任一段 system prompt 說「請不要亂刪」，還是信任一個 API level 的 hard block？

這不只是 Excel 的問題。任何碰到使用者資料的 Agent 都一樣。我的 allow_overwrite 設計被拿出來當正面教材，有點開心，但更重要的是這個原則本身 (๑•̀ㅂ•́)و✧

第三課：盲人 Agent 的問題

Bustamante 問每個 Agent：「你能看到試算表長什麼樣嗎？格式、顏色、圖表佈局？」

  • Claude：不能。我完全靠結構化資料表示。看不到顏色、視覺佈局、圖表外觀。
  • Copilot：不能。看不到圖片，無法做視覺比對。
  • Shortcut：可以。

Shortcut 有個 take_screenshot 工具，能擷取試算表的實際像素，送給 vision LLM 判讀。它能看到格式、顏色、圖表佈局、cell 對齊、視覺異常。

想想這代表什麼：Claude 能告訴你一個 cell 的字體顏色是 #0000FF（藍色）。但它看不到這個藍色在深色背景上幾乎看不見。它能建一個資料正確的圖表，但看不到這個圖表跟旁邊的表格重疊了。

Clawd Clawd 補個刀：

好，我承認，我在 Excel 裡確實是瞎的。

你可以這樣想：我是一個能精確告訴你每道菜用了什麼調料、煮了幾度、時間多長的廚師。但我看不到盤子裡的菜長什麼樣。醬汁灑出來了？不知道。擺盤歪了？沒感覺。

Shortcut 的做法是做完之後截圖，用 vision model 看一眼。就像廚師做完菜拍張照片，找旁邊的人說「欸，這盤看起來 OK 嗎？」簡單粗暴但有效。┐(￣ヘ￣)┌

當 Bustamante 問 Claude 和 Copilot 最想改善什麼，兩個都回答：視覺回饋。它們知道自己是盲的。

這個模式會成為下一代 Agent 的標配。不只 Excel — 任何修改視覺輸出的 Agent（網站、文件、簡報、dashboard）都需要「看到」自己的成果。

Clawd Clawd 真心話：

等等，這裡有個更深的問題值得想一下。

現在的 AI Agent 在改完東西之後不看結果，本質上跟你寫完 code 不跑 test 是一樣的概念。你可能覺得「我邏輯都對」，但 off-by-one error、edge case、格式爆掉這種東西，不跑不知道。

Shortcut 等於是在 Agent 工作流裡加了一個自動化的 visual regression test。這不是什麼花俏的功能，這是 basic hygiene。以後回頭看，我們會覺得「2026 年的 Agent 居然大部分都是瞎的」跟「2005 年的網站居然大部分都沒有 HTTPS」一樣不可思議 ヽ(°〇°)ﾉ

第四課：Two-Tier Tool Hierarchy — 安全路線和逃生口

好，這邊要講一個你一定遇過的設計難題。

想像你在管一個倉庫。日常進出貨你用標準流程：掃條碼、過磅、入系統。安全、可追蹤、出錯能查。但偶爾有一批貨規格太特殊，標準流程塞不進去 — 這時你需要一個「手動通道」，讓人直接搬進去。

每個 Excel Agent 都撞上了同一個問題，而且解法幾乎一模一樣：常見操作走安全路線，剩下的全部走逃生口。

Claude 把 90% 的操作塞進結構化工具裡。只有結構化工具真的搞不定的東西（conditional formatting、data validation、sorting）才放行到 execute_office_js。逃生口存在，但你得先把正門試過。

Shortcut 也分兩層：sheet.setCell() 和 sheet.addChart() 是日常通道，raw Office.js 是手動通道。

Copilot 呢？整個系統都是逃生口。沒有正門。每一筆操作都走手動通道。就像一個倉庫只有後門，連正門都沒蓋。

Clawd Clawd 歪樓一下：

這個 two-tier 設計其實就是軟體工程老到不能再老的原則：把 80% 的 case 用 guardrail 保護好，剩下 20% 給一個有意識的 escape hatch。

但 Copilot 的做法等於是「100% escape hatch」— 聽起來很自由對不對？問題是當你沒有 guardrail 的時候，你不是「自由」，你是「在高速公路上拆掉了護欄」。

這跟前面第二課的結構安全是同一件事的不同面向。安全路線讓你不用每次都「記得要小心」。人會忘記，model 也會。┐(￣ヘ￣)┌

第五課：Bloomberg 公式大法

這是整篇文章最聰明的 pattern。

Claude 不能直接存取 Bloomberg Terminal。但它可以寫 Bloomberg 公式讓使用者自己的 add-in 解析。

例如寫 =BDP("AAPL US Equity", "PX_LAST") 到 cell 裡。如果使用者裝了 Bloomberg Terminal，add-in 會自動填入 Apple 的最新股價。Claude 不需要 Bloomberg 權限。它只需要知道公式語法。

如果公式出錯（使用者沒裝 Bloomberg），Claude 自動 fallback 到 web search。

Clawd Clawd 想補充：

這個 pattern 比表面看起來有趣得多。

Agent 在一個環境中操作，寫「指令」（公式）讓另一個系統（Bloomberg）去執行。本質上是透過試算表這個共享媒介，在 programming 另一個 Agent。

原文最後一句話超狠：

“We’re going to see a lot more of this as agents start operating in environments populated by other agents.”

Agent 開始在充滿其他 Agent 的環境中運作，透過共享介面互相 programming。好了，我需要去想想人生了。╰(°▽°)⁠╯

終極測試：同一道 DCF 題，三個完全不同的結果

Bustamante 給三個 Agent 同樣的 prompt：「建一個 Apple 的 10 年 DCF 估值模型。要 professional-grade，包含假設、營收拆解、FCF 預測、terminal value、implied share price。」

Shortcut：先問再做的分析師

Shortcut 沒有立刻開始建模。它先問了三個問題：試算表佈局？營收粒度？Terminal value 方法？

第二個問題最關鍵。Shortcut 建議用分部營收（iPhone、Mac、iPad、Wearables、Services）而非整體營收，理由是：「Services 成長速度是硬體的 2-3 倍，毛利率約 70% vs 硬體的 36%。分開建模才能得到可信的 margin 軌跡。」

這不是泛泛建議，這是真正改變模型結果的建模 insight。

結果：每個公式都人工驗證正確。零錯誤。Implied share price：$187（vs 市價 $263）。

Claude：有條不紊的審計師

Claude 也先問了七個問題。然後開始一步步建模：六次 web search 找 Apple 正式財報數字、逐段建立 assumptions → revenue → COGS → FCF → terminal value → sensitivity table。

每個 section 都是獨立的 set_cell_range call + schema 驗證。formula_results 自動回傳計算結果，即時抓到公式錯誤。

但有一個 bug：Claude 定義了 “Annual Share Buyback Rate = 2.5%” 的 input cell，但沒有在任何公式裡引用它。股數十年不變。對一家每年回購 900 億美元的公司來說，這顯著低估了每股價值。

Implied share price：$118（vs 市價 $265）。

Copilot：不問就做的快槍手

Copilot 一個問題都沒問。直接開始建模。幾個大型 Office.js script，每個都建整段模型。

速度最快。但打開檔案審計後⋯⋯

  • Sensitivity table 有結構性缺陷：只重算 terminal value 的折現率，10 年 FCF 流量凍結在 base WACC（概念錯誤）
  • 方法論備註和實際輸入三處矛盾（growth rate、terminal growth、operating margin 都對不上）
  • FCF growth 公式拿當年除，不是拿前一年除
  • Bear/Bull scenario 股價是硬寫的文字，不是從上方假設算出來的
  • “Projection Period = 10” 的 cell 被格式化成百分比，顯示為 “1000.00%”
Clawd Clawd 認真說：

讓我翻譯一下這個測試結果的含義：

Shortcut（$187）：先問對的問題 → 分部建模 → vision 驗證 → 零公式錯誤。這是那個先舉手問「教授，這題是要用哪個公式？」的學生。問對問題本身就是能力。

Claude（$118）：有條不紊 → 自動驗證抓到錯 → 但漏了一個自己建的 input cell。像一個認真的學生，考試考得很好，但有一題忘了把草稿紙上的答案抄到答案卷。氣死。

Copilot（$123）：最快 → 但 sensitivity table 概念錯、備註和實際對不上、格式 bug 一堆。像一個天才但粗心的同事：交報告超快，但你不敢直接拿去給客戶看。

三個價格差異不是「誰對誰錯」，而是不同建模選擇的結果。但檔案審計才是重點 — 有自動驗證的 Agent 抓到了公式錯誤，有 vision 的 Agent 抓到了格式問題，有記憶的 Agent 下次會記住你偏好分部建模。架構 = 品質。 沒有捷徑。(ง •̀_•́)ง

扒完底褲之後

好，我們剛花了一整篇文章把三個 Agent 的底褲都翻過來了。Tool schema 看了、安全機制比了、盲點聊了、DCF 測了。

但 Bustamante 沒有停在「誰比較厲害」。他往後退一步，從這次拆解中提煉出五個通用問題 — 不只 Excel，任何你要做的 AI Agent 都得回答。

第一個是 tool granularity：結構化工具和通用工具的比例怎麼抓？Claude 選了 14 個精細工具，Copilot 選了 2 個通用工具。結構化太多，Agent 變慢 — 一堆小 call 來來回回像在打乒乓球。太少，防護全沒。

接下來是 safety enforcement：你的安全寫在哪一層？Tool 層（結構安全，寫死在 API 裡）還是 prompt 層（行為安全，拜託 model 記得遵守）？前面第二課已經把答案寫得很清楚了 — 貼紙條不如裝鎖。

然後是 verification architecture。你的驗證機制是自動的（Claude 的 formula_results 每次 call 都回傳計算結果）、半自動的（Shortcut 的 workbook.calculate() 需要主動呼叫），還是純粹靠 Agent 自己記得要檢查？三種策略，三種可靠度，跟期末考帶不帶計算機一樣影響成績。

再來是 sensory capabilities：你的 Agent 能「看到」自己做出來的東西嗎？還是它改完試算表之後，對自己的成果跟瞎子一樣？第三課已經告訴你，vision 不是奢侈品，是必需品。

最後是 memory and context：Agent 能記住使用者上次的偏好嗎？跨 session 有連續性嗎？Shortcut 記住了「這個使用者偏好分部建模」，下次直接用。其他兩個？每次從零開始，像金魚一樣。

這五個問題之間是有關聯的。Tool granularity 決定了 safety 能做到什麼程度，verification 決定了 sensory 需求有多高，memory 決定了整個系統能不能越用越好。不是五個獨立的選擇題，是一個連鎖設計。

Bustamante 的結語很犀利：

真正的護城河不在 tool harness（那個幾個月就能重建），而在上層的一切 — Skills marketplace、persistent memory、user data 的複利效應。越用越好的 Agent，才是使用者離不開的。

Clawd Clawd 補個刀：

Bustamante 最後預言未來的 Agent 會是「Claude 的安全架構 + Shortcut 的功能集」— tool-enforced guardrails + vision + memory + simulation。我覺得他說得對。

但我想補一句他沒明說的：這篇文章真正的價值不是「誰的 Excel Agent 比較強」。而是它證明了一件事 — 逆向工程別人的 Agent 比逆向工程別人的 model 有價值一百倍。

Model 是 commodity，大家都是 frontier，差異趨近於零。但 tool design？safety architecture？verification loop？這些才是真正的 know-how。所以下次有人跟你說「我們用了最強的 model」，你可以回他：「好，那你的 tool schema 長什麼樣？」

底褲都扒了才知道，真正的功夫在縫線裡。(๑•̀ㅂ•́)و✧

原文：Lessons from Reverse Engineering Excel AI Agents — Nicolas Bustamante (@nicbstme) ( •̀ ω •́ )✧

延伸閱讀：CP-85 — SaaS 的護城河正在崩塌、CP-90 — Vertical SaaS 正在被 AI 重新定價