9,800 星的 genoffice：一个真的能开 .docx 的 AI 办公套件，改完还是 Word 能认的原文件

一、核心取舍：只重写你改过的那几个字节

几乎所有「AI 生成 Word」的工具，最后一步都是「重新拼一个文件」。这种做法的问题很明显：样式丢了、页眉页脚没了、批注和公式变成死图。

genoffice 反过来做，它把原始文件当成源，不另存一份，只做局部手术：

打开 docx ─► 按哈希归档原文件（此后不再触碰）           ─► 解析 word/document.xml 顶层元素（w:p / w:tbl …）           ─► 生成块树，每块锚定 docxIndex + 原始 XML 片段           ─► Tiptap 流式编辑器（手动编辑 + AI 编辑，脏块追踪） 保存      ─► 脏块 → OOXML 片段（只引用文件里已有的样式）           ─► 拼回原 document.xml；未改动的块保留原字节           ─► 重新打包 zip；其余条目逐字节复制

README 的说法是「byte-preserving」（字节保留）：没有改动到的部分，一个字节都不会变。所以一份被 AI 改过的合同，拿到 Word 里打开还是原来的排版，页眉、页脚、批注、修订、公式、墨迹都还在。

这个设计在表格和幻灯片里也是同一套逻辑：原文件是源，编辑是窄补丁。它带来的直接好处是「不会因为用了 AI 就把文件弄坏」——这是同类工具体验里翻车频次偏高的一处。

二、六个编辑器，一个 AI 面板

装完之后是一个标签页窗口，六种文件各自有专属编辑器，但右侧是同一个 AI 面板，操作方式也统一：选中文字会出现 Ask AI 小浮层，可以立即发送，也可以把几条不同位置的改动排队，最后一趟跑完。

其中 PDF 那一块值得多说一句。很多「PDF 编辑」工具的做法是在文字上面盖一个白色矩形再写新字，一旦放大或者换阅读器就露馅。genoffice 走的是另一条路：用 PDFium 把页面的内容流整个重写，字体还是原来那个字体。转换也一样在本机完成——PDF 转 Word、Excel、PowerPoint 都不上传，扫描件走系统 OCR。

三、AI 的两种用法：改，和问

改：每一轮都是可回滚的快照

在 Docs 里让 AI 改一段总结，它会先读需要的那几个块，再改写 Overview、插入一个新的项目符号段落。整个过程里，每一次 AI 回合都是一个快照，面板上直接给「回滚」按钮；打开「修订模式」，改动就以 Word 风格的修订记进来，谁改的、改了什么一目了然。

Sheets 里更能看出区别。用一句话让它加一个「Summary」工作表，它写的是真的 <code>SUMIF</code> 公式，不是算好再粘进去的数字；顺手插一个柱状图，43 处改动打包成一次可撤销的批量操作。公式在写完之后会被表格引擎求值，所以读出来就是数字，不是一串待计算的字符串。

Slides 里是「一句话题目 → 十页 deck」：先规划故事线，再逐页画到画布上，最后交出来的是一个真正的 .pptx。生成的页面不是图片，是可以继续改标题、换配图、调母版的对象。

问：答案带出处，点一下就打开原文

首页的 Ask AI可以把你在意的几个文件标星，当作一个小知识库。用自然语言提问，它会在这些文件里检索、按页读取，然后作答——每一句结论后面都挂着一个引用，点引用直接打开那个文件并跳到对应位置。

这套问答和搜索共用同一个本机索引，模型只看得到命中的片段，而且只通过你自己配置的供应商发出。

四、搜索：找「回答问题的文件」，而不是「包含关键词的文件」

首页的搜索建在本机 SQLite 全文索引上，覆盖 Word、Excel、PowerPoint、PDF、Markdown、HTML 的文件名、文件夹名和正文，对中日韩文字做了分词。

但真正有意思的是一个可选项：Jev 重排。它的例子很典型——搜「laptop refresh policy」，全文检索会把一份「浏览器缓存刷新策略」、一份「品牌焕新计划」、一份「仪表盘刷新排期」排在前面，因为它们字面更匹配；而那份写着「笔记本三年更换周期」的设备标准文档，反而排在很后面。

打开 Jev 重排之后，本机命中的前 20 条会被送给 TypeSafe 的 System One 模型判断相关性：它不给每个文档生成一段话，而是一次调用返回每条一个校准过的相关性分数，然后按分数重新排序。上面那个例子里，设备标准文档会被顶到前列，结果数旁边出现一个 Jev 标记。

五、真正让它在开发者圈子里传开的：命令行和 Agent

如果说编辑器是给普通人用的，那么 genoffice这个命令行是给写代码的人用的。它随应用一起安装，自带运行时，所有命令在终端里无界面跑同一套引擎，文档不会发到任何地方。

更关键的是配套的 agent skill（skills/genoffice/SKILL.md，7.8 万字节，229 行）。装进 Claude Code、Codex、Cursor、Gemini CLI、GitHub Copilot、OpenCode 或 Windsurf 之后，编码 Agent 就能直接产出真的 Office 文件，而不是「给你一段 Markdown 你自己贴进 Word」。

安装有三种方式：

README 里展示的 Solar System 八页 deck，就是 Claude Code 用一条提示词做出来的。Agent 实际执行的命令长这样：

genoffice capabilities --json                        # 查当前配了哪些云端能力 genoffice guide slides design                        # 读 deck 的工作流与版式库 genoffice image "the eight planets in a row …" --aspect 16:9 --out deck/assets/cover.jpg genoffice slides check deck/outline.json --json      # 8 页大纲，无问题 genoffice slides check deck/pages/01.json --json     # 单页构建并检查溢出与重叠 genoffice create --type pptx --spec deck/pages --outline deck/outline.json --out deck/solar-system.pptx --json genoffice slides render deck/solar-system.pptx --out deck/shots --json genoffice slides audit deck/solar-system.pptx --json # 8 页，无版式问题 genoffice slides replace deck/solar-system.pptx --slide 4 --spec deck/pages/05.json --json

这套流程里有个值得注意的分工：genoffice 内部不发生任何模型调用。思考的是 Agent，构建和检查的是 CLI，产物是一个普通 .pptx，用 PowerPoint 也能打开。它把「AI 写文档」这件事拆成了「谁想、谁做、谁验」三个角色。

slides check会把问题拒在门外——文字溢出、元素重叠、图片被拉伸，都是硬错误，不通过就不让生成下一页。这类「先审计再交付」的做法，正好补上了生成式 AI 最容易出错的一环。

六、MCP：不碰终端的 Agent 也能用

有些客户端跑不了终端，有些场景你不想给 Agent 一个 shell。所以同一批命令也暴露成了 MCP 工具，README 里说的是 29 个工具，外加把这些工具的参考文档作为资源提供。入口有三种：

接进 Claude Code 就一行：

claude mcp add --transport stdio genoffice -- genoffice mcp

Cursor、Claude Desktop 之类填一段 JSON：

{ "mcpServers": { "genoffice": { "command": "genoffice", "args": ["mcp"] } } }

README 里还完整记录了一次「纯 MCP、不碰命令行」的构建过程：Claude Code 只挂了 genoffice 的 MCP 服务器，问一句话做一份 2026 年可再生能源投资人简报，最后跑了 38 次工具调用、约 13 分钟——4 次搜索拿 IEA、BNEF、IRENA 的数字，7 次图片搜索加 7 次 media判断候选图是不是真照片，然后 deck_start定风格与大纲，deck_page一页一页写并且逐页校验，deck_build组装，slides_audit查溢出，slides_render把每页渲染成 PNG 返给模型看，deck_replace修掉三页不满意的。

整个过程里，只有 search和 media两个工具的数据离开了本机。

七、模型随你挑，也可以一个 key 都不用

AI 后端有两种配置方式：

登录 Genspark，什么都不用设。模型走 Genspark 的代理（Claude、GPT、Gemini 系列），Agent 自带联网搜索、图片搜索、图像生成、图像/音视频分析。

自己带 key，支持 Claude、OpenAI、Gemini、DeepSeek、Kimi、GLM、Qwen、Doubao、MiniMax、Grok、Mistral、OpenRouter、Requesty、Opper、Cheaper Inference、Atlas Cloud、OpenCode Zen/Go，以及任何 OpenAI 兼容端点——本机跑的模型服务器也算。搜索和图像有单独的供应商设置：Serper、Serply、Tavily 或 Parallel 做网页搜索，OpenAI、Gemini、Doubao/Seedream 等做图像。

一个细节：Parallel 的免费 Search MCP 在没有任何登录和 key 的情况下是默认的网页搜索，并且排在那套 DuckDuckGo 抓取前面。也就是说，一个 key 都没有的时候，联网搜索仍然能用，只是有速率限制。

八、怎么装，装完能干什么

各平台的安装包都在 Releases 页，macOS 和 Windows 的安装包有签名：

Linux 下 deb 走 apt 装会自动带依赖并加进应用菜单，AppImage 则要先装 FUSE 2 运行时（Ubuntu 24.04 上包名是 libfuse2t64），再 chmod +x直接跑。

想从源码来，需要 Node 22.12+、npm 10，以及一个 Rust 工具链（只有表格的 xlsx 侧车需要）：

npm install npm run fixtures     # 生成测试用 docx 夹具 npm test             # 引擎 + 应用单元测试（docs/sheets/slides 不需要显示器） npm run typecheck    # 每个 workspace 跑 tsc --noEmit npm run dev          # 六个编辑器 + 外壳，对着 Vite 开发服务器

九、它和 WPS AI、Copilot 那类工具差在哪

现在带 AI 的办公软件不少，但路子差别挺大。粗略分三类：

genoffice 的取舍很清楚：把「文件的所有权」和「模型的选择权」都交回给用户。代价是它不是一个多人实时协作平台，也没有云端同步——它就是一组装在你机器上的桌面应用。

十、怎么看待这个项目

76 天做到 9,887 星、36 个版本，这个速度说明它踩中了一个真实的痛点：大家已经接受「让 AI 写文档」，但还没接受「AI 写出来的文档不能用」。

它的答案不是把生成质量再调高一点，而是换了个底座——不重新造文件，只在原文件上动刀。字节保留这件事听起来很工程、很不性感，但它决定了这份文件明天还能不能在 Word 里被同事打开、被法务批注、被打印。对一个办公软件来说，这比生成得多花哨重要得多。

另一个值得关注的设计是「CLI 负责构建、Agent 负责思考、check 负责验收」的分工。它把 AI 生成里最难保证的一致性，变成了可以用命令退出码判断的东西——slides check不通过就是退出码 1。这种「把不确定性关进流程里」的思路，比再多几轮提示词工程都实在。

不足也很明显。项目太新，0.11 版本，文档密度跟不上功能密度，很多能力只写在 README 和 SKILL.md 里；PDF 转换、导出 PDF、docx 转 html 这些路径要依赖应用本体，纯命令行环境跑不起来；没有移动端，没有协作，没有版本历史——这些都是桌面单机工具的天然短板。

但如果你正好在找一个「AI 能改、改完还是真文件、还能被编码 Agent 批量调用」的办公套件，这个组合目前不多见。9,887 颗星里，大概有相当一部分是冲着 genoffice mcp那一行命令点的。

把 AI 塞进办公软件不难，难的是让它在改完之后，文件还是原来那个文件。

本文数据抓取于公开 GitHub API 与仓库文件，统计口径为实测值。文中指出的问题均为当前快照下的观察结果，项目在持续更新中，建议以仓库最新状态为准。