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

最近一直在优化易标投标工具箱的超长标书生成。

把几十万甚至上百万字生成出来，其实不算最难。正文按目录叶子节点拆开，并发请求AI就行了。

真正难的是：**每个章节单独看都没问题，合在一起却不像同一份标书。**

比如：

- 实施方案写工期90天，进度计划变成120天
- 售后方案承诺2小时响应，服务保障又写成4小时
- 项目经理、人员数量、设备型号在不同章节反复变化
- 前面写三年质保，后面突然只剩一年

这种错误比文字不够漂亮严重得多。评标专家只要交叉看两章，就会怀疑整份方案是不是东拼西凑的。



**源码和提示词已经开源：**

GitHub：https://github.com/FB208/OpenBidKit_Yibiao

## 长上下文解决不了全文一致性

很多人的第一反应是：换一个上下文更大的模型，把招标文件和已生成正文全部塞进去。

但上下文能装下，不等于AI能稳定用到。

《Lost in the Middle》论文专门测试过这个问题：关键信息放在长上下文中间时，模型表现会明显下降。上下文越长，关键事实反而越容易被大量无关内容淹没。

而且标书正文是分章节并发生成的。每个请求都只看当前章节，它们并不知道其他章节刚刚写了什么。

所以只在提示词里写一句“请保证全文一致”，基本等于没写。AI既不知道哪些内容必须统一，也不知道发生冲突时应该听谁的。

![超长标书中的事实冲突示例](https://oss.agnet.top/keep/2026/07/14/20260714193121875.png)

## 我的解题思路

我的方案不是让AI记住几十万字，而是给整份标书建立一份独立的“事实底稿”。

简单来说就是三步：

1. 生成前，先确定全文统一使用哪些事实
2. 生成时，只把当前章节需要的事实交给AI
3. 生成后，再检查全文有没有违反这些事实

![超长标书全文一致性工作流](https://oss.agnet.top/keep/2026/07/14/20260714193124730.png)



## 第一步：生成全局事实变量

在生成正文前，我增加了一个“全局事实设定”步骤。

它会先按模型上下文限制切分招标文件，提取后续正文会反复使用、并且必须保持一致的内容，例如：

```markdown
## 项目实施周期
- 项目总工期为90个自然日
- 系统试运行期为30个自然日

## 售后服务承诺
- 故障受理响应时间不超过2小时
- 一般故障在8小时内完成处理
- 免费质保期为3年
```

这里有一个很重要的区别：**全局事实不是招标要求摘要。**

“招标人要求工期不超过90天”只是要求；“本方案项目总工期为90天”才是后续正文可以统一使用的事实。

程序会依次处理：

- 从招标文件中分段提取事实
- 用知识库补充更具体、且不冲突的技术设定
- 如果是已有方案扩写，优先保留原方案中的人员、设备、周期和服务承诺
- 最后合并重复项，删除空泛要求，形成一份轻量事实清单

事实生成后不会马上开始写正文，而是先让用户查看和修改。因为AI可以帮助统一口径，但工期、质保、人员和设备最终能不能承诺，只有投标人自己知道。

![全局事实底稿定向约束不同章节](https://oss.agnet.top/keep/2026/07/14/20260714193116805.png)

## 第二步：每个章节只读取需要的事实

有了全局事实，也不能把它们全部塞进每一次正文请求。

事实太多不仅浪费Token，还会产生新的干扰。写“系统架构”时，根本不需要读取培训时间和售后响应。

所以在正文编排阶段，AI只看到全局事实的标题，然后判断当前章节需要哪些事实：

```json
{
  "writing_focus": "说明项目实施阶段和进度控制措施",
  "facts": {
    "titles": ["项目实施周期", "项目组织配置"]
  },
  "knowledge": {
    "item_ids": ["knowledge_001"]
  },
  "table": {
    "needed": true,
    "purpose": "展示阶段、周期和交付成果"
  }
}
```

等真正生成正文时，程序再根据标题取出完整事实内容，只注入当前章节。

同时我在提示词里增加了两条硬约束：

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

正文扩写、单章节重新生成也走同一套逻辑。这样即使各章节并发生成，它们仍然引用同一份外部事实底稿。

## 第三步：生成完成后，再审计一遍全文

生成前做了约束，也不能默认AI一定遵守。

知识库素材、已有方案、正文扩写和用户手工修改，都可能重新带入旧数据。所以正文全部完成后，我又增加了一轮全文一致性审计。

易标目前提供两种方式。

### 普通修复

普通模式会按目录顺序把超长正文分组，每组和全局事实一起交给AI，只检查已经明确写出的事实冲突。

AI只返回：冲突发生在哪个章节、冲突原文是什么、违反了哪条事实。

修复时也不让AI重写整章，而是返回精确修改：

```json
{
  "old_text": "本项目计划在120个自然日内完成全部建设内容。",
  "new_text": "本项目计划在90个自然日内完成全部建设内容。"
}
```

程序只有在 `old_text` 能够唯一命中当前小节时才会替换。找不到，或者出现多处相同内容，都拒绝修改并重新尝试，避免为了修一个数字误伤整章。

### Agent修复

普通模式已经能处理大多数明确冲突，但几十万字正文反复分组、审计、返回JSON，再逐条修复，工作流还是很复杂。

于是我又上了“邪修”：把全文一致性修复交给项目内嵌的Agent。

程序会准备两个文件：

```text
global-facts.md    全局事实和招标文件关键解析结果
technical-plan.md  当前技术方案完整正文
```

Agent不需要在一次请求里读完并修完全文。它可以搜索关键词、分段读取、建立索引，再多轮修改 `technical-plan.md`。

这相当于把“超长上下文问题”，变成了Agent更擅长的“搜索文件并修改文件”。



正文文件中每个章节都有固定的开始、结束标记和章节ID。Agent完成后，程序会重新解析并校验：

- 章节有没有被新增、删除或重排
- 章节ID和标记是否完整
- 修改是否发生在允许的正文范围内
- 哪些小节真的发生了变化

校验通过后，只回写发生变化的小节；校验失败则保留原正文。

![Agent全文一致性审计与修复流程](https://oss.agnet.top/keep/2026/07/14/20260714193134942.png)

## 能不能100%保证一致？

不能。

如果全局事实本身就是错的，后面的正文只会非常一致地一起写错。

自动审计擅长找工期、人员、数量、型号、质保、响应时间这类明确冲突，但对履约可行性、隐含逻辑和法律责任，还是需要专业人员复核。

所以这套方案真正解决的是：

- 不再让每个章节随机编一套事实
- 把几十万字的人工交叉检查，缩小为少量事实清单和冲突小节复核
- 修改冲突时只动必要位置，不重写已经正确的内容

对用AI写标书来说，重点不是选择一个“永远不会出错”的模型，而是在生成正文前先确认事实底稿。

对开发AI标书工具来说，也不要把全文一致性全部押在Prompt上。**应该把事实做成独立数据，把引用关系做成编排结果，把一致性做成生成后的审计任务。**

长上下文解决的是“能不能输入”，这套工作流解决的才是“几十万字能不能始终说同一套话”。
