别隔着柜台反复拆包装了 —— Word 文档迭代的轻量与重量之辩

朋友最近跟我吐槽，说他用 Claude Code 写 Word 文档，哪怕装上了专门的 docx skill，还是慢得让人抓狂。我随口问了一句：你试过用 Markdown 或者 HTML 当中间格式吗？

他马上回了一句：“不行，我输入输出都得是 Word。”

原来他的迭代过程一直是在 Word 里原地打转：生成 v1，修改成 v2，再改成 v3……每一版都是 .docx 进出。我忽然意识到一个问题：docx 这个 skill，本质上是写一段代码去解析和操作 Word 文档，每一次的读取和生成，都要额外消耗时间和 token。如果把这些开销都叠加到反复迭代里，那可不是慢上一点点。

于是我给了他一个建议：为什么不在迭代期间完全用纯文本格式呢？Markdown 也好，HTML 也好，把它们当作中间状态。等你把内容打磨得差不多了，再一次性让 AI 生成最终的 Word 文档。这样一来，只有最后一次才需要动用重量级的文档解析，前期全部是轻量的文本操作。

为了验证这个想法，我用 Claude Code + DeepSeek V4 做了一组简单的对比测试。任务非常简单——从一个 Word 文件和纯文本 txt 文件中读取文字，然后做一次简短的内容归纳。

数据由完成任务后调用/cost获取，对应的钱的花费仅供参考，实际可能得把单位换成人民币。

所谓的“墙上时间”（Wall Clock Time），指的是从任务开始到全部结束，你实实在在感受到的那段等待时间——就好比你抬头看墙上的钟，秒针走了多久。报告里的“API 耗时”只反映模型那边干活的速度，而“墙上时间”才是你端着咖啡干等的真实体验。

一个简单得不能再简单的读取归纳，Word 模式花的钱贵了将近 70%，墙上时间几乎是纯文本的三倍，token 消耗也明显更大。如果放到反复迭代的场景里，v1 改 v2 改 v3……每一轮都要再承受一遍这种额外负担，时间和成本的差距会迅速膨胀到让人难以接受。

背后的道理其实不复杂。docx 本质上是一个复杂的打包格式，AI 要想操作它，就要生成或调用代码去解构文档、定位内容、再重新封装。那些你看不见的结构解析、样式处理、命名空间维护，在每一次读写时都会变成实实在在的 token 消耗。如果你只是想让 AI 帮忙打磨一段话、调整一些逻辑，这些开销更像是无谓的“物流成本”。

所以，如果你也经常需要和 AI 一起反复打磨文档，一个非常通用的建议就是：把纯文本格式当作主场。在内容创作、修改、推敲的阶段，让一切都在 Markdown 或纯文本里发生，你只管审核、修改、重写，AI 也只需面对轻量的文字。等版本基本敲定，再一次性召唤 docx skill 生成漂亮的 Word 文件。PPT、Excel也是一样的，先用纯文本搞定内容，再生成最后的文档。

这就像你去蛋糕店订制蛋糕。蛋糕师傅每改一次就把蛋糕里三层外三层包装好，打个蝴蝶结递给你。你拆开一看，奶油裱花不太满意，于是又仔仔细细包回去还给他。他再拆开，修改，重新包好递给你。你们就这样一来一回地折腾——可明明你俩就站在同一个店里，中间只隔着一个柜台。为什么不直接把蛋糕胚放在台面上，你说一句他抹一刀，改到你点头为止，最后再好好包装呢？docx 就是那个还没定稿就被反复打包的蛋糕。

甚至可以考虑更彻底一点的做法——如果最终呈现不需要死守 .docx 格式，不妨直接使用 HTML 作为最终产出。在屏幕阅读场景下，一份排版得当的 HTML 页面，可读性完全不输 Word，而且它天生的轻量和可交互性，还能延展出更多可能。我之前的一篇下一代！AI时代你还在用PPT吗？就传递了类似的思想。

在 AI 工作流变得越来越日常的今天，选择对的时间用对的格式，比无脑硬刚要重要得多。别跟蛋糕师傅隔着柜台反复拆包装——你俩明明就站在一起。