夜雨聆风OfficeCLI 正式出道
事情是这样的。
今天 GitHub 上有一个项目突然就炸了。
不是那种慢慢涨 star 的节奏。是一天之内冲上 trending，六千五百多个 star，五百多个 fork，issue 区被挤得满满当当。
项目名字叫 OfficeCLI。
我第一眼扫过去，心里想的又是哪个命令行工具套壳。结果把 README 翻完，我愣了大概三十秒。
不是因为它技术多牛。
是因为它解决了一个我每天都在吐槽，但从来没想过有人会专门去做的问题。
AI Agent 能写代码、能画图、能生成视频、能跑数据分析。
但它打不开一个 .docx 文件。
它看不了 Word，改不了 Excel，做不了 PPT。
一个能写 Python 脚本、能调 API、能跑 Docker 的智能体，面对老板甩过来的一句「帮我改下这个季度的汇报 PPT」，它的反应跟一个不会用 Office 的实习生一模一样。
干瞪眼。
直到 OfficeCLI 出现。
说真的，我不是那种看到新工具就兴奋的人。这几年见过太多套壳产品，热度一过就没人提了。
但 OfficeCLI 有几个点，是真的打动我了。
先聊一个最直观的感受。
以前你让 Agent 生成一个 PPT，它得这么干。装 python-pptx 库，写五十行代码，处理各种布局问题，保存，然后自己根本看不到生成效果，只能盲猜排版对不对。
就像一个蒙着眼睛画画的人。画完了还得让别人告诉他画得好不好。
现在呢。
一条命令。
officecli create deck.pptx
再加一条。
officecli add deck.pptx / --type slide --prop title="Q4 Report"
没了。
然后你让 Agent 跑一个 officecli watch deck.pptx，浏览器里直接实时预览。加一个 shape，刷新一下。改一个颜色，再刷新一下。
render、look、fix 这个闭环，第一次在一个 CLI 工具里跑通了。
五十行 Python 加三个库干的事，变成了一条命令。
回到 OfficeCLI 这块，真正让我觉得「这东西有点东西」的，是它从根子上就不是给人设计的。
你打开它的 README，第一个板块叫 For AI Agents。不是 For Humans，不是 For Developers。
给 Agent 一行 curl 命令，它自己就读 skill 文件，自己就学会怎么安装、怎么用。officecli install 跑一遍，自动检测你电脑上装了哪些 AI 编码工具，Claude Code、Cursor、Windsurf、GitHub Copilot，然后自己把 skill 文件全塞进去。
Agent 重启一下，立刻就能帮你操作 Office 文档。
零配置。
这种思路不是拍脑袋想出来的。它背后有一个很关键的判断，Agent 不需要 GUI，不需要菜单，不需要按钮。它需要结构化的输入输出，需要稳定的路径寻址，需要知道自己做错了之后怎么修正。
OfficeCLI 把这三件事全做了。
每个命令支持 json 输出，统一的 schema。元素用路径寻址，slide[1] 加 shape[1]，跟 CSS 选择器一样直观。写错了，返回 structured error，带 error code，带 suggestion，带 valid values。Agent 不需要人类来告诉它「你拼错了一个属性名」，它能自己读错误信息、查可用元素、修正路径、重试。
self-healing workflow。在这个工具里不是 PPT 上画的概念图，是实际跑起来的流程。
然后就是我觉得最骚的设计。
内置渲染引擎。
大多数 Office 自动化库有个致命问题，Agent 生成的文档长什么样，Agent 自己看不到。它只能读 XML 结构，但不能看见文字有没有溢出、两个 shape 有没有重叠、图表颜色搭配是不是辣眼睛。
OfficeCLI 把渲染引擎直接打包进了二进制文件里。
不需要浏览器引擎，不需要 Office 组件，不需要任何外部依赖。
三种模式。view html，生成独立 HTML 文件，浏览器打开就能看。view screenshot，输出 PNG 图片，多模态 Agent 可以直接读图。watch 模式，本地起一个 HTTP 服务，每次 add、set、remove 操作自动刷新浏览器。
那结果会怎样呢。
你的 Agent 可以在 CI/CD pipeline 里、在 Docker 容器里、在一台没有显示器的服务器上，生成 PPT、渲染预览、检查排版问题、自己修正、再检查。
全程不需要人类介入。
想想这个画面。
凌晨三点，你的 Agent 在服务器上跑着，生成一份一百页的年度报告。它每写完一页就截图自己看，发现标题溢出了就调字号，发现图表位置歪了就调坐标，最后 validate 一遍确认没问题，close 保存。
人类早上来上班，文档已经躺在那里了。
功能深度这块，我本来以为「能读写就行」，结果翻开 wiki 之后发现自己还是太天真了。
Word 方面，段落、runs、表格、样式、页眉页脚、图片、公式、批注、脚注、水印、书签、目录、图表、超链接、分节、表单域、内容控制、域代码、OLE 对象，全支持。连 i18n 和 RTL 从右到左文字都有，印地语、阿拉伯语、泰语、CJK 的 locale-aware 页码编排都做了。
Excel 方面更离谱。150 多个内置函数自动求值，你写 SUM(A1:A2)，保存的时候值就已经算好了，不需要绕一圈回 Office 重新计算。VLOOKUP、INDEX、MATCH、日期函数、文本函数，140 多个函数全覆盖。原生 OOXML 透视表，一条命令从数据源范围生成多字段行列过滤，十种聚合方式，showDataAs 模式，日期分组，计算字段。切片器、命名范围、数据验证、图片、迷你图、条件格式、自动筛选、形状。
PowerPoint 这边，幻灯片、形状、图片、表格、图表、动画、morph 过渡、3D 模型 glb 格式、幻灯片缩放、公式、主题、连接器、视频音频、分组、演讲者备注、批注、OLE 对象、占位符。
我当时就愣住了。
这是一个人能写完的东西吗。
跑去看了下 contributors。goworm，三千九百五十次提交。IceyLiu，五十五次。Claude，十四次。
是的你没看错。Claude 也是这个项目的贡献者之一。
一个 2026 年 3 月 15 日才创建的仓库，到今天 6 月 9 日，不到三个月，版本号已经到 v1.0.107。C# 代码量超过一千万行，macOS、Linux、Windows 全平台支持，Word 加 Excel 加 PPT 三件套的完整 OOXML 操作全覆盖。
这尼玛就是。
说到 Office 自动化，大家脑子里能蹦出来的方案其实不少。
python-pptx、python-docx、openpyxl，这些 Python 库用的人最多。但每个格式需要一个独立的库，而且 Agent 用起来很痛苦。要理解 Python API，要处理各种边界情况，最要命的是生成之后看不到效果。
LibreOffice 的 headless 模式能做文档转换和批量处理，但得装 LibreOffice 本身，Docker 里部署很重，而且人家设计初衷就不是给 Agent 用的。
微软官方的 COM 和 Add-in 方案，只能跑在 Windows 上，需要完整的 Office 安装，COM 接口调用对 Agent 来说更是天书。
OfficeCLI 把上面这些方案挨个看了一遍，然后做了一个完全不同的选择。
开源免费，Apache 2.0 协议。单个二进制文件，零安装。跨平台。所有操作都是 CLI 命令，输出结构化 JSON。内置渲染引擎让 Agent 能看见结果。模板合并功能让 Agent 设计一次布局，下游代码填充 N 次数据。还有 round-trip dump 功能，把任何 docx 序列化成可重放的 batch JSON，Agent 可以从人类写的模板学习结构，然后用 batch 功能批量生成变体。
这不是又一个 Office 自动化库。
这是一个从第一天开始，就只为 AI Agent 设计的 Office 操作层。
顺着上面这个再聊聊模板合并这个功能，我觉得它解决了一个特别痛的问题。
Agent 每次从头生成文档，布局永远不一致。今天生成的 PPT 第一页标题在左上角，明天生成的就跑到了中间。不是 Agent 笨，是每次生成的随机性导致这个问题几乎无解。
OfficeCLI 的做法很聪明。
Agent 设计好一个模板，里面用双花括号 client、双花括号 total、双花括号 date 这样的占位符标记需要填充的位置。然后下游代码只需要调用 officecli merge template.docx output.docx 加 JSON 数据，就能批量生成一百份格式统一、内容各异的文档。
设计一次，贵。
填充 N 次，便宜，确定性，零 token 消耗。
这个思路跟编程里的「一次编写，到处运行」是一个道理。把最费脑子的事（设计布局）做一次，后面全是便宜的重复劳动。
MCP 服务器这块也值得一聊。
OfficeCLI 内置了 MCP 服务。一条命令 officecli mcp claude 注册到 Claude Code，officecli mcp cursor 注册到 Cursor，officecli mcp vscode 注册到 VS Code 和 Copilot。
所有文档操作都通过 JSON-RPC 暴露为工具调用。Agent 不需要 shell 访问权限，不需要理解命令行参数格式，直接通过 MCP 协议调用。
也就是说，你甚至不需要教 Agent 怎么用 OfficeCLI。装好二进制文件，跑一下 officecli install，它自动检测、自动安装 skill、自动注册 MCP。然后你的 Agent 就已经具备了完整的 Office 文档操作能力。
我自己还没跑过这个流程，但光想想这个体验，就觉得有点兴奋。
当然不是所有人都习惯用命令行。
团队还做了一个配套的桌面应用叫 AionUi。用自然语言描述你想要什么，AionUi 在底层调用 OfficeCLI 帮你完成。
CLI 给 Agent 用，GUI 给人用。底层同一个引擎。
这个分工我觉得挺对的。没有为了讨好人类用户而牺牲 Agent 的体验，也没有因为是 Agent-first 就完全不管人类用户的需求。两边都照顾到了。
聊了这么多好的，也该说说我觉得还不到位的地方。
毕竟真诚是这个时代最稀缺的东西。
功能深度确实惊人，但 wiki 里很多高级功能对普通 Agent 来说学习成本不低。虽然内置了 help 系统，officecli pptx set shape 能查看某个元素类型的所有可设置属性，但 Agent 要在这么多属性里找到正确的那个，还是需要不少试错。
社区也还在早期。项目创建不到三个月，Discord 刚建，中文文档有但还在完善。想成为 AI Agent 标准的 Office 操作层，社区生态的成熟度还需要时间。
但这些都不是致命问题。
三个月做到这个程度已经远超我的预期。而且从 commit 频率来看，今天还在发 v1.0.107，开发节奏非常快。
写到这儿我突然想到一个更大的事。
OfficeCLI 让我看到的不是「Agent 能操作 Office 了」这么简单。
它背后有一个趋势。
过去的软件设计，默认用户是一个坐在屏幕前、有双手有眼睛有大脑的人。所以有 GUI，有菜单，有鼠标操作，有拖拽。所有这些交互范式，都是围绕人类的生理特征和认知习惯设计的。
但 AI Agent 不是人。
它不需要看到按钮才知道怎么操作。它需要结构化的接口，明确的 schema，可预测的输入输出格式，出错之后的自我修正能力。
OfficeCLI 是第一批真正从「用户是 Agent」这个前提出发设计的工具之一。
不是给人用的工具加个 API 就丢给 Agent 用。
是从第一天开始，每一行代码、每一个命令格式、每一个错误返回，都在考虑一件事。
如果调用我的是一个 AI，它需要什么。
这个转变比看起来重要得多。
当越来越多的工具开始以 Agent-first 的思路重新设计，我们会进入一个完全不同的软件交互范式。人类不再直接操作软件，而是告诉 Agent 想要什么，Agent 去调用各种 Agent-first 的工具来完成。
人类的角色从操作者变成了指挥者。
这个转变不会一夜之间发生。
但 OfficeCLI 这样的工具，就是这场转变的第一批基础设施。
回头看看开头那个画面。
一个能跑 Docker、能调 API、能写 Python 的智能体，面对老板的「帮我改下 PPT」干瞪眼。
现在它不用干瞪眼了。
OfficeCLI 刚刚出道。v1.0.107，今天刚发的版本。六千五百多 stars，五百多 forks，Apache 2.0 开源，跨平台，单二进制文件，零依赖。
它可能还不完美。社区还在早期。高级功能的学习曲线不低。
但它做对了一件事。
让 AI Agent 终于有了一双可以操作 Word、Excel 和 PPT 的手。
而这件事，一旦做到，就再也回不去了。
https://github.com/iOfficeAI/OfficeCLI
https://officecli.ai
谢谢你看我的文章，我们，下次再见。
/ 作者：mojianpo/ 投稿或爆料，请联系邮箱：406223802@qq.com
