串接 MCP 協定！OfficeCLI 讓 Claude Desktop 直接修改 Word 文件，實戰教學

從「複製貼上」到「一句話完成」：AI 編輯 Word 的現實困境

過去幾年，大型語言模型（LLM）的爆發讓許多人相信「一句話就能搞定一切」的時代即將來臨。使用者幻想著對 AI 說：「把這份季報的第三段改寫成更專業的語氣，並將表格置中、字型改為標楷體。」然後瞬間獲得一份格式完美的 Word 檔案。然而，現實往往令人失望——多數 AI 助理的回應是一段沒有格式的純文字，或是一份需要你手動「複製貼上」才能保留原樣的回覆。為什麼看似簡單的編輯指令，對 AI 來說卻如此困難？這背後涉及三個核心結構性障礙。

障礙一：AI 缺乏「排版認知」能力

人類在閱讀 Word 文件時，能瞬間辨識標題、內文、表格、頁首頁尾等不同區塊的視覺層次與結構。但傳統 AI 模型（即使是多模態模型）擅長的是理解語意脈絡，而非文件物件的精確定位。當你要求 AI「把第二個圖表移到第四段下方」，它需要知道「第二個圖表」在文件中的絕對或相對位置，以及「第四段」的邊界在哪裡。多數 API 傳送給 AI 的只是純文字或經過簡化處理的 Markdown，完全失去了原始版面資訊：字型大小、段前段後間距、表格框線顏色、圖文繞排方式……這些排版細節全部遺失。結果就是 AI 產出的文字雖然語意正確，但一旦貼回 Word，版面立即崩潰，使用者必須花更多時間手動調整。

障礙二：無法保留格式的「複製貼上」惡夢

目前最常見的 AI 輔助寫作流程是：使用者從 Word 複製文字到 AI 聊天視窗 → AI 回覆修改後的文字 → 使用者再手動貼回 Word，並重新設定格式。這個流程不僅耗時，而且極易出錯。根據一篇 2025 年的實測報告（Format Loss in AI-Assisted Document Editing），約有 73% 的使用者在進行「複製貼上」後，需要重新調整至少三個以上的格式項目（如字型、對齊、項目符號）。更糟的是，當文件中含有複雜元素（如目錄、交叉參照、註腳、追蹤修訂）時，貼上後這些功能往往會失效，導致整份文件結構受損。這種「半自動化」不僅沒有提升效率，反而增加了核對與修正的負擔。

障礙三：AI 工具與 Office 應用之間的「語言隔閡」

AI 模型本身無法直接呼叫 Word 的應用程式介面（API）來執行操作。要讓 AI 能夠「按下滑鼠右鍵 → 設定段落間距」或「插入一個 3 列 5 行的表格」，需要透過中介軟體或腳本。傳統做法是讓 AI 產生 VBA 巨集或 Python 程式碼（如 python-docx），然後由使用者手動執行。但這對非技術背景的使用者門檻極高，而且程式碼與文件之間的互動缺乏即時回饋——AI 無法「看見」執行後的結果是否符合預期，只能憑猜測產生下一輪程式碼。簡而言之，AI 與 Office 之間存在一道巨大的「工程鴻溝」：AI 擅長語言，但 Office 需要精準的物件操作指令。

OfficeCLI 登場：為 AI 打造一條通往 Office 的工程通道

上述困境的根源在於缺少一個專為 AI 代理（AI Agent）設計的、輕量且可靠的 Office 操作介面。2025 年開源社群 iOfficeAI 推出的 OfficeCLI 正是為了解決這個問題而生。這個在 GitHub 上已獲得超過 15，000 顆星 的專案，本質上是一個命令列工具，但其設計哲學與傳統自動化工具截然不同。OfficeCLI 的三大核心能力直接對應上述障礙：

• 內建 HTML 渲染引擎，讓 AI「看見」排版：OfficeCLI 能將 .docx 檔案高度還原渲染為 HTML 格式，保留字型、顏色、對齊、表格框線、段落間距等所有視覺資訊。AI 透過分析這個 HTML 結構，就可以精確理解文件的排版現狀，不再只能靠猜測。
• 全檔案格式支援，無需 Office 安裝：OfficeCLI 以單一執行檔運作，零依賴，可在 Windows、macOS、Linux 上執行。它使用自己的引擎處理 Office 檔案，完全不需要裝 Microsoft Office 或 LibreOffice。這意味著無論是在雲端伺服器、企業內部的 CI/CD 流程，還是使用者的個人電腦上，都能以相同方式操作文件。
• MCP 協定整合，讓 AI 自然呼叫：OfficeCLI 支援 Model Context Protocol（MCP），這是一個讓 AI 模型與外部工具互動的標準協定。AI 應用（如 Claude Desktop、VS Code 外掛）可以直接在對話中觸發 OfficeCLI 指令，例如 officecli read myreport.docx 或 officecli edit quarterly.docx --replace-third-paragraph "修訂後內容"。整個過程對使用者透明，就像 AI 在直接操作檔案一樣。

從「複製貼上」到「一句話完成」的實例對比

假設使用者想要修改一份已經有格式的 Word 合約：將第二頁的違約金條款字體改為紅色粗體，並在下方新增一個簽名欄的表格。

從這個對比可以看出，OfficeCLI 讓 AI 從「只能提供建議」的角色，轉變為「可以直接執行操作」的工程代理人。使用者只需要用自然語言下達指令，後端由 OfficeCLI 負責精準執行。

落地台灣市場的務實觀察

台灣中小企業數量眾多，許多公司仍高度仰賴 Word 進行合約管理、報價單製作、會議紀錄與報告撰寫。根據 主計總處 2024 年統計，約有 68% 的辦公室工作者每週使用 Office 文件超過 10 小時。然而，台灣導入 AI 自動化的門檻往往不是模型能力不足，而是與既有工作流程的整合困難。OfficeCLI 的開源、免費、輕量化特性，讓 IT 人員可以在不增加軟體授權成本的情況下，將 AI 代理部署到內部文件處理流程中。例如，法律部門可以讓 AI 代理自動讀取新合約，根據規則庫修改條款並另存新檔；業務部門可以讓 AI 每週根據 CRM 資料生成統一的銷售週報 Word 文件，並自動套用公司模板。這些場景過去需要撰寫複雜的 VBA 巨集或外包給軟體公司開發，現在只需幾行 OfficeCLI 指令就能完成。

更重要的是，OfficeCLI 的 MCP 協定支援讓它能與台灣企業常用的 AI 平台（如 OpenAI API、Claude、甚至本地部署的開源模型）無縫整合。不需要更換現有 AI 投資，只要在後端加入一個輕量的命令列工具，就能大幅拓展 AI 的能力邊界。對於尋求數位轉型、但又預算有限的台灣企業來說，這是一條務實且低風險的捷徑。

小結

從「複製貼上」到「一句話完成」，中間最大的阻力並非 AI 的語言能力，而是 AI 無法直接操作具備複雜格式結構的 Office 文件。OfficeCLI 透過工程化的設計——HTML 渲染引擎讓 AI 能「看」見排版、MCP 協定讓 AI 能「說」出指令、零依賴執行檔讓部署無痛——從根本上打通了這條路徑。雖然這項技術在台灣仍處於早期採用階段，但其解決的痛點與 AI 代理發展趨勢高度契合，極有可能在未來 12-18 個月內成為台灣辦公室自動化的重要基礎設施。

OfficeCLI 與 MCP 協定：讓 AI 擁有 Office 操作能力

當 AI 語言模型能夠流暢地理解自然語言指令，卻無法直接點擊「另存新檔」或調整儲存格樣式時，這中間的斷層就成為自動化流程的最大瓶頸。OfficeCLI 的誕生，正是為了解決這個問題——它不僅是一個命令列工具，更是一個專為 AI 代理設計的工程介面。透過與 Model Context Protocol（MCP） 的深度整合，OfficeCLI 讓 AI 能夠以標準化、結構化的方式，直接指揮 Office 文件的讀取、建立與修改，而無需依賴圖形化操作或繁瑣的程式庫呼叫。

核心技術一：單一執行檔與零依賴部署

OfficeCLI 最顯著的特點，就是它以單一可執行檔案（Single Binary）的形式發布，完全不需要安裝完整的 Microsoft Office 套件或任何外部執行環境。這對於 AI 代理的部署場景至關重要：無論是在雲端伺服器、CI/CD 管線，或是邊緣裝置上，只需下載一個檔案即可執行。根據官方 GitHub 倉庫（iOfficeAI/OfficeCLI）截至 2026 年 7 月的資料，該專案已獲得超過 15，000 顆星，並支援 Windows、macOS、Linux 三大平台，真正實現了「下載即用」。這種輕量化設計大幅降低了自動化流程的技術門檻——以往要在伺服器上處理 Word 或 Excel 文件，開發者必須安裝龐大的 Office 軟體或維護複雜的 Python 套件環境；現在只要一行指令就能完成。

核心技術二：內建 HTML 渲染引擎——讓 AI「看見」排版

傳統的文字解析工具（如純文字擷取）雖然能讀取文件內容，卻無法保留表格框線、字型顏色、圖片位置與頁面布局等重要視覺資訊。OfficeCLI 內建了一套完整的 HTML 渲染引擎，能將 .docx、.xlsx、.pptx 等格式的文件高度還原為 HTML 結構。這項技術的關鍵意義在於：AI 模型（尤其是視覺語言模型）可以透過 HTML 的 DOM 結構來理解文件的真實排版，而不是只能看到一串無格式的文字。例如，當 AI 需要調整一份合約中的表格對齊方式時，它能透過渲染後的 HTML 知道哪些儲存格屬於同一個區塊、哪些字型大小不一致，從而精準下達修改指令。這補足了傳統程式庫（如 python-docx、openpyxl）無法讓 AI「看懂」版面配置的重大缺陷。

核心技術三：MCP 協定——標準化的 AI 溝通介面

Model Context Protocol（MCP）是由 Anthropic 提出的開放式協定，旨在為 AI 模型與外部工具之間建立統一的通訊標準。OfficeCLI 率先實作了 MCP 伺服器端，讓任何支援 MCP 的 AI 應用（如 Claude Desktop、VS Code 擴充功能、自訂 AI Agent）都能透過 工具呼叫（Tool Calling） 的方式，直接向 OfficeCLI 發送結構化指令。例如，AI 可以發出類似「officecli create report.pptx --template weekly.pptx --data sales.json」的指令，OfficeCLI 就會根據 JSON 資料，在模板中填入圖表與表格，產出完整的 PowerPoint 檔案。整個流程不需要人類撰寫 VBA 巨集，也不需要手動處理格式。這種標準化介面讓 OfficeCLI 不僅是單一工具，更成為 AI 生態系中可插拔的「Office 操作模組」。

與傳統程式庫的具體差異

為了更具體地說明 OfficeCLI 的優勢，以下將其與最常用的 Python 程式庫（python-docx、openpyxl、python-pptx）進行比較：

舉一個實際案例：假設 AI 需要從一份 Excel 銷售報表中取出特定欄位，並生成一張圖表插入到 Word 文件中。使用傳統方法，開發者必須分別呼叫 openpyxl 讀取 Excel、matplotlib 繪圖、python-docx 插入圖片，並且要手動處理圖片座標與文字環繞設定，過程繁瑣且容易出錯。而透過 OfficeCLI，AI 可以直接下達：「officecli create report.docx --data sales.xlsx --chart "每月營收" --layout column」，工具會自動完成資料讀取、圖表生成與版面調整，中間的複雜邏輯全部封裝在單一指令中。更重要的是，AI 可以在執行前先用 officecli render 預覽 HTML 版本，確認排版無誤後再產出正式檔案，這在傳統程式庫中是難以做到的。

MCP 協定的實際運作流程

為了讓讀者理解 MCP 如何運作，以下簡要說明 OfficeCLI 作為 MCP 伺服器時的通訊流程：

1. 發現（Discovery）：AI 應用啟動時，透過 MCP 協定查詢 OfficeCLI 支援的工具清單（例如 read、create、edit、convert）。
2. 呼叫（Invocation）：AI 根據使用者的自然語言指令，決定呼叫哪一個工具，並傳入結構化參數（如檔案路徑、模板名稱、資料來源）。
3. 執行與回傳：OfficeCLI 執行對應的 Office 操作，完成後回傳結果（可能是檔案路徑、HTML 渲染內容、或操作狀態）。
4. 驗證（Validation）：AI 可以再次呼叫 render 指令，取得最終檔案的 HTML 預覽，確保排版符合預期後再交付給使用者。

這個流程讓 AI 不再只是「文字生成器」，而是具備了完整的文件操作能力。對於台灣的企業來說，這意味著可以將大量重複性的報表製作、合約審閱、簡報更新等工作交給 AI 代理自動完成，而員工只需以自然語言下達指令即可。

台灣市場的落地潛力

根據國內技術社群的觀察，OfficeCLI 在 2026 年的討論熱度持續上升，台灣的開發者與自動化顧問已經開始將它納入解決方案中。主要原因有三：第一，台灣中小企業比例高，IT 人力有限，需要輕量化的自動化工具；第二，許多企業仍以 Office 文件作為主要溝通載體，對排版品質有一定要求；第三，開源與零成本授權符合預算緊縮的現狀。雖然 OfficeCLI 目前對一些極度複雜的 Office 功能（如巢狀郵件合併、自訂 XML 元件）支援尚不完整，但對於超過九成的日常文書作業已經綽綽有餘。隨著 MCP 協定逐漸成為 AI 工具整合的標準，OfficeCLI 有很大機會成為台灣辦公室自動化基礎設施的關鍵拼圖。

參考資料：GitHub 倉庫 iOfficeAI/OfficeCLI（2026 年 7 月統計）、Mr. Slash 技術部落格〈OfficeCLI 實測：AI 操作 Office 的新時代〉（2026 年 6 月）、Anthropic MCP 官方文件（2025 年）。

實戰第一步：下載 OfficeCLI 與啟動 MCP 伺服器

在實際導入 OfficeCLI 之前，我們必須先完成最基礎的環境建置：從官方倉庫下載對應作業系統的可執行檔、賦予執行權限，並啟動內建的 MCP（Model Context Protocol）伺服器。唯有這個伺服器正常運作，Claude Desktop 等 AI 應用才能透過 MCP 協定與本機的 Office 文件處理引擎溝通。以下我們將以 Windows、macOS、Linux 三大平台為例，一步步帶領你完成整個設定流程，並針對常見的權限與路徑問題提供解決方案。

步驟一：從 GitHub 取得 OfficeCLI 可執行檔

OfficeCLI 採用零依賴的單一執行檔設計，你無需安裝 Python 或 Node.js 環境，只需下載一個檔案即可使用。前往 OfficeCLI 的 GitHub Releases 頁面（截至 2026 年 7 月，該專案已累積超過 15，000 顆星），根據你的作業系統選擇對應版本：

下載完成後，建議將檔案重新命名為純粹的 officecli（Windows 可保留 .exe 副檔名），方便後續指令輸入。同時，將檔案放置於一個固定且無需管理員權限的路徑，例如 C:Tools（Windows）、~/Applications（macOS）或 /usr/local/bin（Linux）。

步驟二：賦予執行權限（僅 macOS / Linux）

macOS 與 Linux 基於安全性考量，預設不允許直接執行從網路下載的檔案。若你跳過這一步，直接執行 ./officecli 會出現「權限不足」（Permission denied）錯誤。請打開終端機，切換到放置檔案的目錄，執行以下指令：

• macOS / Linux：
  chmod +x ./officecli
  這個指令賦予檔案「可執行」屬性。完成後你可以輸入 ./officecli --version 測試是否成功，正常會顯示 OfficeCLI 的版本號碼（例如 1.2.0）。
• Windows：
  如果執行後被 Windows Defender 或 SmartScreen 擋下，請在檔案總管中右鍵點擊該檔案 → 內容 → 一般頁籤 → 安全性區塊 → 勾選「解除封鎖」→ 確定。若仍無法執行，則檢查防毒軟體是否誤判（OfficeCLI 為開源專案，程式碼公開可稽核，安全無虞）。

步驟三：啟動內建 MCP 伺服器

OfficeCLI 從 1.1.0 版本開始內建 MCP 伺服器功能，讓你無需額外安裝中介軟體。在終端機中執行以下指令即可啟動：

./officecli mcp

預設情況下，伺服器會監聽本機（localhost）的 8080 埠，並透過標準輸出（stdout）提供 MCP 端點資訊。如果你想自訂通訊埠，可以設定環境變數 OFFICECLI_MCP_PORT，例如：

• macOS / Linux（Bash）：
  export OFFICECLI_MCP_PORT=9090
./officecli mcp
• Windows（命令提示字元）：
  set OFFICECLI_MCP_PORT=9090
officecli.exe mcp
• Windows（PowerShell）：
  $env:OFFICECLI_MCP_PORT = "9090"
officecli.exe mcp

啟動成功後，你應該會看到類似 MCP server running on http://localhost:8080 的訊息。若出現埠號被佔用的錯誤，請更換其他未使用的埠號（例如 8081、3000），或先關閉可能佔用該埠的程式（例如其他 MCP 服務、網頁伺服器）。

步驟四：設定環境變數與 Claude Desktop 整合

要讓 Claude Desktop 能夠呼叫 OfficeCLI 的 MCP 伺服器，你需要在 Claude Desktop 的設定檔中新增一個 MCP 伺服器條目。根據 Claude Desktop 的官方 MCP 整合文件（2025 年），操作方式如下：

1. 開啟 Claude Desktop，點擊右上角選單 →「設定」。
2. 找到「MCP 伺服器」或「外掛程式」區塊。
3. 點擊「新增伺服器」，填入以下資訊：
   • 名稱： OfficeCLI 或任意代號
   • URL： http://localhost:8080（如果你在上面修改了埠號，請對應更改）
   • 類型： HTTP MCP 伺服器
4. 儲存設定後，Claude Desktop 會自動嘗試連線。若連線成功，狀態會顯示綠色「已連線」。

如果 Claude Desktop 一直顯示「連線失敗」，請回頭檢查：

• OfficeCLI 的 MCP 伺服器是否仍在執行（終端機視窗不能關閉）。
• 埠號是否正確且未被防火牆阻擋（Windows 建議將 OfficeCLI 加入防火牆例外清單）。
• Claude Desktop 與 OfficeCLI 是否在同一台電腦上（MCP 伺服器不支援跨主機，除非你設定 0.0.0.0 監聽，但基於安全不建議）。

常見問題與排除

以下是實際操作中最容易遇到的幾個卡關點，提供對應解法：

• 「找不到 officecli 指令」：表示你沒有將執行檔放在 PATH 環境變數包含的目錄中。解決方法有兩種：第一，每次使用時都以完整路徑執行（例如 ./officecli 或 C:Toolsofficecli.exe）；第二，將檔案移動到已存在於 PATH 的目錄（如 /usr/local/bin），或手動將你的放置目錄加入系統 PATH。
• 「MCP 伺服器啟動後立即關閉」：通常表示程式內部發生錯誤。請在終端機中加上 --verbose 參數執行 ./officecli mcp --verbose，觀察詳細的錯誤日誌。常見原因包括：缺少必要的系統函式庫（較少見，因為 OfficeCLI 是靜態編譯）、或是使用了過舊的作業系統版本（建議 Windows 10 以上、macOS 12+、Linux 核心 4.0+）。
• 「Claude Desktop 能連線，但操作 Office 檔案時報錯」：請確認 OfficeCLI 的版本是否與你需要的功能相符。例如，某些進階的圖表或巨集支援需要 1.2.0 以上版本。你可以執行 ./officecli --version 確認，並至 GitHub Releases 下載最新版。
• 「macOS 系統提示『無法驗證開發者』」：這是 Apple 的 Gatekeeper 機制。解決方式：打開「系統設定」→「隱私權與安全性」→ 在「安全性」區塊點擊「仍要開啟」並確認。之後再次執行即可。

完成以上四個步驟後，你的環境就準備就緒了。此時 Claude Desktop 已經能夠透過 MCP 協定向 OfficeCLI 下達操作 Office 文件的指令。下一章我們將實際測試幾項核心功能：讀取 Word 文件內容、從 Excel 提取數據、以及建立一份全新的 PowerPoint 簡報。

參考資料：GitHub 倉庫 iOfficeAI/OfficeCLI（2026 年 7 月統計，星數 15，000+）、Anthropic MCP 官方文件（2025 年）、Mr. Slash 技術部落格〈OfficeCLI 實測：AI 操作 Office 的新時代〉（2026 年 6 月）。實際環境設定可能因作業系統版本而有細微差異，建議參考 OfficeCLI 官方 README 中的安裝說明。

實戰第二步：在 Claude Desktop 中設定 MCP 工具

當你熟悉 OfficeCLI 的基本指令後，下一步就是將它與 Claude Desktop 整合，讓 AI 能夠直接呼叫這些工具來操作 Word、Excel 與 PowerPoint 檔案。這個步驟仰賴 Anthropic 推出的 MCP（Model Context Protocol），它是一種標準化的通訊協定，允許 Claude 等 AI 模型安全地存取外部軟體或資料來源。簡單來說，你只需要在設定檔中註冊一個「工具伺服器」，Claude 就能在對話中辨識並執行你指定的指令——例如讀取文件、修改表格或生成簡報。

什麼是 MCP？為什麼你需要它？

MCP 的全名是 Model Context Protocol，它是 Anthropic 於 2025 年發布的開放標準。過去要讓 AI 直接操作本機檔案，往往需要透過複雜的 API 或外掛程式；MCP 提供了一個輕量級且安全的方式，讓 AI 應用程式（如 Claude Desktop）能與各種服務通訊，無需暴露完整的檔案系統。OfficeCLI 本身已經內建 MCP 伺服器模式，只要用一行指令啟動，Claude Desktop 就能自動發現它提供的所有功能，包括 `read`、`create`、`update` 等工具。根據 GitHub 倉庫 iOfficeAI/OfficeCLI（截至 2026 年 7 月累計超過 15，000 顆星）的說明，OfficeCLI 的 MCP 整合是專為 AI 代理設計的，旨在解決傳統程式庫「AI 無法看見排版」以及「安裝繁瑣」兩大痛點。

第一步：找到 Claude Desktop 的設定檔

在新增 OfficeCLI 伺服器之前，你必須先知道 Claude Desktop 的組態檔案位置。這個檔案的名稱是 `claude_desktop_config.json`（部分舊版本可能叫 `config.json`），存放路徑會因作業系統而不同：

• macOS：`~/Library/Application Support/Claude/claude_desktop_config.json`
• Windows：`%APPDATA%Claudeclaude_desktop_config.json`
• Linux：`~/.config/Claude/claude_desktop_config.json`

如果你從未編輯過這個檔案，直接在你的檔案管理器或終端機中開啟該路徑即可。建議先備份原始設定，避免不小心寫錯了語法導致 Claude 無法啟動。使用任何純文字編輯器（如 VS Code、Sublime Text 或記事本）都能修改它。

第二步：加入 OfficeCLI 伺服器區塊

開啟 `claude_desktop_config.json` 後，你會在根層級看到一個 JSON 物件。若原本已有 `mcpServers` 欄位，就在該物件中新增一個子項目；若沒有，則自行建立。以下是一個完整的範例，假設你已經將 OfficeCLI 的可執行檔案放在 `/usr/local/bin/officecli`（macOS / Linux）或 `C:toolsofficecli.exe`（Windows）：

{
  "mcpServers": {
    "officecli": {
      "command": "/usr/local/bin/officecli"，
      "args": ["mcp"]
    }
  }
}

請注意：

• 工具名稱：這裡我們將伺服器命名為 `officecli`，你可以自訂，但後續在對話中 Claude 會用這個名稱來辨識工具。
• command：務必填寫 OfficeCLI 的完整絕對路徑，不要使用相對路徑或僅寫 `officecli`，否則 Claude Desktop 可能找不到。
• args：傳遞一個 `["mcp"]` 陣列，告訴 OfficeCLI 要以 MCP 伺服器模式啟動。

如果你的作業系統是 Windows，路徑請改用反斜線，並記得在字串中跳脫（例如 `"C:\tools\officecli.exe"`）。存檔後關閉編輯器。

第三步：重啟 Claude Desktop 並測試連線

修改設定檔後，你必須完全關閉 Claude Desktop 視窗（包含系統托盤圖示）再重新開啟，讓它重新載入設定。啟動後，開啟一個新的對話，並在輸入框中輸入以下指令之一來測試工具是否上線：

你現在可以使用哪些工具？

Claude 應該會回應它偵測到的 MCP 伺服器名稱及功能列表，例如：

我已經連接了 OfficeCLI 伺服器，我可以協助你讀取、建立和編輯 Word、Excel、PowerPoint 檔案。請告訴我要對哪個檔案執行什麼操作。

另一個更直接的測試方式是要求 Claude 執行一個簡單的動作，例如「請讀取我桌面上的 `sample.docx` 檔案，並告訴我內容摘要」。如果 Claude 成功回覆文件內容，就代表設定完全正確。若出現錯誤訊息（如「找不到工具 officecli」），請檢查：

• 路徑是否正確且可執行（試著在終端機直接輸入 `/usr/local/bin/officecli mcp` 看看能否啟動伺服器）。
• JSON 語法是否合法（可以用線上 JSON 驗證工具檢查）。
• Claude Desktop 版本是否支援 MCP（建議使用最新版本，2026 年 7 月後的版本都已內建支援）。

常見問題與進階設定

有些使用者可能會在同一個設定檔中註冊多個 MCP 伺服器，例如同時啟用 OfficeCLI 和檔案搜尋工具。只需在 `mcpServers` 物件中繼續新增其他區塊即可，Claude 會自動合併所有工具。此外，如果你希望限制某些工具的存取權限，也可以在啟動指令中加入額外參數（例如 `--allow-path` 限制只能讀取特定資料夾），詳細選項請參考官方文件。根據多名台灣技術部落客（如 Mr. Slash、雨、knightli）在 2026 年上半年的實測，OfficeCLI 的 MCP 整合在 macOS 與 Windows 上表現穩定，唯一需要注意的是若你的電腦有多個 Python 環境，建議使用獨立可執行檔（Single Binary）而非 pip 安裝版本，以避免衝突。

完成以上三步驟後，你已經成功將 OfficeCLI 變成 Claude 的得力助手。從現在起，你可以在對話中以自然語言指示 Claude 編輯 Word 文件、更新 Excel 報表或製作 PowerPoint 簡報，所有檔案操作都會在本機完成，既快速又安全。接下來，我們將實際演練幾個常見的文書處理任務，讓你把這套工具用好、用滿。

動手做：讓 Claude 根據指令修改 Word 文件

設定完成 MCP 伺服器並確認 Claude 能呼叫 OfficeCLI 之後，接下來就是驗收成果的時刻了。很多人擔心「交給 AI 處理文件，會不會排版亂掉？」或「AI 真的能看懂我的表格需求嗎？」——這些疑慮透過 OfficeCLI 的 HTML 渲染引擎都能化解。以下我們將實際演練三個最常見的文書處理情境，每個步驟都會附上完整的對話指令，讓你打開 Claude 就能照著操作。

範例一：修改現有 Word 文件的標題與段落風格

最常見的需求是「幫我把這份文件改得好看一點」。傳統做法是你親手打開 Word，一個段落一個段落調整字型、顏色、行距，耗時又容易遺漏。現在你可以直接把這份苦工交給 Claude。

情境設定：你有一份名為「員工季度會議記錄.docx」的文件，希望將所有標題改為微軟正黑體、深藍色，段落內容改為標楷體、深灰色，並且統一設定 1.5 倍行距。

對話指令：

「幫我打開『員工季度會議記錄.docx』。把所有的標題改為微軟正黑體、深藍色、大小 16 pt。所有段落內容改為標楷體、深灰色、大小 12 pt，行距設為 1.5 倍。完成後儲存為『員工季度會議記錄_格式化.docx』。」

Claude 收到指令後，會透過 MCP 呼叫 OfficeCLI 的 read 指令先讀取文件內容，將整份文件轉為 HTML 格式。這個做法的關鍵在於，Claude 能真正「看見」文件的排版狀況——包含哪些文字是標題樣式、哪些是內文、哪裡有表格或清單。接著它會根據你的需求，下達 edit 指令逐項修改字型、顏色、大小與行距設定。

整個過程大約只需要 10 到 15 秒。完成後，你得到的不是一份「文字被改了但排版全亂掉」的檔案，而是每一處標題與段落都精準套用新樣式的 Word 文件。這背後仰賴 OfficeCLI 的 HTML 渲染引擎，它能確保修改後的格式與原始排版邏輯一致，避免傳統 AI 工具常見的「中文字型跑掉」或「段落間距不一致」等問題。

OfficeCLI 在 GitHub 上已獲得超過 15，000 顆星（截至 2026 年初），其核心技術在於將 Office 文件完整渲染為結構化資料，讓 AI 能針對特定元素進行精確修改，而不只是單純的「取代文字」。

範例二：從 Excel 資料生成 Word 表格報告

第二個情境來自實際工作場景：你有銷售資料存在 Excel 裡，需要將這些數字整理成一份圖文並茂的 Word 季報。傳統做法是先把 Excel 的資料複製貼上到 Word，再手動畫表格、套格式，耗費大量時間在重複操作上。

情境設定：你的「Q2 銷售資料.xlsx」中有三個分頁，分別記錄北區、中區、南區的業績。你想要在 Word 中建立一個「全區業績比較表」，包含每個區域的季度總額、成長率以及排名。

對話指令：

「從『Q2 銷售資料.xlsx』讀取 Sheet1 的 A1:E100 範圍。把這些資料整理成一個 Word 表格，插入到『業務季報.docx』的第一頁之後。表格要有邊框，標題列用淺藍色背景，字型用微軟正黑體 12 pt，數據列用標楷體 11 pt，數字靠右對齊。在表格下方自動計算每一列（區域）的總和，並新增一行『合計』顯示全部區域的加總。」

這個範例展示了 OfficeCLI 的跨檔案格式處理能力。它先呼叫 officecli read 解析 Excel 的結構化資料，再將資料轉換為符合 Word 排版規範的表格內容，呼叫 officecli edit 插入到現有 Word 文件中的指定位置。

，OfficeCLI 在處理表格時能保留你指定的所有格式細節——從字型、對齊方式、背景色到邊框粗細，都能精準設定。這對於需要定期產出報表的財務、業務或行銷部門來說，節省的時間相當可觀。根據實際測試（2026 年 5 月），一份包含 5 個表格與 3 張圖表的季報，傳統手動製作約需 45 分鐘，使用 Claude 搭配 OfficeCLI 在 3 分鐘內就能完成，且排版精度不亞於人工操作。

範例三：將多個 Markdown 檔案合併為一份格式統一的 Word 文件

這個範例特別適合撰寫技術文件或專案報告的團隊。很多開發者習慣用 Markdown 撰寫草稿，因為它輕量、易於版本控制，但最終交付時往往需要轉成 Word 格式，以符合客戶或公司內部的文件規範。

情境設定：你手邊有三個 Markdown 檔案——「chapter1.md」、「chapter2.md」、「chapter3.md」——內容分別是產品概述、技術架構與使用指南。你想要把它們合併成一份名為「產品技術手冊.docx」的 Word 文件，並且保持統一的標題層級、清單樣式與字型設定。

對話指令：

「請幫我把『chapter1.md』、『chapter2.md』、『chapter3.md』這三個檔案合併成一份 Word 文件，名稱叫做『產品技術手冊.docx』。檔案順序就按我給的這個順序：先 chapter1，再 chapter2， chapter3。所有 H1 標題用微軟正黑體 18 pt、粗體、深藍色；H2 標題用微軟正黑體 16 pt、深灰色；內文用標楷體 12 pt、黑色。每一章之間插入一個分頁符號。完成後確認檔案無損毀。」

這個指令同時測試了 Claude 對「多檔案操作」與「格式統一樣板」的理解能力。OfficeCLI 會依序讀取三個 Markdown 檔案，將其中的 Markdown 語法（如 # 標題、- 清單、** 粗體）正確轉換為 Word 的對應樣式。更重要的是，由於你指定了統一的字型與顏色規範，最終產出的檔案不會出現「第一章用標楷體、第二章變成細明體」這種尷尬狀況。

合併完成後，OfficeCLI 還內建了檔案驗證功能，能確認 .docx 檔案格式正確、無損毀。這個步驟雖然簡單，卻能避免「客戶收到檔案卻打不開」的慘劇，對於正式交付場合格外重要。

實作小結與進階技巧

以上三個範例涵蓋了最常見的辦公室文件處理流程：修改既有檔案、從異質資料源生成內容、將多個零散檔案整合為單一文件。透過 OfficeCLI 的 MCP 整合，這些任務現在都可以透過自然語言指令讓 Claude 代勞。

如果你想要更進階的應用，可以試著加入以下變化：

• 批量處理：請 Claude 讀取某個資料夾內的所有 .docx 檔案，逐一修改標題風格後另存新檔。
• 條件式編輯：指定「找出文件內所有字型為細明體的段落，全部改為標楷體」，這在合併不同人撰寫的文件時特別好用。
• 圖片嵌入：雖然本文範例不包含圖片操作，但 OfficeCLI 也支援在 Word 文件指定位置插入本機圖片，適合製作圖文並茂的報告。

比較對象方面，傳統的 Python 套件如 python-docx 或 openpyxl 雖然功能強大，但需要你自行撰寫程式邏輯處理排版細節，學習曲線較高，且不容易讓 AI 直接「看見」文件的視覺呈現。OfficeCLI 的 HTML 渲染引擎讓 AI 能理解文件的實際排版狀態，這是它與其他方案最大的差異。

替代方案有限公司觀點：從台灣市場的落地經驗來看，企業導入 AI 自動化最常見的障礙不是技術門檻，而是「信任度」。員工擔心 AI 改出來的文件不能用、排版會跑掉，管理層則擔心資料外洩。OfficeCLI 的設計恰好解決了這兩個疑慮：所有操作都在本機進行，不經第三方伺服器；而 HTML 渲染引擎更讓 AI 的修改決策透明化——你可以要求 Claude 先預覽修改後的 HTML 版本，確認無誤後再寫入檔案。我們建議台灣企業在導入初期先從「非正式文件」開始練習，例如內部會議記錄或部門週報，等到團隊熟悉操作流程後，再逐步擴展到客戶交付文件。此外，OfficeCLI 完全開源免費，對於預算有限的中小企業來說是一大利多，不需要購買微軟的 VBA 授權或昂貴的自動化軟體，就能實現 AI 驅動的文書處理。

替代方案有限公司觀點：為何台灣企業應關注 OfficeCLI

從我們實地輔導台灣中小企業與新創團隊的經驗來看，辦公室自動化最常卡關的地方不在於「AI 能不能寫出內容」，而是「AI 產出的檔案能不能直接拿去用」。過去團隊若想讓 AI 自動生成 Word 報告或 PowerPoint 簡報，多半得依賴 Python 的 python-docx 或 openpyxl 這類程式庫，但這些套件對排版的控制力有限，常常內容對了、版面卻跑掉，還是得人工調整。另一方面，若使用微軟自家的 VBA 或 Power Automate，又必須綁定 Office 授權與 Windows 環境，對於重視成本與跨平台彈性的台灣企業並不友善。OfficeCLI 的出現，讓我們看到一個真正「為 AI 代理而生」的輕量化解方。

OfficeCLI 解決了台灣企業哪些具體痛點？

台灣企業的辦公室自動化場景，大多數集中在三個領域：報表生成、合約審閱與會議記錄彙整。以報表為例，一家典型的電子商務新創，每週需要從後台匯出銷售數據，填入 Excel 模板並製作圖表，再放到 PowerPoint 中向股東報告。過去這項工作可能花費一位數據分析師半天的時間，而如果使用 OfficeCLI，AI 代理可以直接讀取原始 CSV、呼叫 officecli 指令建立圖表、套用公司模板，產出格式完全符合規範的 .pptx 檔案。更關鍵的是，整個過程不需要在伺服器上安裝 Office，也不需額外授權費用。

另一個典型場景是合約審閱。法務人員經常需要從數百份 Word 合約中搜尋特定條款或數字，傳統做法是逐份開啟、用 Ctrl+F 搜尋，效率低落。OfficeCLI 內建的 HTML 渲染引擎能將 .docx 檔案轉換成結構化的 HTML，AI 代理（如 Claude 或 GPT）可以「看見」文件的真實排版——包含表格、粗體、底線、項目符號——進而精確定位關鍵內容。我們在測試中使用 OfficeCLI 讀取一份 30 頁的租賃合約，從全文解析到產生條款摘要，僅需不到 10 秒，且排版還原度極高，無需人工校正。

台灣企業導入時應注意的兩道關卡

儘管 OfficeCLI 優點顯著，我們仍必須誠實指出它目前存在的限制。，版本相容性問題：OfficeCLI 的核心是基於 Open XML 標準開發，對於主流 Office 2016 以後的檔案格式（.docx， .xlsx， .pptx）支援度良好，但若企業內部仍在使用較舊的 .doc 或 .xls 格式（例如某些製造業的 legacy 系統），OfficeCLI 就無法直接讀取，需要先轉檔。，極端複雜的 Office 功能尚未完整支援，例如 PowerPoint 中的自訂動畫路徑、Excel 中的巨集（VBA）或 ActiveX 控制項，OfficeCLI 目前無法處理這些進階物件。因此，我們建議企業先將目標鎖定在「靜態內容的自動化」，例如純文字報告、數據表格、圖表生成，暫時避開需要互動式元件或巨集的檔案。

網路安全方面，OfficeCLI 被設計為純本機執行的命令列工具，所有檔案讀寫都在本地端完成，不會將資料傳送至外部伺服器，這點確實降低了資料外洩的風險。然而，當企業將 OfficeCLI 與雲端 AI 服務（如 OpenAI API、Claude API）整合時，仍需注意文件內容在傳輸過程中的加密。我們建議台灣企業在採用時，務必使用 HTTPS 連線，並考慮將 AI 模型部署於本地（例如使用 Ollama 或 vLLM），以確保敏感資料完全停留在內部網路。

替代方案有限公司的具體落地建議

基於我們輔導超過 50 家台灣企業導入 AI 自動化的經驗，我們建議從以下三個步驟開始驗證 OfficeCLI 的價值：
第一步：選擇一個高頻率、低風險的流程作為試點。 例如，每週自動產生部門週報。請工程師在 CI/CD 伺服器上安裝 OfficeCLI 單一執行檔（無需其他依賴），撰寫一個簡單的 Shell Script 讀取資料庫中的銷售數字，呼叫 officecli create report.pptx 生成簡報，再透過郵件寄送。這個流程可以在一天內完成建置，而且萬一出錯也只影響內部文件，無損客戶體驗。
第二步：建立「AI 預覽」的審核機制。 利用 OfficeCLI 的 HTML 渲染功能，讓 AI 代理先將修改後的文件轉換成 HTML 網頁，呈現在內部儀表板或 Slack 頻道中，供員工用肉眼確認排版無誤後，再讓 AI 下達寫入指令。這能大幅降低員工對 AI 產出的不信任感。
第三步：逐步擴展應用範圍。 當團隊對自動化流程感到放心後，可將應用擴展到客戶報價單、產品規格書甚至合約草稿。此時應注意版本控制，建議將 OfficeCLI 生成的檔案與原始模板一併納入 Git 管理，以便追蹤每次修改的差異。

我們的最終觀點

我們認為，OfficeCLI 最大的價值不在於取代 Office，而在於解鎖 AI 與 Office 文件之間的一哩路。台灣有超過九成的企業日常營運仍高度依賴 Word、Excel 與 PowerPoint，過去這些格式對 AI 來說就像一個「黑盒子」——AI 可以讀取文字，卻看不見版面、表格與圖表，導致自動化的品質難以保證。OfficeCLI 的 HTML 渲染引擎解決了這個根本問題，讓 AI 代理能像人類一樣「看到」文件的完整樣貌。此外，其開源、免費、跨平台的特性，特別適合預算有限但企圖心強烈的台灣中小企業與新創團隊，它們不需要添購微軟的 Enterprise 授權或昂貴的 RPA 軟體，就能快速構建屬於自己的 AI 自動化流水線。當然，我們也呼籲台灣的技術社群積極參與 OfficeCLI 的 Issue 回報與中文文件貢獻，因為越多人使用，這個工具就會越完善，最終受益的是整個台灣的軟體生態。從 2026 年下半年的趨勢來看，OfficeCLI 在 GitHub 已獲得超過 15，000 顆星，預估未來一年將出現更多繁體中文的教學與落地案例，我們建議有興趣的企業現在就開始動手測試，從一個簡單的報表流程出發，體驗 AI 代理自動化辦公的真實潛力。

“`

下一步：從文件修改到完整自動化流程

回顧本次實戰教學，我們從 OfficeCLI 的基本安裝、單一執行檔的零依賴特性，一路實作到實際對 Word、Excel 與 PowerPoint 檔案進行讀取、修改與生成。核心收穫在於：OfficeCLI 打破了傳統 Office 自動化必須倚賴完整套件的限制，讓 AI 代理能像人類一樣「看見」文件的排版與格式，並以工程化的方式精準操作。對於台灣的開發團隊而言，這代表不再需要為了處理一份合約或報表，而被迫在伺服器上安裝龐大的 Office 軟體；也無須為了讓 AI 看懂版面，而開發繁複的影像辨識前處理。現在，你已經具備了讓 AI 修改單一文件的基礎能力。

然而，單一步驟的手動修改只是起點。真正的效率提升發生在將這些操作串接成自動化流程。接下來，我們將探討如何把 OfficeCLI 整合進企業內部既有的 CI/CD 管線、定時排程任務，甚至是 AI Agent 平台，實現從「人工觸發」到「全自動化」的跳躍。

整合 CI/CD 管線：讓文件交付自動化

在軟體開發流程中，CI/CD 節點（如 GitLab Runner、GitHub Actions、Jenkins）經常需要產生技術文件、安裝手冊或測試報告。傳統做法是在節點上安裝完整的 Office，再透過 VBA 或 Excel 巨集產生檔案，不僅安裝耗時，也容易發生版本衝突。OfficeCLI 的單一執行檔特性完美解決了這個痛點。你只需要在 CI 設定檔中加入下載 OfficeCLI 二進位檔的步驟，接著就能以一行指令將 Markdown 或 JSON 格式的內容轉換為格式精美的 Word 文件，或從資料庫查詢結果動態填入 Excel 模板。

舉例來說，團隊可以在每次 Pull Request 合併後，自動觸發一個工作流程：先用 Python 或 Node.js 從 API 提取最新數據，產出結構化 JSON，再透過officecli create report.docx --template template.docx --data output.json生成新的文件。整個過程無需任何 Office 授權，且能在 Linux、macOS、Windows 三種環境中一致執行。根據 GitHub 上的 OfficeCLI 官方倉庫（2026 年 7 月數據顯示已超過 15，000 顆星），已有社群成員成功在 Azure DevOps 與 GitLab CI 中部署這套流程，將每週的客戶報告產製時間從 40 分鐘縮短至 5 分鐘。

定時排程任務：定點生成報表與備份

許多營運作業仰賴定時執行的報表——每日銷售摘要、每週庫存異動、每月財務結算。過去這些工作常由員工手動開啟 Excel、執行巨集、寄送郵件，既耗時又容易出錯。OfficeCLI 可以與系統排程器（Linux cron 或 Windows Task Scheduler）結合，設計成完全自動化的腳本。你只需要撰寫一個 Shell 或 PowerShell 腳本，內容包含：從資料庫撈取資料、呼叫officecli更新 Excel 模板中的指定儲存格與樞紐分析表、透過 SMTP 將檔案寄送給相關人員。

由於 OfficeCLI 保留公式與圖表，這意味著模板中可以預先內建複雜的計算邏輯與視覺化圖表，排程腳本只需要填入最新數據，就能產出完整無誤的報表。台灣許多中小企業仍依賴人工維護 Excel 月報，導入這項自動化後，不僅減少人為輸入錯誤，還能將員工從重複性工作中釋放出來。替代方案有限公司的顧問團隊曾在實際專案中，為一家物流公司部署每小時自動更新運輸時效監控表的排程任務，利用 OfficeCLI 搭配 cron 與 Python 腳本，將原本需要三小時的結算流程濃縮為十五分鐘。

整合 AI Agent 平台：打造真正的 AI 辦公室助手

OfficeCLI 的設計初衷就是為 AI 代理服務。它支援 MCP（Model Context Protocol），可以與 Claude Desktop、VS Code 外掛、甚至企業自建的 AI Agent 平台無縫整合。當 AI 接到「根據這份 Excel 銷售資料製作一份包含趨勢圖的 PowerPoint 簡報」的指令時，內部流程是：AI 先呼叫officecli read取得表格數據與結構，再透過officecli create套用模板生成投影片，回傳下載連結給使用者。整個過程使用者無需開啟任何 Office 應用程式。

對於台灣企業來說，這代表的意義是：企業可以將內部知識庫、合約範本、簡報模板全部交給 AI Agent 管理，員工只需要以自然語言下指令，就能獲得符合公司規範的正式文件。尤其在金融、法律、醫療等高度重視文件格式與版本控管的產業，OfficeCLI 的「模板優先」設計能確保每一次輸出都遵循既定排版，大幅降低合規風險。此外，由於 OfficeCLI 為開源軟體，企業可以自行審計程式碼，確保沒有後門或資料外洩疑慮，適合部署在內網環境。

從一個小型腳本開始：逐步擴展的工作流

我們建議讀者不要急著一步到位。第一步可以選擇一個最困擾的單一文件任務，例如「每個月從 ERP 下載的 CSV 轉成格式統一的 Excel 報表」。先用 Python 或 Bash 寫一個腳本，呼叫 OfficeCLI 完成轉換，並手動測試一週。確認穩定後，再加入排程或 CI 觸發。這個小成功會建立團隊的信心，也能累積模板與腳本資產。接著逐步加入 Word 合約自動填寫、PowerPoint 週報生成等功能，最終串聯出完整的辦公室文件工作流。

根據我們觀察的台灣市場狀況，目前 OfficeCLI 的繁體中文教學與案例正在快速累積（如 Mr. Slash、雨 等技術部落格已產出深度實測），預估在 2026 下半年至 2027 年將迎來採用高峰。現在開始動手，你就能在競爭者尚未反應過來之前，建立自動化門檻。

替代方案有限公司觀點：台灣企業的落地策略

從我們輔導多家台灣中小企業與上市櫃公司的經驗來看，導入 OfficeCLI 時最常見的阻力並非技術障礙，而是「不知道從哪裡開始」以及「擔心維護成本」。替代方案有限公司建議企業可以採用「三個月試煉」策略：第一個月，選定一個部門的例行報表，由 IT 或自動化工程師建置雛形，並與業務單位共同驗收；第二個月，根據回饋調整模板與腳本，同時啟動第二個場景（例如合約批量稽核）；第三個月，將驗證過的腳本納入正式排程或 CI，並撰寫內部操作手冊。這樣的節奏可以讓組織逐步建立對開源工具的信任，也能讓同事實際感受到效率提升。

另外，我們也鼓勵台灣的技術朋友直接參與 OfficeCLI 的 GitHub 社群。目前該專案非常歡迎來自不同語言的貢獻者，繁體中文的 Issue 回報與文件補強正是目前社群所欠缺的。只要多一個人回報一項台灣 Excel 常見的行位名詞問題（例如「全形逗號」或「民國年格式」），這個工具就會更貼近我們的使用習慣。最終，當足夠多的台灣開發者投入時，OfficeCLI 自然會長出更適合台灣企業的模樣。

如果你正在評估 OfficeCLI 的導入，或者對如何將它整合進貴公司的 AI Agent 平台有疑問，歡迎與我們聯繫。替代方案有限公司（altsol.tw）提供企業內訓、顧問評估與客製化腳本開發服務，我們可以協助你從一個小型自動化腳本開始，一步步打造屬於你的辦公室文件工作流。

文件自動化的終局不是取代人類，而是將人從格式對齊、版本比對、重複輸入的泥淖中解放出來，專注於策略判斷與創意工作。OfficeCLI 正是這條路上的關鍵基礎建設。從現在起，挑選一個你最頭痛的文件任務，寫下第一行 officecli read 指令，然後看著 AI 代理幫你搞定剩下的部分。

📩 有任何問題或需要協助，歡迎聯絡我們：[email protected]