OfficeCLI 深度解剖：全球首个为 AI Agent 而生的命令行 Office 套件——三层渐进式架构、确定性 JSON 与自愈错误码的工程真相

一句话开场：过去二十年，我们让人去适应 Office；OfficeCLI 想做的事情反过来——让 Office 去适应机器，尤其是那种不长眼睛、只会读文本的 AI Agent。

如果你最近盯着 GitHub Trending，大概率会注意到一个有点"违和"的项目：iOfficeAI/OfficeCLI。它不是又一个 AI 编程助手，也不是又一个 MCP Server 模板，而是自称"全球首个专为 AI 智能体设计的 Office 套件"。7 月初它单日暴涨上千 star，几天内冲进主榜。

作为一个天天泡在终端、又被各种"让 AI 帮我生成周报 / 填个 Excel 模板 / 抽一堆 PPT 文字"需求折磨的程序员，我看到这个项目的第一反应是警惕：Office 自动化这条赛道尸横遍野，python-docx、openpyxl、Apache POI、LibreOffice --headless……哪个不是十年老兵？再来一个又能怎样？

但把它的设计文档和命令行接口翻了个底朝天之后，我改了主意。OfficeCLI 真正的创新不在"能操作 Office"，而在于它是从 LLM 的认知局限出发倒推出来的一套文档操作范式。这篇文章，我想从第一性原理出发，把它的架构、命令模型、确定性输出、自愈机制一层层拆开，讲清楚它到底解决了什么老问题，又埋了哪些新的坑。

一、背景：为什么"让 AI 操作 Office"是个真问题

先别急着看架构，我们得先回答一个更根本的问题：现有工具到底差在哪？为什么需要专门为 Agent 造一个？

1.1 传统 Office 自动化的三座大山

第一座山：环境依赖地狱。

用过 python-docx 的都知道，写文档还行，但要"读一个已有 docx 的样式、改其中某段的字号、再另存"，代码会迅速膨胀。要处理 xlsx 里的公式、图表、条件格式，openpyxl 的 API 复杂度直接劝退。更别提 PPT——python-pptx 连个像样的排版都费劲。而如果你想要"真·渲染"（比如把 docx 转成图片给人看效果），基本只能上 LibreOffice headless 或者 Microsoft Office COM 自动化，前者一个安装包几百 MB，后者只能跑在 Windows 上还得装正版 Office。

对人来说，这些依赖装一次就好。但对一个要在沙箱、CI、容器里临时拉起的 AI Agent 来说，"装依赖"这一步本身就是失败率最高的环节。

第二座山：非确定性输出。

传统库的输出是给人读的，或者是 Python 对象。当你把它接到 LLM 的工具调用链里，问题就来了：同一个操作，报错信息五花八门，成功了也没有稳定的结构化反馈。Agent 拿到一坨自然语言 traceback，只能靠"猜"下一步怎么办。这是 Agent 工作流最致命的地方——不可预测的反馈无法驱动可靠的自主决策。

第三座山：Agent"看不见"文档。

这是最容易被忽略、却最关键的一点。人改文档，是"所见即所得"：打开 Word，看到第三段字太小，鼠标一拖就改了。但 LLM 没有眼睛，它面对的是一坨 OOXML（Office Open XML）——一个 docx 解压出来就是几十个 XML 文件、命名空间套命名空间的庞然大物。让 LLM 直接读写 OOXML？token 爆炸不说，改错一个闭合标签整个文档就废了。

所以核心矛盾是：Agent 需要一个"既能看见文档语义、又能精确定位并修改元素、还不会把文档改坏"的中间层。 OfficeCLI 的全部设计，都是在回答这个矛盾。

1.2 OfficeCLI 的破题思路

它给出的答案可以浓缩成四条设计公理：

1. 单二进制、零依赖——一个可执行文件，内置渲染引擎，不需要装 Office，curl | bash 一行装完。
2. 确定性 JSON 输出——每个命令都能吐出结构化 JSON，Agent 拿到就能解析，不用猜。
3. 路径化寻址——像操作 DOM / 文件系统一样，用路径精确定位文档里的任意元素。
4. 自愈错误码——报错不是终点，而是带着"怎么修"的提示，让 Agent 能自我纠正。

这四条串起来，就是把 Word/Excel/PPT 的"读 → 改 → 看 → 再改"整个闭环，收敛成一串对 LLM 极其友好的命令。下面逐层拆。

二、核心概念：三层渐进式架构

OfficeCLI 最值得讲的设计，是它把文档操作按抽象层次切成了三级（L1/L2/L3）。这不是拍脑袋分的，而是精确对应了 Agent 在不同任务下需要的"分辨率"。

┌─────────────────────────────────────────────┐
│  L1  读取层 (Semantic View)                    │
│      view: outline / text / stats / diagnose  │  ← "我先看看这文档长啥样"
├─────────────────────────────────────────────┤
│  L2  DOM 层 (Structured Elements)             │
│      get / query / set / add / remove / move  │  ← "精确定位并改这个元素"
├─────────────────────────────────────────────┤
│  L3  原始 XML 层 (Raw OOXML)                    │
│      raw / raw-set (XPath)                     │  ← "上层搞不定，我直接怼底层"
└─────────────────────────────────────────────┘

这个分层的精妙之处在于：Agent 可以按需选择成本最低的层级。绝大多数任务在 L1/L2 就解决了，只有极少数长尾场景才需要下探到 L3。这本质上是一种针对 token 成本和出错概率的"渐进式披露"（progressive disclosure）。

2.1 L1 读取层：让 Agent "看见"文档

L1 的核心命令是 view，它的价值是把一个二进制 Office 文件"翻译"成 LLM 能低成本理解的语义视图。它支持多种输出模式：

• outline：只给大纲结构（标题层级、章节树），token 极省，适合 Agent 先建立全局认知。
• text：纯文本抽取，适合内容分析、摘要、检索。
• stats：统计信息（字数、段落数、表格数、图片数）。
• annotate / 标注模式：带元素路径的标注视图，为 L2 的精确定位做铺垫。
• diagnose：问题诊断，主动扫出文档里的潜在问题（比如样式缺失、空表格、断裂的引用）。
• html：HTML 预览，配合内置渲染引擎，Agent 甚至能"看到"排版效果。

举个例子，Agent 接手一个陌生的 docx，第一步几乎总是：

# 先看大纲，建立全局认知，token 消耗极小
officecli view report.docx --mode outline --json

返回的是结构化 JSON，大致长这样（示意）：

{
  "ok": true,
  "file": "report.docx",
  "mode": "outline",
  "outline": [
    { "path": "/body/p[0]", "level": 1, "text": "季度技术复盘" },
    { "path": "/body/p[3]", "level": 2, "text": "一、稳定性" },
    { "path": "/body/tbl[0]", "type": "table", "rows": 5, "cols": 3 },
    { "path": "/body/p[12]", "level": 2, "text": "二、性能" }
  ]
}

注意那个 path 字段——/body/p[3]、/body/tbl[0]。这就是路径化寻址的入口，它把 L1 的"看见"和 L2 的"操作"无缝衔接起来。Agent 看完大纲，就知道"要改的那段"的确切坐标，不需要再瞎猜。

2.2 L2 DOM 层：像操作网页一样操作文档

L2 是整个工具的核心，它把文档抽象成一棵可查询、可增删改的 DOM 树。如果你写过前端，会有强烈的既视感——它几乎就是把 document.querySelector 那套搬到了 Office 文档上。

关键命令：

来看几个实战片段。

查询所有包含"性能"二字的段落：

officecli query report.docx "p:contains(性能)" --json

把第 3 段的字号改成 14pt、加粗：

officecli set report.docx "/body/p[3]" --prop "fontSize=14" --prop "bold=true"

克隆一个已有的表格行来批量填数据（这是 Excel/表格场景的杀手锏）：

# 用第一行做模板，克隆出一行追加到末尾
officecli add report.docx --from "/body/tbl[0]/tr[0]" --to "/body/tbl[0]" --index last

CSS 风格的选择器是点睛之笔。:has()、:contains() 这些伪类，让 Agent 能用"语义描述"而不是"精确坐标"来定位元素——这恰恰符合 LLM 的思维方式。比如"找到那个包含'总计'的表格的最后一列"，可以直接翻译成一条 query，而不用先 get 整棵树再在内存里遍历。

2.3 L3 原始 XML 层：留给硬骨头的后门

任何抽象都有漏网之鱼。OOXML 规范庞大到没有任何上层 API 能 100% 覆盖，总有些冷门属性、厂商扩展、复杂域代码是 L2 表达不了的。L3 就是为这些长尾准备的逃生舱：

# 直接看底层 XML
officecli raw report.docx "/body/p[3]"

# 用 XPath 直接改底层 OOXML
officecli raw-set report.docx --xpath "//w:p[3]/w:pPr/w:spacing" --attr "w:line=360"

raw-set 用 XPath 直接操作 OOXML，是"任何上层 API 都搞不定时"的终极手段。它的存在体现了一个成熟工具的自觉：给你一条捷径，但也给你一个不封顶的天花板。 上层 API 保证 80% 场景的易用性，L3 保证剩下 20% 的可达性。

三、确定性 JSON：Agent 工作流的地基

前面反复提到"确定性 JSON 输出"，这里单独展开，因为它是 OfficeCLI 区别于所有传统库的分水岭。

3.1 为什么确定性如此重要

我们对比一下。传统 Python 脚本操作失败时：

# openpyxl 典型报错
Traceback (most recent call last):
  File "x.py", line 12, in <module>
    ws['A1'] = wb.formula
AttributeError: 'Workbook' object has no attribute 'formula'

Agent 拿到这坨东西，得先"读懂"这段自然语言 traceback，再推断出"哦，我调错属性了"，然后猜下一步。这个过程既费 token 又不可靠——同样的错误，换个 Python 版本 traceback 格式就变了。

而 OfficeCLI 的设计是，无论成功失败，都返回严格 schema 的 JSON：

{
  "ok": false,
  "code": "ELEMENT_NOT_FOUND",
  "message": "No element matched path /body/p[99]",
  "hint": "Document has 45 paragraphs (index 0-44). Use 'view --mode outline' to inspect valid paths.",
  "context": { "requested": "/body/p[99]", "maxIndex": 44 }
}

看到区别了吗？code 是机器可判定的枚举，hint 是给 Agent 的自我修复建议，context 给出了纠错所需的上下文。Agent 的决策逻辑可以写成清晰的状态机，而不是"读 traceback 猜意图"。

3.2 确定性带来的工程红利

确定性输出解锁了三件在传统工具上很难做到的事：

1. 可组合（Composable）：JSON 输出可以直接 | jq 处理，也可以喂给下一条命令，构建纯 CLI 的文档处理流水线。
2. 可缓存（Cacheable）：同样的输入产生同样的输出，Agent 可以放心缓存 view 结果，避免重复读文件。
3. 可测试（Testable）：CI 里可以对命令输出做严格断言，回归测试不再靠"眼睛看"。

举个组合的例子——把一份报告里所有二级标题抽出来，生成目录：

officecli view report.docx --mode outline --json \
  | jq -r '.outline[] | select(.level==2) | .text' \
  | nl -w2 -s". "

这条管道纯粹靠标准输出串起来，没有一行胶水代码。这才是"Unix 哲学 + Agent 时代"的正确打开方式。

四、自愈错误码：把"报错"变成"下一步指令"

自愈机制是 OfficeCLI 最有"Agent 味"的设计。传统工具的错误是"终止信号"，OfficeCLI 的错误是"引导信号"。

4.1 错误码的分层设计

它的错误码大致可以分成几类（基于其确定性 JSON 契约的设计理念，具体码值以官方文档为准）：

• 定位类：ELEMENT_NOT_FOUND、AMBIGUOUS_PATH（路径匹配到多个元素）——提示 Agent 去 view 确认坐标。
• 参数类：INVALID_PROP、UNSUPPORTED_VALUE——提示合法取值范围。
• 文件类：FILE_LOCKED、CORRUPT_DOCUMENT——提示是否需要修复或另存。
• 能力类：NOT_SUPPORTED_AT_L2——明确告诉 Agent"这个操作 L2 干不了，请下探到 L3"。

最后这个 NOT_SUPPORTED_AT_L2 特别有意思。它不是简单地说"我不行"，而是主动引导 Agent 切换到更底层的接口。这就是三层架构和自愈错误码的协同：错误码本身就是层级之间的路由信号。

4.2 一个完整的自愈闭环示例

假设 Agent 的任务是"把报告第一个表格的表头背景改成蓝色"。它的实际执行轨迹可能是这样：

# Step 1: 先看结构（L1）
officecli view report.docx --mode outline --json
# → 得知 /body/tbl[0] 是目标表格

# Step 2: 尝试用 L2 改表头行背景
officecli set report.docx "/body/tbl[0]/tr[0]" --prop "bgColor=#0066CC" --json
# → 返回 { "ok": false, "code": "NOT_SUPPORTED_AT_L2",
#          "hint": "Row-level shading needs cell-level tcPr. Set bgColor on each td, or use raw-set on w:tcPr/w:shd." }

# Step 3: Agent 读懂 hint，改为逐单元格设置
officecli query report.docx "/body/tbl[0]/tr[0]/td" --json
# → 得到 3 个单元格路径

officecli set report.docx "/body/tbl[0]/tr[0]/td[0]" --prop "bgColor=#0066CC" --json
officecli set report.docx "/body/tbl[0]/tr[0]/td[1]" --prop "bgColor=#0066CC" --json
officecli set report.docx "/body/tbl[0]/tr[0]/td[2]" --prop "bgColor=#0066CC" --json
# → 三次 ok:true

# Step 4: 渲染确认效果（L1）
officecli view report.docx --mode html --out preview.html

整个过程，Agent 没有一次是"卡死"的。每次失败都带着"下一步该怎么做"的明确指引。这才是"为 Agent 设计"的真正含义——不是把人的工具包装一下给 AI 用，而是把 AI 的认知特点（无视觉、靠文本、需要显式引导）作为一等公民来设计。

五、MCP 一键集成：从"装工具"到"教会 Agent"

OfficeCLI 内置了 MCP（Model Context Protocol）Server，可以一键注册到主流 AI 编程工具：Claude Code、Cursor、VS Code Copilot、LM Studio 等。

5.1 SKILL.md：让 Agent 自学成才

它的接入方式堪称"元设计"。官方给出的一行接入：

# 对支持终端和 Agent Skills 的智能体，只需把这条命令发给它
curl -fsSL https://officecli.ai/SKILL.md

Agent 读取这个 SKILL.md，就能学会 OfficeCLI 的安装方式、命令格式、文档操作流程。安装脚本还会自动检测机器上已知的 AI 工具目录，把 SKILL.md 写进去——相当于工具自己教会了 Agent 怎么用自己。

这个设计的哲学值得单独品：传统工具的文档是给人读的 README，OfficeCLI 的"文档"是给 Agent 读的 SKILL.md。README 追求可读性，SKILL.md 追求"可执行的确定性"——命令格式、参数枚举、错误处理流程，全部结构化。

5.2 安装体验

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/iOfficeAI/OfficeCLI/main/install.sh | bash

# Windows (PowerShell)
irm https://raw.githubusercontent.com/iOfficeAI/OfficeCLI/main/install.ps1 | iex

单二进制、零依赖，这句话在实测里的含金量很高。不需要 .NET runtime（虽然它用 C# 写，但走的是 AOT / self-contained 发布路线，从项目结构里的 officecli.slnx、build.sh 能看出是 .NET 生态），不需要 Office，不需要 LibreOffice。对 CI/容器场景来说，这意味着 Dockerfile 可以极简：

FROM alpine:3.20
RUN apk add --no-cache curl bash \
 && curl -fsSL https://raw.githubusercontent.com/iOfficeAI/OfficeCLI/main/install.sh | bash
# 之后 Agent 就能在容器里操作 Office 文档了，镜像干净得像刚洗过

六、代码实战：搭一条"数据 → 报告"的自动化流水线

光看命令不过瘾，我们串一个真实场景：每天定时把一份 JSON 监控数据，灌进 Word 报告模板，渲染成 HTML 发给团队。

6.1 准备模板与数据

假设有 template.docx，里面有一个占位表格（表头 + 一行模板行），还有一个 {{date}} 占位符。数据是 metrics.json：

{
  "date": "2026-07-25",
  "rows": [
    { "service": "gateway", "qps": 12400, "p99": "38ms", "status": "healthy" },
    { "service": "auth",    "qps": 8900,  "p99": "52ms", "status": "healthy" },
    { "service": "search",  "qps": 3200,  "p99": "180ms","status": "degraded" }
  ]
}

6.2 用 Shell 编排（纯 CLI 流水线）

#!/usr/bin/env bash
set -euo pipefail

SRC="template.docx"
OUT="report-$(date +%F).docx"
cp "$SRC" "$OUT"

# 1) 替换标题里的日期占位符
DATE=$(jq -r '.date' metrics.json)
officecli set "$OUT" "/body/p:contains({{date}})" --replace-text "{{date}}=$DATE" --json

# 2) 遍历数据行，用模板行克隆填充
TABLE="/body/tbl[0]"
ROW_TPL="$TABLE/tr[1]"   # tr[0] 是表头，tr[1] 是模板行

jq -c '.rows[]' metrics.json | while read -r row; do
  # 克隆模板行到表格末尾
  NEW_ROW=$(officecli add "$OUT" --from "$ROW_TPL" --to "$TABLE" --index last --json | jq -r '.path')

  svc=$(echo "$row"    | jq -r '.service')
  qps=$(echo "$row"    | jq -r '.qps')
  p99=$(echo "$row"    | jq -r '.p99')
  status=$(echo "$row" | jq -r '.status')

  officecli set "$OUT" "$NEW_ROW/td[0]" --text "$svc" --json
  officecli set "$OUT" "$NEW_ROW/td[1]" --text "$qps" --json
  officecli set "$OUT" "$NEW_ROW/td[2]" --text "$p99" --json
  officecli set "$OUT" "$NEW_ROW/td[3]" --text "$status" --json

  # 状态异常的行标红
  if [ "$status" != "healthy" ]; then
    officecli set "$OUT" "$NEW_ROW/td[3]" --prop "fontColor=#CC0000" --prop "bold=true" --json
  fi
done

# 3) 删除原始模板行（占位用的）
officecli remove "$OUT" "$ROW_TPL" --json

# 4) 渲染成 HTML 预览
officecli view "$OUT" --mode html --out "report-$(date +%F).html"

echo "报告已生成：$OUT"

这段脚本的关键点：

• 全程没有一行 Python，纯 shell + jq + officecli 就搞定了"读改看"闭环。
• --from 克隆模板行，是处理"动态行数表格"的标准姿势，避免了手动构造复杂 OOXML。
• 每一步都带 --json，任何一步失败都能被 set -e 捕获，且错误信息是结构化的，方便排查。

6.3 交给 Agent 编排（自然语言驱动）

如果接到 Claude Code / Cursor 里，你甚至不用写脚本，直接说：

"读 metrics.json，把数据填进 template.docx 的表格，status 不是 healthy 的行标红，最后渲染成 HTML 给我看。"

Agent 会读 SKILL.md 学会命令，然后自己走完上面那套 view → add → set → view 的流程。中途如果某条命令报错，自愈错误码会引导它纠正。这就是"确定性 JSON + 自愈错误码 + MCP"三件套协同的最终形态。

七、性能与工程权衡：单二进制背后的取舍

聊点更硬核的。单二进制、零依赖、内置渲染引擎，听起来很美，但工程上没有免费的午餐。

7.1 内置渲染引擎的代价

要在不依赖 Office/LibreOffice 的前提下把 docx/xlsx/pptx 渲染成 HTML 或图片，意味着 OfficeCLI 必须自己实现一套 OOXML 的排版引擎。这是极重的活——OOXML 的排版规则、字体度量、表格自动布局、分页逻辑，任何一个都能写成一篇论文。

现实的权衡大概率是：渲染追求"够用"而非"像素级还原"。对 Agent 的使用场景来说，它需要的是"确认改对了没有"的视觉反馈，而不是"拿去印刷"的精确排版。所以对渲染保真度要有合理预期——复杂图表、艺术字、嵌入对象的还原度，很可能不如真·Office。这不是缺陷，是场景取舍。

7.2 路径寻址 vs 文档变更的稳定性

路径化寻址（/body/p[3]）很优雅，但有个隐藏的坑：索引会随文档结构变化而漂移。你 add 了一个段落，后面所有段落的索引就变了。在批量操作时，这可能导致"改了 A，B 的路径就失效了"。

OfficeCLI 用几种方式缓解：

1. query 用语义选择器（:contains()）而非纯索引，降低对绝对位置的依赖。
2. add/move 返回新元素的实际路径（前面脚本里的 NEW_ROW=$(... | jq -r '.path')），让 Agent 拿到最新坐标。
3. 建议的操作顺序是"从后往前删、从前往后加"，减少索引漂移的影响。

但这仍然要求 Agent（或写脚本的人）对"操作会改变后续路径"有清醒认知。这是路径寻址模型的固有复杂度，不是 bug。

7.3 大文件与 token 成本

view --mode text 抽全文，对一个几百页的文档来说，token 会爆。这时候 L1 的多模式设计就体现价值了：先 outline 建立结构认知（token 极省），再用 get --depth 或 query 精确拉取需要的局部，而不是一股脑把全文塞给 LLM。分层不只是为了易用，更是为了控制 Agent 的上下文成本。 这一点在处理大文档时是刚需。

八、横向对比：它和老前辈们到底差在哪

结论很清楚：如果你是人在写脚本，python-docx 依然够用；但如果你要让 AI Agent 自主操作文档，OfficeCLI 是目前范式最对的那个。 它的护城河不是"功能多"，而是"为机器认知而设计"这个定位。

九、冷静的一面：几个需要警惕的点

作为一个不轻易吹捧新项目的老程序员，我必须泼几盆冷水。

1. "全球首个"是营销话术，别当技术指标。 命令行操作 Office 的工具早就有（比如各种 pandoc、docx 相关 CLI），"专为 AI Agent 设计"才是它真正的差异点。别被"首个"带偏了评估标准，要看它解决问题的方式对不对。

2. 成熟度需要时间验证。 项目 star 涨得猛，但一个内置渲染引擎的复杂系统，边角 case（复杂样式、特殊域代码、加密文档、宏）的健壮性，只有在大量真实文档上跑过才知道。生产环境接入前，务必用你自己的真实文档做充分回归测试。

3. OOXML 的水太深，L3 是双刃剑。 raw-set + XPath 给了你无限能力，也给了你把文档改成"打不开"的能力。让 Agent 自由使用 L3 是有风险的，建议在关键流程里对 L3 操作加人工复核，或者操作前先备份（cp 一份再改）。

4. 渲染保真度别抱过高期望。 前面说过，内置渲染是"够用"级别。如果你的场景是"生成给客户的正式合同 PDF，要求和 Word 打开一模一样"，那还是老老实实上真·Office 或 LibreOffice。OfficeCLI 的甜区是"Agent 自动化处理 + 结构化操作"，不是"高保真出版"。

5. 依赖官方托管的 SKILL.md / install 脚本有供应链风险。 curl | bash 和 curl officecli.ai/SKILL.md 都很方便，但在企业环境里，建议把二进制和 SKILL.md 镜像到内网，审计后再用，别直接对着公网管道执行。

十、总结与展望：Agent 时代的"工具适配论"

把 OfficeCLI 拆到这里，我想跳出项目本身，聊一个更大的判断。

过去几十年，软件工具的设计中心一直是"人"：GUI 追求直观、所见即所得，因为用户是有眼睛、会点击、能容忍模糊反馈的人。但 AI Agent 的崛起，正在催生一类**"以机器为一等公民"的工具**。它们的设计原则完全不同：

• 人要"所见即所得"，Agent 要"确定性 JSON"。
• 人能读 traceback 猜意图，Agent 要"自愈错误码"显式引导。
• 人靠鼠标定位，Agent 要"路径 + 语义选择器"。
• 人读 README，Agent 读 SKILL.md。

OfficeCLI 的真正意义，不在于它多好地操作了 Office，而在于它是这类"Agent 原生工具"的一个清晰样本。它把"Office 自动化"这个老到发霉的问题，用 Agent 时代的设计语言重新回答了一遍。

我的预判是：未来两三年，我们会看到越来越多领域的工具被"Agent 原生"地重写一遍——数据库客户端、云资源管理、设计工具、CI/CD……凡是过去为人设计 GUI 的地方，都会长出一个"确定性输出 + 自愈引导 + MCP 集成"的 CLI 兄弟。OfficeCLI 只是这场迁移在办公文档领域的先声。

当然，工具再好，也替代不了对问题本身的理解。OfficeCLI 帮 Agent 把文档改对了，但"该改成什么样"永远是人的判断。技术让执行变得廉价，反而让"想清楚要什么"变得更值钱。

如果你手头正好有"让 AI 批量处理 Office 文档"的需求，值得花半小时把它装上、拿真实文档跑一圈。但记住我前面的冷思考——先小范围验证，再上生产。工具是新的，但工程的谨慎，永远不过时。

本文基于 OfficeCLI 公开资料与设计理念梳理，具体命令参数、错误码定义与渲染能力以官方仓库文档为准。文中代码为演示用途，实际使用请以你的版本实测为准。