AI生成标书如何保证超长内容的全文一致性

背景

在利用 AI 生成超长标书（数十万至百万字）时，技术上的难点并非生成内容本身（通过将正文按目录叶子节点拆解、并发请求 AI 即可实现），而是如何保证全文一致性——即各个章节单独看起来没问题，但合在一起却像拼凑而成。典型错误包括：工期数字前后矛盾、售后服务响应时间不一致、人员配置与设备型号重复变化、质保期表述冲突等。这类错误远比文字不够优美更严重，评标专家只需交叉翻阅两章即可质疑方案的整体性。传统思路依赖增大模型上下文窗口或将所有内容塞进单个请求，但《Lost in the Middle》论文已证明关键信息放在长上下文中间时模型表现会显著下降，上下文越长关键事实反而越容易被淹没。此外，正文分章节并发生成时，每个请求只看到当前章节，无法获知其他章节已写的内容，简单在 Prompt 中写“请保证全文一致”基本无效。

核心内容

为系统性地解决超长标书的一致性难题，作者提出了一套基于“事实底稿”的三步工作流，并已开源（OpenBidKit_Yibiao）。

第一步：生成前——建立全局事实变量

在正式生成正文之前，先执行“全局事实设定”步骤。该步骤按模型上下文限制切分招标文件，从中提取后续正文会反复使用且必须保持一致的具体事实（而非招标要求摘要）。例如：

• 项目总工期为 90 个自然日（而非“招标人要求工期不超过 90 天”）
• 故障受理响应时间不超过 2 小时
• 免费质保期为 3 年

程序依次处理：从招标文件分段提取事实 → 用知识库补充更具体且不冲突的技术设定 → 若是已有方案扩写，优先保留原方案中的人员、设备、周期和服务承诺 → 合并重复项，删除空泛要求，形成轻量事实清单。生成后先让用户查看和修改，因为 AI 可以帮助统一口径，但工期、质保等最终能否承诺只有投标人自己知道。

第二步：生成中——每个章节只读取需要的事实

全局事实不能全部塞进每一次正文请求，否则浪费 Token 并产生新干扰（如写“系统架构”时无需读取培训时间）。因此在正文编排阶段，AI 只看到全局事实的标题，并据此判断当前章节需要哪些事实（输出 JSON，包含 writing_focus、facts.titles、knowledge.item_ids、table.needed 等字段）。生成正文时，程序根据标题取出完整事实内容，只注入当前章节。同时 Prompt 中增加两条硬约束：

• 提供了相关全局事实时，必须优先使用，不得前后矛盾；
• 没有提供时，不要主动编造人员、周期、质保、品牌和型号。

正文扩写、单章节重新生成也走同一套逻辑，确保各章节并发生成时仍引用同一份外部事实底稿。

第三步：生成后——全文一致性审计

即使生成前做了约束，AI 仍可能不遵守，且知识库素材、已有方案、手工修改都可能带入旧数据。因此正文完成后增加一轮审计。提供两种方式：

1. 普通修复：按目录顺序将超长正文分组，每组和全局事实一起交给 AI，只检查已明确写出的冲突。AI 返回冲突章节、冲突原文、违反的事实。修复时只返回精确的 old_text → new_text 替换（例如“120天”改为“90天”），程序仅在 old_text 能唯一命中当前小节时才替换，否则拒绝修改并重试。
2. Agent 修复：将全文一致性修复交给项目内嵌的 Agent。Agent 读取两个文件（global-facts.md 和 technical-plan.md），无需一次读完全文，而是搜索关键词、分段读取、建立索引、多轮修改文件。正文每个章节有固定开始/结束标记和章节 ID，Agent 执行后程序重新解析并校验：章节是否被增删改、ID 和标记是否完整、修改是否发生在允许范围内。校验通过则只回写变化的小节，否则保留原正文。

关键要点

• 长上下文的局限性：增大上下文窗口不能解决全文一致性问题。模型在长上下文中间会丢失关键信息，且并发生成导致每个请求缺乏对其他章节的感知。
• 核心思路是事实底稿：在生成前确立一份独立于正文的“全局事实变量”，后续所有章节均引用此底稿，而非依赖模型记忆。
• 三步骤结构的严谨性：生成前 → 设定事实（可人工审核）、生成中 → 按需注入事实（避免信息过载）、生成后 → 审计冲突（精确替换修复）。
• 事实与要求的区分：全局事实是“本方案做出的具体承诺”（如工期90天），而非招标要求（如工期不超过90天）。只有前者才能作为正文统一使用的依据。
• 按需注入减少干扰：每个章节只读取与其直接相关的事实，避免无关事实污染 Prompt 并浪费 Token。
• 硬约束防止胡编：Prompt 中明确要求“有事实时必须用，没有事实时不得编造人员、周期、品牌等”。
• 精确修复而非整章重写：普通修复只返回旧文本到新文本的精确替换，且通过唯一性校验避免误伤；Agent 修复则通过文件搜索和修改工具逐步调整。
• 无法 100% 保证：如果全局事实本身错误，后续正文只会统一错误；自动审计擅长发现数字、型号、人员、质保期限等明确冲突，但对履约可行性、隐含逻辑和法律责任的审查仍需人工复核。
• 开源项目：完整源码和 Prompt 已通过 OpenBidKit_Yibiao 在 LINUX DO 社区开源。

意义与影响

该工作流从根本上改变了 AI 生成超长结构化文档的一致性保障方式——从“依赖模型记忆”转向“建立外部事实底稿+按需注入+事后审计”。其意义体现在多层：

• 对 AI 标书工具开发者：不将全文一致性押在 Prompt 或模型能力上，而是将事实抽象为独立数据、将引用关系编排为按需注入、将一致性检查变为生成后的审计任务。这一范式可推广至其他长文档生成场景（如法律文书、技术手册、项目报告）。
• 对投标实务：显著降低人工交叉检查的工作量——从逐章核对数十万字，缩小为仅复核少量事实清单和冲突小节；同时减少 AI 胡编乱造带来的风险，使 AI 生成的标书更可能通过评标专家的一致性质疑。
• 对长上下文模型的反思：提醒业界不要盲目追求增加上下文窗口，而是优先设计外化知识的管理机制。事实底稿类似于“文档级数据库”，AI 按需查询而非全量记忆，更符合人类写作的分工流程。
• 开源生态贡献：通过开源工具提供了可复现的参考实现，鼓励社区在此基础上改进（如扩展审计规则、支持更多结构化格式、集成其他模型）。