照着 README 跑一遍 OfficeCLI,看看有哪些惊艳的地方

很多人已经敢让 AI 写周报、改报价、整理 PPT 了，但真到“保存回 Office 文件”这一步，还是不太敢放手。

原因不复杂。不是 AI 会不会写，而是它改完以后，你怎么确认标题没乱、表格没跑、文件没坏。

OfficeCLI 这两天值得看，不只是因为它在热榜上，而是因为它把这条链路补得比较完整。GitHub README 写得很直接：它是单二进制，不用装 Office，支持 .docx、.xlsx、.pptx，还能把文件渲染成 HTML、PNG，走一遍“改完就看，看完再决定要不要继续”的闭环。7 月 6 日刚发了 v1.0.129，仓库 Wiki 还给了现成 workflows，examples/ 目录里也有可以直接照抄的 .sh 和 .py 脚本。

所以这篇不聊“办公自动化会不会颠覆谁”，只回答 3 个问题：

• 第一次先拿哪份文件试
• 照 README 应该怎么跑
• 什么情况算过关，什么情况要先停

第一次别拿正式合同，先拿这两类文件

如果你是第一次试 OfficeCLI，我更建议你在这两类文件里选一个：

1. 内部周报 .docx

最适合测标题、段落、列表、表格有没有被改坏。

好处是：

• 内容真实，不是玩具 demo
• 结构够简单，方便你一眼复核
• 改坏了也能回滚，不会直接影响客户

2. 演练用报价单 .xlsx

最适合测单元格写入、公式、数字格式和预览链路。

好处是：

• 能测出 Excel 这条线到底稳不稳
• 很快就能看出公式和显示有没有错位
• 适合验证“AI 改表”到底是不是你需要的那种能力

第一次先别碰这些：

• 正式合同
• 客户最终报价单
• 多人同时在改的共享总表
• 带复杂宏、加密、复杂批注的文件

不是因为它一定不行，而是 README、Issues 和 Wiki 都已经在提醒你，首测应该先走低风险路径。

开始前先准备 4 件事

1. 复制一份测试副本

不要在原件上直接试。

2. 确认安装方式

README 现在给的是这套安装命令：

装完先验证：

如果这里都没过，先不要往后跑。

3. 准备一个很小的首测任务

第一次只做一类改动，比如：

• 把周报统一成 Heading1 / Heading2
• 把一段过长文字拆成 3 条 bullet
• 给报价表补一列税后价
• 给总价行加 SUM

4. 先写下成功标准

例如：

• 改动能正确写回文件
• 预览和实际保存结果一致
• 复核时间比手工改更短

没有成功标准，首测很容易变成“感觉好像能用，但又不敢继续”。

先跑 Word：最稳的首测路线

OfficeCLI 的 Wiki 里有一份完整的 Create a Word Report from Scratch workflow，examples/word/ 目录也有现成脚本。第一次不一定要从零创建整份报告，但它给了你很清楚的命令路径。

如果你今天只想验证“它是不是能安全改一份周报”，我建议按下面的顺序跑。

第一步：先读结构，不要先改

先看文档结构：

如果你想继续确认正文层级，可以再看：

你这里主要看两件事：

• 它有没有把段落、标题、表格读出来
• 路径是不是清楚到你能定位 /body/p[1]、/body/p[2] 这类元素

第二步：开 resident mode，再做小改动

README 和 workflows 都建议多步操作时用 resident mode。

如果第一段是标题，第二段是正文，你可以先做这种低风险修改：

这一轮先别追求“整篇自动重写”，只确认 3 件事：

• 标题样式能不能正常改
• 正文文字能不能安全替换
• 新段落和 bullet 能不能正常插进去

第三步：先预览，再决定要不要继续

README 里最值钱的一点，不是“能改”，而是“改完能看”。

如果你更想看截图链路，也可以用：

这一轮重点查：

• 标题层级有没有乱
• bullet 有没有跑掉
• 表格和图片有没有被意外影响
• issues
   有没有直接报结构问题
• validate
   能不能通过

第四步：确认稳定再 close

close 之前发现不稳，就先停在这里，不要继续叠加修改。

再跑 Excel：看它是不是只会“写值”，还是能接住报价表

OfficeCLI Wiki 的 Excel workflow 是从零建一个 sales.xlsx，再写表头、写值、写公式、加图表、冻结表头、加数据校验。你第一次不一定全做，但至少要测到“写值 + 公式 + 预览”这 3 步。

第一步：先看表，再看公式

先确认它能读出：

• 当前 sheet
• 表头
• 关键单元格路径，比如 /Sheet1/A1、/Sheet1/D2

第二步：只改一列低风险字段

例如你有一份演练报价表，A 到 D 列分别是产品、数量、单价、总价，可以先这样测：

如果你只是想确认公式链路能不能走通，这一轮已经够了。

第三步：补一个最实用的表格动作

Wiki 的官方 workflow 里还有两个很适合首测的动作：

这两步值钱的地方在于，它们比“纯写值”更接近真实表格工作：

• freeze=A2
   能验证表头冻结
• validation
   能验证下拉状态列

第四步：看结果是不是你真敢交给它

改完先查：

如果你想进一步核对结构，也可以跑：

这样能直接看到哪些格子现在已经是公式。

examples/ 目录其实就是现成教程

如果你觉得 README 还不够细，OfficeCLI 仓库里最有用的不是宣传页，而是 examples/。

它不是只有一张截图，而是按 Word、Excel、PPT 分好目录，每个例子基本都带 4 个文件：

• 讲解用的 .md
• 直接运行的 .sh
• Python SDK 版本的 .py
• 已生成好的 .docx/.xlsx/.pptx

也就是说，你不一定非得自己从空白命令开始试。完全可以先挑一个最接近你任务的例子，比如：

• examples/word/tables
• examples/word/paragraph-formatting
• examples/excel/cell-formatting
• examples/excel/data-validation

先照着脚本跑，再把里面的文件名和字段换成你自己的。

这比空想“AI 改 Office 行不行”更有用，因为你能直接看到：

• 命令长什么样
• 输出文件长什么样
• 哪一步开始接近你的真实工作

什么结果算这次首测过关

第一次试，只要满足下面 4 条，就可以算它值得继续：

1. 它能稳定读出你的文件结构

不是只打开文件，而是 outline、get --json 能真的帮你定位元素。

2. 你要求的那一批改动都生效了

包括标题、段落、单元格、公式，不是命令返回成功但文件没变。

3. 预览、校验和实际文件没有明显打架

也就是 view html、issues、validate 和最终文件表现基本一致。

4. 你的复核时间真的下降了

如果最后还是花 15 分钟一项一项对，那它现在只是换了一种返工方式。

哪些信号一出现就先停

GitHub Issues 里已经能看到几类现实边界，这些都不适合拿正式文件硬顶：

1. 命令执行了，但结果不清楚

这类静默失败最麻烦，因为你不知道是没改，还是改坏了。

2. Excel 写进去了，但显示还是旧内容

仓库里已经有人提到过 inline string 相关显示问题，这类表先别直接上正式链路。

3. 加密文件、受保护文件识别异常

如果它把受保护文件误判成损坏文件，你就不该继续拿正式文件试。

4. 一上来就接整套 MCP 或 Agent 自动化

README 虽然把 MCP、skills、自动安装都写进去了，但第一轮更稳的做法还是手动跑命令。先确认 CLI 路径通，再考虑接 Claude、Codex、Cursor 这些外层代理。

最后一句判断

OfficeCLI 现在最值得试的，不是“AI 能不能替你写周报”，而是“AI 改完 Office 文件以后，你终于有一条比较像样的检查链路”。

第一轮别贪大。先拿一份内部周报或演练报价单，照 README 和 Wiki 把 install -> view -> open -> set/add -> html/issues/validate -> close 这条路走一遍。走通了，再扩大；中间任何一步不稳，就先别碰正式文件。