让 AI 做 PPT 总翻车,多半不是它不会写,是它看不见

上个月我让 AI 把一份季度汇报改成 PPT。它很快，二十几秒就把文件生成了。

我双击打开。第一页标题顶着页面上沿，第二页两张配图的说明文字叠在一起，第三页有个文本框跑到了幻灯片外面。

我把截图丢回去问它怎么回事。它说，坐标都是按我给的数字填的。

这话没错。x=2cm、y=5cm，一个数字都没错。问题是它从头到尾没看过自己写出来的东西长什么样。

后来翻 GitHub，找到一个刚好在解这件事的项目，叫 OfficeCLI。三月中旬建仓，七个多月做到 3.2 万 star，Apache-2.0，C# 写的，定位很直接：给 AI 用的 Office 套件。

— 上面是人说的话，中间是这个工具，下面是它交出来的东西

先把一件事说清楚。.docx、.xlsx、.pptx 本质都是一个 zip 包，里面装着一堆 XML。人用 Word 打开时，渲染器把标签翻译成页面；AI 写文件时，面对的就是标签本身。

它知道这里有第 3 个形状、坐标 720000 EMU、字号 24，但它不知道这个标题一行装不下，也不知道两个形状叠在一起了。

这就是为什么让 AI 做文档，最后一步总要人接手。它能生成，但不能验收。

七月初这个项目在 Hacker News 上拿过 215 分，评论里最集中的质疑是：这东西真比让 Claude Code 直接写 Python 强吗？没人给出数字。

以前的解法是 python-docx、openpyxl、python-pptx 三个库，三套 API，为了生成一页带标题的幻灯片写五十行。写完，你还是得自己打开看一眼。

命令执行成功，和文档看起来对，中间有一道缝。agent 干的活基本都掉在这道缝里。

OfficeCLI 最有意思的地方不在命令设计，在于它把一整个渲染引擎塞进了可执行文件里。

具体有三种出口，用途不太一样。

渲染是自研的，覆盖的东西比想象中多：形状、图表（趋势线、误差线、瀑布图、K 线、迷你图）、公式（OMML 转 LaTeX 走 KaTeX）、3D 模型（.glb 走 Three.js）、morph 过渡、幻灯片缩放。

我一开始觉得这是炫技。后来想明白，这套东西真正的价值是它不依赖 Office，也不依赖显示器。CI 里、Docker 里、没有图形界面的服务器上，只要二进制能跑，这个闭环就能跑。

— 这页是全自动生成的，没套模板，也没人调过字号

左边一行小字是品牌，右边一圈渐变色块，底部写着管理规模和成立年份。这种页面人工做也不省事，难的不是画圆，是知道圆该放在哪。

装法有好几种。macOS 和 Linux 一行脚本，Windows 用 PowerShell 的 irm，也可以走 brew、scoop、npm。

然后创建、加页、开预览。

每敲一条，浏览器里的预览变一次。全程没打开 PowerPoint。

命令分三层，需要哪层用哪层

L2 用得最多。元素靠路径寻址，/slide[1]/shape[2] 这种，不用理解 XML 命名空间。每条命令加 --json 返回结构化结果，不用写正则去抠 stdout。

出错也留了后路。你让它取第 50 页，文件里只有 8 页，它不会只丢一句报错，会返回 code 是 not_found，再加一句 suggestion：有效范围 1-8。agent 拿到这句能自己改，不用人来救。

给 agent 用更省事。curl 一下 SKILL.md，或者跑一次 officecli install，它会自己检测机器上装了哪些 AI 工具，Claude Code、Cursor、Windsurf、Copilot，把技能文件塞进去。也内置 MCP 服务器，officecli mcp claude 一行注册。

第一个是 merge。模板里写 {{client}}、{{total}} 这种占位符，一条命令用 JSON 填进去。段落、表格单元格、形状、页眉页脚、图表标题都认。

这个设计解决的是一个很具体的浪费。你要出两百份合同，让模型从头生成两百遍，版式还不一样；正确做法是设计一次，填充两百次。后者不烧 token，结果也确定。

第二个是 Excel 的公式引擎

内置 350 多个函数，写进去就求值，get 一下就能读到算好的数，不用回 Excel 重算。可溢出的动态数组（FILTER、SORT、UNIQUE、LAMBDA）也支持，_xlfn. 前缀它自己补。

数据透视表也能一条命令生成，缓存和定义直接写进 OOXML，Excel 打开就看到聚合结果。

还有个功能挺聪明，叫 dump。把一份现成文档（整个文档，或者单张表、单页幻灯片、单个工作表）序列化成可重放的 JSON，再用 batch 放回去。等于让 agent 读人类做的范本，学结构，而不是从原始 XML 里猜。

— Word：修订记录表、页眉、页码都出来了

— Excel：KPI 条加分组柱状图，一条命令一层层堆的

顺手提一句，同一批人还做了 AionUi，一个 3.3 万 star 的桌面客户端。说白了是给不用命令行的人用的壳，底层就是这套引擎。一个人用界面，一个 agent 用命令，两条路通到同一个地方。

1一个人扛着

6,262 次提交里，6,123 次来自同一个账号，第二名的贡献是 55 次。二十四个贡献者，实际是一个人写完了 97%。这不是说它写得糙，是说这个项目断了就真断了。

2没有格式一致性测试

它没拿微软的 ECMA-376 规范逐条验证过。README 里渲染引擎写的就是“从零实现”，不是微软那套。所以高保真的高，是渲染得像 Office，不是保证和 Office 一模一样。真要交投标文件，自己打开核一遍。

3唯一一份横评，是竞品做的

竞品在自己的发布帖里测了 Word 编辑任务：OfficeCLI 中位 13 次工具调用，Anthropic 官方 docx 技能 10 次，竞品自己 3 次。厂商测自己，数字当参考，别当结论。

4版本喷得很猛

三月建仓到十月底，159 个版本，v1.0.159 是 10 月 27 号发的。最近提交翻下去几乎全是 fix。说明它在真实使用里被撞得挺狠，也说明它还在补。

5边界比想象中硬

.vsdx 不支持；已经用 PowerPoint 打开的文件改不了；Windows 上常驻进程有个毛病，命令返回后还会卡住父进程一分钟左右。另外安装脚本会改你的 AI 工具配置，心里有个数。

我写这篇不是因为 OfficeCLI 多完美。上面那五条，随便一条都能劝退一部分人。

我觉得有意思的是它的思路。过去两年我们一直在提高模型能力，但模型再强，碰到它读不懂的格式也只能干瞪眼。工具覆盖度这件事，进步速度比模型慢得多。

Office 文档算难啃的一块。格式封闭，渲染复杂，几乎每个人都得用，愿意从头啃的人一直不多。有人花七个多月写了个渲染引擎，就为了让 AI 能看见自己干的活。这件事本身值得记一笔。

我是明翼，热衷于分享 AI 观察与开源干货。你平时是让 AI 直接生成 Office 文件，还是自己套模板？评论区聊聊。