标书生在 Word 里

正文里九十八行标题被套上了连续编号，从 1.1 一路排到 1.100，打印稿同样带号。这就是「格式是导出按钮」这条路会撞上的墙——下面细讲根因，先说我们为什么不走那条路。

两条路线 {#luxian|两条路线]

一种做法：让 AI 生成 Markdown 或者纯文本，导出时再「转换」成 Word。演示时看不出问题，因为演示不看格式。

另一种做法：正文从一开始就写在 Word 里。一节一个文件，写作、修订、批注全部落在 Word 对象上；招标方给了样子的格式件——投标函、授权书、开标一览表——从招标原件按元素拷贝进来，表格、样式、编号原样迁移；AI 的每一处改动都是 Word 修订，你逐条接受或拒绝。

评标专家在 Word 和 PDF 里打分，格式不合规本身是扣分项甚至废标项。格式不是最后一步的转换问题，是生产环境本身。

98 行是怎么污染的

回到开头那本乱号的标书。排查下来，根因藏在 Word 的样式机制里。

Word 的样式有两套身份：内部编号和名字。历史标书素材里带着一个叫「标题 2」的样式，挂着自己的自动编号；拷贝素材时，这个样式跟着迁进了整本文档。于是文档里出现了两个「标题 2」——一个来自模板，一个来自素材。WPS 打开时按名字合并，两个样式揉成一个，整本所有二级标题被套上连续编号。

九十八行，就是这么来的。

修法是几条机械规则：样式迁移按内部编号和名字双维查重；重名的自动改名，断掉按名合并的路径；编号和标题样式的绑定一律剥除——章节编号由程序按目录树序生成，不靠 Word 自动编号；拷进来的段落剥掉源文档的导航元数据。修完重跑：重名样式三组归零，污染九十八行归零。页数从一百零三变成一百二十一——之前的「紧凑」，其实是排版坏了的紧凑。

同族的问题还抓到过一个：素材标题同时带样式级和段落级两层自动编号，整本里出现「1.1.2.4.1 数据项定义」这种五级深号，和合册程序盖的「6.1」章号同页并存。这一次我们连设计原则一起修了：素材的内容和版式可以保真，素材自带的章节编号不保真——乱编号比没编号糟糕得多。

编号归程序管，模型不参与

既然样式自动编号这么容易失控，编号从哪来？

从目录树来。编号是树位置的纯函数：第三章下面第二节就是 3.2，再往下的小标题按出现顺序接 3.2.1、3.2.2。程序在合成整本时拼进标题文本，四种编号格式（「第X章」式、「1.1」式、公文「一、（一）」式、无编号）任务级可选。模型全程不参与——它不知道自己在树里的位置，让它编号必错。

顺带治了另一个观感问题：节内小标题和真正的节标题曾经同为二级标题，平铺在一起分不出层次。现在小标题按目录树深度自动下沉，评委看到的层级就是目录的层级。

字体的暗渠

格式系统里最阴险的一层，叫主题字体。Word 里主题字体的引用优先级高于显式声明的字体，而默认模板的主题里，中文字形那一栏是空的。结果就是：代码里明明白白写了黑体和宋体，从来没生效过；一落空，Word 回退到自己的默认东亚字体——在没装中文语言包的机器上，全文变成日文的「ＭＳ 明朝」。

修法是三层：显式字体声明补齐、默认文档属性钉死中文、主题里的中文字形填上值。连浏览器预览都查了一遍——预览器有自己的一套伴生样式，会让标题显示成 Word 里根本没有的旧蓝色。预览里看到什么，用户就认为是什么，预览即交付。

合册即交付态

AI 写完的节文件带着修订痕迹——这是设计好的，你要逐条审。但合成的整本必须干净。合册时程序做四件事：接受全部修订（有一次实测六百多个插入标记和六百多个删除标记原样混在整本里，新旧标题成对出现）；把不属于章节骨架的标题从导航里摘出去；目录页和实收章节机械对账，多列的、漏列的点名；最后整本登记为正式产物。

也有程序不碰的地方：表格的插行删行不支持，界面直接告诉你「请在 Word 里改」。能确定做好的程序化，没把握做好的，交给专门的工具——这本身就是一种诚实。

我们自己走过的弯路

最后交代一下：这个产品的正文管线，前两版用的是 Markdown，写作、修订、自查都跑通了。切换成 Word 直出，等于把跑通的链路推翻重来。

不是 Markdown 错了，是它对格式的保证到不了交付级：样式、编号、修订、批注，转换器要么丢要么乱，演示看不出来，打印全出来。承认这一点的那天，我们改了整整一夜的架构。

Word 里这些全是确定性操作，那模型和程序各干什么？下一篇《模型负责思考，程序负责正确》。