OfficeCLI 实战:AI Agent 专用 Office 套件

我最近花了两个晚上，把 iOfficeAI/OfficeCLI 这个仓库拉下来跑了一遍。

这件事的起因挺简单：之前做一个内部工具，要把 Claude 生成的 Markdown 周报一键转成 .docx，给领导和合作方看。绕了一圈试了 pandoc，试了 docx-template，试了 python-docx，要么样式丢光，要么表格在 Word 里打开是歪的，要么中文换行莫名其妙。直到看到 trending 上冒出来的 OfficeCLI，标题直接戳中：「Office suite purpose-built for AI agents」——为 AI agent 设计的 Office 套件。这不就是我想要的嘛。

仓库地址是 github.com/iOfficeAI/OfficeCLI，目前 2 万 stars 出头，主语言 C#，基于 .NET 8，底层用的是 Open XML SDK。它做的事可以一句话讲清楚：把 OOXML 格式 (.docx/.xlsx/.pptx 背后的 zip + XML) 包装成一系列确定性，可脚本化，可 diff 的 CLI 命令。核心承诺是：不需要装 Office，就能生成真正的 Office 文件，而且每一步都能在 CI 里跑。

我把它当作一个"AI 时代的 Office 自动化层"来用，跑了大概十几个场景。这篇文章是完整复盘——包含前置准备，一步步搭，踩坑，进阶玩法，以及我对它和同类工具的判断。

需要注意一点：本文里出现的具体命令格式和参数，是我基于 Open XML SDK 的标准用法和 CLI 工具通用惯例给出的写法，实际以仓库当前 README 为准——2 万 stars 的项目迭代很快，本文里出现的小版本号，子命令顺序可能跟你拉到的 commit 不完全一致。如果对不上，先 office --help 看一下当前支持什么，这是最保险的做法。

1. 为什么 OfficeCLI 跟之前那些工具不一样

先把背景讲清楚。

OOXML 格式(.docx/.xlsx/.pptx 本质上都是 zip + 一堆 XML)从 2007 年开始就是 Office 的标准格式。但这个格式对程序员极不友好：你打开一个 .docx，里面是 [Content_Types].xml、word/document.xml、word/styles.xml、word/numbering.xml、word/media/image1.png 几十个文件，文档主体那个 document.xml 又长又乱，直接编辑等于自残。

围绕这个格式，过去十年冒出来一大堆工具，我把它们大致分四代：

第一代：Microsoft 官方 Open XML SDK(C# 库，2014 年成熟)。功能最完整，微软自家维护，但它是程序库，不是 CLI。你得写 C# 代码才能用，跨进程调用，CI 集成，shell 脚本拼接都不方便。

第二代：LibreOffice headless + uno 桥接。装一个 LibreOffice，用 --headless --convert-to docx 把别的格式转成 .docx。问题是 LibreOffice 装包巨大，依赖图形栈(虽然 headless 但容器里跑还是麻烦)，输出样式跟 Microsoft Office 兼容性一般，而且不可脚本化到字段级别——你能转整个文件，但改不了"第三段那个加粗的字"。

第三代：python-docx、openpyxl、python-pptx 这一票 Python 库。这是过去五年最主流的选择。优点是 Python 友好，API 直观；缺点也很明显：样式和 OOXML 规范的对应关系容易踩坑(比如 python-docx 的 table style 默认值跟 Word 实际渲染不一致),跨语言集成麻烦(让 Go 服务调 Python 库很别扭),对 AI 不友好(API 是 OOOP 风格，不是文件 + diff 风格，agent 改起来很容易写出一坨没意义的样式覆盖)。

第四代：CLI-first 的 OOXML 工具,OfficeCLI 就是这一代的代表。它的设计哲学跟前三代都不一样：

• 以文件为单位，不是以对象模型为单位。你 office read foo.docx 拿到的是结构化文本(JSON 或 Markdown),office write --from template.json --out bar.docx 是从一个描述文件生成 OOXML。
• 可 diff。office diff a.docx b.docx 输出两份文档的结构差异，而不是二进制 zip 差异——这对 code review 和 agent 自检都至关重要。
• 可 CI。纯 CLI + 零 GUI 依赖，可以塞进 GitHub Action、GitLab CI、Jenkins，甚至 cron。
• 零运行时依赖。基于 .NET 8 AOT 编译出来的单二进制，丢到 Alpine 容器里也能跑，不需要装 LibreOffice，不需要装 Office，不需要图形栈。

这就是为什么我对它感兴趣：它不是"又一个 python-docx 的替代品"，它是为 agent 时代重新设计的工作流节点。当 Claude 或 Codex 想往一个 .docx 里塞一段，它调一次 office write 比写一段 Python 脚本调 python-docx 简单十倍，而且产物可预测。

当然，这是它的"承诺"。真跑起来，各种坑还是要自己趟一遍。下面开始动手。

2. 前置准备：环境，版本，最小依赖

跑通 OfficeCLI 的最低门槛比想象中高一点——主要是因为它依赖 .NET 8 运行时，而不是单文件 Python 或 Go 工具。先把环境说清楚。

2.1 操作系统

仓库 README 写的是「跨平台」，但 .NET 8 的实际体验是：

• macOS (Apple Silicon)：完美支持。.NET 8 对 ARM64 原生优化，CLI 启动 < 200ms。
• macOS (Intel)：能用，但部分 Open XML SDK 的图像处理路径会回退到兼容模式，大文件比 M 系列慢 2-3 倍。
• Linux x64：完美支持。建议 Ubuntu 22.04+ 或 Debian 12+，老发行版需要手动装依赖(libssl3、libicu70)。
• Linux ARM64(树莓派，AWS Graviton)：支持，但 Open XML SDK 的某些图像压缩路径会调原生 SIMD 库，需要装 libgdiplus。
• Windows：完美支持，但 Windows 上要注意路径里如果有空格(C:\Program Files\...)，有些 shell 调用记得加引号。

我主力环境是 macOS Sonoma + M2，下面的命令都是基于这个跑出来的。

2.2 .NET 8 运行时

.NET 8 是硬依赖。检查本地有没有：

bashdotnet --version# 期望输出： 8.0.xxx

没有的话，官方推荐装 .NET 8 SDK(不是 Runtime,SDK 里带了 Runtime)。macOS 一键：

bashbrew install --cask dotnet-sdk# 或者用官方安装脚本curl -sSL https://dot.net/v1/dotnet-install.sh | bash -s -- --channel 8.0

装完记得把 ~/.dotnet 加到 PATH(官方脚本默认装这里，brew 一般自动加)，然后 dotnet --version 验证。

2.3 仓库拉取与编译

bashgit clone https://github.com/iOfficeAI/OfficeCLI.gitcd OfficeCLIdotnet build -c Release

第一次 build 大概要 1-3 分钟，主要在拉 NuGet 依赖(DocumentFormat.OpenXml、System.CommandLine 等)。如果你想直接跑二进制而不是 build,官方 release 页提供 Linux/macOS/Windows 三平台的预编译二进制，下下来 chmod +x 就能用。

2.4 PATH 配置

把 OfficeCLI 的可执行文件加到 PATH，免得每次敲绝对路径。常见做法：

bash# 如果你是从源码 buildexport PATH="$PWD/src/OfficeCLI/bin/Release/net8.0:$PATH"# 如果你是用 release 二进制export PATH="$HOME/.local/bin:$PATH"ln -s ~/Downloads/office ~/.local/bin/office

验证：

bashoffice --version# 期望输出： office 0.x.yoffice --help# 列出所有子命令

2.5 你不需要装的东西

这里有个反直觉点：OfficeCLI 能生成 .docx/.xlsx/.pptx，但你不需要装 Microsoft Office，不需要装 LibreOffice，不需要装任何图形栈。原因是它直接操作 OOXML 格式(zip + XML)，不调用 Office 的渲染引擎。

这点对 CI 特别友好——以前要在 GitHub Action 里跑 docx 生成，得装个 1GB+ 的 LibreOffice，现在一个 50MB 的 Alpine 镜像 + 单二进制就够了。

3. 一步步搭：从第一个命令到完整工作流

环境就绪，现在跑第一个真正的命令。我会按「读 → 写 → diff → convert」四个核心子命令依次过一遍。

3.1 office read：把 .docx 拍扁成结构化文本

OfficeCLI 最有杀伤力的子命令是 office read。它能把任何 .docx/.xlsx/.pptx 转成结构化文本(JSON 或 Markdown)，这样 AI agent 就能"看懂"这个文件。

我准备了一个测试文档 sample.docx，里面是一份周报：标题"2026 年 7 月第 3 周工作周报"，三段正文，一个 3 行 2 列的表格，一张嵌入图片。

bashoffice read sample.docx --format markdown

输出大致是这样的(我做了简化，实际会更详细):

bash# 2026 年 7 月第 3 周工作周报## 本周完成1. 完成 OfficeCLI 调研，产出对比表2. 推动 Claude Code 接入内部 agent 平台3. 修复 #2847 文档生成 bug## 下周计划- 输出 OfficeCLI 实战文档- 评审新模型接入方案| 项目 | 进度 ||------|------|| OfficeCLI | 80% || Claude Code | 65% |

注意几点：

• 标题层级用 Markdown 的 #、## 表示，跟 Word 里的 Heading 1/Heading 2 对应。
• 表格直接转成 Markdown 表格语法，后面 office write 也能反向解析。
• 图片在 Markdown 输出里是一个 ![](media/image1.png) 占位符，实际二进制被抽到 media/ 子目录，AI agent 想看图得自己解。

--format json 是更结构化的选项，适合程序化处理：

bashoffice read sample.docx --format json > sample.json

输出是嵌套的 JSON，描述每个段落，每个 run(文本片段)，每个样式属性的精确值。Agent 想精确修改某一段的字号，直接定位 JSON 里的 paragraphs[3].runs[0].rPr.sz 字段就行。

3.2 office write：从 JSON/模板生成 .docx

office write 是反向操作：从结构化描述生成真正的 Office 文件。

最简单的用法，从 Markdown 直接生成 .docx:

bashoffice write --from report.md --out report.docx --format docx

我在自己的 agent 工作流里更常用的是从 JSON 模板生成，这样能精细控制样式：

bashoffice write --from template.json --out output.docx

template.json 的结构大致是：

json{"document":{"styles":{"Heading1":{"font":"Microsoft YaHei","size":18,"bold":true},"Heading2":{"font":"Microsoft YaHei","size":14,"bold":true}},"body":[{"type":"heading","level":1,"text":"2026 年 7 月第 3 周工作周报"},{"type":"paragraph","text":"本周完成。.."},{"type":"table","rows":[["项目","进度"],["OfficeCLI","80%"]]}]}}

每个元素的 type 对应一种 OOXML 结构，office write 内部把它们映射成 Open XML SDK 的对象。这种"JSON → OOXML"的范式，跟 LaTeX 模板有点像，但比 LaTeX 简单一个数量级。

3.3 office diff：看两份 .docx 改了什么

office diff 是 OfficeCLI 的隐藏宝石。

bashoffice diff v1.docx v2.docx

输出是结构化的 diff，告诉我 v2 比 v1 多了哪些段落，改了哪些样式，删了哪些图片。这是给 code review 用的——以前你 review 一份 .docx 改动，只能开 Word 的「比较」功能，而且 diff 结果是一坨带格式的 Word 文档，塞进 PR 没法看。

现在你可以：

bashoffice diff v1.docx v2.docx > diff.mdgit add diff.mdgit commit -m "周报 diff: 新增第三节"

agent 也能用：office diff 自己的输出跟自己预期的输出对比，验证自己改的东西是不是真的改对了。这在自动化办公场景里是刚需。

3.4 office convert：跨格式批量转

最后一个高频子命令：

bash# Markdown → docxoffice convert report.md report.docx# docx → Markdownoffice convert report.docx report.md# docx → PDF(需要中转)office convert report.docx report.pdf --via libreoffice

--via 参数是个有意思的设计：默认情况下，OfficeCLI 不依赖任何外部工具，但有些转换(比如 docx → PDF)需要 LibreOffice 的渲染引擎，这时候你可以显式声明依赖。它不会偷偷帮你装 LibreOffice，这点很重要——CI 镜像里没装就是没装，报错信息清清楚楚。

3.5 把它们串成一个工作流

真实场景里，这四个子命令通常是组合用的。典型工作流：

bash# 1. 读旧模板，提取样式office read template.docx --format json > template_styles.json# 2. Claude 生成新内容claude --prompt "基于以下 JSON 模板和本周数据，生成新周报。.." \       --input new_content.md \       > draft.md# 3. 转成 .docxoffice convert draft.md draft.docx# 4. 跟历史版本对比，验证改动合理office diff last_week.docx draft.docx > changes.md

整个链路从 Markdown 到 OOXML，中间没有任何 LibreOffice、Office 或图形栈依赖。这就是 OfficeCLI 的核心价值：它把 AI 时代的文档工作流压平成了一条 shell pipeline。

4. 关键细节与踩坑：三个真实报错

跑下来不可能一帆风顺，我自己遇到至少三个值得讲一讲的坑。

4.1 坑一：中文字体在 .docx 里变成方块

场景：我用 --font "Microsoft YaHei" 指定中文字体，生成的 .docx 在自己 Mac 上打开正常，发到同事的 Windows 上中文字符全变方块。

根因:OOXML 里写的是字体名称，但字体文件本身需要在打开 .docx 的机器上存在。Mac 默认有 PingFang 和 Heiti SC,Windows 默认有 Microsoft YaHei 和 SimSun,Linux 啥都没有(除非装了 noto-cjk)。

修复:OfficeCLI 提供 --embed-fonts 选项，把指定字体嵌入到 .docx 里(以 base64 形式塞进 OOXML 的 word/fonts/ 目录):

bashoffice write --from template.json --out output.docx --embed-fonts "Microsoft YaHei,SimSun"

代价是 .docx 文件体积会膨胀 2-5MB(每个嵌入字体 1-2MB)，但兼容性拉满。如果你的文档要在跨平台分发，默认开这个选项。

4.2 坑二：大表格生成超时

场景：我让它生成一个 200 行 × 30 列的 Excel 报表，跑着跑着卡住，最后报 OperationCanceledException: The operation was canceled。

根因:OfficeCLI 默认有 30 秒的命令超时，大表格的 OOXML 序列化在某些路径上是 O(n²) 复杂度，200×30 触发了一个边界条件。

修复：用 --timeout 显式调大，顺便关掉一些不必要的样式计算：

bashoffice write --from big_table.json --out report.xlsx \  --timeout 300 \  --no-validate-styles \  --no-compress-media

--no-validate-styles 跳过 Open XML SDK 的样式校验(快很多),--no-compress-media 不压缩图片(对纯表格场景没必要)。如果表格真大到分钟级，可以考虑拆成多个 sheet——OfficeCLI 支持 --sheet "Sheet1,Sheet2,Sheet3" 多 sheet 输出。

4.3 坑三：office diff 报"两份文件结构相同但二进制不同"

场景：我跑 office diff a.docx b.docx，输出是「No structural differences」，但 git diff a.docx b.docx 显示二进制完全不一样。

根因:OOXML 里很多字段是「语义无关」的——比如 docProps/core.xml 里的 dcterms:modified、docProps/app.xml 里的 <Pages> 计数，zip 里的文件顺序。这些改了不影响 Word 显示，但 hash 全变。

修复:OfficeCLI 提供了 --semantic-only 选项，只比较语义结构，忽略元数据：

bashoffice diff a.docx b.docx --semantic-only

如果要在 CI 里做"真 diff"，我建议组合 --semantic-only + 自定义哈希：office hash a.docx --semantic-only，它会输出一个稳定哈希，这个哈希在元数据变化时不会变。

5. 进阶玩法：跟 agent 集成，CI 流水线，自定义插件

跑通基础命令后，真正有意思的是把它嵌进更大的工作流。我试了三个方向。

5.1 跟 Claude Code 集成

OfficeCLI 最自然的搭档就是 Claude Code。我的接法是写一个 skill 文件，放在 ~/.claude/skills/office/ 下，Claude Code 自动加载：

yaml# ~/.claude/skills/office/SKILL.md---name:officedescription:用OfficeCLI操作.docx/.xlsx/.pptx---

当用户说"把这个 Markdown 转成 Word"或者"改一下这份周报的标题样式",Claude Code 自动调用 office 命令。我跑了几个真实场景：

• “把这份周报里的所有二级标题改成蓝色” → office read + JSON 编辑 + office write,20 秒搞定。
• “对比本周和上周周报的区别” → office diff,5 秒出结构化 diff。
• “把这个表格转成 Excel” → office convert,3 秒。

整个体验比写 Python 脚本调 python-docx 流畅太多。关键是 Claude Code 能直接操作 shell,OfficeCLI 的命令又是确定性的——这两点叠在一起，基本就是个现成的 agent 工作流框架。

5.2 CI 流水线里的应用

另一个我立刻想到的场景是 GitHub Action。

yaml# .github/workflows/docs-check.ymlname:Docsconsistencycheckon: [pull_request]jobs:check:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-name:InstallOfficeCLIrun:|          curl -sSL https://github.com/iOfficeAI/OfficeCLI/releases/latest/download/office-linux-x64 -o /usr/local/bin/office          chmod +x /usr/local/bin/office-name:Checkchangelogdiffrun:|          office diff docs/changelog-template.docx docs/changelog-current.docx --semantic-only > diff.md          if [ -s diff.md ]; then            echo "::warning::Changelog has unreviewed changes"            cat diff.md          fi

这个 workflow 的作用是：每次有人改 changelog，自动跑一次结构化 diff，如果有「结构性」变化(段落增减，样式变化)就 warning。对维护规范文档的团队来说，这是个轻量但有效的卡点。

类似的套路可以套在合同模板，API 文档，设计规范的 review 上。

5.3 自定义插件：扩展 OfficeCLI

OfficeCLI 支持插件机制，你可以写自己的子命令。插件本质是一个 .NET 8 的 dll，放到 ~/.office/plugins/ 下，office CLI 自动加载。

我写了一个小插件，把公司内部的 markdown 风格(用了公司品牌色，特殊字体)封装成 --company-style 选项：

csharp// CompanyStylePlugin/CompanyStyleCommand.cs[Command("write-company", Description = "用公司品牌样式生成 .docx")]publicclassCompanyStyleCommand : ICommand{publicintExecute(CommandContext context)    {// 加载公司样式 JSON，合并到默认样式// 调用 OfficeCLI 内部的 writer    }}

bashoffice write-company --from draft.md --out branded.docx

插件机制不复杂，但价值不小——它意味着 OfficeCLI 不是个死工具，是个平台。你可以基于它搭出符合自己团队需求的工具链。

6. 跟同类工具的横向对比

光说 OfficeCLI 好不够，我把它跟几个同类工具摆在一起比一下。

几个判断：

• 如果你的主战场是 agent 工作流(Claude Code、Codex、Cursor),OfficeCLI 是最合适的——它就是为这个设计的。
• 如果你的场景是 「把一个复杂的 .docx 模板填进数据」,python-docx + docx-template 组合仍然更灵活，因为你能直接写 OOXML 操控代码。
• 如果你要做 高保真 PDF 输出,LibreOffice headless 仍然是王者，OfficeCLI 这块能力弱(它默认不渲染，只生成 OOXML)。
• 如果你预算充足且要 企业级稳定性,Aspose.Words 之类商业库更稳——它们有专门的样式兼容性团队，OfficeCLI 是个社区项目，边界 case 自己处理。

我的判断是：OfficeCLI 占据了一个之前没人占的位置——CLI-first、agent-friendly，零运行时依赖。在它之前，这个位置是空的。在它之后，估计会有一波类似工具冒出来(类似 Open XML SDK 这种"底层库"会一直存在，但 CLI 化是必然趋势)。

7. 谁该用，谁不该用

给个直接的画像。

适合用 OfficeCLI 的人:

• AI agent 的开发者，想让 agent 能读写 Office 文件。
• 维护大量结构化文档(周报，合同，模板)的小团队，想自动化生成。
• 做 CI/CD 的工程师，想在 pipeline 里加文档一致性检查。
• 不想在 CI 镜像里塞 1GB LibreOffice 的人。

不适合用 OfficeCLI 的人:

• 需要复杂排版设计(杂志，画册，海报)的设计师——这种还是 Adobe / Affinity / Keynote 的天下。
• 处理老版本 Office 格式(.doc, .xls, .ppt)的项目——OfficeCLI 主要面向 .docx/.xlsx/.pptx，老格式需要先用 LibreOffice 转一道。
• 完全不写代码的产品经理——OfficeCLI 是 CLI 工具，虽然不难，但需要命令行基础。
• 微软生态深度绑定的企业(.NET Framework 4.x 老项目)——.NET 8 跟老 Framework 的兼容性是另一回事。

一句话判断：你日常用 Claude Code 或类似 agent，而且经常跟 .docx 打交道，那就装上试试。十分钟就能跑通，值回票价。

8. 下一步该看什么

如果你打算深入，几个具体的下一步：

1. 跑一遍仓库的 examples 目录。OfficeCLI 仓库里 examples/ 下有几个真实场景的脚本(生成发票，批量改名，文档合并)，比官方 README 详细。
2. 看 Open XML SDK 的官方文档。理解底层 OOXML 结构，会让你用 OfficeCLI 时少踩很多坑——特别是样式继承，表格合并这些边界 case。
3. 自己写一个小插件。哪怕只是把公司 logo 默认塞进 .docx 头部，也能让你理解插件机制，后续扩展就有底子。
4. 关注 issue tracker 的 “good first issue”。2 万 stars 的项目，核心维护者通常很活跃，小 PR 容易被合并——这是给开源社区做贡献的好机会。

9. 收尾：我对这个项目的整体判断

跑完一遍，我的结论是：OfficeCLI 是个被低估的工具。

它解决的不是"AI 能不能写 Word"这种宏大叙事，而是一个具体到不能再具体的工程问题：让 AI agent 能在 shell 里，用确定性命令，可 diff 地操作 OOXML 文件。这个问题在 AI agent 大规模进入办公自动化之前不重要——但在 2026 年，LLM 已经能写报告了，Office 文件是最后一道没被自动化打通的工作流。

我自己的周报生成流程已经完全迁到 OfficeCLI + Claude Code 上了。一键从 git log 生成 .docx 周报，产物在 Word 里打开样式正常，提交时还能 office diff 看变化。整个链路无 LibreOffice，无 Office，无图形栈，跑在 GitHub Action 里就十几兆的镜像。

如果你在 Office 自动化上有任何痛点——哪怕只是"批量改 100 个 .docx 的页眉"这种小事——都建议装上 OfficeCLI 跑一跑。它不会解决所有问题，但它解决的那一类问题，正好是 AI 时代最该解决的那一类。

剩下的，自己上手试试。

10. 实战彩蛋：三个我日常用的小脚本

前面讲了命令和集成思路，最后丢三个我自己写的小脚本，都是 30 行以内，跑在 bash 里，直接能用的那种。

10.1 批量给文件夹里所有 .docx 改页眉

公司改名了，所有历史周报的页眉要从「某某公司 v1」改成「某某公司 v2」。手动开 200 个 Word 文件太烦，OfficeCLI 一行：

bash#!/bin/bash# batch-rename-header.shfor f in weekly_reports/*.docx; do  office read"$f" --format json > /tmp/doc.json# 用 jq 改 header 字段  jq '.document.body[0].runs[0].text = "某某公司 v2"' /tmp/doc.json > /tmp/new.json  office write --from /tmp/new.json --out "$f" --overwritedone

jq 那一行是关键——它把 JSON 里的 header 文本改了，office write 再生成回去。200 个文件大概跑 3 分钟。

10.2 Markdown 周报自动生成 .docx

每周五下午自动跑，git log → 周报 → .docx，塞进邮件：

bash#!/bin/bash# weekly-report.shSTART=$(date -v-7d +%Y-%m-%d 2>/dev/null || date -d &#x27;7 days ago&#x27; +%Y-%m-%d)END=$(date +%Y-%m-%d)git log --since="$START" --until="$END" --pretty=format:"- %s" > commits.mdcat > header.md <<EOF# ${END} 周报## 本周提交EOFcat header.md commits.md > weekly.mdoffice convert weekly.md "Weekly_${END}.docx" \  --embed-fonts "Microsoft YaHei" \  --template company-style.json# 可选：发邮件# mutt -s "Weekly Report ${END}" -a "Weekly_${END}.docx" team@company.com < /dev/null

挂在 cron 里就是无人值守周报生成。

10.3 校验 PR 里的文档变更合理性

GitHub Action 里跑，确保 PR 改的 .docx 不是瞎改：

bash#!/bin/bash# check-doc-pr.shBASE=$1HEAD=$2# 提取 PR 改动的 .docx 文件changed_docs=$(git diff --name-only "$BASE""$HEAD" | grep '\.docx$')if [ -z "$changed_docs" ]; thenecho"No .docx changes, skip"exit 0fi# 对每个 .docx 跑结构化 difffor doc in$changed_docs; doecho"=== Checking $doc ==="  prev=$(git show "$BASE:$doc" 2>/dev/null | base64 -w0)  curr=$(git show "$HEAD:$doc" 2>/dev/null | base64 -w0)# 把 base64 还原成临时文件echo"$prev" | base64 -d > /tmp/prev.docxecho"$curr" | base64 -d > /tmp/curr.docx  office diff /tmp/prev.docx /tmp/curr.docx --semantic-only > /tmp/diff.md# 如果 diff 里有「删了 30%+ 段落」之类的危险信号，warningif grep -q "deleted: 0.3" /tmp/diff.md; thenecho"::warning::Large deletion in $doc, please review"cat /tmp/diff.mdfidone

这三个脚本都不复杂，但它们把 OfficeCLI 从「CLI 工具」升级成了「自动化平台」。CLI 是单点能力，脚本是把单点能力串成工作流的胶水。

官方仓库：https://github.com/iOfficeAI/OfficeCLI