分析 Anthropic 的 Agent Skill docx：功能、程式組成、使用方法與注意事項

Anthropic 的 skills/docx 本質上是一套「讓 AI 更穩定處理 Word 文件」的工作規範與腳本工具集。
它不是只告訴模型「去寫一個 .docx」，而是把 Word 文件處理拆成幾條明確路徑：新建文件、讀取內容、編輯既有文件、處理修訂、加入評論、格式轉換、校驗 OOXML 結構。

如果只用一句話概括：

讓 agent 不再把 .docx 當黑盒，而是把它當成 ZIP + XML + Office 相容性問題來處理。

這個 skill 解決什麼問題

一般模型在處理 Word 文件時，常見問題大致有這幾類：

只會輸出文字，不會真正產生結構正確的 .docx
修改既有文件時，容易破壞 OOXML 結構
遇到批註、修訂、評論串時，不知道要改哪些 XML
文件能產生，但在 Word、LibreOffice、Google Docs 間相容性不穩
不清楚何時該用 pandoc，何時該直接解包改 XML

docx skill 的價值就在這裡，它把「該怎麼做」先規範好了：

讀內容時，優先用 pandoc 或解包
新建 .docx 時，優先用 docx-js
編輯既有 .docx 時，優先走「解包 -> 修改 XML -> 重新打包 -> 校驗」
處理接受修訂、評論、schema 校驗等細節時，用配套腳本而不是硬寫

這套方法很實用，因為 Word 文件問題通常不是「文字對不對」，而是「文件結構是否還能被 Office 正常接受」。

目錄與程式組成

這個 skill 大致可以分成四層。

1. 說明層：`SKILL.md`

SKILL.md 是入口，主要做兩件事：

定義觸發條件
只要需求涉及 Word、.docx、評論、修訂、目錄、頁碼、模板、格式化文件等內容，就應啟用這個 skill。
規定工作路徑
明確指定不同任務要走哪條技術路線，而不是每次臨場發揮。

它同時是使用說明與操作規範。裡面最有價值的是相容性規則，例如：

docx-js 預設是 A4，不是 US Letter
橫向頁面時，寬高參數要按它的內部邏輯傳
列表不能手工插入 Unicode bullet
表格寬度要同時設 table 與 cell
插入圖片時 type 不能省
生成後要跑 validate

這反映出它追求的不只是「能生成」，而是「能穩定開啟、穩定渲染、穩定相容」。

2. Office 包操作層：`scripts/office/*`

這一層負責把 .docx/.pptx/.xlsx 當成 Office Open XML 套件來處理。

`unpack.py`

作用是把 Office 文件解包到目錄，並做一些整理：

解壓 ZIP 包
對 XML / .rels 做 pretty print
對 .docx 可選執行 merge_runs
對 .docx 可選執行 simplify_redlines
將智慧引號轉成 XML 實體，降低後續處理風險

它不只是「解壓」，而是把內容整理成更適合 agent 與人類繼續編輯的狀態。

`pack.py`

作用是把修改後目錄重新打包成 .docx/.pptx/.xlsx。
打包前還會做兩件要事：

可選執行校驗與自動修復
重新壓縮整理 XML，移除無意義空白與註解

若提供 --original，會結合 validator 比對，這點很關鍵。
因為很多 Word 修改不是「能打包回去」就算成功，而是要確認結構與修訂語義都成立。

`validate.py`

這是整個 skill 的品質閘門。
它會校驗：

XML 是否良構
namespace 是否正確
各類 ID 是否唯一
relationship / content type 是否匹配
是否符合 XSD schema
空白保留規則是否正確
插入、刪除、評論標記是否合法

對 .docx 來說，這幾乎是核心能力。
很多「看起來只改一點 XML」的問題，都會在這裡暴露。

`soffice.py`

這是一個很有工程味的輔助工具。
它不是單純呼叫 LibreOffice，而是為受限環境做兼容處理，會設置 SAL_USE_VCLPLUGIN=svp，必要時還會用 shim 處理 AF_UNIX socket 限制。

這代表它考慮的不是只有本機手動場景，也包含 agent、CI、沙箱等自動化環境。

3. Word 專項能力層：評論、修訂與 redline

`comment.py`

這個腳本負責幫 DOCX 加評論。
它做的不只是寫一段 comment XML，因為 Word 評論涉及多個部件協同：

word/comments.xml
commentsExtended.xml
commentsIds.xml
commentsExtensible.xml
document.xml 中的 comment range marker
[Content_Types].xml 與 document.xml.rels 中的關係宣告

腳本已把這些依賴關係處理好。
若是第一次加評論，會自動補模板檔、relationship 與 content types，能大幅降低手工改 OOXML 的出錯率。

`accept_changes.py`

這個腳本目標很明確：接受所有修訂。
做法不是硬改 XML，而是透過 LibreOffice headless + Basic macro 呼叫 .uno:AcceptAllTrackedChanges。

這很穩妥，因為「接受修訂」在 Word 語義中不只是刪 <w:ins> / <w:del>。
直接改 XML 很容易留下邊角問題；由 Office 引擎處理通常更可靠。

`validators/redlining.py`

這是我認為很關鍵的一段。
它會把「某作者的修訂」分別從原始文件與修改後文件中剝離，再比較正文文字是否一致，以判斷修訂是否被正確包在 tracked changes 結構裡。

也就是說，它不只驗 XML 格式，而是在驗「是否按修訂語義編輯」。

這對 agent 特別重要，因為 AI 常見錯誤是：

直接改正文，沒包進 <w:ins> / <w:del>
在別人的插入或刪除結構裡改壞層級
最終文字改了，但 redline 語義不成立

這個 validator 就是在擋這類「看似可用、其實語義錯誤」的問題。

4. Schema 與輔助層：`schemas/`、`helpers/`、`templates/`

`schemas/`

這裡放的是一整套 OOXML / ECMA / Microsoft 擴展相關 XSD。
代表校驗規則盡量基於正式 schema，而不是臨時規則。

`helpers/`

這裡主要有：

merge_runs.py
simplify_redlines.py

作用是對解包後的 Word XML 做適度清理，讓結構更穩定、更易編輯與比對。

`templates/`

這裡存放評論功能依賴的 XML 模板，如：

comments.xml
commentsExtended.xml
commentsIds.xml
commentsExtensible.xml
people.xml

這些模板很重要，因為很多 Word 部件不是「缺了會自動補」，而是必須按 Office 接受的格式預置。

典型使用方法

從 SKILL.md 的建議看，這個 skill 很適合以下工作流。

場景一：讀取或分析既有 DOCX

若目標是抽取內容、閱讀結構、轉 Markdown，優先用：

1

pandoc --track-changes=all document.docx -o output.md

若要看底層 XML，則用：

1

python scripts/office/unpack.py document.docx unpacked/

前者適合讀內容，後者適合看結構。

場景二：新建 DOCX

這個 skill 建議用 docx-js 生成，而不是手搓 OOXML：

1

npm install -g docx

生成後再校驗：

1

python scripts/office/validate.py doc.docx

適合報告、memo、letter，以及含標題、目錄、頁腳、分頁、表格的正式文件。

場景三：編輯既有 DOCX

這是最核心的流程：

1
2
3


python scripts/office/unpack.py document.docx unpacked/
# 修改 unpacked/ 下的 XML
python scripts/office/pack.py unpacked/ output.docx --original document.docx

重點在 --original。
它讓系統在回包時做 schema 與 redline 層面的驗證，而不是盲目打包。

場景四：接受所有修訂

1

python scripts/accept_changes.py input.docx output.docx

這一步依賴 LibreOffice，適合把已審閱文件整理成乾淨版。

場景五：添加評論

1
2


python comment.py unpacked/ 0 "Comment text"
python comment.py unpacked/ 1 "Reply text" --parent 0

要注意：腳本會補評論內容與必要部件，但仍需按註解在 document.xml 補上 comment range marker，才能把評論正確掛到文字範圍。

這個 skill 最值得注意的幾個坑

若只快速掃過 SKILL.md，很容易低估裡面「相容性規則」的價值。以下幾點尤其重要。

1. `.docx` 不是純文字檔，而是 Office 套件

最大的誤區是把它當作「有格式的文字檔」。
實際可能同時涉及正文 XML、relationships、content types、comments / people / ids、schema 約束、修訂語義。

所以這個 skill 才會強調「解包 - 編輯 - 校驗 - 回包」。

2. `docx-js` 能生成，不代表預設值符合你的目標

SKILL.md 明確提到多個預設陷阱，例如 A4 預設、橫向頁面寬高邏輯、列表 bullet、表格寬度雙重宣告、Google Docs 百分比寬度相容性等。

生成工具只是起點，不是最終品質保證。

3. 評論與修訂都不是單點修改

無論 comment 或 tracked changes，都不是改一個 XML 就結束。
需要維護多部件一致性，這正是腳本化的價值。

4.「能開啟」不等於「改對了」

文件能被 Word 開啟，不代表結構正確。
很多問題會在再次編輯、審閱模式、批註顯示、Google Docs 開啟、重新接受修訂時才暴露。

因此 validate.py 和 pack.py --original 非常關鍵。

5. 依賴外部工具時要先備好環境

這個 skill 依賴：

pandoc
LibreOffice / soffice
docx-js
Python 依賴，如 defusedxml、lxml

如果環境缺工具，即使流程正確也無法完整執行。

這個 skill 適合什麼，不適合什麼

適合

批量生成 Word 報告
結構化產生正式文件
自動化修改 .docx
保留或處理 tracked changes
自動加入批註
把 Word 文件納入腳本或 agent 工作流

不太適合

只做簡單 PDF 導出
只要純文字內容，不在意 Word 格式
完全依賴手動可視化編輯
期待零依賴、零環境準備完成全部 Word 自動化

總結

Anthropic 的 skills/docx 強項不在「會生成 Word」，而在「知道 Word 為什麼容易出問題，並先把問題拆開處理」。
它把文件生成、底層 XML 編輯、修訂語義、schema 校驗、Office 相容性等原本零散的知識，整理成一條可執行工作流。

若只是偶爾導出簡單文件，它可能略重；
但只要場景涉及既有 .docx 修改、評論、修訂、自動化批處理或相容性要求，這套 skill 的價值就很高，因為它補上的正是 AI 最容易忽略、也是 Office 文件最容易翻車的細節。

簡單總結：

SKILL.md 負責定義路徑
scripts/office/* 負責解包、回包、校驗與相容性
comment.py 與 accept_changes.py 負責 Word 專項能力
schemas/ 與 validators 把「看起來能用」提升到「結構上可靠」

程式位置：https://github.com/anthropics/skills/tree/main/skills/docx

這個 skill 解決什麼問題

目錄與程式組成

1. 說明層：SKILL.md

2. Office 包操作層：scripts/office/*

unpack.py

pack.py

validate.py

soffice.py