给 AI 一个 SKILL.md,它就学会了 Word/Excel/PPT?

你有没有算过，让 AI 学一个新工具的成本？

一般是三步：读 README、查 API 文档、写几行试错代码。有时候光 README 就几万字，token 哗哗烧。如果告诉你，有一款工具把这个过程压缩到一步——只给它一个 403 行的 markdown 文件，它就学会了 Word、Excel、PPT 的全部操作——你信吗？

这个项目叫 OfficeCLI。3 个月、4,369 次提交、113 个 tag，Apache-2.0 开源。数字本身就说明了很多事：要么作者是卷王，要么这东西确实踩中了什么。我看了一下午觉得是后者。

仓库速览：3 个月做到什么程度

仓库在 iOfficeAI/OfficeCLI 下，初始提交是 2026 年 3 月 15 号，到现在满打满算 3 个月。4,369 次提交——算一下平均每天 48 次，这密度比很多 3 年的项目都高。

20 个分支、113 个 tag、8 个 open issue。主语言是 C#，跑在 .NET 10 上，运行时是嵌入的，用户不需要装 .NET 环境。副语言是 Python，有个独立的 officecli-sdk。开源协议走 Apache-2.0，干干净净。

113 个 tag 这个数字值得说一下——平均每天超过 1 个 tag，发版节奏极快，semver 大概率不严。好处是迭代猛，坏处是生产环境得锁定具体版本。这点后面讲风险时再说。

官网 officecli.ai 做得挺全，文档、demo、安装脚本都在一块，整体观感不像一个 3 个月的仓。

核心创新：SKILL.md 是什么

这是整篇文章我最想讲清楚的东西。

SKILL.md 是个 403 行的 markdown 文件，挂在 officecli.ai/SKILL.md 上。它不是 README——README 写给人看，SKILL.md 写给机器看。内容覆盖了 OfficeCLI 是什么、怎么装、怎么用、命令怎么拼、出错怎么处理、常见模式怎么套。结构化的程度够高，AI agent 一次性加载就能操作 Word/Excel/PPT。

用法只有一行：

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

你的 AI agent 拿到这个文件之后，立刻具备操作 Office 文档的全部能力，不需要任何额外配置。不需要读几百行 API 文档，不需要翻多个链接，不需要试错之后回头查——这就是"3 步变 1 步"的具体含义。

SKILL.md 不是概念。你在 Claude Code 里跟它说"帮我做个 Q4 汇报 PPT"，它读到这个文件之后，就知道用 officecli create 建文件、用 officecli add 加页面和形状、用 officecli view 预览。全过程不需要你教它 OfficeCLI 怎么用。

我越看越觉得这代表了一种新范式。过去 AI 学工具的思路，是训练的时候把 API 文档吞进模型权重。SKILL.md 的思路是：工具自己提供一份专门给 AI 看的说明书，AI agent 运行时动态加载。这没有训练成本，更新 SKILL.md 就能更新 AI 的能力，不需要等模型重训。

配套机制也做得很细。所有命令都支持 --json 标志输出结构化结果，agent 不需要 regex 解析。属性名拼错会返回"最接近的正确拼写"，有自愈能力。支持 MCP server，一行注册到 Claude Code、Cursor、VS Code。还有 officecli install 自动检测 AI 工具配置目录，把该挂的都挂上。

不止 SKILL.md：三层架构 + 四大引擎

SKILL.md 是入口，但真正让 AI 用得爽的，是 OfficeCLI 的内部设计。

整个工具分三层，理念是"渐进式暴露复杂度"。L1 是语义视图层，用 view 命令输出文本大纲、注释版、HTML、截图——agent 不需要理解 OOXML 就能看懂文档结构。L2 是 DOM 层，用 get、query、set、add、remove、move、swap 操作结构化元素，已经接近编程接口了。L3 是原始 XML 层，提供 raw、raw-set、add-part、validate，XPath 直通底层——这是逃生舱，L1 和 L2 搞不定的极端场景才用。对 AI 来说，先用 L1 试探，需要时下潜到 L2，再不够才碰 L3，token 用量能省不少。

四大引擎里有几个让我眼前一亮的设计。

渲染引擎不依赖 Office 也不依赖 LibreOffice，从零实现。view html 出独立 HTML，view screenshot 每页出 PNG——多模态 agent 可以直接"看到"文档长什么样。还有 watch 命令起 localhost:26315 实时预览。传统文档自动化的最大痛点是 agent 不知道自己做出来的东西到底对不对，渲染引擎解决了这个问题。

公式引擎支持 150 多个 Excel 函数，写入即算，不用等 Excel 重算。动态数组函数 _xlfn. 自动加前缀，原生 OOXML 透视表——把 Excel 最硬核的能力吃透了。

模板合并用 merge 命令，{{key}} 占位符替换为 JSON 数据。这个设计的直觉是：agent 用大量 token 设计一次复杂的 document 布局，下游填充 N 次模板的时候 token 成本为零。对批量生成报表的场景来说，这几乎是必须有的能力。

往返 dump 用 dump 加 batch 把任何 .docx 或 .pptx 的子树序列化成可重放的 batch JSON。agent 可以通过结构化 spec 学习已有文档的内部结构，这比让它去猜 OOXML 要可靠得多。

实际跑一下：5 分钟做一份 PPT

理论讲完了，上实操。打开终端，复制粘贴就行。

# 1. 一行安装（macOS / Linux）curl -fsSL https://raw.githubusercontent.com/iOfficeAI/OfficeCLI/main/install.sh | bash# 2. 创建空白 PPTofficecli create deck.pptx# 3. 启动实时预览（浏览器自动打开 http://localhost:26315）officecli watch deck.pptx# 4. 另开一个终端，加一张幻灯片officecli add deck.pptx / --type slide --prop title="Q4 Report"# 5. 加一个形状officecli add deck.pptx '/slide[1]' --type shape \  --prop text="Revenue grew 25%" \    --prop x=2cm --prop y=5cm \      --prop font=Arial --prop size=24 --prop color=FFFFFF# 6. 查看大纲officecli view deck.pptx outline# → Slide 1: Q4 Report#   → Shape 1 [TextBox]: Revenue grew 25%# 7. 导出 PNG（多模态 agent 友好）officecli view deck.pptx screenshot -o /tmp/deck.png

做个对比。用 python-pptx 做同样的事，大概要写 50 行 Python：导入 Presentation、建 slide、拿 shapes、设 title、设位置、调样式、save。OfficeCLI 一行 officecli add 就完了。而且 python-pptx 只能 Python 调，CLI 方案任何语言都能用——Python、Node、Go、Rust、一个 shell 脚本就够了。

watch 命令的实时预览体验很特别。你一边敲命令改文档，浏览器里一边刷新显示，像前端开发时用 webpack dev server。做文档自动化能实时看到产出，debug 效率完全不一样。

横向对比：它到底处于什么位置

把 OfficeCLI 放到整个 Office 工具链里，它的位置会变得很清楚。

微软 Office 是桌面 GUI 的绝对霸主，功能最全但不是开源的，也没有 AI 原生的 CLI 加 JSON 接口。LibreOffice 是开源桌面办公套件，能做 headless 转换，但同样没有 AI 友好的程序化接口。python-docx 和 openpyxl 是 Python 生态里操作 Office 的工具，问题是跨语言困难，而且没有内置渲染能力——agent 产出了文档但"看不到"自己产出的东西。

OfficeCLI 恰好踩在一个缝隙里：不需要跟微软 Office 抢 GUI 用户，不需要跟 LibreOffice 抢桌面办公，也不需要跟 python-docx 抢 Python 脚本。它就是给 AI agent 用的——单二进制、零安装、CLI 加 JSON 加 MCP、任何语言都能调、内置渲染让 agent 能看到自己的产出、Word/Excel/PPT 统一操作。目前在这条赛道上，它是唯一严肃做到这个定位的开源项目。

和 python-pptx 的根本区别不只是语言。python-pptx 需要你写代码，OfficeCLI 是你告诉 AI"帮我做个 Q4 汇报"，AI 自己去调 CLI。python-pptx 产出的文档你只能在 Office 里打开才能看效果，OfficeCLI 的 view 命令直接出 PNG 和 HTML，agent 当场就看到了。

AI 工具链集成：把 Office 操作装进你的 IDE

MCP 集成这块，OfficeCLI 做得非常省心。

officecli mcp claude       # Claude Codeofficecli mcp cursor       # Cursorofficecli mcp vscode       # VS Code / Copilotofficecli mcp lmstudio     # LM Studio

传统 MCP server 多数是 Python 或 Node 服务，要 npm install、要配置 JSON、要理权限。OfficeCLI 是单二进制加一行命令，门槛直接降到地板。

自动安装就更省事了。officecli install 一行命令，自动检测并配置 Claude Code 的 ~/.claude/skills/ 目录、GitHub Copilot、Cursor、Windsurf、Codex、VS Code、LM Studio——全平台一次搞定。

实际体验是这样的：你在 Claude Code 里说"帮我做一份 Q4 运营数据分析报告，要有目录页、两个图表页、一个总结页"，Claude Code 读到 SKILL.md，调用 MCP 工具，建 docx、加页面、插图表、设格式，然后用 view screenshot 把每一页的 PNG 拍给你看。如果哪页不满意，你说"第三个图表换成饼图"，它直接 officecli set 改元素。整个过程不需要你去打开 Word——这就是 MCP 原生的价值。

风险与适用边界

说了这么多好话，该讲的糗事也得讲。项目才 3 个月，稳定性数据严重不足。主要提交者是 goworm 一个人，bus factor 等于 1。113 个 tag 意味着发版极快，但 semver 可能不严——生产环境务必锁版本。8 个 open issue 说明社区活跃度还有待验证。

依赖和生态上也有几点要注意。.NET 10 运行时是嵌入的，用户无感，但开发者本地编译需要 .NET 10 SDK。macOS 公证流程的 CI 工作流里出现过 allow-jit entitlement 修补，说明公证过程中踩过坑。插件生态还在早期，README 提到三类插件但没见过公开市场。

商业层面也有风险。公司名叫 iOfficeAI，和 Microsoft Office 的商标关系值得关注——法律风险在合规要求高的企业里不是小事。官网 officecli.ai 域名的长期承诺也不明确。"World's first and the best" 这类自夸式话术读 README 的时候注意甄别。

那谁该用呢？AI agent 工程师找程序化 Office 方案的，CI/CD 管道里做报告自动化、文档生成的，多模态 agent 开发者需要 agent 看到自己产出的，企业文档自动化团队做模板填充、批量处理的——这几类人能直接受益。

谁该再等等？需要 GUI 模板编辑的用 MS Office 就行，需要打印出版级 PDF 的用 InDesign 或 LaTeX，以数据可视化为主的用 D3 或 Observable。生产 SLA 要求高的团队，等项目再稳定 1-2 年。

最后

回到标题的反问：给 AI 一个 SKILL.md，它就学会了 Word/Excel/PPT？

答案是：至少在 2026 年的开源生态里，这是最优雅的答案。

OfficeCLI 不性感，不炒作概念。只是在安安静静地用 3 个月时间、4,369 次提交，把"AI 学 Office"这件事从 3 步压到 1 步。403 行 markdown，一行 curl，过去 agent 读几万字 README 才能上手的工作，现在一口气就学会了——而且是结构化的、机器友好的、自带渲染反馈的。

如果你也是 AI 开发者，建议先打开 officecli.ai/SKILL.md 看 5 分钟。你会发现，以前 agent 学一个工具像读一本说明书，现在就像插一张 SIM 卡。