M2.7 开启了模型的自我进化。在专业办公领域，它对 Excel/PPT/Word 的复杂编辑能力有了显著提升。

但真正用过 Agent 处理文档的人都知道：最难的不是写不出来，是写出来不能用。

公式存完变成了死数字。模板编辑一轮后格式全乱了。数据透视表保存之后悄悄丢了。文件能打开，但没办法作为最终交付产出。

MiniMax 踩过这个坑，然后把解法开源了。

为什么"能跑"的文档"不能用"

Openpyxl 是 Python 社区最常见的 Excel 处理方案，但它有一个工程上很难接受的缺陷：文件读入再写回之后，某些高级内容会被静默丢弃。数据透视表、迷你图、VBA 宏——没了，但没有报错，没有提示。对于"读取→编辑→回写"这个最常见的真实使用场景，这种静默失败是致命的。

python-docx 面临类似问题。复杂表格嵌套、多级目录、页眉页脚控制、修订追踪——有些功能不支持，有些功能支持但生成出来的文档结构容易出错。

问题不在于生成，在于底层链路的可控性。

四个 Skill，四种不同的底层选择

docx：选 .NET OpenXML SDK，而不是 python-docx

.NET OpenXML SDK 是微软官方维护的底层库，对 ECMA-376（Word 文件格式的官方标准）实现最完整。选它意味着更高的部署成本——需要额外部署 .NET 运行环境——但换来的是对 Word 文档结构的完整控制。

文档质量比部署便利性更重要。

xlsx：直接操作 XML，绕开所有 Python Excel 库

.xlsx 文件本质上是一个压缩包，里面是一组 XML 文件。MiniMax 的做法：解压 → 只修改目标单元格对应的 XML 节点 → 重新打包。每次编辑只动需要动的地方，样式、图表、宏都原封不动保留。

另一个关键点：公式。MiniMax 要求每一个派生值都必须是真正的 Excel 公式，比如 SUM(B2:B9)，这样用户打开文件后还能正常编辑和联动。

为此他们开发了 13 个独立的 Python 工具脚本，并写了一篇 34,000 字的金融格式化标准文档，对齐投行级别的数字格式要求。

pdf：封面和正文拆成两套渲染引擎

封面用 HTML + CSS 编写，通过 Playwright 渲染为 PDF。渐变、网格、混合模式、自定义字体——CSS 原生就支持，多数 PDF 绘图 API 做这些非常吃力。正文交给 ReportLab 排版，它在段落流控制、分页策略、页眉页脚方面更稳定可控。最后通过 merge 脚本把两部分合二为一。

拆成两套引擎，系统更复杂，但封面可以大胆做设计，正文仍然保持工程上的稳定。

pptx：先定义约束体系，再做生成

PPT 生成的难点不在于往 slide 上放内容，在于视觉风格的统一。字体大小、间距、配色、圆角弧度，任何一个地方不一致，整份演示文稿看起来都会很粗糙。

MiniMax 的做法：先定义约束体系，再去做生成。页面类型定义了 5 种标准类型，风格上设计了 4 套配方（Sharp、Soft、Rounded、Pill），每套配方定义了圆角半径、阴影参数、边框粗细、间距比例等一整套数值。切换配方，就能整体改变一份 PPT 的视觉调性。

自进化机制：Execute → Evaluate → Fix

一个 skill 如果不能在失败里持续学习，它很快就会停留在 demo 阶段。

MiniMax 没有把质量迭代完全交给人工 review，而是搭了一套固定的三阶段循环：

Execute → Evaluate → Fix

先执行一组真实用例 → 再根据规则检查输出是否达标 → 把失败样例沉淀成可修复的问题，进入下一轮迭代。

"达标"的定义不只是文件能打开。MiniMax 真正关心的是：结构是不是完整，公式还是不是公式，版式在读写之后有没有悄悄变形，模板约束有没有被破坏。

一个 xlsx 文件即使成功保存，如果数据透视表丢了、公式被写成了静态数字，在真实交付里都算失败。

只有底层链路足够可控，评测才可能对齐到真正有意义的质量指标，而不是停留在"程序没报错"这一层。