目录：一本标书
最复杂的部分

如果只看成品，目录就是一串章节标题。所以常有人问：这不就是列个提纲吗，至于单独写一篇吗？

至于。列提纲用的是一路信息，编标书的目录用的是四路，而且这四路经常互相打架。

四路输入

第一路，招标文件给的结构要求。有些招标文件会给出建议的章节框架。注意，它通常只是通用性质的建议，是起点，不是答案。照抄它，你这个项目特有的东西就被抄没了。

第二路，业务和技术需求。这个项目真正要解决什么问题，方案要覆盖哪些场景。需求复杂的地方，一节可能要拆成三节；需求简单的地方，几节可以合成一节。目录的长短由它决定，不由「显得丰满」决定。

第三路，必要章节。有些招标文件明确要求：须提供某某证明、须包含某某方案。这些是硬性包含项，漏一个就是风险。

第四路，评分标准。分值分布告诉你往哪儿使劲。评分项最好能在目录里被显性看见——评标专家按结构找内容，找一个评分点翻了三页没翻到，这分丢得冤。

四路怎么合在一起

顺序有讲究：

1. 先拿结构要求搭骨架，记住它只是骨架；
2. 按业务和技术需求扩展、拆分，这是目录长出自己样子的一步；
3. 补必要章节，查漏，硬性的东西一个不能少；
4. 按评分标准修订，该突出的突出，该重排的重排。

四路并不总是一致。招标文件给的建议目录，未必装得下评分要求；评分表想重点呈现的能力，原始目录里可能没有位置；一条技术要求，常常要拆进两个章节才算回应完整。所以搭目录是个来回权衡的过程，不是一次填空。

目录说明：给每一节配一张施工卡

目录定了，还有一层工作：给每一节写说明。行业里叫「目录说明」，我们产品里叫「写作指引」。每节一行，五个字段：节名，怎么写（照格式件填、拿素材改、还是从头写），依据哪条要求，用哪些素材，还缺什么。

它有两个用处。往下游看，它是写正文的依据；往上游看，它是目录的检查表，每一节为什么存在，看说明就知道。

最容易低估的一点：目录说明很少一次写好。目录完全定稿之后，经常要回头重写，尤其是那些从招标文件的格式要求里直接复制来的节点。投标函、授权书、开标一览表，这类节点原本只是「一张表」，从来没有内容规划，说明必须重写才说得通。

我们在这里栽过一个跟头。说明里的「缺口」一列，本来是写给写手看的执行指令，结果工具指令、行号、缺料提醒混在一行里，用户完全看不懂。根子在于一个字段服务两个读者。后来把它拆开：要你提供什么、要你确认什么、资料里已经找到什么、AI 准备怎么做，各归各的。这个跟头反过来证明，「目录说明有两个读者」不是理论，是真会出事的地方。

目录在产品里长什么样

• 目录是产物，不是聊天记录里的一段话。每个节点能追溯到来源：这一节因为哪条要求、哪个评分项存在。血缘断了就报，不静默通过。
• 目录是可编辑的。树形编辑，改一处编号实时变：拖一下，1.1.2 当场变成 1.1.3。编号由程序按树序生成，用「第X章」还是「一、（一）」还是「1.1」，任务级可选。
• 目录是可对账的。目录叶子和已写章节定期核对：缺哪几节、目录是不是比正文新，机器报事实，裁决留给人。
• 目录形态和交付形态要对得上。评标索引表、分项报价表这类节点，交付形态就是一张表，硬写出「正文」来装样子，反而会被校验挑出来。表格、清单、填表类节点，交付就该是模板或附件填充。

目录为什么必须由人来确认

四路输入摆齐了，漏项扫出来了，血缘理清了，该 AI 干的都干了，为什么最后还要停下来等人确认？

因为剩下那一步是判断。结构要求只是通用建议，意味着必须结合这个项目做取舍；评分权重怎么映射成章节，没有标准答案。这一步做对了，后面所有的写作都有骨架；做错了，写得再顺，也是在错误的骨架上越走越远。

所以产品在这里停下来。这是少数几个「必须停」的地方之一。

我们推翻过的两个方案

第一个是我们自己的。最早的工具就是「生成目录」的立场：给模型一个任务，让它吐一份目录。后来整套删掉重做——它跳过了上面说的权衡，产出的目录看起来像模像样，但没有一个节点能回答「你为什么存在」。

第二个是从别人那里学来、又被我们拦下的：为了兑现「字数无上限」，拿总字数除以每章字数，倒推出必须长出多少个节。一个本来五百字能说清的承诺章节，就这么被撑成三千字的注水章。验收约束不能反过来当结构生成器。

目录说完了。下一篇讲一个更沉重的话题：为什么我们把「不废标」排在得分和文采前面——《最贵的错误是废标》。