Markdown 草稿配合本地渲染：节省取决于一次通过率
掘金实验比较了让大模型直接编写完整 HTML 与“模型生成 Markdown 草稿、本地引擎负责图表和排版”两种流程。作者引用一项 Claude Sonnet 5.5 上游基准：直接 HTML 平均使用 4,893 个输出 token，而 Markdown 草稿平均为 612 个。作者另用 Seed 2.1 lite 测试三个问题，结果显示节省取决于草稿能否一次渲染通过：其中两个问题通过该流程减少了 token 和成本，另一个问题因触发修复轮，输出 token 和成本反而高于直接 HTML。该流程每页还自动生成四至五个图表，而直接 HTML 的三个输出均没有 SVG 图表。其写作检查器无法阻止事实和数据编造。
该报告展示了一种让模型专注内容、由确定性代码处理展示的工程分工。它同时表明，草稿一次渲染成功时这种方法可以减少输出 token 和成本，但严格规范、修复开销与人工终审仍不可忽视。
我先说结论：把「写内容」和「排版」拆开，让模型只写内容、排版交给代码，是这次实验里收益最大的一条改动。
起因很朴素。我给模型提了个问题，让它直接给我一页 HTML 当回答。它写出来了，能用，但我数了一下 token 构成——模型生成的页面里只有 21% 是内容，剩下 79% 是 SVG 坐标、CSS 和标签。这意味着我花钱买的算力，大头花在了「把标题放在左边还是居中」这种问题上。
这张图把问题说清楚了：手写整页平均 4,893 token，其中图表坐标与路径占 47%、HTML 标签占 17%、CSS 占 15%，正文内容只占 21%。而走「只写 Markdown 草稿」这条路，平均 612 token，100% 是内容。
我的做法是把这两件事拆开：模型只写一份 Markdown 草稿，排版引擎在本地把它渲染成一页带图表、带主题、能直接发公众号的信息网页。 下面是我搭的这条流水线的机制和实测数据。