夜雨聆风能打开，不代表能交付
你让 AI 帮你生成了一份 Excel 报表。
打开文件，整整齐齐。列头对齐，公式完整，图表精美。你把文件发给客户，顺手保存一次。
客户打开。
数据透视表消失了。没有报错，没有提示，就像它从来没存在过。
这不是假设场景。这是用 openpyxl 处理 Excel 文件时真实会发生的事。那个库在读取再写入时，会悄悄丢掉高级功能，数据透视表、迷你图、VBA 宏，全都不见了，而且不告诉你。你以为交付了一份完整的文件，实际上交出去的是一颗定时炸弹。
MiniMax 最近开源了他们的 Office Skills，一套专门用来生成“真正可交付”文档的工具链，覆盖 Word、Excel、PDF、PowerPoint 四种格式，MIT 许可。
“难的不是生成文件。难的是生成一份能交付的文件。”
这句话背后，是一套完整的技术选择逻辑，以及一个让技能自我迭代的评估机制。
Word：选了更难部署的那个库
python-docx 是社区最常用的 Word 生成库，轻量，易用，大多数教程都从这里出发。
但当场景推进到嵌套表格、多级目录、页眉页脚的精确控制、修订记录，这个库开始露出边界，要么功能不支持，要么产生结构性损坏的输出。
MiniMax 的选择是 . NET OpenXML SDK.
OpenXML SDK：微软官方的 Office 文档底层库，对 ECMA-376（Word 格式的国际标准）有最完整的实现。代价是需要部署 .NET 运行时，比纯 Python 方案复杂得多。就像用原厂零件而不是通用替代品修车，稳定性更高，但采购链更长。
他们的判断是：文档质量比部署便利更重要。
在这个基础上，他们围绕三个核心场景构建：从零生成完整文档、在不破坏格式的前提下编辑已有文档、应用设计模板并自动做结构合规检查。配套写了 OpenXML 格式参考文档、CJK 排版规范、10 多个可运行的代码示例。
Excel：绕开所有库，直接动 XML
Excel 的失败方式比 Word 更隐蔽。
openpyxl：最常用的 Python Excel 操作库，读写 .xlsx 文件的主要工具。在处理基础表格时表现稳定，但遇到 pivot table、sparkline、VBA 宏等高级功能时，读取再写回会导致这些功能静默消失，不报错，不警告。
这个问题在生产环境里很难接受。读取、修改、写回，这是最普通的工作流，偏偏在这里出问题，而且出了还不说。
MiniMax 的做法是跳过所有 Python Excel 库，直接操作 XML 层。
一个 .xlsx 文件本质上是个 zip 压缩包，里面装着 XML 文件。就像把一栋楼的图纸装进档案袋，想改某个房间，就把那张图纸取出来，只修改它，再放回去。解压，定向修改目标单元格的 XML 节点，重新打包。每次编辑只碰需要改的部分，样式、图表、宏保持原样。
另外还有一条硬规则：所有衍生值必须保持真实的 Excel 公式，SUM(B2: B9)，而不是预先算好的数字。用户打开文件，数据仍然是联动的，改一个源头，所有引用它的地方都跟着变。
他们为此构建了 13 个独立的 Python 工具脚本，覆盖解压打包、列插入、行偏移、公式校验、动态重算、格式审查等操作。还写了一份 34000 字的财务格式规范，对齐投行级的数字格式和布局标准。
PDF：封面和正文，用两套引擎
PDF 生成的核心难题不是排版文字，而是构建一套可复用的设计系统。
MiniMax 为 15 种文档类型分别设计了封面布局、字体方案和色彩体系。这件事有个结构性矛盾：封面要好看，需要渐变、网格、混合模式、自定义字体；正文要稳定，需要对分页、段落流、页眉页脚有精确控制。这两件事，很难用同一个引擎都做好。
他们的解法是用两套引擎分别负责不同部分。封面用 HTML + CSS，通过 Playwright 渲染成 PDF，因为 CSS 原生就能处理那些视觉效果，大多数专用 PDF 绘图库在这里都很笨拙。正文用 ReportLab，提供工程层面稳定可预期的控制。最后用合并脚本把两部分拼成一个完整的 PDF。
就像一家餐厅把甜品区和主厨区分开，各自用最合适的设备和工艺，最后由服务员端上同一张桌子。系统复杂度提升了，但两端都没有妥协。
PowerPoint：先定义约束，再生成内容
PPT 生成里，内容从来不是最难的部分。
难的是视觉一致性。字号差了 1pt，间距松了 2px，圆角半径不统一，某张幻灯片的颜色偏了一点点，整套 PPT 就开始看起来像是拼凑的。
MiniMax 的方法是反转顺序：先把约束系统定义清楚，再在约束里生成内容。
他们规定了五种标准页面类型，封面、目录、章节分隔页、内容页、总结页，每种都有明确的布局规则和元素定位。然后设计了四种风格配方，Sharp、Soft、Rounded、Pill，每个配方是一套完整的数值集，圆角半径、阴影参数、边框粗细、间距比例全部写定。
换配方就像换制服，不是一件一件地改，而是整套替换，视觉风格统一切换。
实现上用 PptxGenJS，编辑已有模板时和 Excel 同样的策略：解压 .pptx，直接修改 XML，重新打包，尽量保留原有结构。
“能运行”和“能交付”之间，有一个评估体系
建一个能生成文件的工具不难。难的是知道下一个版本是不是真的更好，而不是只是换了一种方式出错。
MiniMax 构建了一个固定的三阶段循环：执行、评估、修复。跑真实用例，用规则检查输出，把失败提炼成可执行的问题，送入下一轮。每次修复后立刻验证，这次真的改好了，还是只是在别处出了新问题？
他们对“通过”的定义，远不止“文件能打开”。
要检查结构是否完整，公式是否还是公式，布局在读写过程中有没有静默变形，模板约束是否被保留。一个保存成功但丢失了数据透视表的 .xlsx，一个目录能渲染但无法更新的 .docx，都算失败。
这也是为什么每种格式都选了更复杂技术方案的原因。只有底层管线足够可控，评估才能衡量真正重要的东西，而不只是“程序没有报错”。
反过来的路径
有一种常见的产品路径：先把演示做漂亮，再想办法让它真正能用。
MiniMax 做的是反过来的路径：先把“能交付”这件事定义清楚，然后把所有技术选择对准这个目标。
每一个选择，都是用更高的系统复杂度换更可靠的最终输出。
代价和选择总是成对出现的。他们做的只是把这件事说清楚，然后选了那个更难的选项。
回到最开始那份消失了数据透视表的 Excel，现在有解法了。
代码在这里：github.com/MiniMax-AI/skills，MIT 许可。
原文来源：MiniMax Blog
