做 AI 办公应用,先要有可编程的表格和文档:Univer 1.0 来了

让 AI 填一张表很容易；让它修改的表格仍能被人打开、检查公式、继续协作，就没那么容易了。

很多团队想给自己的业务系统加上“像电子表格一样编辑”的能力。开始时只要一个网格，随后会遇到公式、筛选、撤销、文档排版、权限、文件转换，以及“让 AI 改完以后怎么核对”。如果每个环节都自己造轮子，办公应用很快就变成一项长期基础设施工程。

这周值得看的开源项目是 Univer。它由 DreamNum 维护，定位是可嵌入产品的 Office SDK，而不是另一个必须整体搬进来的在线办公网站。9 月 24 日，项目发布 1.0.0，随后同日推出 1.0.1、1.0.2。2026 年 9 月 26 日约 22 时查询 GitHub Trending 周榜时，它显示“本周 3,928 个 Star”。这是 GitHub 的滚动七日口径，不能理解成北京时间周一以来的精确净增量，也不能直接说明质量。

想象一个销售分析平台：用户在网页里改预算表，另一边是根据单元格实时变化的报表；AI 可以生成公式，运营人员再手动调整。这里需要的不只是“显示 Excel”，而是表格模型、计算、渲染、命令和界面能够一起工作。Univer 的思路，是把这些能力做成 SDK，允许产品按需选择。

仓库的开源核心包含插件系统、Canvas 渲染引擎、公式引擎和 Facade API。它提供 Sheets 与 Docs 的基础编辑能力，Slides 的开源模型和界面仍在发展。官方 1.0 发布说明提到 Sheets、Docs、Slides、Boards、Bases、PDF 六类编辑器，但那是整个 Univer 产品系列的描述。尤其是 Bases、PDF，以及许多高级功能，不能只看发布标题就认定开源仓库已经免费提供完整实现。

图 1｜原创示意：仓库开源能力与商业扩展要分开看

Univer 的关键设计是“插件优先”。公式、格式、文档界面等能力由不同包组合，开发者可以用预设快速得到一个可工作的表格，也可以自己挑选插件，控制依赖和加载方式。对已有 SaaS 或内部系统，这比把整套办公产品嵌进去更灵活：导航、账号、业务数据仍由原系统掌握。

用户看到的是可编辑的网格或页面；底下是文档模型、命令、公式计算和渲染层。Facade API 则把常见操作整理成较统一的调用入口，例如访问工作簿、工作表、区域与公式。浏览器里可以有人操作的界面；在 Node.js 里也能用无界面模式处理表格或文档。这给批量处理、自动化和 Agent 调用提供了接口，但具体能力仍取决于所装的包和许可证。

这套分层设计还有一个朴素好处：产品团队不必把“编辑器长什么样”与“内容怎么算”绑在一起。比如同一份预算表，前台需要选区、工具栏和格式，夜间任务只需要读取数据、计算并写回结果。两种场景可以围绕同一套内容模型设计，而无需在后台假装点开一个网页。它减少的是集成时反复搬运数据的工作，并不免除对文件格式、版本和权限的验证。

图 2｜原创示意：界面与无界面任务共用可编程底座

“让 AI 帮我做报表”经常被演示成一句话生成文件。真正进入业务流程，问题会更细：它改了哪个单元格？公式引用了什么？写入后渲染有没有溢出？人能否在同一份内容上接着修改？Univer 的 AI 方向把办公内容暴露为结构化操作对象，并强调内容检查、截图和布局诊断。项目还提供基于 SDK 构建的 Workspace 等示例，让人看到 Agent 改动和人工复核如何衔接。

这不意味着装上开源包就自带一个可靠的“AI 同事”。模型选择、提示、权限控制、结果验证和多人协作都需要另行设计；官方文档也把实时协作、共享修订和相关 Worktree 工作流放在对应 Web SDK 与协作能力之下，套餐和许可证随功能而变。把 API 视为可审查的操作接口，比把宣传中的全部 AI 场景都视为现成开源功能更准确。

图 3｜原创流程：提出需求、结构化修改、检查结果、人工确认

如果只是想看看效果，先访问官方示例；如果要做最小集成，仓库 README 的 Preset Mode 给出了表格起步方式：安装 @univerjs/presets 与 @univerjs/preset-sheets-core，再按文档注册预设、语言包和样式。需要细控时用 Plugin Mode。不要把一行安装命令误当成完整的生产集成教程；持久化、身份、权限和业务数据同步仍要自己设计。

试用时可以先定一个很小的验收场景：在页面创建工作簿，写入三行数据和一个求和公式，刷新后检查内容是否仍在；再让脚本读回计算结果。这样能尽早发现真正决定选型的问题，例如所需插件、数据保存方式、公式兼容性和界面性能，而不是被展示页上的功能数量带着走。

它适合在产品里嵌入可编辑表格或文档的开发团队，也适合希望让自动化程序读写办公内容的工具作者。只想偶尔打开一个 XLSX 的个人用户，直接使用现成办公软件可能更省事。尤其在评估前，应列清功能清单：是否需要导入导出 Office 文件、多人实时协作、图表、透视表或 PDF 编辑。仓库 README 明确把多项能力归入 Pro，商业边界会直接影响预算和架构。

图 4｜原创示意：从需求、许可到集成成本逐项核对

这次 1.0 并非只换了版本号。官方列出更统一的编辑器集成模型、性能与兼容性改进，也提醒从 0.25 升级会遇到 API 删除和包结构变化；预设不再提供 UMD 构建，依赖旧调用的应用需要迁移。项目的部分表面仍在持续开发，使用内部或实验性 API 的团队尤其应先做原型验证。1.0.2 已修复若干问题，但修复列表里也包含 Pro 功能，不能据此推断开源版包含这些能力。

安全方面，任何允许 Agent 修改业务文档的系统，都应该限制可写范围，记录变更，并在重要内容交付前人工检查。若接入协作服务或外部模型，还要明确数据流向、权限和留存策略。这些是集成者必须处理的工程责任，不是 Univer 单独能够替你保证的结果。

Univer 值得关注的原因，是它把“办公文件”从一个最终产物，进一步变成应用可以嵌入、程序可以操作、人仍能继续编辑的工作空间。对打算做 AI 报表、内部业务工具或文档型产品的团队，这是一套值得认真试做原型的底座。先从开源能力表和最小集成入手，再决定高级功能是否需要商业版本。