編輯器後台

為什麼 如此擅長編輯文件？

語言模型可以寫出很好的句子，但將其連同格式放回去則是另一回事。我們將解釋為什麼讓 AI 編輯文件一直以來都如此困難，以及我們為了修正此問題打造了什麼。

閱讀時間 9 分鐘2026年10月3日

概覽

請聊天機器人修改 Word 檔案中的某個條款，等於是要求它同時做兩件事：修改文字，以及重寫承載這些文字的檔案格式。語言模型很擅長第一件事，但對第二件事卻不可靠。

從模型手中接下第二項工作。本文說明為什麼這點很重要、它如何在長篇文件中運作，以及它與聊天網站和電腦使用代理程式有何不同。

  1. 01語言模型是將文件讀取為標記（markup），而非頁面。
  2. 02一個錯誤的字元就能讓檔案無法讀取，而過長的輸出結果則大幅增加了出現錯誤字元的機率。
  3. 03 將內容與格式分離：模型負責編輯文字，我們的程式碼負責寫入檔案。
  4. 04如同現代的編碼代理程式一樣，長文件會被分批、分割並賦予上下文。
  5. 05聊天網站可以使用 Python 編輯檔案，但變更可能會默默遺失。
  6. 06電腦使用代理程式的編輯方式如同人類，但成本高出許多。

01

LLM 只看得到文字，看不見格式

在 Word 中開啟合約，您會看到一個頁面：採用公司風格的標題、粗體金額、帶底線的截止日期。Word 程式會建立這些格式，以便我們進行視覺化編輯。Word 檔案 (.docx) 的底層是一個複雜的 XML 系統，我們看到的每個字都痛苦地附帶了稱為標記的隱藏字詞註解。12

你看到的內容

模型所看到的內容

<w:p>  <w:pPr><w:pStyle w:val="Heading2"/></w:pPr>  <w:r><w:t>4. 租金</w:t></w:r></w:p><w:p>  <w:pPr><w:jc w:val="both"/></w:pPr>  <w:r><w:t xml:space="preserve">承租人應於 </w:t></w:r>  <w:r><w:rPr><w:i/><w:u w:val="single"/></w:rPr><w:t>每個月的第一天</w:t></w:r>  <w:r><w:t xml:space="preserve"> 支付 </w:t></w:r>  <w:r><w:rPr><w:b/><w:color w:val="1F4E79"/></w:rPr><w:t>US$2,400</w:t></w:r>  <w:r><w:t>。</w:t></w:r></w:p>
圖 1相同的條款出現兩次。文字佔了 31 個字元；其周圍的 XML 則佔了 420。word/document.xml 摘錄。

大型語言模型無法獲得 Microsoft Word、LibreOffice 或 Pages 的協助，必須依靠自身對標記的理解。為了正確編輯，大型語言模型需要理解原始標記的效果，並以正確的標記寫出新句子。

02

LLM 的輸出本質上是不穩定的

模型可能已經有了大幅改善，但即使是最新版本仍然會犯錯。在微軟研究院（Microsoft Research）針對 52 個專業領域中 19 個模型的 2026 年研究顯示，諸如 Gemini 3.1 Pro、Claude 4.6 Opus 和 GPT 5.4 等前沿模型，在長篇編輯工作流程結束時，平均會損壞 25% 的文件內容。4

在 Word 檔案中，一個小錯誤就足以使檔案無法使用。此處模型漏掉了一個斜線：

<w:p>  <w:pPr><w:jc w:val="both"/></w:pPr>  <w:r><w:t xml:space="preserve">承租人應於 </w:t></w:r>  <w:r><w:rPr><w:i/><w:u w:val="single"/></w:rPr><w:t>每個月的第一天</w:t></w:r>  <w:r><w:t xml:space="preserve"> 支付 </w:t></w:r>  <w:r><w:rPr><w:b>1<w:color w:val="1F4E79"/></w:rPr><w:t>US$2,400</w:t></w:r>  <w:r><w:t>。</w:t></w:r></w:p>
圖 2少了一個斜線會導致粗體標籤保持開啟。該 XML 檔案將不再符合結構良好（well-formed）的標準，Word 也將無法正常開啟該檔案。3

XML 對於錯誤的標記容忍度為零。檔案不是結構良好，就是結構不良。Word 有時可以修復損壞的檔案，但修復後的副本可能會遺失文字或格式。

輸出越長，錯誤越多

風險隨著長度增加而升高。LongProc 是 2025 年針對長結構化輸出的基準測試，發現開源權重模型在輸出達到 2,000 個 Token 時開始表現不穩，而 GPT-4o 在達到 8,000 個 Token 時則明顯退化。5 另一項研究發現，隨著輸入內容增加，效能會下降 13.9% 至 85%，即使模型能夠檢索到每一個相關的事實。6 一份 10 頁的 Word 文件大約有 10,000 個 Token，試圖一次編輯所有 10 頁而不出錯簡直難如登天。

<w:p>  <w:pPr><w:pStyle w:val="ClauseText"/></w:pPr>  <w:r><w:rPr><w:b/><w:sz w:val="24"/></w:rPr><w:t>5.1</w:t></w:r>  <w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t xml:space="preserve"> Harlow &1 Pike LLP 就本租約所產生的一切事宜代表房東行事。</w:t></w:r></w:p><w:p>  <w:pPr><w:pStyle w:val="ClauseText"/></w:pPr>  <w:r><w:rPr><w:b/><w:sz w:val="24/>2</w:rPr><w:t>5.2</w:t></w:r>  <w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t xml:space="preserve"> 承租人應保持租賃物良好的實質修繕狀態與狀況。</w:t></w:r></w:p><w:p>  <w:pPr><w:pStyle w:val="ClauseText"/></w:pPr>  <w:r><w:rPr><w:b/><w:sz w:val="24"/></w:rPr><w:t>5.3</w:t></w:r>  <w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t xml:space="preserve"> 任何通知均須以書面形式提出，並送達附表 2 中列出的地址。</w:t></w:p>3<w:p>  <w:pPr><w:pStyle w:val="ClauseText"/></w:pPr>  <w:r><w:rPr><w:b/><w:sz w:val="24"/></w:rPr><w:t>5.4</w:t></w:r>  <w:r><w:rPr><w:sz w:val="24"/></w:rPr><w:t xml:space="preserve"> 若租金逾期超過 214
  1. 1文字中單獨出現的「&」符號（與號）。XML 要求必須將其跳脫為實體。
  2. 2缺少結尾引號。其後的所有內容都會被讀取為值的一部分。
  3. 3在段落結束前未關閉的文字區段（run）。
  4. 4輸出直接停止。長篇生成可能會達到長度限制或在標籤中間逾時。
圖 3四個模型輸出的子句，四種失敗。任何一個單獨存在都會使檔案無法讀取。

03

如何解決此問題

我們編寫自訂程式，將格式與內容分離。模型會接收需要變更的文字以及頁面的算繪圖片，藉此獲得 Word 程式的協助。接著，我們的程式會將編輯過的文字放回原本的文字區段中，並保持檔案其餘部分不變。

您的檔案

<w:p>  <w:pPr><w:jc w:val="both"/></w:pPr>  <w:r><w:t xml:space="preserve">承租人應於 </w:t></w:r>  <w:r><w:rPr><w:i/><w:u w:val="single"/></w:rPr><w:t>每個月的第一天</w:t></w:r>  <w:r><w:t xml:space="preserve"> 支付 </w:t></w:r>  <w:r><w:rPr><w:b/><w:color w:val="1F4E79"/></w:rPr><w:t>US$2,400</w:t></w:r>  <w:r><w:t>。</w:t></w:r></w:p>

將內容與格式分離

擷取的內容

承租人應於 每個月的第一天 支付 US$2,400。

呈現的頁面

兩者都會傳送給模型

語言模型編輯文字。絕不觸碰 XML。

模型會傳回編輯後的內容

模型輸出

承租人應於 每個月的第一天每個月第五天 支付 US$2,400US$2,600。

將文字寫回原本的文字區段中

您的檔案（已編輯）

<w:p>  <w:pPr><w:jc w:val="both"/></w:pPr>  <w:r><w:t xml:space="preserve">承租人應於 </w:t></w:r>  <w:r><w:rPr><w:i/><w:u w:val="single"/></w:rPr><w:t>每個月第五天</w:t></w:r>  <w:r><w:t xml:space="preserve"> 支付 </w:t></w:r>  <w:r><w:rPr><w:b/><w:color w:val="1F4E79"/></w:rPr><w:t>US$2,600</w:t></w:r>  <w:r><w:t>。</w:t></w:r></w:p>

✓ 有效的 .docx。粗體、顏色和底線與原本完全相同。

圖 4編輯管線簡化版。反白文字是檔案中唯一變更的部分。

這同時解決了兩個問題。模型現在能看到它之前看不到的格式，並且不再寫入最容易損壞的標記。

您在通用聊天機器人中找不到這層架構。擷取、呈現和重新組合程式是由 自己的工程師建構和維護的。

04

解決長上下文問題

有些編輯篇幅很長：跨越多頁的段落，或是要在數百個地方一致套用的變更。針對這些情況，我們借鏡了軟體工程的做法。2026 年 3 月，Anthropic 在一個公開的 npm 套件中，意外發布了其 AI 編碼代理程式 Claude Code 的原始程式碼。7

那個外洩的程式碼編輯器教導了一個簡單的道理：要編輯較長的內容，就把它拆解。我們將文件分割成頁面群組（這項技術稱為分批），並將長段落分割成句子，好讓每次的編輯都夠小而正確。

將文件拆散會產生一個新問題：上下文。如何使用第 2 頁的定義來編輯第 60 頁的段落？在這裡，兩年在 AI 程式碼編輯器（Cursor、GitHub Copilot、OpenAI Codex）方面的經驗發揮了作用。他們的答案是上下文工程，將相關資訊收集到一個聚焦的集合中，並提供給具有乾淨上下文視窗的子代理程式。8 我們對文件採取相同的做法。我們會像細心的讀者一樣，將邏輯相關的資訊分組，然後將其與編輯目標一起傳送給進行實際變更的子編輯。

1批次處理文件

第 1–40 頁第 41–80 頁第 81–120 頁第 121–160 頁第 161–200 頁第 201–240 頁第 241–280 頁第 281–300 頁

2分割長段落

第 18.3 條 · 第 60 頁
句子 1句子 2句子 3句子 4句子 5

3收集上下文，然後進行平行編輯

定義用詞第 2–12 頁

當事人與角色第 1 頁

先前的修正案第 34 頁

子編輯 1第 1–40 頁 + 集合

子編輯 2第 41–80 頁 + 集合

子編輯 3第 81–120 頁 + 集合

圖 5一份 300 頁的文件經過拆解。每位子編輯都會分到一小部分文件，以及該部分所依賴的上下文。

範例：遮蔽判決書

律師希望將判決書中的每位證人姓名遮蔽，並列出所引用的案件清單供資淺律師研究。

  1. 搜尋。 透過一般的模式比對即可尋找每個人名與每筆判例引注。此階段尚不需要模型。
  2. 分類。 每個姓名及其前後的句子會交給模型進行判定：證人、律師或法官。這些答案建構出證人集合。
  3. 收集。 相同的方法建立了一組引用的案例。
  4. 執行。 由於我們確切知道每個證人姓名出現的位置，因此我們會在原始檔案中遮蔽這些位置，且只遮蔽這些地方。

高等法院

王座分庭

Harrow v Kestrel Logistics Ltd

修改前：Mrs Justice Holloway

判決書

Mrs Justice Holloway：本索賠源於被告倉庫之裝卸區於 2024 年 3 月 14 日發生之倒塌事故。原告由 Ms Priya Raman 代表，被告由 Mr Thomas Whitby 代表。我聽取了為期四天的口頭證詞。

主要目擊證人 Mr Daniel Okafor 是夜班堆高機操作員。Mr Okafor 向法庭作證指出，裝卸區的警示燈已經故障數週，而且他曾回報過兩次。第二位證人 Ms Margaret Ellison 是一名在 2 月檢查該裝卸區的承包商，她證實其報告建議立即進行維修。我認為兩位證人都謹慎且可信。

佔用人對合法進入其處所者負有注意義務，此原則已確立，我以 Donoghue v Stevenson [1932] AC 562 中的鄰居原則作為出發點。於新型情況下課予義務是否公平、公正且合理，受 Caparo Industries plc v Dickman [1990] 2 AC 605 規範，但本案情況並非新型。Mr Whitby 主張所索賠之損失過於遙遠。該主張須對照 Hadley v Baxendale (1854) 9 Exch 341 加以檢驗。

在審視了 Mr Okafor 與 Ms Ellison 的證詞以及相關文件後，我確信被告早已知悉該瑕疵卻未採取行動。原告之責任訴求成立。損害賠償金額將於後續聽證會中評估。感謝 Ms Raman 與 Mr Whitby 清晰且聚焦的陳詞。

圖 6切換檢視以查看結果。判決與姓名皆屬虛構；所引述的三個案例則為真實案件。

05

chatgpt.com、claude.ai 和其他聊天網站能做到一樣的事嗎？

有時候，是的。這些網站通常包含 Python 直譯器，讓模型能夠開啟 Word 或 PowerPoint 檔案，並透過程式碼來編輯其 XML。

但程式碼仍然是由不穩定的模型所編寫，且沒有任何機制可以核對結果與原始檔案是否相符。在我們的內部測試中，我們經常收到出現非預期刪除與修改的文件。在一個極端案例中，一份 20 頁的文件交回來時變成了 10 頁，且毫無預警。

具備 Python 功能的聊天網站

20 頁
10 頁

完成！我已根據您的要求更新了文件。

未提及那 10 頁遺失的內容。

變更日誌

  • 第 4 頁 · 第 2.1 條

    三十（30）天 六十（60）天

    還原
  • 第 9 頁 · 第 6.3 條

    供應商 承建商

    還原
  • 第 17 頁 · 附表 1

    US$2,400 US$2,600

    還原

產生新文件

圖 7左圖：我們內部測試中發生的無聲截斷。右圖：OneTurn 上的所有 AI 變更皆已列出且可還原。

對於任何嚴謹的工作來說，悄悄發生的遺漏或修改都是致命的。在 上，我們的 AI 代理程式所做的每一項變更都會被記錄下來。您可以審查每一項變更、還原其中任何一項，並產生新的文件。

06

像 OpenClaw 或 Manus 這樣的電腦使用代理程式（computer-use agents）能做到這一點嗎？

這些代理程式像真人一樣控制電腦。它們在 Microsoft Word 或 PowerPoint 中開啟文件，然後捲動、點擊並輸入。11 因為它們使用與人類相同的程式，所以能像人類一樣進行編輯，而且成果往往令人驚艷。

代價是成本與速度。代理程式透過在捲動時擷取螢幕畫面來讀取文件，且每一個小步驟都需要進行模型呼叫來決定下一步該怎麼做。光是一張 Full-HD 螢幕截圖就要消耗大約 1,500 到 2,700 個 Token。10 在 OSWorld 評測中，即使是表現最好的代理程式，所需步驟也比實際必要的多出 2.7 到 4.3 倍，且後續步驟所花的時間最多比初期步驟長 3 倍。9

電腦使用代理程式

  1. 擷取螢幕畫面
  2. 模型決定下一步行動
  3. 捲動、點擊或輸入
  4. 對每個步驟重複此動作

  1. 讀取一次文字
  2. 批次編輯
  3. 寫入檔案
20頁合約，30處修訂電腦使用代理程式
模型呼叫≈ 180≈ 12
每次呼叫的 Token 數≈ 10,000≈ 4,000
總 Token 數≈ 1,800,000≈ 48,000
差異約 37 倍，若計入在 OSWorld 上測得的額外步驟，則約為 100–160 倍
圖 8假設：約 11,000 字；60 張截圖以閱讀文件；每次編輯 4 個動作；每次呼叫包含一張截圖以及最近的歷史紀錄。OneTurn 會讀取一次文字並分批發送編輯。

根據我們的估算，對於相同的編輯，電腦使用代理程式（computer-use agent）所使用的 LLM Token 數量可能是 的 100 倍之多，且完成所需的時間也長得多。

來源

  1. WordprocessingML 文件結構Microsoft Learn · Open XML SDK 文件
  2. ECMA-376：Office Open XML 檔案格式Ecma 國際組織 · 標準
  3. 驗證文字處理文件Microsoft Learn · Open XML SDK 文件
  4. 當您委託 AI 時，LLM 會損壞您的文件Laban、Schnabel 與 Neville · 微軟研究院 · 2026
  5. LongProc：在長程序生成上對長上下文語言模型進行基準測試Ye 等人 · COLM 2025
  6. 即使檢索完美，僅增加上下文長度也會損害 LLM 的效能Du 等人 · EMNLP 2025 研究發現
  7. Anthropic 透過 npm 原始碼對應檔意外洩漏 Claude Code 原始碼InfoQ · 2026年4月7日
  8. 針對 AI 代理程式的有效上下文工程Anthropic 工程團隊 · 2025年9月29日
  9. OSWorld-Human：評測電腦使用代理程式的效率Abhyankar、Qi 與 Zhang · MLSys 2026
  10. 視覺：解析度與 Token 成本Claude 平台文件
  11. 在 OpenClaw 熱潮中，Meta 的 Manus 推出桌面應用程式，將其 AI 代理帶入個人裝置CNBC · 2026年3月18日

各圖皆為專為本文製作的插圖。XML 為真實的 WordprocessingML；檔案名稱、人物與判決皆為虛構。

在您承受不起損壞的文件上試試看。

免費試用 →