docx

docx skill 概覽

docx skill 的用途是什麼

docx skill 可協助代理更可靠地建立、檢查與修改 Microsoft Word .docx 檔案，比起一般泛用提示更少盲點。它特別適合需要真正 DOCX 工作流程的使用者：產出格式完整的 Word 交付文件、擷取內容供審閱、編修既有檔案、處理註解與追蹤修訂，或直接操作 Office XML 結構來修復套件層級的問題。

哪些人適合安裝 docx skill

如果你經常需要做以下事情，就很適合安裝這個 docx skill：

• 產出 Word 文件，而不只是純文字
• 不必手動點開 Word，也能編輯既有 .docx
• 保留文件結構，例如標題、註解與修訂記錄
• 先把舊版 .doc 轉成可後續處理的格式
• 當一般文字擷取不夠時，深入檢查套件內容

對於 AI 輔助文件作業來說，如果最終輸出必須仍是可用的 .docx，而不只是 markdown 草稿，這個 skill 尤其實用。

docx skill 和一般提示有何不同

docx skill 最大的差異，在於它對工作流程的掌握非常具體。它不會把 DOCX 視為「只是文字」。這個 skill 明確知道 .docx 本質上是由 XML 檔組成的 ZIP 封裝，因此會依照不同任務，引導代理走對的處理路徑：

• 用 pandoc 做偏重文字的讀取與擷取
• 透過 unpack/edit/repack 進行結構層級的修改
• 用 LibreOffice 自動化完成部分格式轉換與接受追蹤修訂
• 當 XML 編輯可能導致檔案損壞時，加入驗證與修復步驟

因此，對於 DOCX 工作流程來說，docx skill 比起單純一句「幫我寫份報告」的泛用指令，更可信也更實際。

最適合用 docx skill 處理的工作

當你的真實需求是以下其中一種，就很適合使用 docx skill：

• 「建立一份含章節與專業格式的 Word 報告」
• 「讀取這個 .docx 並摘要內容，包括追蹤修訂」
• 「替換或重整現有 Word 檔中的內容」
• 「以程式方式加入註解或處理修訂」
• 「先把 .doc 轉成 .docx，再安全地編修」

採用 docx skill 前要先知道的重要限制

這個 skill 不是萬用辦公室套件。它最擅長的是明確指向 .docx 的任務。以下情境就不是它最理想的適用範圍：

• PDF
• 以 Google Docs 原生協作為主的流程
• 試算表比重很高的工作
• 必須靠 Word 桌面版人工微調才能達到的版面精準度
• 不能安裝任何本機工具，例如 pandoc 或 LibreOffice 的使用者

實際上的取捨是：docx skill 能提供更多控制力，但套件層級編修本身就需要更謹慎。

如何使用 docx skill

先看安裝情境，不要只找指令

該 repository 並沒有在 SKILL.md 內標示單一正式的 docx install 指令，所以比較正確的理解方式是：你會先從 Anthropic skills repository 加入這個 skill，再搭配本機輔助腳本與外部工具使用。實務上，如果你正在評估 docx usage，應先假設可能需要：

• Python
• pandoc，用於讀取與偏轉換型的內容擷取
• LibreOffice soffice，用於 .doc 轉換與接受修訂
• 能執行內附 Python 腳本的 shell 環境

如果你的環境會阻擋偏 GUI 的辦公軟體工具，或不允許原生 subprocess 呼叫，務必要先確認。這通常才是真正卡住採用的主因。

先讀這些檔案

若想最快掌握全貌，建議依這個順序閱讀：

1. skills/docx/SKILL.md
2. skills/docx/scripts/office/unpack.py
3. skills/docx/scripts/office/pack.py
4. skills/docx/scripts/accept_changes.py
5. skills/docx/scripts/comment.py
6. skills/docx/scripts/office/soffice.py

這條閱讀路徑能直接看出 docx skill 的實際運作模型：先讀取、再解包、修改、驗證、重新封裝，只有在 XML 編輯不適合的情況下，才交給 LibreOffice。

依任務選對工作流程

一份好用的 docx guide，第一步就是先選對處理路線：

• 讀取或分析內容： 使用 pandoc，或直接檢查解包後的 XML
• 建立新文件： 使用 SKILL.md 中提到的文件產生路徑
• 編修既有文件： unpack → 修改 XML/assets → repack
• 將 .doc 轉成 .docx： 先用 LibreOffice 做轉檔
• 接受追蹤修訂： 使用內建的 LibreOffice macro 輔助工具
• 加入註解： 使用 comment script，並正確插入 XML 標記

如果跳過這一步，一開始就直接動手編，品質通常會很快下滑。

docx skill 需要哪些輸入，才能產出可靠結果

若想讓 docx usage 穩定，提供給代理的資訊不能只有「幫我做個 Word 文件」。較理想的輸入通常包含：

• 若是編修，提供來源檔案路徑
• 預期輸出檔案路徑
• 這次任務是建立、讀取、轉換、加註解，還是修訂
• 格式需求，例如標題層級、頁碼、目錄、表格、信頭
• 是否必須保留追蹤修訂或註解
• 文件中是否有圖片、表格或樣板，而且必須完整保留

較弱的提示：

• 「幫我編輯這份 Word 文件。」

較強的提示：

• 「打開 contract_review.docx，保留追蹤修訂，摘要所有註解，然後建立一份新的 executive_summary.docx，包含 H1/H2 標題、簡短風險表格，以及最後的建議章節。」

使用者真正會在意的實用指令

repository 裡直接浮現出幾個高價值操作：

先把舊版 .doc 轉掉，再做其他事：

python scripts/office/soffice.py --headless --convert-to docx document.doc

擷取文字，同時保留修訂脈絡：

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

把 DOCX 解包，進行 XML 層級修改：

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

修改完成後重新封裝：

python scripts/office/pack.py unpacked/ output.docx --original document.docx

這些指令正好體現了 docx for DOCX Workflows 的核心價值：不只是寫文字，而是能比較安全地操作 Word 套件本身。

如何下提示，讓 docx skill 正確觸發

當你的請求把檔案類型與操作說清楚時，這個 skill 比較容易正確啟動。建議明確包含：

• .docx
• 你要的最終結果
• 是在既有檔案上作業，還是從零開始
• 哪些內容一定要保留

較好的觸發範例：

• 「根據這些筆記建立一份格式完善的 .docx 董事會備忘錄。」
• 「讀取這個 .docx，擷取文字並包含追蹤修訂。」
• 「解包這個 .docx，更新封面頁後再重新封裝。」
• 「在這份 Word 文件的指定段落加入審閱註解。」

如果你其實需要的是套件安全的編輯，就不要只用像「把文件改好一點」這種模糊說法。

什麼時候該用 pandoc，什麼時候該直接改 XML

這是最重要的實務判斷之一。

以下情況適合用 pandoc：

• 想擷取易讀文字
• 想轉成 markdown
• 想更容易檢視追蹤修訂
• 重點在內容分析，而不是版面或結構手術

以下情況適合用 unpack/edit/repack：

• 要處理註解
• 要做理解追蹤修訂的結構性修改
• 要替換圖片或其他套件部件
• 要直接修正 word/ 底下的 XML 與 relationships

如果你的目標是語意閱讀，直接改 XML 通常太重。反過來說，如果你要的是精準修改 DOCX，本身只做純文字擷取通常不夠。

追蹤修訂與註解的特殊處理

這個 repository 在這方面的支援相當務實：

• scripts/accept_changes.py 會透過 LibreOffice 接受追蹤修訂
• scripts/comment.py 協助把註解插入解包後的文件
• scripts/office/helpers/ 裡的輔助程式會處理 run 合併與 redline 簡化

這很重要，因為一旦文件含有修訂，原始 DOCX XML 會變得複雜得多。如果你的文件涉及法務審閱、編輯註解或多方協商版本，docx skill 會比一般文件產生器更值得考慮。

小心 DOCX XML 特有的品質陷阱

有些失敗模式很容易被忽略：

• 註解標記必須正確放在 document.xml 裡
• 註解文字應先做 XML escaping
• DOCX 編修可能破壞 relationships 或 schema 有效性
• run 過度碎裂時，search/replace 會變得不可靠
• 追蹤修訂會扭曲表面上看見的文字流

內建的 pack/validate 路徑能降低風險，但不代表你可以不仔細定義任務。

可能阻礙採用 docx skill 的環境細節

在評估 docx install 時，辦公軟體自動化往往是實際阻礙。repository 裡的 soffice.py 特別處理了 sandbox 環境：在 Unix sockets 失效時，可能需要 LD_PRELOAD shim。這是一個很明確的訊號，表示作者本來就預期實際部署會遇到環境摩擦。

如果你的部署環境無法執行 LibreOffice，有些流程仍然可用，但：

• .doc 轉換會更麻煩
• 不能使用提供的腳本來接受追蹤修訂
• 某些「像自動操作 Word 一樣處理」的需求，可能得改用別的工具鏈

建議採用的 docx skill 工作流程

一個穩定好用的預設 docx guide 工作流程如下：

1. 先確認來源是 .doc 還是 .docx。
2. 如果需要，先把 .doc 轉成 .docx。
3. 判斷任務是文字擷取，還是套件層級編修。
4. 只有在需要結構層級修改時才解包。
5. 進行精準修改，不要對 XML 做大範圍 regex 式改寫。
6. 若可行，重新封裝時用原始檔做驗證比對。
7. 最後用 Word 或 LibreOffice 開啟輸出，做一次視覺 smoke test。

這套流程能避開最常見的檔案損壞與結果不一致問題。

docx skill 常見問題

docx skill 適合新手嗎？

適合，但前提是你的需求明確而且範圍有限，例如轉檔、擷取內容或做小幅修改。不過，進階的 docx usage 很快就會進入套件層級 XML 操作。新手只要遵守有引導的工作流程，不把 Word 檔當成一般文字 blob 亂處理，仍然可以用得很成功。

什麼情況下 docx skill 會比一般寫作提示更好？

當輸出必須是實際可用的 Word 檔，或你必須保留既有 .docx 的結構時，就該用 docx。一般寫作提示可以幫你起草內容，但通常不會告訴代理如何安全地轉檔、解包、驗證，或處理註解與修訂。

docx skill 可以從零建立新文件嗎？

可以，但 repository 最有力的證據主要集中在實際檔案操作與編修工作流程，而不只是產生文字內容。如果你的核心需求只是「寫內容」，很多工具都做得到；但如果你要的是「交付或編修一份可正常使用的 .docx」，這個 skill 更合適。

docx skill 能處理舊版 .doc 檔嗎？

可以，但不是直接原生處理。舊版 .doc 應先透過 LibreOffice 轉換。這是一條很重要的邊界：docx skill 是為 .docx 工作流程設計的，不是拿來直接編輯原生 .doc。

docx skill 適合法務或高審閱量文件嗎？

有可能很適合，因為在這個 repository 裡，追蹤修訂、註解與驗證都是一等公民。不過，審閱密集型文件在產出後，仍然應該用 Word 相容編輯器實際打開檢查一次，確認可見行為是否正確。

什麼情況不該使用 docx skill？

以下情況可略過這個 docx skill：

• 你只需要純文字輸出
• 最終目的地是 PDF，不是 Word
• 工作流程以 Google Docs 為主
• 你無法執行它依賴的本機工具
• 你更在意桌面出版等級的像素級版面精準度，而不是可編輯的 DOCX 結構

如何改進 docx skill 的使用效果

給 docx skill 明確的輸出限制

想讓 docx 結果更穩，最快的方法就是明確指定最終成品，而不只講主題。建議包含：

• 目標檔名
• 來源檔名
• 哪些要保留、哪些可重寫
• 必要章節
• 風格限制
• 註解、修訂、圖片或表格是否必須完整保留

這能降低工具選錯路的機率，也能避免代理預設走向只處理文字的路徑。

先要求代理說明要走哪一條流程

若想提升 docx usage 品質，可以先要求代理在執行前說明它要採用哪種路徑：

• pandoc
• unpack/edit/repack
• LibreOffice conversion
• comment 或 revision tooling

例如：

• 「開始編輯前，先告訴我這個任務應該用 pandoc 擷取還是 unpack/repack，並說明原因。」

這個簡單步驟，往往能及早抓出很多方向選錯的問題。

做搜尋與取代時，最好補上結構提示

如果你要做內容替換，請盡量指出內容位於哪裡：

• 內文
• 頁首／頁尾
• 註解
• 表格
• 封面頁
• 特定章節標題

原因很實際：DOCX 文字常被拆散在很多 runs 裡。若只給一句模糊的「把所有提到的地方都改掉」，很可能會漏改，甚至破壞格式。

處理註解與 XML escaping 時要特別小心

加入註解時，最好提供乾淨且 XML-safe 的文字。repository 已明確指出，註解文字應事先做 escaping。若你的註解裡包含 ampersands、智慧引號或特殊符號，請明講這些內容必須 escape 或 normalize。

這看似小細節，但會直接影響結果檔案能否正常開啟。

只要有原始檔，就盡量使用原檔驗證

重新封裝時，如果你手上有來源檔，請加上 --original。這會讓驗證器擁有更多上下文，也讓 docx skill 在編修既有文件時更安全。這是整個 workflow 裡最值得養成的習慣之一。

第一版輸出後，用檔案層級的回饋來迭代

不要只說「看起來不對」。更有效的後續回饋會像這樣：

• 「文件打得開，但 Word 裡看不到註解。」
• 「追蹤修訂被攤平成最終文字了，請保留修訂。」
• 「內文有更新，但頁首品牌資訊還是舊的。」
• 「XML 有成功封裝，但表格區塊的格式壞掉了。」

這種回饋能幫助代理判斷下一步該怎麼修，而不是盲目重試。

需要及早排查的常見失敗模式

在把流程擴大之前，先留意以下問題：

• 輸出檔打得開，但註解消失
• 追蹤修訂被不小心接受或遺失
• 修改只影響可見內文，沒有碰到頁首／頁尾
• 智慧引號或特殊符號導致 XML 壞掉
• 重新封裝後 ZIP 看似正常，但 Word 無法開啟

在大量處理之前，先拿小文件做一次快速 smoke test，非常值得。

如何讓複雜 docx 檔案得到更好的結果

面對複雜的 docx for DOCX Workflows，建議把任務拆開：

1. 先擷取並檢查內容
2. 確認實際要修改的位置
3. 每次只套用一種類型的修改
4. 重新封裝並驗證
5. 做視覺確認

這比一次到位的單輪提示慢，但對樣板、合約、報告，以及修訂很多的文件來說，可靠得多。

如果你要延伸 docx skill，本身最值得改善的是什麼

如果你評估的是如何改進 docx skill 本身，最有價值的補強方向會是：

• 為常見任務提供更清楚的 documented entrypoints
• 把範例提示對應到各種 workflow lane
• 提供更精簡明確的安裝／前置需求清單
• 更清楚區分「建立新文件」與「編修既有文件」的操作指引
• 補上註解、redlines、圖片替換的端到端範例

這些改進比起再增加泛泛的說明文字，更能降低採用門檻。