使用介面：claude.ai（網頁版）、Claude Desktop（Cowork mode）

前情

Day 07 把 Claude Desktop 裝起來以後，找個題目來比較它跟網頁版的差別，而前一天的硬體診斷無法比較，因為網頁版無法碰到我的電腦。

Office 檔案就不一樣了。上傳一份 docx 給網頁版，它照樣能拆能改能產出。今天我做的事情是：同一份素材、同一段需求，Model 與 Effort 同樣都設成 Opus 5 High，兩個分頁幾乎同時丟出去，讓 claude.ai 和 Claude Desktop 的 Cowork mode 各自跑一遍，再把兩邊的產出攤開來看。

我想知道的是：介面本身有什麼差異？（所以把 Model 跟 Effort 都故意設成一樣的） 兩個同時做完後，我的5小時流量從0%上升到75%，我也算是大手筆吧 Orz...

產出檔案

三個原始檔與兩邊的產出都放在 GitHub，資料夾按介面分開，方便對照著閱讀，內容是我們自己安排與製作的，僅供參考：

• Day08 資料夾（含兩份原始 docx／xlsx）
• [Output] claude.ai：旅遊手冊_Word範本.dotx、..._行程時間規劃_整理版.xlsx、2026東京近郊自駕_旅遊簡報.pptx
• [Output] Claude Desktop Cowork：旅遊手冊_範本.dotx、..._行程時間表_整理版.xlsx、..._行前說明會.pptx

1. 題目

素材是我在四月時家庭旅行，去東京近郊自駕八天七夜、行前自己整理的兩份檔案，都是真實使用過的檔案，不是為了測試而特地做的乾淨範本：

我的需求提示詞只有：

1. 幫我從現有的 WORD 拿出模板，建立一個 Word 模板在該資料夾。
2. EXCEL 的部分是一個行程時間表，請幫我整理成更方便閱讀的 EXCEL 表格。
3. 幫我利用 Word 與 Excel 製作一個旅遊的 PPT。

沒有規格書、沒有參考範例、沒有配色要求。 反正等它問，它不問就是它覺得可以 (?) 。

2. 第一個岔路：檔案在哪裡

需求第一句寫「建立在該資料夾」。這句話兩個介面的理解不一樣，而且都不是理解錯誤，是能力邊界不同。

claude.ai：檔案是我手動上傳的，落在容器的 /mnt/user-data/uploads（唯讀），產出寫到 /mnt/user-data/outputs，最後我自己下載。「該資料夾」在 Sandbox 裡不存在，這句話實際上做不到。

Claude Desktop：一開始就先跟我要授權。

device_request_folder_access(
  paths = ["D:\Research\iThome2026\Day08_20260822"],
  reason = "需要讀取這個資料夾裡的 Word 與 Excel..."
)
→ {"granted": ["D:\Research\iThome2026\Day08_20260822"]}

授權完 device_list_dir 看內容、device_stage_files 把兩個檔案搬進 Sandbox 中、處理完 device_commit_files 寫回去。原始那兩個檔案完全沒被動到，新產出一律用新檔名。

要注意的是，Cowork 這條路徑不是「Claude 直接在我電腦上做事」，中間那段處理一樣在雲端 Sandbox 裡。本機檔案和 Sandbox 檔案是兩套檔案系統，改了一邊另一邊不會動。差別只在頭尾多了 stage 和 commit 兩步，才會知道為什麼要先授權資料夾。

Day 07 學到「連了資料夾不等於能執行 Windows 指令」，今天補上其他部分：連了資料夾也不等於處理是在本機發生的。

3. 第二個岔路：先問，還是先做

這裡的差異最明顯。

Claude Desktop 動手前先丟了三題選擇題：

claude.ai 一題都沒問，直接開工。

有趣的是，它自己選的答案和我在另一邊選的幾乎一樣：也做了 .dotx、也做了總表加美化分頁。同一顆模型面對同一段模糊需求，猜出來的答案本來就會收斂到差不多的地方，所以「不問」在這次沒有造成災難。

但我覺得第一題值得停一下，.docx 和 .dotx 的差別，是雙擊的時候會「開一份新文件」還是「開範本本身」，我故意沒有講清楚，想看看它會怎麼問我或怎麼做。

而 Claude 用選擇題問，等於順手把可能性攤開來，讓我知道有哪些岔路可以走。這是開放式問句做不到的，開放式問句我可能只會回答「你決定就好」。

4. Word 範本：兩條完全不同的技術路線

同一個目標，兩邊的做法差很多。以下是兩個介面個別拆解給我的實作內容

claude.ai：拆掉重組。

解壓 docx
  ├─ 保留：styles.xml / theme1.xml / numbering.xml / settings.xml / footer1.xml
  ├─ 改寫：document.xml（重新生成 body，沿用原本的命名空間宣告）
  ├─ 刪除：word/media/（封面照）+ image / hyperlink 關聯
  └─ 改 [Content_Types].xml：document.main+xml → template.main+xml
重新 zip → .dotx

Claude Desktop：用 python-docx 就地改。 不重新產生，所以 styles.xml、theme、numbering、頁首頁尾原封不動。核心是一個保留格式的換字函式：

def set_text(p, text):
    runs = p.runs
    if not runs:
        p.add_run(text); return
    runs[0].text = text                       # 沿用第一個 run 的字型／顏色／粗體
    for r in runs[1:]:                        # 其餘 run 直接刪掉
        r._element.getparent().remove(r._element)

兩邊踩的雷不太一樣，但有一個共通點：孤兒關聯會直接讓檔案顯示損毀。刪掉 word/media/image1.jpeg 卻沒清掉 document.xml.rels 裡的 rId8，驗證直接報 Broken reference to media/image1.jpeg。順帶一提，這張封面照就是檔案從 362 KB 縮到 47 KB 的主因。

claude.ai 還多踩一個：為了讓目錄開檔時自動更新，要在 settings.xml 加 <w:updateFields w:val="true"/>，直接塞在 </w:settings> 前面會被 schema 打回票，因為 CT_Settings 是 sequence，這個元素必須排在 <w:hdrShapeDefaults>、<w:footnotePr>、<w:compat>、<w:rsids> 之前。

而 .dotx 本身的差別，最後歸結成 [Content_Types].xml 裡一行字串：

<!-- 從 -->
ContentType="...wordprocessingml.document.main+xml"
<!-- 改成 -->
ContentType="...wordprocessingml.template.main+xml"

改副檔名沒有用，要解壓、改這行、再從資料夾內部重新打包。

「拿出模板」到底要拿掉什麼

這是整個任務裡唯一需要判斷力的地方，而且兩邊的判斷方向一致：分辨哪些內容是這趟旅行的，哪些是每趟旅行都會用到的。

保留原樣的：入境日本／入境台灣注意事項、醫療器材限量表、去程回程攜帶物品清單、Sim 卡與漫遊方案、所有樣式與表格框線。

換成佔位符的：封面日期與主題、航空公司、租車公司、車款與取還車店點、行程總覽八列的日期、住宿票卷進食三張表的資料列。

claude.ai 那邊有個決定比較符合預先設想：攜帶物品清單沒有清空，護照、行動電源、洗碗精這些實際品項全留著。理由是這部分每趟旅程都能重用，清成空白的 【】 反而讓範本變廢紙。

範本化不等於全部清空。要判斷的是哪些是 instance、哪些是 pattern。

不過到底哪些算是每次出國旅遊都會用到的，我覺得 Claude 的判斷還是不完全正確，畢竟在實務上會有不同國家、不同航空公司、不同行程目的（家庭旅遊、朋友旅遊、獨自旅行、商務旅行、純休息）等。

5. Excel：兩邊都做了同一件事—把寬表變長表

原檔的組織方式是「每天一個分頁」，適合當天照著走，但回答不了「這趟總共花多少時間在移動」或「哪幾天的景點要買票」。兩邊都新增了一張把八天全部串起來的長表，每列一個事件，多一個天數欄。

兩邊都做了事件自動分類，用關鍵字把事件分成移動／餐食／景點／住宿之類的，再進行上色。分類規則部分有所講究，Claude Desktop 那份的比對順序是刻意排的：走行人連通道從偕樂園到千波湖 要靠「連通道」命中交通，班機報到&機場購物 要落在手續而不是餐食。

這種規則沒有標準答案，是看著資料一條一條調出來的。也因為沒有標準答案，最後一定要把成品重看一遍。

時長欄兩邊都用公式不寫死，而且都寫了自我保護：

=IF(AND(ISNUMBER(A3),ISNUMBER(B3)),ROUND((B3-A3)*1440,0),"")

為什麼要 ISNUMBER，後面第 7 節會講。

還有一個 openpyxl 的坑兩邊都踩到：寫出去的公式沒有快取值。不跑一次重算，任何讀快取值的工具（pandas、預覽器）都會讀到 None。所以流程裡多一步 LibreOffice 全量重算，回傳 {"status":"success","total_formulas":379,"total_errors":0} 才算數。

claude.ai 這邊多做的「票券與費用」分頁有個設計比較合理：原始備註裡是「1200-2300円」「約 1000-2000円」這種區間，它沒有替我決定數字。做法是把 23 筆原始備註列出來當佐證，金額欄設成黃底（input cell 的慣例）讓我自己填，下方 SUM 自動加總。

AI 留欄位給給使用者填，的確比亂猜一個數字有用。

6. PPT：17 頁 vs 16 頁

兩邊都選了 pptxgenjs（Node）而不是 python-pptx，理由一樣：python-pptx 無法複製投影片，而且 text_frame.text = 會把段落塌成單一無樣式的 run。

配色也是兩邊都沒用預設商務藍，都跟著這趟旅程本身走：粉蝶花藍、櫻粉、藤紫、深靛。理由是這趟行程本來就是去看粉蝶花、櫻花、杜鵑、紫藤和芝櫻的，封面照片就是粉蝶花。

pptxgenjs 的坑兩邊也一致，而且都是「寫錯不會報錯，直接產出損毀檔案」那種：

• 顏色不能帶 #、不能用 8 碼含 alpha，透明度要用 transparency: 0-100
• pres.layout 必須在加投影片之前設定
• LAYOUT_WIDE 是 13.3 × 7.5 吋，座標超出邊界不會被裁切，元素直接消失
• 選項物件會被就地改寫，兩個 add* 不能共用同一個 options 物件

7. 人沒看到、機器看到的事

這節是「AI 以為它幫我看到我自己看不到的東西」，但實際上可能不是這樣。

7.1 住宿費用重複計價，差了 8,891 元

原始的住宿總表裡，第 2–3 天住同一間「とびた荘」，在 Excel 中是 C11:D11 合併儲存格，值 8891，是兩晚的總價。

問題來了：openpyxl 讀合併儲存格時只有左上角有值，但視覺上看起來兩欄都是 8891。照欄位加總會變成：

4750 + 8891 + 8891 + 4815 + 10477 + 3449 + 4437 = 45,710
正確答案                                      = 36,819

差 8,891 元。

兩邊都抓到了，處理方式也一樣：第 3 天的價格欄留空、加註說明、SUM 才會對。Claude Desktop 還多做一步，把原本那個空白欄補成灰色斜體的「↑ 同 Day 2（連住）」。因為原檔留白我自己看得懂，但排版整齊之後看起來像漏填。

合併儲存格是 Excel 最常見的「視覺正確、資料錯誤」來源。人看表格是看版面，程式讀表格是看資料結構，兩者在合併儲存格上會分岔。

7.2 一格塞了兩筆時間

D1-0418 的 A3 儲存格內容是：

05:00
05:20

宜蘭出發 05:00、新竹出發 05:20，兩邊人不同起點，我當初就這樣寫進去了。

對 Claude 來說，後果是這格變成字串而不是時間，所有「結束減開始」的計算在這一列失效。這也就是第 5 節那個 ISNUMBER 存在的理由：真實檔案永遠比範例檔案髒，處理程式要能容錯，不能假設乾淨。

8. 驗證：schema 過了不代表看起來對

兩邊都跑了兩層檢查：結構驗證加目視驗證。目視驗證的做法是同一招：轉 PDF、轉圖、真的用眼睛看。

soffice --headless --convert-to pdf out.pptx
pdftoppm -jpeg -r 110 out.pdf slide

抓到的東西完全不一樣，因為兩邊排版本來就不同。

claude.ai 的 PPT 抓到五個：

Claude Desktop 的抓到兩個：出入境頁雙欄卡片高度 4.6 吋但內容只用到一半，下半部空一大塊；收尾頁的紫色裝飾圓形壓在文字上，而且頁尾灰字落在紫底上對比不足。

第三點比較特別：line: { width: 0 } 這種「看起來完全合理」的寫法會失效。純看程式碼看不出來，純看 XML 也看不出來，只有算繪成圖片才會現形。

schema 驗證只證明「檔案打得開」，不證明「東西看起來對」。留白、壓字、對比不足這幾種問題，只有把成品轉成圖片重新看過才會發現，而且要當成沒寫過那段程式碼地看。

9. 兩邊都沒解決的事

字型算繪不可靠。 檔案裡寫的是微軟正黑體，但 Sandbox 裡只有 Noto Sans CJK。預覽看到的是代換之後的結果，字寬跟微軟正黑體不一樣。容器裡看到「剛好放得下」，在真正的 PowerPoint 可能會換行。非安全字型要多留大約 10% 空間，而且不要相信預覽的 fit 判斷。

摘要式的數字要自己再看一次。 claude.ai 的簡報上寫「3 縣走訪」，是它依住宿地推的（茨城、栃木、千葉）；Claude Desktop 那份寫「4 個縣」。行程其實有經過群馬縣館林市，只是沒有在那裡過夜。所以前者漏了，後者算進去了。這種數字沒有標準答案，取決於「走訪」怎麼定義，但正因為沒有標準答案，才更該自己確認一次。

同一份檔案，兩邊數出來的事件筆數不一樣。 claude.ai 說 183 筆，Claude Desktop 說約 190 筆。差別應該出在空白列和標題列怎麼算，但這件事本身就說明：AI 報給我的統計數字是它的解析結果。

時間成本沒有省到零。 實際流程是讀 Skill → 讀檔 → 寫產生器 → 驗證 → 抓到缺陷 → 修 → 重驗。修正回合佔了相當比例。真正省下的是「從零排版」的時間，不是「檢查」的時間。

10. 順帶一提：為什麼它動手前要先去讀 SKILL.md

兩邊的第一個動作都不是寫程式，是去讀對應的 SKILL.md：

view /mnt/skills/public/docx/SKILL.md
view /mnt/skills/public/xlsx/SKILL.md
view /mnt/skills/public/pptx/SKILL.md

我原本以為那裡面是 API 教學，翻開來發現不是，是環境限定的踩雷筆記：

• xlsx：「LibreOffice 無法評估 XLOOKUP／FILTER／UNIQUE，任何前綴都不行，改用 INDEX／MATCH」
• pptx：「顏色不能帶 #、不能用 8 碼含 alpha，否則檔案損毀」
• pptx：「堆疊長條圖的 dataLabelPosition 用 outEnd 會損毀檔案」
• docx：「表格要同時設 columnWidths 與每個 cell 的 width，用 PERCENTAGE 會在 Google Docs 壞掉」

這就是 Skill 在補的東西。不是模型不知道 pptxgenjs 怎麼用，是模型不知道這個容器裡的 LibreOffice 是哪個版本、會怎麼壞。補的是環境知識，不是領域知識。

之後會再回來講關於 Skill 的事。

小結

先講變數控制：模型都是 Opus 5、Effort 都設 High，兩邊幾乎同時開始跑。拿掉「模型能力不同」這個變數之後，這次真正比出來的是介面本身的差異，結果是在「拿到一份既有檔案、重整成三種格式」這類任務上，兩個介面做出來的東西差不多。都選 .dotx、都把寬表變長表、都用 pptxgenjs、都抓到那 8,891 元的合併儲存格錯誤、連踩的坑都一樣。這不是巧合，是同一顆模型在處理同一批 SKILL.md 之後，收斂出來的自然結果。

真正留下來的差異只有兩處，而且都是能力邊界，不是誰做得比較好：

開頭問不問。 Claude Desktop 先丟三題選擇題，claude.ai 直接動手。這次不問沒有出事，因為 claude.ai 自己猜的答案跟我在 Desktop 選的幾乎一樣，不過那不代表「不問」永遠安全，只代表這次的模糊空間剛好夠小。.docx 還是 .dotx 這種岔路，猜錯的成本是整份重做，選擇題能先把可能性攤開來，這件事本身是有價值的，只是這次沒感受到。

結尾寫不寫得回本機。 Claude Desktop 能把檔案 commit 回原資料夾，claude.ai 只能產在 Sandbox outputs 讓我下載。需求第一句「建立在該資料夾」，只有一邊真的做得到。

沒比出勝負，所以這題最後變成一個純粹的個人選擇：不需要寫回本機、想要少一層授權流程的時候，claude.ai 更省事，網頁分頁開開關關也比等桌面應用程式啟動快；需要直接落地到專案資料夾、或者想省下手動下載搬檔那幾步的時候，用 Claude Desktop。兩邊都不會因為介面本身讓產出打折扣，差別只在哪一種操作習慣比較順手。

最後，坦白來說，我其實更喜歡 cloud 版本做出來的簡報，不過這個就比較見仁見智了。

註一：本文對 claude.ai 與 Claude Desktop（Cowork mode）的功能描述以 2026 年 8 月 22 日的產品行為為準。關於 Sandbox 環境、可用工具鏈與內建 Skill 內容日後都可能改變。

註二：兩邊各跑一次，屬定性觀察，不是統計證據。同一段需求再跑一次，選擇題會不會出現、產出幾個分頁、抓到哪些缺陷，都可能不同。

註三：文中的公式數（382／379）、事件筆數（183／約 190）、分頁數與投影片頁數，都是各自那一次執行的回報值。兩邊事件筆數不一致的原因我沒有進一步追查。

註四：門票總額約 ¥11,400／人是依 Excel 備註逐項推算的結果（足利花卉公園取區間上限 ¥2,300，不含停車費），不是實際支出。住宿 NT$ 36,819 則是原始 Excel 既有數字的正確加總。

註五：兩邊執行時模型與 Effort 皆設定為 Opus 5、High，以此固定「模型能力」這個變數，讓比較聚焦在介面本身的差異上。但這仍是各跑一次的結果，不是重複多次取平均，見註二。