Agent Skill on KnightLi的博客

使用 AI 維護 Hugo 多語言部落格的 Agent Skill

Mon, 06 Apr 2026 10:00:00 +0800

如果你正在維護 Hugo 多語言部落格，常常會遇到一個高頻痛點：

中文寫完後，還要同步生成英文與繁體版本
三個語言檔需要保持結構一致
front matter 既要翻譯，也要符合 Hugo 格式

sync-post-translations 就是為這個場景設計的 Agent Skill。

這個技能解決什麼問題

sync-post-translations 的定位很清楚：

以 index.zh-cn.md 作為來源檔
在同一目錄生成或更新 index.en.md、index.zh-tw.md
保持 Markdown 結構一致
對 front matter 套用明確規則（尤其是 date、slug）

適用觸發詞示例：

「同步翻譯英文繁體」
「把這篇文章同步成英文和繁體」

技能目錄結構

.\sync-post-translations\
├─ SKILL.md
└─ agents\
   └─ openai.yaml

核心程式碼一：SKILL.md

以下是此技能的核心規則檔：

---
name: sync-post-translations
description: 将 Hugo 文章从简体中文源文件（`index.zh-cn.md`）同步翻译为英文（`index.en.md`）和繁体中文（`index.zh-tw.md`）。当用户提出“en 繁体”“同步翻译英文繁体”或要求同时生成/更新两种语言版本且需保持 front matter 与 Markdown 结构一致时使用。
---

# 同步文章翻译

使用此技能为同一篇文章生成或更新多语言版本。

## 工作流程

1. 在目标文章目录中定位源文件 `index.zh-cn.md`。
2. 读取完整 front matter 与正文内容。
3. 在同目录创建或更新 `index.en.md` 与 `index.zh-tw.md`。
4. 确保三语结构对齐后执行 Hugo 构建检查。

## 翻译规则

1. 严格保留 `slug` 原值。
2. `date` 统一规范为 Hugo 常用带时间格式（RFC3339），示例：`2026-04-05T10:00:00+08:00`。
3. 自然翻译以下 front matter 字段：`title`、`description`、`tags`、`categories`。
4. 保持 Markdown 结构不变：标题层级、列表形态、代码块、链接与命令行示例。
5. 技术标识符保持原样：文件名、CLI 参数、模型名、设备名、URL、包名等。
6. 若 YAML 的 `title` 含有 `:`，必须加引号，避免解析报错。
7. 在不改变语义前提下，使用目标语言自然标点与表达习惯（`en`、`zh-tw`）。

## 输出约定

1. 仅在源文章同目录写入目标文件。
2. 汇报变更的文件路径。
3. 条件允许时执行 `hugo --source . --destination public`，并反馈通过/失败；失败时给出关键报错行。

## 质量标准

1. 全文术语前后一致。
2. 避免机器直译感，优先可发布文风。
3. 章节内容完整，不省略示例、注意点与总结。

核心程式碼二：agents/openai.yaml

這個檔案定義了技能在 Agent 端的展示與預設提示詞：

interface:
  display_name: "同步文章翻译"
  short_description: "生成或更新 EN + ZH-TW 翻译稿"
  default_prompt: "使用该技能在同一 Hugo 文章目录中，从 `index.zh-cn.md` 生成或同步 `index.en.md` 与 `index.zh-tw.md`，保留 `date` 与 `slug`，保持 Markdown 结构一致，并执行 Hugo 构建校验。"

實戰調用示例

1) 面向人的自然語言觸發

1
2

请把 content/post/2026/04/06/index.zh-cn.md 同步翻译成英文和繁体，
要求 date 用 RFC3339，slug 不变，最后跑 hugo 校验。

2) 你應該期待的輸出結果

已更新：
- content/post/2026/04/06/index.en.md
- content/post/2026/04/06/index.zh-tw.md

构建校验：
- hugo --source . --destination public
- 结果：PASS

為什麼這些規則很關鍵

slug 保持不變，可以穩定 URL 與歷史外鏈。
date 統一為 RFC3339（含時區）可避免 Hugo/主題在時間解析上的歧義。
Markdown 結構不變，可避免翻譯後目錄、程式碼區塊、短代碼渲染錯位。
技術標識符不翻譯，可顯著降低「命令不可用／檔名不匹配」問題。

常見坑位與規避

title 裡有 : 卻沒加引號，YAML 會解析失敗。
把 --flag、URL、套件名翻譯了，示例命令會直接失效。
三語標題層級不一致（例如中文 ## 變成英文 ###），目錄錨點會錯位。
只翻譯正文不處理 front matter，頁面列表與 SEO 資訊會異常。

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

Sat, 04 Apr 2026 11:00:00 +0800

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