让 AI 真正「会做」Office:OfficeCLI 上手实测

一、先从一个都踩过的坑说起

你让 AI 帮你做一份 PPT。它确实「做」出来了——但打开一看：

• 标题溢出文本框，被裁掉一半；
• 字体全部回退成了默认的等线，和设计稿完全不搭；
• 说好要做的图表没做，只是把数据堆进了单元格。

问题不在 AI 不会写内容，而在它根本「看不见」自己做出来的东西。它往文件里写了一堆 XML， 写完就撒手，既不知道版式对不对，也不知道公式有没有真的算出来。

这就是 OfficeCLI 想填的坑。它是 iOfficeAI/OfficeCLI， 一个专门给 AI Agent 用的 Office 三件套命令行工具。我把它装到本机、配合 Claude Code 实测了一轮， 结论先说：它最有价值的不是「能操作 Office」，而是给 AI 装了一双眼睛。

二、它到底是什么

一句话：把 Word、Excel、PPT 的读写能力，封装成一个单文件、零依赖、不需要安装 Microsoft Office 的命令行， 让 AI 用敲命令的方式操作文档。

几个关键事实，先摆出来（都核实过）：

• 项目 2026 年 3 月 15 日 才创建，到现在 5 个月，27.8k 星、1.9k fork；
• 发版非常勤，我写文章这天最新版是 v1.0.143（2026-07-28）；
• 背后是 AionUi 这个组织，定位 “AI on UI”；
• Apache 2.0 协议，可商用。

安装就是一行（Windows PowerShell）：

irm https://raw.githubusercontent.com/iOfficeAI/OfficeCLI/main/install.ps1 | iex

装完它还会顺手把技能文件装进 Claude Code / Cursor / Copilot 的 skills 目录——它自己就是「AI Skills 生态」的一个玩家，这点后面再展开。

三、核心体验：让 AI「看见」自己做了什么

这是我认为 OfficeCLI 最值钱的设计，也是和 python-docx、openpyxl 这类纯代码库最本质的区别。

它内置了一个渲染引擎，能把文档直接渲成 HTML 或 PNG。于是一个完整的工作流变成了：

render → look → fix（渲染 → 看一眼 → 修复）

官方仓库的 README 里放了一组由 AI agent 全程用 OfficeCLI 生成、零模板零手改的成果图， 其中一张是一份风投机构风格的商务演示封面——品牌名、一句话定位、渐变色块装饰、底部一行融资信息， 排版工整到很难相信是命令行敲出来的：

按它的构图拆解，对应的命令大致是这样一层层叠上去的：

officecli create deck.pptxofficecli add deck.pptx / --type slide --prop background=E9F3FBofficecli add deck.pptx '/slide[1]' --type shape --prop shapeType=oval \  --prop x=14cm --prop y=-2cm --prop w=10cm --prop h=10cm --prop fill=B39DDB --prop alpha=70officecli add deck.pptx '/slide[1]' --type shape --prop text="HORIZON." \  --prop x=1.5cm --prop y=3cm --prop size=40 --prop bold=trueofficecli add deck.pptx '/slide[1]' --type shape \  --prop text="Backing founders who build the infrastructure of tomorrow." \  --prop x=1.5cm --prop y=7cm --prop size=16 --prop color=5F6368officecli add deck.pptx '/slide[1]' --type shape \  --prop text="Seed & Series A  ·  \$180M AUM  ·  Est. 2018" \  --prop x=1.5cm --prop y=9.5cm --prop size=13 --prop color=8A8F98

渲成图片「看」一眼，确认版式再决定要不要微调：

officecli view deck.pptx screenshot -o slide.png

如果发现哪里不对——比如某个文本框溢出了——AI 看到截图后可以直接定位修复， 再渲一次确认。做 → 检查 → 修好，整个闭环不需要人插手，这就是它和普通代码库的分水岭。

一个让我眼前一亮的细节

当我用 officecli get 去读一个形状的属性时，返回里有一项：

effective.font.ea=等线   effective.font.ea.src=/theme/minorFont

它把「中文最终用了哪个字体、是从主题哪一层继承来的」都算好告诉你了。 对于排查「为什么我的中文排版和预期不一样」这类问题，这个 effective.* 设计非常贴心。

四、三件套实机长什么样

Excel：公式是真的会算，图表一行生成

同一组官方展示图里还有一张经营仪表盘——深蓝标题条、四张 KPI 卡片（总销售额、平均客单价、 Top 品类、总订单数），下方四张绿色柱状图分别拆解品类、产品、客户、销售代表的活跃度：

拆出来大概是这几类命令的组合——先写 KPI 卡片，再逐张插图表：

officecli set dashboard.xlsx /Sheet1/A3 --prop value="YTD TOTAL SALES" --prop color=6B7280officecli set dashboard.xlsx /Sheet1/A4 --prop value="=SUM(Data!G:G)" --prop bold=true --prop size=22officecli set dashboard.xlsx /Sheet1/A1 --prop value="Northwind Traders | Monthly Performance Dashboard" \  --prop bold=true --prop color=FFFFFF --prop fill=13294B# ... 其余三张 KPI 卡片同理逐格写入 ...officecli add dashboard.xlsx /Sheet1 --type chart --prop chartType=column \  --prop dataRange='Data!G:G' --prop categories='Data!A:A' --prop colors="34A853" \  --prop title="Category Activity"

写公式也真的会算，YTD TOTAL SALES 那格用的就是 =SUM(...)，不是手填的死数字。--prop value="=SUM(B2:B3)" 这类写法读回来的结果是：

{ "formula": "SUM(B2:B3)", "computedValue": "306000", "evaluated": true }

它内置了 350+ 个 Excel 函数和透视表引擎。对「让 AI 帮你算数据」的场景，这意味着AI 能确认自己的公式没写错——而不是写完交给用户才发现 #REF! 一片红。

Word：带封面色块的正式文档也能搞定

第三张官方展示图是一份产品简介文档——深蓝渐变封面色块上印着公司名、产品名、 版本标签，翻到正文是一句加粗的产品主张：

对应的操作大致是先用一个填色矩形做封面色块、叠三行文字，再往正文写标题段落：

officecli create report.docxofficecli add report.docodex /body --type shape --prop shapeType=rect \n  --prop w=100% --prop h=6cm --prop fill=2A3B8Fofficecli add report.docodex '/body/shape[1]' --type textbox \n  --prop text="HELIX SYSTEMS INC." --prop color=A9C2FF --prop size=11officecli add report.docodex '/body/shape[1]' --type textbox \n  --prop text="HELIX" --prop color=FFFFFF --prop bold=true --prop size=32officecli add report.docodex /body --type paragraph \n  --prop text="One Cluster. Every Workload. Unlimited Scale." \n  --prop bold=true --prop size=22

五、拆开看：这个 CLI 的架构设计

用熟之后我回头翻了它的设计，发现几个决策挺值得说——它本质上是一个为 AI 重新设计的文档操作栈， 而不是把现有库简单包一层命令行。

三层递进：能用语义就别碰 XML

它把操作复杂度分成了三层，由浅入深：

• L1 语义视图：view outline / text / issues，AI 先快速读懂「这文档讲了什么、有没有问题」；
• L2 DOM 操作：add / set / get / remove，对形状、表格、图表做结构化增删改；
• L3 裸 XML：raw / raw-set，直接用 XPath 兜底，任何 OpenXML 能表达的操作都不会被卡死。

这个分层对 AI 很友好：简单任务永远停在高层，只有高层够不着时才下沉到 XML。 AI 不用一上来就理解 OOXML 那套命名空间地狱。

路径寻址：给每个元素一个稳定「坐标」

文档里每个元素都有一个可读的路径，比如 /slide[1]/shape[2]、/body/tbl[1]/tr[1]/tc[2]。 AI 定位元素就像在文件系统里 cd 目录，不需要懂 XML，也不需要解析整棵文档树。 我前面所有 set 命令靠的就是这套寻址。

常驻模式 + 批处理：把「开文件」的开销抹掉

传统脚本每改一次都要开一次文件、写一次盘。OfficeCLI 的做法是：

• Resident 常驻进程：文档留在内存里，后续命令通过命名管道直接操作，延迟接近零， 磁盘写入推迟到空闲或显式 save/close；
• Batch 批处理：一次提交一串操作，默认原子性——任何一步失败整批回滚， 不会留下改了一半的半成品文件。

这两个设计合起来，解决的是 AI 改文档时最要命的「改到一半出错、文件已损坏」的问题。

单二进制 + 内置渲染引擎

整个工具编译成一个自包含二进制，运行时不需要 .NET、不需要 Python、更不需要装 Office。 连那个「AI 的眼睛」渲染引擎都是从零写的、直接内嵌——所以它在没有 Office 的服务器、 Docker 容器、CI 流水线里都能跑，这才是「AI 后端」该有的形态。

把这五件事串起来看，它的设计取向非常一致：所有决策都优先考虑「AI 怎么用得稳」， 而不是「人怎么用得爽」。这也是为什么它能成为 Agent 生态里少有的文档基础设施。

六、给 AI 接上它：一条命令的事

OfficeCLI 内置了 MCP（Model Context Protocol）服务器，对接主流 AI 编程助手就一条命令：

officecli mcp claude    # 注册到 Claude Codeofficecli mcp cursor    # 注册到 Cursorofficecli mcp vscode    # 注册到 VS Code / Copilot

我实测了 officecli mcp list 能正确识别出本机装了哪些客户端。

它还提供了一个通用的技能描述文件，任何 Agent 都能拉取：

curl -fsSL https://officecli.ai/SKILL.md

这一点很对当下的胃口——工具不再是给人用的 CLI，而是设计成「AI 一装就会」的技能包。 如果你关注过最近 GitHub 上 Skills 生态的爆发（anthropics/skills、addyosmani/agent-skills 等）， OfficeCLI 就是这股潮流在「办公文档」这个垂直领域的落地样本。

七、值不值得试

适合谁：

• 经常要让 AI 批量处理 / 生成 Office 文档（报告、数据表、周报 PPT）的人；
• 在做 AI Agent 产品，需要一个稳定的「文档操作后端」的开发者；
• 受够了 AI 生成文档「格式乱、没法自检」的人。

一句话总结：OfficeCLI 没有发明新东西，它做的是把「AI 操作 Office」这件脏乱差的事， 用一个单二进制 + 渲染闭环 + MCP 生态，做成了一套今天就能用的工程方案。 5 个月 2.8 万星，市场已经用脚投票了。

而它身上最值得琢磨的，其实是那个趋势信号——当工具都开始为 AI 而不是为人设计， 「AI 能自己动手干活」这件事，才算真正落了地。

参考链接

• 项目仓库：iOfficeAI/OfficeCLI
• 组织官网：AionUi
• 技能描述文件：officecli.ai/SKILL.md