夜雨聆风办公自动化变了
读取、修改、渲染、检查、修正——办公文件正在进入 Agent 的交付闭环。
我们现在用 AI 做办公，通常卡在最后一步。
让它写一份周报，很快；把内容放进公司模板、调整标题层级、检查分页，还得自己来。
让它分析一份表格，也不难；但公式有没有被破坏、图表是否错位、结果能不能直接交付，还是要人工确认。
PPT 更明显：大纲几分钟就有，真正耗时间的是把它变成一份能打开、能修改、能检查的演示文件。
所以我看到 OfficeCLI 时，真正感兴趣的不是它上过 GitHub Trending，而是它背后的一个变化：AI Agent 开始从“给我一段内容”，走向“替我处理一份文件”。
OfficeCLI 值得关注的地方，不是又多了一个 Office 生成器，而是 Word、Excel、PPT 开始具备一条完整的 Agent 工作链。
根据 OfficeCLI 官方说明，它用一个命令行工具处理 Word、Excel 和 PowerPoint，可以创建、读取和修改文档，也不要求本机安装 Office。
更关键的是“渲染”。它可以把文档转成 HTML 或 PNG，让 Agent 不只看到文件结构，还能看到接近最终交付的视觉结果。
只会生成文件，Agent 做完就停了；能够渲染检查，它才有机会发现标题挤出卡片、表格超出页面、文本框被截断，然后回去继续修改。
我更愿意把它理解成一个办公文件执行层：上面可以是 Codex 或其他 Agent，下面则是可被读取、修改和验证的真实文件。
过去的办公自动化，通常是固定动作：打开软件、点某个菜单、复制一列数据、导出一个文件。它的优点是稳定，缺点是环境一变就容易失效。
Agent 式工作流先理解任务，再选择动作，还能根据结果继续调整。真正决定它能否进入生产的，不是“会不会生成”，而是三层能力：
看得懂：读出段落、表格、页面、幻灯片和对象结构。
改得动：准确修改指定内容，而不是整份文件推倒重做。
验得过：渲染结果，对照要求继续修正，并保留人工复核入口。
OfficeCLI 让我觉得有意思，正是因为这三层被放进了同一条命令行链路里。
如果直接让 Agent 接管所有 Word、Excel 和 PPT，我不会这么做。更现实的入口，是输入明确、模板固定、验收标准清楚的任务。
Word：把结构化资料填入已有周报模板，统一标题层级，渲染后检查分页和表格。
Excel：读取固定表格，更新指定区域，保留公式，再检查关键单元格和图表。
PPT：根据确认过的大纲生成初版，替换模板占位内容，渲染每页缩略图，再检查溢出、错位和信息密度。
这些任务有一个共同点：结果不是一句“看起来还行”，而是可以被明确验收。标准越清楚，Agent 越有机会把事情做完整。
第一，复杂格式能不能保住。普通段落和简单表格通过，不代表公司模板、母版、图表、公式、页眉页脚也能稳定处理。
第二，同一任务能不能重复通过。演示成功一次只是 Demo。连续处理十份同类文件，结果是否一致，才接近生产能力。
第三，失败后能不能精确定位。如果只能得到“生成失败”，价值有限；能指出哪一页、哪个对象、哪条规则没通过，才方便修正。
第四，敏感数据和许可边界是否清楚。OfficeCLI 仓库采用 Apache-2.0 许可，但正式使用前仍要检查第三方依赖声明、文件存放位置，以及真实业务数据能否进入这条链路。
开源不等于可以忽略数据安全，能运行也不等于已经适合生产。
不要先搭一套宏大的“全自动办公系统”。先拿一个已经交付过的旧文件，做一次最小验证：
1. 复制一份真实文件，并把敏感信息脱敏。
2. 只定义一个任务，例如“替换三处数据并保留原格式”。
3. 写清验收条件：哪些内容必须不变，哪些结果必须正确。
4. 让 Agent 修改并渲染，对照原文件逐项检查。
5. 记录失败点，再决定它适合辅助、半自动，还是暂时不用。
我的通过标准很简单：内容改对、格式没坏、结果可复核、失败能重来。四项都过，再考虑把它接到批处理、报告生成或内容生产流水线里。
工具的热度会过去，但文件交付不会。Agent 真正碰到知识工作的最后一公里，是从它能通过真实验收开始。
对普通人来说，最好的起点不是相信它能一键接管办公，而是拿一个真实文件，让它先通过一次真实验收。
