Markdown Drafts with Local Rendering: A Conditional Token-Saving Workflow
A Juejin experiment compares an LLM generating complete HTML with a workflow in which the model produces a Markdown draft and a local engine handles charts, themes, and layout. The author cites an upstream Claude Sonnet 5.5 benchmark averaging 4,893 output tokens for direct HTML versus 612 tokens for Markdown drafting. In the author’s separate three-question test using Seed 2.1 lite, savings depended on first-pass rendering success: two questions used fewer tokens and cost through the pipeline, while one required repair rounds and used more output tokens and cost than direct HTML. The pipeline also produced four to five automatically laid-out charts per page, compared with no SVG charts in the three direct-HTML outputs. Its writing checker could not prevent fabricated facts or data.
The report documents a practical division of labor in which the model focuses on content while deterministic code handles presentation. It also shows that this approach can reduce output tokens and cost when drafts render successfully, but that strict specifications, repair overhead, and human final review remain important.
我先说结论：把「写内容」和「排版」拆开，让模型只写内容、排版交给代码，是这次实验里收益最大的一条改动。
起因很朴素。我给模型提了个问题，让它直接给我一页 HTML 当回答。它写出来了，能用，但我数了一下 token 构成——模型生成的页面里只有 21% 是内容，剩下 79% 是 SVG 坐标、CSS 和标签。这意味着我花钱买的算力，大头花在了「把标题放在左边还是居中」这种问题上。
这张图把问题说清楚了：手写整页平均 4,893 token，其中图表坐标与路径占 47%、HTML 标签占 17%、CSS 占 15%，正文内容只占 21%。而走「只写 Markdown 草稿」这条路，平均 612 token，100% 是内容。
我的做法是把这两件事拆开：模型只写一份 Markdown 草稿，排版引擎在本地把它渲染成一页带图表、带主题、能直接发公众号的信息网页。 下面是我搭的这条流水线的机制和实测数据。