DEV Community: 易标AI

标书智能体（六）——超长文本生成和图文控制

易标AI — Fri, 15 May 2026 07:55:20 +0000

分享我开发AI标书智能体遇到的问题及全部解决方案~

在vibe coding时代，越来越觉得代码不重要了。整个标书智能体开发过程中，几乎没有遇到任何代码卡点，唯一稍复杂的是传入文件的解析，在AI的帮助下也轻松解决。

所以，以后的分享内容中不再涉及代码，只分享我遇到的问题及解决问题的思路（提示词、工作流、智能体），让大家能更好的理解AI到底能做哪些事，以及我们如何运用好AI。

需要源码的到GitHub查看：

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

Gitee： https://gitee.com/yibiao-ai/OpenBidKit_Yibiao

先来说问题

之前一期我们已经讲过如何生成几十万甚至上百万字的标书，并保证生成结果的上下文连贯性。

但是github上有朋友善意的提醒我，没有图文附件，不能算标书：

于是我马上安排了mermaid图片生成+火山方舟（doubao-seedream-5.0）+GoogleAIStudio（nano banana pro）三种配图方式。

但是，在100万字的标书中，何时配图？配在哪里？配什么图？值得仔细思考：

首先要知道，我们生成正文是按照目录树叶子节点来生成的，如果给每个叶子节点都配图会面临两个问题
- 成本太高
- 有些章节并不适合配图
完全交给AI判断是否配图
- 依赖目录判断，生成的图片可能和正文没关系
- 依赖正文判断，又要让AI多读一遍生成结果，浪费token
- 生图数量无法控制，导致成本无法预估
控制生图数量
- 设置一个生图上限，AI按顺序生成，可能导致头重脚轻（前面配图很多，到后面没有图片额度了）

预编排阶段，解决正文生成所有问题

为了解决上述问题，我设计了一套预编排流程，在拿到目录后，先对全文目录进行编排，分配每个子节点是否需要生成图片，并给出分数。最后由程序遍历编排结果，选出分数最高的几个节点，标记为需要生图。

这里有一个很重要的点：配图不是正文写完后再临时想起来加，而是在正文生成前就先规划好。

这个小节要不要用知识库素材
这个小节适不适合用表格
这个小节适不适合用 Mermaid 图
这个小节适不适合 AI 生图
如果适合，优先级是多少

这样做的好处非常明显：

不用等正文全部生成完，再让AI重新读一遍几十万字内容
配图数量可以提前控制，成本可预估
图片不会全部集中在前几章，也不会后面章节完全没有图
正文生成时也知道本小节后面可能会配图，能提前和图片内容形成呼应，整体表达更稳

我的实现里，正文生成任务大概分成四步：

收集所有叶子节点
对所有叶子节点做正文编排
根据编排结果并发生成正文
正文生成完成后，再执行配图

正文生成配置

用户在页面上可以先设置正文生成偏好，比如是否启用AI生图、最多生成几张图、是否启用Mermaid、表格数量倾向等。

我现在用的配置结构大概是这样：

{
  "useAiImages": true,
  "maxAiImages": 6,
  "useMermaidImages": true,
  "tableRequirement": "heavy"
}

字段也很直白：

useAiImages：是否启用AI生图
maxAiImages：最多生成几张AI图片
useMermaidImages：是否启用Mermaid图
tableRequirement：表格需求，支持 none、light、moderate、heavy

这里我没有做什么复杂的规则，比如“标题里有流程就一定画流程图”“标题里有架构就一定生图”。这种硬编码规则看起来聪明，实际很容易翻车。

我更倾向于让AI先判断，再由程序做全局控制。

比如表格如果选择“少量”，就让AI先提名候选小节，然后程序最多选 20%；选择“适中”，最多选 40%；选择“大量”，则保持比较宽松的策略。

AI生图也一样，AI可以提名很多候选，但最终只会按 maxAiImages 择优执行。

正文编排JSON结构

每个叶子节点都会生成一个编排结果，结构大概如下：

{
  "knowledge": {
    "item_ids": ["knowledge_001", "knowledge_002"]
  },
  "table": {
    "needed": true,
    "purpose": "用于归纳本小节的实施步骤、责任分工和输出成果"
  },
  "mermaid": {
    "needed": false,
    "title": "实施流程",
    "code": "flowchart TD\nA[\"需求确认\"] --> B[\"方案设计\"] --> C[\"实施部署\"]",
    "priority": 3,
    "reason": "本小节包含清晰的流程关系，适合用流程图表达"
  },
  "image": {
    "needed": true,
    "style": "engineering_diagram",
    "title": "系统部署架构",
    "prompt": "生成一张专业克制的系统部署架构示意图，体现业务系统、应用服务、数据库、运维监控和安全边界之间的关系，画面适合投标技术方案插图",
    "priority": 4,
    "reason": "本小节涉及系统部署关系，适合用工程图示增强表达"
  }
}

这几个字段的作用分别是：

knowledge.item_ids：要引用哪些知识库素材
table.needed：正文生成时要不要用表格
mermaid.needed：是否适合生成Mermaid图
image.needed：是否适合AI生图
priority：推荐分数，3表示有价值，4表示推荐，5表示强推荐

注意，这里的 needed: true 不是说一定执行，只是说进入候选池。

真正执行时还会过一遍全局选择。

比如全文有80个小节，AI认为20个小节都适合生图，但用户只允许最多6张，那程序就会把候选小节分段，然后在每一段里选优先级最高的。这样就能避免前面章节把图片额度全部用完。

正文编排提示词

正文编排阶段，我没有让AI写正文，只让它做判断，所以提示词一定要克制。

SystemPrompt

你是投标技术方案正文编排助手。请根据章节上下文判断本小节最适合的表达方式。

要求：
1. 只返回 JSON，不要输出解释、总结或 Markdown。
2. 由你自行判断是否适合使用表格或配图，判断要克制、合情合理，不要为了形式而硬插。
3. 表格仅在能明显提升表达清晰度时使用，例如归纳职责、步骤、参数、风险、措施、成果等。
4. Mermaid 图只适合简单、抽象、文本节点型关系图，例如少量节点的流程、层级、时间线或职责关系，不用于复杂工程场景或实物示意。
5. AI 生图适合设备、现场、机柜、电池、系统架构、部署拓扑、施工/运维场景、工程空间关系、实物示意等更具象的图。
6. Mermaid 图和 AI 生图都只是候选判断，可以同时为 true；系统会在配图阶段保证同一个章节最终只执行一种配图。
7. image.needed 表示进入 AI 生图候选池，不代表最终一定生成；本次 AI 生图有数量上限，系统后续会全局择优。
8. 不要求用满 AI 生图上限，没有具象对象、空间关系或实物场景时不要硬插。
9. priority 含义：3 表示有价值候选，4 表示推荐，5 表示强推荐；只有达到 3 才将 image.needed 设为 true。
10. engineering_diagram 表示工程图示风，适合系统架构、部署拓扑、设备连接、机柜布置、施工组织或运维场景示意等具象工程图。
11. realistic_photo 表示专业实景示意风，适合设备、场地、机房、施工现场、检测工具、运维操作等真实场景表现。
12. knowledge.item_ids 只能从参考知识库轻量条目的 id 中选择；可以多选，可以为空数组；不要编造 id。

UserPrompt

参考知识库轻量条目：
{knowledge_items}

项目概述信息：
{project_overview}

上级章节信息：
{parent_chapters}

同级章节信息：
{sibling_chapters}

当前章节：
章节ID：{chapter_id}
章节标题：{chapter_title}
章节描述：{chapter_description}

请为当前章节返回正文编排 JSON：

{
  "knowledge": {
    "item_ids": ["从参考知识库轻量条目中选择的 id；没有合适条目时返回空数组"]
  },
  "table": {
    "needed": true,
    "purpose": "说明表格在本小节中要表达什么；不需要表格时留空"
  },
  "mermaid": {
    "needed": false,
    "title": "Mermaid 图标题；不需要时留空",
    "code": "合法 Mermaid 代码，不包含 Markdown 代码围栏；不需要时留空",
    "priority": 3,
    "reason": "为什么适合或不适合 Mermaid 图"
  },
  "image": {
    "needed": false,
    "style": "engineering_diagram 或 realistic_photo；不需要配图时留空",
    "title": "图片标题；不需要配图时留空",
    "prompt": "用于生图模型的中文提示词；不需要配图时留空",
    "priority": 3,
    "reason": "为什么适合或不适合 AI 生图"
  }
}

正文生成阶段，只写正文，不碰图片

编排完成后，才开始真正生成正文。

这里的思路和之前讲超长文本生成一样：不要指望一次请求生成几十万字，而是按目录叶子节点拆开生成。

每个小节生成时，会带上这些上下文：

项目概述
上级章节
同级章节
当前章节标题和描述
编排阶段选中的知识库素材
编排阶段决定的表格需求
编排阶段决定的配图意图，比如图片标题、图片风格、生图提示词
用户重新生成时填写的额外要求

这里其实是一个很关键的小设计。

预编排结果不只是给程序看的，也会传给正文生成模型。比如这个小节后面要配一张“系统部署架构示意图”，那正文生成时AI就会知道：这段正文不是孤立的一段文字，后面还会有一张架构图来辅助说明。

这样生成出来的正文会更自然地为图片做铺垫，比如先把系统分层、网络边界、服务关系讲清楚，再由后面的图片承接这些内容。读者看到正文和图片时，会觉得它们是一体的，而不是正文写完后硬贴了一张图。

正文生成提示词

SystemPrompt

你是一个专业的标书编写专家，负责为投标文件的技术标部分生成具体内容。

要求：
1. 内容要专业、准确，与章节标题和描述保持一致。
2. 这是技术方案，不是宣传报告，注意朴实无华，不要假大空。
3. 语言要正式、规范，符合标书写作要求，但不要使用奇怪的连接词，不要让人觉得内容像是 AI 生成的。
4. 内容要详细具体，避免空泛的描述。
5. 注意避免与同级章节内容重复，保持内容的独特性和互补性。
6. 可以使用 Markdown 段落、列表和表格；表格必须服务于内容表达，不要为了形式硬插。
7. 正文只生成文字、列表、表格等内容，配图由系统另行处理。
8. 严禁输出 Mermaid、PlantUML、Graphviz、flowchart、graph、sequenceDiagram 等图表代码块、mermaid.ink 链接或图片 Markdown；配图由系统另行处理。
9. 表格单元格内如有多项内容，优先使用编号、顿号、分号或短句，不要使用 HTML <br> 标签。
10. 直接返回章节内容，不生成标题，不要任何额外说明。

UserPrompt

项目概述信息：
{project_overview}

参考正文素材：
{knowledge_contents}

上级章节信息：
{parent_chapters}

同级章节信息（请避免内容重复）：
{sibling_chapters}

正文编排决策：
表格：{table_decision}
AI 生图：{image_decision}
配图意图：{illustration_decision}

当前章节信息：
章节ID：{chapter_id}
章节标题：{chapter_title}
章节描述：{chapter_description}

请根据项目概述信息和上述章节层级关系，生成详细的专业内容，确保与上级章节的内容逻辑相承，同时避免与同级章节内容重复，突出本章节的独特性和技术方案优势。

直接返回编写的正文内容，不要输出标题、解释、总结等任何其他内容。

这里我还加了一个小细节：同级章节信息会传给AI。

同时，正文编排决策里的配图信息也会传给AI。它不需要在正文里直接输出图片，但它会知道后面准备放什么图，于是正文可以围绕这张图的表达重点来写，避免正文和图片“两张皮”。

比如“实施方案”“进度计划”“质量保障”这些章节，很容易互相串内容。如果不告诉AI同级章节有哪些，它就会把所有好听的话都塞进当前小节，后面小节就开始重复。

所以每个小节生成时，不只知道自己要写什么，也知道旁边的小节在写什么。

这对几十万字标书非常关键。

配图阶段

等所有正文小节生成完后，才进入配图阶段。

这里分两类：

Mermaid 图
AI 生图

Mermaid适合简单流程、层级、职责关系；AI生图适合工程现场、设备、系统架构、部署拓扑这类更具象的画面。

我没有把它们混在正文生成里，是因为图和文字的失败成本不一样。

正文生成失败，这个小节就是真失败；但配图失败，不应该影响正文结果。最多就是提示“这张图没生成成功，正文已保留”。

AI生图流程

AI生图用的是编排阶段生成好的 image.prompt。

系统会再补一段固定风格要求：

画面采用工程项目图示风格，结构清晰、专业克制、适合投标技术方案插图。
避免出现品牌标识、水印、夸张营销元素和无关文字。

如果是实景风格，则换成：

画面采用专业实景照片风格，真实、克制、适合投标技术方案插图。
避免出现品牌标识、水印、夸张营销元素和无关文字。

为什么要加这段？

因为生图模型很容易生成那种“宣传海报风”“科技蓝大屏风”“到处都是发光线条”的图片，看着很炫，但放在标书里非常违和。

标书里的图，应该像工程资料，不应该像广告图。

Mermaid配图流程

Mermaid更适合流程图、组织结构图、职责关系图这类内容。

编排阶段已经让AI返回了 mermaid code，但这里还不能直接相信它。

因为Mermaid对语法很敏感，AI经常会写出浏览器渲染失败的代码，比如中文节点没加引号、连接语法太随意、节点ID里带了特殊字符。

所以配图阶段会先校验Mermaid能不能正常渲染。

如果不能渲染，就再让AI修复，修复提示词大概是这样：

Mermaid修复提示词

你是 Mermaid 图代码修复助手。请根据渲染错误修复现有 Mermaid 代码。

要求：
1. 只返回 JSON，不要输出解释、总结或 Markdown。
2. 目标是让 Mermaid 在浏览器前端稳定渲染，优先做最小必要修改。
3. 优先使用 flowchart TD；节点 ID 只使用 ASCII 字母、数字和下划线。
4. 中文节点标签必须写成 A["中文标签"]，不要写成 A[中文标签]。
5. 不使用多节点连接简写，必须展开成多条独立连线。
6. 不使用分号；每行只写一个 Mermaid 语句。
7. 不要输出 Markdown 代码围栏。
8. 如果原图结构过于复杂，请简化为可渲染的核心流程图。

修复成功后，再把 Mermaid 代码块追加到正文后面：

```

mermaid
flowchart TD
A["需求确认"] --> B["方案设计"]
B --> C["实施部署"]
C --> D["验收交付"]


```

*图：实施流程图*
```

`

这里有朋友可能会问：为什么不直接把Mermaid也转成图片插进正文？

因为在编辑页面里，Mermaid代码块更方便预览和修改，如果AI生成的mermaid内容不太合适，还是可以自行修改的。

mermaid的执行链路如下：

- 页面预览：前端本地渲染 Mermaid
- 正文存储：保存 Mermaid 代码块
- Word导出：再转成图片插入Word

这个链路会比一开始就存图片更灵活。

## 最终保存的编排结果

为避免小节内图片太多，即使AI判断本小节既可以用mermaid，也可以用AI生图，我们也要用程序过滤掉，只保留一种图片类型。

最终保存的“实际采用的配图类型”：

```json
{
  "1.1.1": {
    "plan": {
      "knowledge": {
        "item_ids": ["knowledge_001"]
      },
      "table": {
        "needed": true,
        "purpose": "用于归纳实施步骤和输出成果"
      },
      "mermaid": {
        "needed": true,
        "title": "实施流程",
        "code": "flowchart TD\nA[\"需求确认\"] --> B[\"方案设计\"]",
        "priority": 3,
        "reason": "适合表达流程关系"
      },
      "image": {
        "needed": true,
        "style": "engineering_diagram",
        "title": "系统部署架构",
        "prompt": "生成一张专业克制的系统部署架构示意图...",
        "priority": 4,
        "reason": "适合表达部署关系"
      }
    },
    "illustration_type": "ai",
    "updated_at": "2026-05-15T10:00:00.000Z"
  }
}
```

这里 `mermaid.needed` 和 `image.needed` 可以同时为 true，但 `illustration_type` 最终只能是一个：

- `ai`：最终采用AI生图
- `mermaid`：最终采用Mermaid图
- `none`：最终不配图

这样做的好处是，AI负责“提名”，程序负责“拍板”。



# 为什么要浪费这么大精力限制图片数量

原因很简单，生图成本太高了。

我其实更倾向于AI只生成文字，然后人工从网上搜几张图插进去就好了。（为什么不自动搜图？我试过，自动搜很容易搜到广告图等，为了准确，还得加AI识图，成本也不低。）

下面方式国内外主流AI生图模型的价格对比，最低的一张也要两毛钱，还不能保证质量：

| 区域 | API / 平台                                | 保留模型                             | 官方 / 公开价格                             | 折合人民币 / 张      |
| ---- | ----------------------------------------- | ------------------------------------ | ------------------------------------------- | -------------------- |
| 国内 | 阿里云百炼                                | **Qwen-Image-2.0-Pro / 2026-04-22**  | 中国内地 ¥0.50/张；国际 ¥0.550443/张        | **¥0.50–0.55**       |
| 国内 | 阿里云百炼                                | **Wan2.7 Image Pro**                 | 中国内地 ¥0.50/张；国际 ¥0.562065/张        | **¥0.50–0.56**       |
| 国内 | 火山方舟 / 豆包                           | **Seedream 5.0 Lite**                | 公开参考 ¥0.22/张                           | **约 ¥0.22**         |
| 国内 | 腾讯云                                    | **混元生图 3.0**                     | ¥0.20/张                                    | **¥0.20**            |
| 国内 | 可灵 / Kling API                          | **Kling v3 Omni Image**              | 1K $0.028/张                                | **约 ¥0.19**         |
| 海外 | OpenAI API                                | **GPT Image 2**                      | 1024×1024 Medium $0.053；High $0.211        | **约 ¥0.36 / ¥1.44** |
| 海外 | Google Gemini API / Vertex AI             | **Gemini 3 Pro Image**               | 1K/2K $0.134；4K $0.24                      | **约 ¥0.92 / ¥1.64** |
| 海外 | Google Vertex AI                          | **Imagen 4 Ultra**                   | $0.06/张                                    | **约 ¥0.41**         |
| 海外 | Black Forest Labs / DeepInfra / Replicate | **FLUX.2 Max**                       | 1MP 首张输出 $0.07；后续 MP $0.03/MP        | **约 ¥0.48 起**      |
| 海外 | xAI API                                   | **Grok Imagine Image Pro**           | 1K/2K $0.07/张；编辑输入图另 $0.002/图      | **约 ¥0.48**         |
| 海外 | Stability AI                              | **Stable Image Ultra**               | 公开参考 8 credits≈$0.08/张                 | **约 ¥0.55**         |
| 海外 | Ideogram API / fal / Replicate            | **Ideogram 3.0 Quality**             | $0.09/张                                    | **约 ¥0.62**         |
| 海外 | Recraft API                               | **Recraft V4.1 Pro Raster / Vector** | Raster $0.25；Vector $0.30                  | **约 ¥1.71 / ¥2.05** |
| 海外 | Runway API                                | **Gen-4 Image**                      | 720p 5 credits=$0.05；1080p 8 credits=$0.08 | **约 ¥0.34 / ¥0.55** |



# 结尾

本来只是想随便分享一下自己开发过程中的心得，没想到获得了广泛关注，也有很多朋友给我提出了不少很好的改进建议，所以决定把项目认真重构。

使用更稳定的electron框架，开箱即用，力争做到做成AI写标书的小龙虾~~

![image-20260515153341542](https://oss.agnet.top/keep/2026/05/15/20260515153343589.png)

# 完整代码已开源

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

Gitee： https://gitee.com/yibiao-ai/OpenBidKit_Yibiao



#AI写标书 #标书AI #AI标书智能体 #标书小龙虾

标书智能体（五）——如何让弱模型也能稳定输出复杂json

易标AI — Wed, 06 May 2026 09:26:51 +0000

用 Python + React 打造一个开源的 AI 写标书智能体~

完整代码已开源。

代码很多，文章只放主要代码和提示词，完整代码可以查看开源项目。

Github: https://github.com/FB208/OpenBidKit_Yibiao

Gitee: https://gitee.com/yibiao-ai/OpenBidKit_Yibiao

今天是第五期，我参考OpenCode的自我反思、矫正机制，优化了标书提纲生成，不再依赖模型自身能力“抽卡”，而是通过自我反思、矫正机制确保任何弱模型都能稳定输出结果。（测试用的LongCat-Flash-Lite）

第二期已经讲过一次“生成标书提纲”，当时的核心思路是：

短标书 + 强模型，可以一次性生成完整 JSON。
长标书 + 普通模型，就拆成一级目录、二三级目录分步生成。
最后再校验 JSON 格式，把多个结果拼成完整目录。

这个方案已经能解决大部分问题。

但后面真拿一些便宜模型、弱模型去跑，就会发现一个更现实的问题：

不是模型不会写目录，而是无法做到稳定，生成目录的质量完全依靠运气。

尤其是标书目录这种三级嵌套结构，模型很容易出现下面这些问题：

JSON 语法错误，少逗号、少括号。
外面套了 markdown 代码块。
返回了一堆解释文字，不是纯 JSON。
字段名写错，比如把 children 写成 child。
只生成了两级目录，没有达到三级。
一级目录和评分项对不上。
分步生成时编号混乱。

在标书智能体里，目录是后续正文生成、缓存、编辑、导出 Word 等一切步骤的基础。目录 JSON 一旦出错，后面所有流程都无法正常进行。

所以这一期重点聊：

如何让弱模型也能稳定输出复杂 JSON。

一、不要只相信提示词

只返回 JSON，不要输出任何其他内容。
必须严格按照以下格式输出。
如果输出错误你会受到惩罚。

这种写法当然有用，但不够。

因为弱模型的问题不是“不知道要输出 JSON”，而是它在复杂任务里很容易失控。

所以我的思路是：

提示词只负责提高第一次成功率，真正的稳定性要靠工作流。

现在项目里的目录生成，已经不是简单的一次模型调用，而是一个完整流程：

先生成目录。
校验 JSON 语法。
校验 Pydantic Schema。
校验业务规则。
失败后尝试修复 JSON。
修复失败后重试。
完整目录失败后切换分步生成。
生成后再让模型审核目录质量。
审核不通过，再带着建议重新生成一次。

也就是说，模型不是“答一次就结束”，而是有批改、有返工、有兜底。

二、先定义标准 JSON 结构

目录结构在后端用 Pydantic 定义。

核心结构如下：

class OutlineItem(BaseModel):
    """目录项"""

    id: str
    title: str
    description: str
    source_requirement_id: Optional[str] = None
    source_requirement_title: Optional[str] = None
    children: Optional[List["OutlineItem"]] = None
    content: Optional[str] = None


class OutlineResponse(BaseModel):
    """目录响应"""

    outline: List[OutlineItem]


class OutlineChildrenResponse(BaseModel):
    """指定一级目录下的子目录响应。"""

    children: List[OutlineItem]


class OutlineReviewResponse(BaseModel):
    """目录审核响应。"""

    passed: bool
    suggestions: List[str] = Field(default_factory=list)

这样做的好处是，模型输出以后，不是简单 json.loads() 一下就算通过，而是要真正符合结构。

完整目录要求是：

{
  "outline": [
    {
      "id": "1",
      "title": "",
      "description": "",
      "children": [
        {
          "id": "1.1",
          "title": "",
          "description": "",
          "children": [
            {
              "id": "1.1.1",
              "title": "",
              "description": ""
            }
          ]
        }
      ]
    }
  ]
}

这里有一个很关键的点：

合法 JSON 不等于可用 JSON。

比如模型返回下面这种内容，它是合法 JSON，但对我们没用：

{
  "outline": [
    {
      "id": "1",
      "title": "项目理解",
      "description": "项目理解"
    }
  ]
}

因为它只有一级目录，不满足标书目录的三级结构要求。

所以还需要业务校验。

@classmethod
def _validate_complete_outline(cls, payload: Dict[str, Any]) -> None:
    """校验完整目录至少达到三级结构。"""
    outline = payload.get("outline") or []
    if not outline:
        raise ValueError("目录不能为空")

    if cls._outline_depth(outline) < 3:
        raise ValueError("完整目录至少需要三级结构")

三、统一封装 JSON 生成函数

项目里所有需要 JSON 输出的地方，都会走同一个函数：

async def collect_json_response(
    self,
    messages: list[dict[str, str]],
    temperature: float = 0.7,
    schema: type[BaseModel] | None = None,
    validator: JsonValidator | None = None,
    progress_callback: ProgressCallback | None = None,
    progress_label: str = "JSON结果",
    failure_message: str = "模型返回的 JSON 数据格式无效",
) -> Dict[str, Any]:
    """收集并校验 JSON 响应。"""

它做了几件事：

请求模型。
优先使用 JSON 模式。
如果当前模型不支持 response_format，自动切换普通请求。
提取模型返回中的 JSON。
用 Pydantic 校验。
执行业务校验。
失败后进入 JSON 修复流程。
连续失败后再抛出错误。

其中 JSON 模式请求是这样的：

content = await self.collect_chat_completion(
    messages,
    temperature=temperature,
    response_format={"type": "json_object"}
    if use_response_format
    else None,
)

但是很多 OpenAI-like 服务并不完全支持 response_format。

所以这里没有把系统稳定性绑定在 JSON 模式上，而是做了兼容处理：

except AppError as exc:
    if (
        not use_response_format
        or not self._is_response_format_unsupported_error(exc.message)
    ):
        raise

    await self.emit_progress(
        progress_callback,
        "当前模型不支持结构化 JSON 响应，已降级为普通请求解析。",
    )
    content = await self.collect_chat_completion(
        messages,
        temperature=temperature,
        response_format=None,
    )
    return content, False

这里虽然是“降级”，但不是功能降级，而是兼容不同模型接口。

四、失败后不是重新问，而是定向修复

如果模型返回的 JSON 校验失败，系统不会立刻重来。

因为很多时候，模型已经生成了大部分正确内容，只是某个字段错了，或者外面多了一层代码块。

这时候推倒重来很浪费，而且新结果也未必更好。

所以我加了一个 JSON 修复助手。

提示词如下：

system_prompt = """你是一个严格的 JSON 修复助手。请根据给出的原始内容和校验问题，修复现有结果。

要求：
1. 优先在原结果基础上做最小必要修改，不要整体重写
2. 尽量保留原有结构、字段值、节点顺序和已生成内容
3. 若缺少必填字段，应结合现有上下文补齐合理内容，不要用空字符串敷衍
4. 若存在多余说明、代码块包裹、字段名错误、children 结构不规范或顶层包裹错误，应修正为合法 JSON
5. 只返回修复后的完整 JSON，不要输出任何解释
"""

修复时会把三部分信息传给模型：

目标结果类型，比如“完整目录”“一级目录”“章节子目录”。
当前校验问题，比如 JSON 语法错误、字段缺失、三级目录不足。
模型刚才返回的原始内容。

代码如下：

repair_messages = build_json_repair_messages(
    invalid_content=invalid_content,
    issues=issues,
    target_description=progress_label,
)

这一步其实就是一个非常实用的“自我修复”。

不是简单告诉模型“你错了，再来一次”。

而是告诉它：

你刚才输出了什么。
哪里错了。
现在要在原结果基础上修。
不要重新发挥。

这对弱模型特别有效。

因为弱模型生成复杂 JSON 可能不稳定，但让它修一个已经接近正确的 JSON，成功率会高很多。

五、校验问题要明确告诉模型

修复能不能成功，很大程度取决于错误信息是否具体。

所以代码里会把 JSON 解析错误和 Pydantic 校验错误都格式化成可读问题。

@staticmethod
def _format_json_issues(error: Exception) -> list[str]:
    """格式化 JSON 解析或校验问题。"""
    if isinstance(error, json.JSONDecodeError):
        return [
            f"JSON 语法错误：第 {error.lineno} 行第 {error.colno} 列附近 {error.msg}。"
        ]

    if isinstance(error, ValidationError):
        issues: list[str] = []
        for item in error.errors():
            location = ".".join(str(part) for part in item.get("loc", [])) or "root"
            message = item.get("msg", "字段校验失败")
            issues.append(f"{location}: {message}")
        return issues or [str(error)]

    return [str(error)]

比如模型少了 description 字段，修复助手拿到的就不是一句“格式不对”，而是类似：

outline.0.children.1.description: Field required

模型知道具体哪里错，修复成功率自然更高。

六、完整目录失败，切换分步生成

即使有 JSON 修复，也不能保证一次性生成完整三级目录永远成功。

尤其是弱模型，输出长 JSON 时很容易中途断掉。

所以目录生成还有一个兜底策略：

完整生成失败，就切换为分步生成。

核心代码如下：

try:
    outline = await self._generate_outline_full(
        overview=overview,
        requirements=requirements,
        uploaded_expand=uploaded_expand,
        old_outline=old_outline,
        suggestions=suggestions,
        progress_callback=progress_callback,
    )
    return outline, "full"
except AppError as exc:
    if exc.message != "模型返回的目录数据格式无效":
        raise
    await self.ai.emit_progress(
        progress_callback,
        "一次性生成完整目录失败，切换为分步生成模式。",
    )
    outline = await self._generate_outline_fallback(
        overview=overview,
        requirements=requirements,
        uploaded_expand=uploaded_expand,
        old_outline=old_outline,
        suggestions=suggestions,
        progress_callback=progress_callback,
    )
    return outline, "fallback"

分步生成的逻辑是：

先生成一级目录。
遍历每个一级目录。
单独生成这个一级目录下面的二三级目录。
把多个结果组装起来。
程序统一重新编号。
最后再做完整目录校验。

top_level_outline = await self._generate_top_level_outline(...)

top_level_items = top_level_outline.get("outline", [])
assembled_items: list[dict[str, Any]] = []

for index, item in enumerate(top_level_items, start=1):
    children_response = await self._generate_outline_children(
        overview=overview,
        requirements=requirements,
        parent_item=item,
        uploaded_expand=uploaded_expand,
        old_outline=old_outline,
        suggestions=suggestions,
        progress_callback=progress_callback,
    )

    children = children_response.get("children") or []
    if children:
        merged_item["children"] = children

    assembled_items.append(merged_item)

outline = self._renumber_outline({"outline": assembled_items})

弱模型一次生成不了一个大 JSON，那就让它每次只生成一小段 JSON。

最后由程序负责组装。

这里还有一个细节：编号不要完全相信模型。

经过大量测试，即使在提示词中告诉了模型，你生成的是第二章的目录，但返回的编号仍然是从1开始的，甚至有可能乱编号。

所以最终会用程序统一编号：

@classmethod
def _renumber_items(
    cls,
    items: list[dict[str, Any]],
    parent_prefix: str = "",
) -> list[dict[str, Any]]:
    """递归重排目录项编号。"""
    normalized_items: list[dict[str, Any]] = []
    for index, item in enumerate(items, start=1):
        item_id = f"{parent_prefix}.{index}" if parent_prefix else str(index)
        normalized_item = {**item, "id": item_id}
        children = item.get("children") or []
        if children:
            normalized_item["children"] = cls._renumber_items(children, item_id)
        else:
            normalized_item.pop("children", None)
        normalized_items.append(normalized_item)

    return normalized_items

能用代码保证的事情，就不要交给模型保证。

七、让模型审核自己生成的目录

上面解决的是 JSON 稳定性。

但目录生成还有另一个问题：

JSON 格式正确，不代表目录质量正确。

比如它可能漏掉了某个评分项，或者一级目录没有和技术评分要求对应起来。

所以生成完成后，还会进入审核流程。

审核提示词如下：

system_prompt = """你是一个严格的招标文件目录审核专家。请审核目录是否符合项目概述和技术评分要求。

要求：
1. 重点检查目录是否完整覆盖技术评分要点
2. 检查一级目录名称是否专业、准确，是否尽量与评分项原文保持一致
3. 检查目录层级是否清晰，是否达到三级目录要求，是否存在明显遗漏、错位、重复或不合理章节
4. 只返回 JSON，格式为：{"passed": true, "suggestions": []}
5. 若不通过，suggestions 中必须给出具体、可执行的修改建议
6. 除了 JSON 外，不要输出任何其他内容
"""

审核结果结构很简单：

{
  "passed": false,
  "suggestions": [
    "补充系统安全保障相关章节",
    "一级目录需要更贴近技术评分项名称"
  ]
}

目录生成主流程如下：

first_outline, generation_mode = await self._generate_outline_by_mode(...)

first_review = await self._review_outline(
    overview=overview,
    requirements=requirements,
    outline=first_outline,
    progress_callback=progress_callback,
    stage_label="首次审核",
)

if first_review["passed"]:
    return first_outline

suggestions = first_review.get("suggestions") or [
    "请根据项目概述和技术评分要求补全目录覆盖范围，并修正不合理章节。"
]

second_outline, _ = await self._generate_outline_by_mode(
    overview=overview,
    requirements=requirements,
    uploaded_expand=uploaded_expand,
    old_outline=old_outline,
    mode=generation_mode,
    progress_callback=progress_callback,
    suggestions=suggestions,
)

如果审核不通过，就把审核建议回灌给生成 Prompt，再重新生成。

八、一一对应模式：把一级目录交给程序锁死

后来我又加了一个“一一对应模式”。

原因是很多招标文件的技术评分要求非常明确，技术标目录最好和评分大类一一对应。

如果把一级目录完全交给模型，它可能会合并、改写、漏掉某些评分大类。

所以一一对应模式的思路是：

先从技术评分要求中提取评分大类。
程序根据评分大类直接构造一级目录。
一级目录标题、顺序、关联评分项都锁死。
模型只负责生成每个一级目录下的二三级目录。
最后再校验一级目录和评分大类是否完全一致。

提取评分大类的提示词：

system_prompt = """你是一个专业的招标文件分析专家。请从技术评分要求中提取适合作为技术标一级目录的评分大类。

要求：
1. 只提取技术评分大类，不要提取商务、报价、资质、售后服务等非技术类条目
2. 每个大类都必须适合作为技术标一级目录标题，标题要专业、简洁、完整
3. 同一大类下的细项、子项、分值说明、评分标准要归入 detail_points，不要拆成多个一级目录
4. requirement_id 必须唯一，使用 R1、R2、R3 这种格式
5. description 需要概括该大类关注的核心内容
6. detail_points 中保留该大类下的关键评分细项，使用简洁短句
7. 只返回 JSON，格式必须为 {"groups": [...]}，不要输出任何其他内容
"""

程序构造一级目录：

@staticmethod
def _build_top_level_outline_from_groups(
    groups: list[dict[str, Any]],
) -> list[dict[str, Any]]:
    """根据技术评分大类直接构造一级目录。"""
    outline: list[dict[str, Any]] = []
    for index, group in enumerate(groups, start=1):
        title = str(group.get("title") or "").strip()
        outline.append(
            {
                "id": str(index),
                "title": title,
                "description": str(group.get("description") or title).strip(),
                "source_requirement_id": str(
                    group.get("requirement_id") or f"R{index}"
                ).strip(),
                "source_requirement_title": title,
            }
        )
    return outline

校验一级目录映射：

if len(outline_items) != len(groups):
    raise ValueError("一级目录数量必须与技术评分大类数量一致")

for index, (item, group) in enumerate(zip(outline_items, groups), start=1):
    expected_title = str(group.get("title") or "").strip()
    actual_title = str(item.get("title") or "").strip()
    if actual_title != expected_title:
        raise ValueError(
            f"第 {index} 个一级目录标题必须严格等于技术评分大类标题：{expected_title}"
        )

这个模式的核心思想是：

不要让模型决定所有事情。

能由程序确定的结构，就用程序确定。

模型只负责它擅长的部分。

九、总结

本次升级的核心，不是强化提示词和工作流，而是引入自我反思的过程，让AI生成的结果从“抽卡”模式正式转变为“返回稳定结果”的模式。经测试

以前是：

用户输入 -> 模型生成 -> 返回结果

现在是：

用户输入
-> 模型生成
-> JSON 解析
-> Schema 校验
-> 业务校验
-> JSON 修复
-> 多轮重试
-> 分步生成
-> 目录审核
-> 建议回灌
-> 二次生成
-> 返回结果

所以让弱模型稳定输出复杂 JSON，我觉得关键不是一个神奇 Prompt，而是下面几条工程原则：

提示词要明确，但不能只靠提示词。
所有 JSON 输出必须走统一解析和校验。
校验不只看语法，还要看业务规则。
失败后优先修复已有结果，不要直接推倒重来。
修复时要把具体错误原因告诉模型。
大 JSON 生成失败，就拆成多个小 JSON。
编号、映射关系这类确定性逻辑，尽量交给程序。
生成后要审核，审核建议要能回流到下一轮生成。
长流程要通过 SSE 告诉用户系统正在做什么。

一句话总结：

弱模型不是不能用，而是不能裸用。

只要给它加上校验、修复、重试、分步生成和自我审核，一样可以稳定完成复杂 JSON 输出。

完整代码已开源

Github: https://github.com/FB208/OpenBidKit_Yibiao

Gitee: https://gitee.com/yibiao-ai/OpenBidKit_Yibiao

标书智能体（四）——提示词顺序优化，让缓存命中，输入成本直降10倍

易标AI — Fri, 03 Apr 2026 07:29:17 +0000

用 Python + React 打造一个开源的 AI 写标书智能体~

完整代码已开源。

代码很多，文章只放主要代码和提示词，完整代码可以查看开源项目。

Github： https://github.com/FB208/yibiao-simple

Gitee： https://gitee.com/yibiao-ai/yibiao-simple

今天是第四期，聊一个做 AI 应用大家都特别关心，但容易走错方向的问题：

成本和提示词顺序的关系

提示词的组织顺序如果写对了，除了结果质量，连成本都能一起降下来。

前面三期，我们已经把标书智能体的主流程基本打通了：

解析招标文件，提取项目概述和技术评分要求。
根据解析结果生成技术标提纲。
根据提纲逐章生成正文。

做到这一步，其实系统已经可以用了。

但真用起来就会发现，标书这个场景和普通聊天不一样，最大的成本不一定在输出，而在输入。

一份招标文件动辄几万字，项目概述和评分要求也不短。正文生成时，同一份项目概述、同一套章节层级信息，还会被反复传给模型。

而节约成本最好的办法，不是精简提示词，而是调整提示词的顺序！

如果提示词结构写得不对，服务商的缓存能力就很难吃到，钱就白白花出去了。

一、为什么吃不到缓存

很多大模型服务商都支持 Prompt Cache，或者有类似的缓存机制。

但缓存不是你以为的那种“只要内容一样就行”。

大多数情况下，它看的是请求前缀。

也就是说，前面那一大段内容是不是稳定，是不是一致，是不是每次都放在同样的位置。

如果你把一份很长的正文，放在提示词后面，而前面先拼了很多每次都不一样的说明，那这份长文本虽然看起来是一样的，服务商也未必把它识别成同一个可复用前缀。

拿文档解析这个功能举例。

我们对同一份招标文件，会做两次分析：

提取项目概述
提取技术评分要求

最开始我的写法是这样的：

def build_analysis_messages(file_content: str, analysis_type: str) -> List[Dict[str, str]]:
    if analysis_type == 'overview':
        system_prompt = '提取项目概述的 system prompt'
        analysis_type_cn = '项目概述'
    else:
        system_prompt = '提取技术评分要求的 system prompt'
        analysis_type_cn = '技术评分要求'

    user_prompt = (
        f'请分析以下招标文件内容，提取{analysis_type_cn}信息：\n\n{file_content}'
    )

    return [
        {'role': 'system', 'content': system_prompt},
        {'role': 'user', 'content': user_prompt},
    ]

问题出在哪？

不是 file_content 不一样，恰恰相反，file_content 是一样的。

问题在于：

两次请求的 system_prompt 不一样
两次请求的 user_prompt 前缀也不一样
真正占 token 的大文本 file_content 被放到了后面

这样一来，服务商看到的不是“同一个长前缀”，而是“两个不一样的请求，后面有一大段内容刚好相同”。

那缓存命中率自然就高不起来。

二、解决方案

这个问题想通以后，改法其实很简单。

原则就一句话：

把大且稳定的上下文放前面，把这次请求的任务差异放最后。

改造后的文档解析提示词变成了这样：

def build_analysis_messages(file_content: str, analysis_type: str) -> List[Dict[str, str]]:
    system_prompt = """你是一名专业的招标文件分析助手。请严格基于用户提供的招标文件原文完成分析任务。

通用要求：
1. 保持提取信息的全面性和准确性，尽量使用原文内容，不要自行编造
2. 只输出最终分析结果，不要输出额外说明、过程、提示语或客套话
3. 如果文档内容不足以支持某项结论，应明确说明原文未提及，不要凭空补充
"""

    file_prompt = f"""以下是完整招标文件全文，请先完整阅读，并仅基于原文完成后续任务：

{file_content}"""

    if analysis_type == 'overview':
        task_prompt = '任务：提取并总结项目概述信息。...'
    else:
        task_prompt = '任务：提取技术评分要求。...'

    return [
        {'role': 'system', 'content': system_prompt},
        {'role': 'user', 'content': file_prompt},
        {'role': 'user', 'content': task_prompt},
    ]

这样改完以后，这两个请求的共同前缀就很清晰了：

第一条 system 一样
第二条全文 user 一样
只有最后一条任务说明不一样

这个结构，就比原来那种“先写不同任务，再塞同一份全文”的方式，更容易命中缓存。

三、提纲编写部分优化

第二期讲提纲生成的时候，重点主要放在 JSON 格式和目录质量上。

但从成本角度看，提纲生成也有一样的问题。

同一个项目里，用户经常会多点几次“重新生成目录”。

那同一份 overview 和 requirements 就会被反复发给模型。

旧写法通常是把它们拼成一个大 user_prompt：

user_prompt = f"""请基于以下项目信息生成标书目录结构：

项目概述：
{overview}

技术评分要求：
{requirements}

请生成完整的技术标目录结构，确保覆盖所有技术评分要点。"""

这当然没错，但对于缓存来说，不够细。

我们现在改成了多消息结构：

def generate_outline_prompt(overview: str, requirements: str) -> List[Dict[str, str]]:
    return [
        {'role': 'system', 'content': _build_outline_system_prompt()},
        {'role': 'user', 'content': f'项目概述：\n{overview}'},
        {'role': 'user', 'content': f'技术评分要求：\n{requirements}'},
        {
            'role': 'user',
            'content': '请生成完整的技术标目录结构，确保覆盖所有技术评分要点。',
        },
    ]

如果是结合用户旧目录一起生成，也照样拆开：

def generate_outline_with_old_prompt(
    overview: str,
    requirements: str,
    old_outline: str | None,
) -> List[Dict[str, str]]:
    return [
        {'role': 'system', 'content': _build_outline_system_prompt()},
        {'role': 'user', 'content': f'项目概述：\n{overview}'},
        {'role': 'user', 'content': f'技术评分要求：\n{requirements}'},
        {'role': 'user', 'content': f'用户自己编写的目录：\n{old_outline or ""}'},
        {
            'role': 'user',
            'content': '请在满足技术评分要求的前提下，充分结合用户自己编写的目录，生成完整的技术标目录结构。',
        },
    ]

这么写的好处很直接：

项目概述和评分要求变成了稳定的共享上下文
普通目录生成和旧目录扩写，也能共享前面一部分前缀

四、消耗最大的正文编写，必须优化

第三期讲正文生成时，我们已经解决了两个最核心的问题：

标书太长，不能一次性生成，必须拆成叶子章节逐节写
分节写容易重复，所以要把上级章节和同级章节信息一起传给模型

这个思路本身没有问题。

但从缓存的角度再回头看，会发现正文生成这一段才是真正的大头。

因为正文生成是整个系统里调用次数最多的功能。

一个项目几十个叶子章节很正常。每个章节都要发一次请求，那下面这些内容就会被反复传很多遍：

同一份 project_overview
相同的 parent_chapters
高度重叠的 sibling_chapters
一模一样的正文写作规则

旧写法是把这些内容全拼进一个大 user_prompt：

user_prompt = f"""请为以下标书章节生成具体内容：

{context_info}

当前章节信息：
章节ID: {chapter_id}
章节标题: {chapter_title}
章节描述: {chapter_description}

请根据项目概述信息和上述章节层级关系，生成详细的专业内容..."""

现在改成了分层消息：

def build_chapter_content_messages(
    chapter: Dict[str, Any],
    parent_chapters: List[Dict[str, Any]] | None = None,
    sibling_chapters: List[Dict[str, Any]] | None = None,
    project_overview: str = '',
) -> List[Dict[str, str]]:
    messages = [
        {'role': 'system', 'content': system_prompt},
    ]

    if project_overview.strip():
        messages.append(
            {'role': 'user', 'content': f'项目概述信息：\n{project_overview}'}
        )

    if parent_chapters:
        messages.append({'role': 'user', 'content': parent_context})

    if sibling_chapters:
        messages.append({'role': 'user', 'content': sibling_context})

    messages.append(
        {
            'role': 'user',
            'content': f'''请为以下标书章节生成具体内容：

当前章节信息：
章节ID: {chapter_id}
章节标题: {chapter_title}
章节描述: {chapter_description}

请根据项目概述信息和上述章节层级关系，生成详细的专业内容...''',
        }
    )

    return messages

这一步的价值特别大。

因为同一个父章节下面的多个叶子节点，往往都有下面这些共同点：

project_overview 一样
parent_chapters 一样
sibling_chapters 高度接近
真正变化最大的，其实只是最后那条当前章节任务

也就是说，正文生成这一块，不仅请求多，而且重复上下文还特别长。

这也是为什么正文生成最值得做缓存优化。

五、总结

这次改完以后，我觉得最重要的不是某一段具体提示词，而是下面这套规则。

以后只要是高频 AI 任务，都可以优先按这个思路来组织提示词：

1. `system` 只放稳定规则

不要把这次请求特有的差异塞进 system。

system 更适合放：

通用角色
通用写作规范
通用输出要求

2. 最大、最稳定的上下文尽量前置

比如：

招标文件全文
项目概述
技术评分要求
目录树
上级章节链

这些内容越稳定、越长、越可能重复利用，就越应该尽量往前放。

3. 任务差异尽量放最后

比如：

提取项目概述
提取技术评分要求
生成目录
生成 3.2.1 章节正文

这些都是每次请求最容易变化的内容，应该尽量放到最后。

4. 同一份数据的组织格式要保持稳定

缓存看的是前缀，不只是“意思差不多”。

所以这些细节都要保持一致：

标题写法一致
换行数量一致
列表顺序一致
不要一会儿 strip() 一会儿不 strip()
不要把随机信息、时间戳塞进共享上下文

这些看起来都是小事，但对缓存命中影响非常直接。

六、实测结果

我用OpenRouter上的gemini-2.5-flash模型做了一次标书解析的测试，从几万字的招标文件中解析项目概述和技术评分要求，很明显可以看出第一轮请求是正常的，第二轮请求的输入提示词，基本都吃到了缓存，成本直降90%以上。

测试环境如下：

服务商：OpenRouter
模型：google/gemini-2.5-flash
请求地址：https://openrouter.ai/api/v1/chat/completions
测试方式：招标文件解析

第一次请求日志里的关键字段是：

request_id: c405ec7f755549629e8a47c04d5b2633
prompt_tokens：19349
cached_tokens: 0
upstream_inference_prompt_cost: 0.0058047

第一次请求相当于把缓存写进去，所以 cached_tokens 为 0，输入提示词费用按正常价格计算。

第二次请求日志里的关键字段变成了：

request_id: b4cfd26bdef74b9c941263a96b692cea
prompt_tokens：19737
cached_tokens: 19442
upstream_inference_prompt_cost: 0.00067176

这个结果就很说明问题了：

第二次请求已经成功命中了缓存
命中的缓存 token 数达到了 19442
输入提示词费用从 0.0058047 降到了 0.00067176

也就是说，同样是一份很长的招标文件上下文，第二次请求的输入成本已经降到了第一次的大约九分之一，基本就是接近 10 倍的差距。

这一点特别重要。因为它说明了，缓存优化不是玄学，也不是“可能会省一点”。

只要下面几个条件满足：

前缀稳定
大文本够长
第二次请求跟得足够快
模型和服务商本身支持缓存

那它省下来的钱，是可以直接从日志里看到的。

完整代码已开源

Github： https://github.com/FB208/yibiao-simple

Gitee： https://gitee.com/yibiao-ai/yibiao-simple

标书智能体（三）——生成标书正文代码+提示词

易标AI — Fri, 03 Apr 2026 07:28:34 +0000

用Python+React打造一个开源的AI写标书智能体~

完整代码已开源

代码很多，文章只放主要代码和提示词，完整代码可以查看开源项目

Github： https://github.com/yibiaoai/yibiao-simple

Gitee： https://gitee.com/yibiao-ai/yibiao-simple

今天是第三期，根据生成好的提纲，填充标书内容。

正文生成，并不像上一节讲的提纲生成那么复杂，核心难点只有两个：

标书需求字数太多： 一份标书动辄几万几十万字，直接让AI生成必然行不通。有了上一节生成提纲的经验，我们已经知道答案了，那就是把正文也打碎，让AI按照提纲的叶子节点，逐节生成正文。
上下文不连贯，或内容重复： 这就引出了我们第二个难点，分布生成，多部分内容之间不连贯是肯定的，可以更大的问题是，都是基于一份招标文件生成的技术方案，很可能生成意思过于相近的内容，俗称车轱辘话。下面，咱们就来逐项分析一下，如何解决上述难点。

一、获取生成内容所需信息

从前端拆分提纲，提纲的每一个叶子节点都发起一个生成请求，需要传递以下参数

class ChapterContentRequest(BaseModel):
    """单章节内容生成请求"""
    chapter: Dict[str, Any] = Field(..., description="章节信息")
    parent_chapters: Optional[List[Dict[str, Any]]] = Field(None, description="上级章节列表")
    sibling_chapters: Optional[List[Dict[str, Any]]] = Field(None, description="同级章节列表")
    project_overview: str = Field("", description="项目概述")

chapter： 本章节信息，不多说，这是必须的

{
  "id": "3.2.2",
  "title": "技术实力",
  "description": "技术研发能力和创新情况"
}

parent_chapters： 上级章节列表，为了保持连贯性
sibling_chapters： 同级章节列表，为了生成内容不重复
project_overview： 项目概述，这是核心，让AI知道自己要写的标书的核心需求

二、核心提示词

SystemPrompt

你是一个专业的标书编写专家，负责为投标文件的技术标部分生成具体内容。

要求：
1. 内容要专业、准确，与章节标题和描述保持一致
2. 这是技术方案，不是宣传报告，注意朴实无华，不要假大空
3. 语言要正式、规范，符合标书写作要求，但不要使用奇怪的连接词，不要让人觉得内容像是AI生成的
4. 内容要详细具体，避免空泛的描述
5. 注意避免与同级章节内容重复，保持内容的独特性和互补性
6. 直接返回章节内容，不生成标题，不要任何额外说明或格式标记

UserPrompt
这个就需要拼接一下了

项目概述信息：
{project_overview}

请为以下标书章节生成具体内容：

{context_info if context_info else ''}

当前章节信息：
章节ID: {chapter_id}
章节标题: {chapter_title}
章节描述: {chapter_description}

请根据项目概述信息和上述章节层级关系，生成详细的专业内容，确保与上级章节的内容逻辑相承，同时避免与同级章节内容重复，突出本章节的独特性和技术方案的优势。

context_info是拼接的上级、统计节点信息

# 构建上下文信息
context_info = ""

# 上级章节信息
if parent_chapters:
    context_info += "上级章节信息：\n"
    for parent in parent_chapters:
        context_info += f"- {parent['id']} {parent['title']}\n  {parent['description']}\n"

# 同级章节信息（排除当前章节）
if sibling_chapters:
    context_info += "同级章节信息（请避免内容重复）：\n"
    for sibling in sibling_chapters:
        if sibling.get('id') != chapter_id:  # 排除当前章节
            context_info += f"- {sibling.get('id', 'unknown')} {sibling.get('title', '未命名')}\n  {sibling.get('description', '')}\n"

拼接后的完整user_prompt示例

请为以下标书章节生成具体内容：
上级章节信息：

1 投标文件技术要求响应程度对项目技术要求的响应和符合情况

1.1 技术规格响应详细描述投标产品技术参数与招标技术要求的符合性

同级章节信息（请避免内容重复）：

1.1.2 技术文件完整性提供的技术文件是否齐全、规范当前章节信息：章节ID: 1.1.1 章节标题: 灯具规格符合性章节描述: 逐项说明各灯具规格与招标文件要求的匹配情况

请根据项目概述信息和上述章节层级关系，生成详细的专业内容，确保与上级章节的内容逻辑相承，同时避免与同级章节内容重复，突出本章节的独特性和技术方案的优势。

就这么简单，生成正文不需要过多的逻辑推理，用最普通的大模型即可实现稳定输出，也几乎不存在生成失败的问题~

完整代码已开源

Github： https://github.com/yibiaoai/yibiao-simple

Gitee： https://gitee.com/yibiao-ai/yibiao-simple

标书智能体（二）——生成标书提纲代码+提示词

易标AI — Fri, 03 Apr 2026 07:28:13 +0000

用Python+React打造一个开源的AI写标书智能体~

完整代码已开源

代码很多，文章只放主要代码和提示词，完整代码可以查看开源项目

Github： https://github.com/yibiaoai/yibiao-simple

Gitee： https://gitee.com/yibiao-ai/yibiao-simple

今天是第二期，根据解析好的项目概述和技术评分需求，生成投标文件提纲：

一份好的标书，提纲是关键，而生成好的提纲，则有以下几个难点：

格式化输出：为了生成正文时，AI能够很好的理解提纲，保证结构不错乱，那么提纲必须是格式化的
超出AI输出长度：几十万字的标书，提纲也不会短，现在AI虽然都号称几十万的上下文，但实际输出也就2千字左右，无法直接完整的长提纲
提纲可编辑：虽然AI能生成比较不错的提纲，但还是没法100%满足要求，所以提纲必须是可编辑的，而且编辑后还不能破坏原有的结构

下面，咱们就来逐项分析一下，如何解决上述难点。

一、短标书+能力较强的AI模型

当生成的标书长度要求不高，比如三五万字。且AI能输出的token数比较长，如最新的 glm-4.5 和 doubao-seed-1-6，大约可以直接输出8000字左右，那么就可以使用下面这种简单的结构。

JSON结构

{
  "outline": [
    {
      "id": "1",
      "title": "",
      "description": "",
      "children": [
        {
          "id": "1.1",
          "title": "",
          "description": "",
          "children":[
              {
                "id": "1.1.1",
                "title": "",
                "description": ""
              }
          ]
        }
      ]
    }
  ]
}

提示词

SystemPrompt

你是一个专业的标书编写专家。根据提供的项目概述和技术评分要求，生成投标文件中技术标部分的目录结构。

要求：
1. 目录结构要全面覆盖技术标的所有必要章节
2. 章节名称要专业、准确，符合投标文件规范
3. 一级目录名称要与技术评分要求中的章节名称一致，如果技术评分要求中没有章节名称，则结合技术评分要求中的内容，生成一级目录名称
4. 一共包括三级目录
5. 返回标准JSON格式，包含章节编号、标题、描述和子章节
6. 除了JSON结果外，不要输出任何其他内容

JSON格式要求：
{
  "outline": [
    {
      "id": "1",
      "title": "",
      "description": "",
      "children": [
        {
          "id": "1.1",
          "title": "",
          "description": "",
          "children":[
              {
                "id": "1.1.1",
                "title": "",
                "description": ""
              }
          ]
        }
      ]
    }
  ]
}

UserPrompt

请基于以下项目信息生成标书目录结构：

项目概述：
{overview}

技术评分要求：
{requirements}

请生成完整的技术标目录结构，确保覆盖所有技术评分要点。

二、长标书+普通AI模型

要想使用如 glm-4-air 这样低价的普通模型，也能生成几十万字标书需要的长提纲，那实现起来就复杂多了。

限制

上下文短，仅能输出1500字左右
输出结果不稳定，尤其是json这类结构化数据，可能出现格式错误

思路

先生成一级目录（要与技术评分要求一一对应）
遍历一级目录，逐个生成二、三级目录（多个AI任务并发生成，要保证每个任务生成的目录和其他任务的不重复）
校验生成的json格式是否标准
最后拼成完整的目录

这种生成工作流，理论上可以生成无限长度的提纲。

生成一级标题

SystemPrompt

### 角色
你是专业的标书编写专家，擅长根据项目需求编写标书。

### 人物
1. 根据得到的项目概述(overview)和评分要求(requirements)，撰写技术标部分的一级提纲

### 说明
2. 只设计一级标题，数量要和"评分要求"一一对应
3. 一级标题名称要进行简单修改，不能完全使用"评分要求"中的文字

### Output Format in JSON
{
    "rating_item":"原评分项",
    "new_title":"根据评分项修改的标题"
}

UserPrompt

### 项目信息

<overview>
{overview}
</overview>

<requirements>
{requirements}
</requirements>


直接返回json，不要任何额外说明或格式标记

生成二级标题

为了生成结果稳定，我们不让AI来处理json框架，而是提前用代码拼接好json框架，仅让AI在json框架中填写内容

拼接json框架
我这里额外加了一个nodes_distribution，是为了让二三级目录数量不一样，随机了两个重点章节，这样更符合实际情况，这个不重要，感兴趣可以直接查看源码。
下面的代码是拼接json框架的：

def generate_one_outline_json_by_level1(level1_title: str, level1_index: int, nodes_distribution: Dict) -> Dict:
    # 获取当前一级节点下的二级节点数量和叶子节点分配
    level2_count = nodes_distribution['level2_nodes'][level1_index - 1]
    leaf_distribution = nodes_distribution['leaf_per_level2'][level1_index - 1]

    # 创建一级节点
    level1_node = {
        "id":f"{level1_index}",
        "title": level1_title,
        "description": "",
        "children": []
    }

    # 创建二级节点
    for j in range(level2_count):
        level2_node = {
            "id":f"{level1_index}.{j+1}",
            "title": "",  # 二级标题留空
            "description": "",
            "children": []
        }

        # 创建三级节点（叶子节点）
        leaf_count = leaf_distribution[j]
        for k in range(leaf_count):
            level2_node["children"].append({
                "id":f"{level1_index}.{j+1}.{k+1}",
                "title": "",  # 三级标题留空
                "description": ""
            })

        level1_node["children"].append(level2_node)

    return level1_node

拼接其他章节的标题，需要传给AI参考，以免生成重复的章节内容

other_outline = "\n".join([f"{j+1}. {node['new_title']}" 
                    for j, node in enumerate(level_l1) 
                    if j!= i])

SystemPrompt
json_outline是前面生成的json框架

### 角色
你是专业的标书编写专家，擅长根据项目需求编写标书。

### 任务
1. 根据得到项目概述(overview)、评分要求(requirements)补全标书的提纲的二三级目录

### 说明
2. 你将会得到一段json，这是提纲的其中一个章节，你需要再原结构上补全标题(title)和描述(description)
3. 二级标题根据一级标题撰写,三级标题根据二级标题撰写
4. 补全的内容要参考项目概述(overview)、评分要求(requirements)等项目信息
5. 你还会收到其他章节的标题(other_outline)，你需要确保本章节的内容不会包含其他章节的内容

### 注意事项
在原json上补全信息，禁止修改json结构，禁止修改一级标题

### Output Format in JSON
{json_outline}

UserPrompt

### 项目信息

<overview>
{overview}
</overview>

<requirements>
{requirements}
</requirements>

<other_outline>
{other_outline}
</other_outline>


直接返回json，不要任何额外说明或格式标记

校验生成json结果是否和传入框架一致

import json
def check_json(json_str: str, schema: str | dict) -> tuple[bool, str]:
    """
    根据模板 JSON 校验目标字符串的格式是否符合要求

    Args:
        json_str: 要校验的 JSON 字符串
        schema: 模板 JSON 字符串或字典对象，用于定义预期的数据结构

    Returns:
        tuple[bool, str]: (是否验证通过, 错误信息)
        如果验证通过返回 (True, "")，否则返回 (False, 错误原因)
    """
    try:
        # 解析输入的 JSON 字符串
        try:
            data = json.loads(json_str)
        except json.JSONDecodeError as e:
            return False, f"JSON 解析错误: {str(e)}"

        # 处理 schema 参数
        try:
            if isinstance(schema, str):
                schema = json.loads(schema)
            elif not isinstance(schema, dict):
                return False, "schema 必须是 JSON 字符串或字典对象"
        except json.JSONDecodeError as e:
            return False, f"schema 解析错误: {str(e)}"

        def check_structure(target, template, path=""):
            # 处理数字类型（int 和 float 可以互换）
            if isinstance(template, (int, float)) and isinstance(target, (int, float)):
                return True, ""

            # 检查基本数据类型
            if type(template) != type(target) and not (isinstance(template, (int, float)) and isinstance(target, (int, float))):
                return False, f"路径 '{path}' 的类型不匹配: 期望 {type(template).__name__}, 实际 {type(target).__name__}"

            # 如果是列表类型
            if isinstance(template, list):
                if not template:  # 如果模板列表为空，则允许任何列表
                    return True, ""
                if not target:  # 如果目标列表为空，但模板不为空
                    return False, f"路径 '{path}' 的列表为空，但期望有内容"

                # 检查列表中的每个元素是否符合模板中第一个元素的格式
                template_item = template[0]
                for i, item in enumerate(target):
                    is_valid, error = check_structure(item, template_item, f"{path}[{i}]")
                    if not is_valid:
                        return False, error
                return True, ""

            # 如果是字典类型
            elif isinstance(template, dict):
                # 检查所有必需的键是否存在，并且值的类型是否正确
                for key in template:
                    if key not in target:
                        return False, f"路径 '{path}' 缺少必需的键 '{key}'"
                    is_valid, error = check_structure(target[key], template[key], f"{path}.{key}")
                    if not is_valid:
                        return False, error
                return True, ""

            # 对于其他基本类型，返回 True
            return True, ""

        is_valid, error = check_structure(data, schema)
        return is_valid, error if not is_valid else ""

    except Exception as e:
        return False, f"未预期的错误: {str(e)}"

在执行过程中，设置3次重试，如果校验没通过，再重新执行一次，以保证成功率

完整代码已开源

Github： https://github.com/yibiaoai/yibiao-simple

Gitee： https://gitee.com/yibiao-ai/yibiao-simple

标书智能体（一）——AI解析招标文件代码+提示词

易标AI — Fri, 05 Dec 2025 06:47:18 +0000

用Python+React打造一个开源的AI写标书智能体~

今天是第一期，招标文件解析：

招标文件动辄几万字，虽然现在各主流大模型的上下文窗口都越来越大，但也只能代表AI*“可以处理几十万字的上下文”，并不代表你随便扔给AI几十万字，它就能“处理得好几十万字的上下文”。*

我们在写投标文件之前，一定要先把招标文件通读一遍，标注出需要注意的点，然后再有针对性的撰写招标文件。

AI写标书也是一样，第一步要做的就是招标文件解析。

一、Word、PDF文件内容提取

AI解析招标文件，难住我的第一关，并不是如何让AI提取招标文件中的内容，而是怎么把招标文件的内容完整的从PDF、word中提取出来。

word文件提取，选用的是docx2python

content = None
try:
    # 使用docx2python提取，它能更好地处理表格和结构
    content = docx2python(file_path)
    extracted_text = []
    # 处理文档内容
    if hasattr(content, 'document'):
        for section in content.document:
            for element in section:
                if isinstance(element, list):
                    # 这可能是表格
                    extracted_text.append("\n[表格内容]")
                    for row in element:
                        if isinstance(row, list):
                            row_text = " | ".join([str(cell).strip() for cell in row if cell])
                            if row_text:
                                extracted_text.append(row_text)
                        else:
                            extracted_text.append(str(row))
                    extracted_text.append("[表格结束]\n")
                else:
                    # 普通文本
                    text = str(element).strip()
                    if text:
                        extracted_text.append(text)
    result = "\n".join(extracted_text).strip()
    # 确保释放资源
    if content:
        del content
    gc.collect()
    return result
except Exception as e:
    # 确保释放资源
    if content:
        del content
    gc.collect()

pdf文件提取，则使用pdfplumber

pdf = None
try:
    extracted_text = []
    pdf = pdfplumber.open(file_path)
    for page_num, page in enumerate(pdf.pages, 1):
        # 添加页码标识
        extracted_text.append(f"\n--- 第 {page_num} 页 ---\n")
        # 提取普通文本
        text = page.extract_text()
        if text:
            extracted_text.append(text)
        # 提取表格
        tables = page.extract_tables()
        for table_num, table in enumerate(tables, 1):
            extracted_text.append(f"\n[表格 {table_num}]")
            for row in table:
                if row:  # 跳过空行
                    # 过滤空值并连接单元格
                    row_text = " | ".join([str(cell) if cell else "" for cell in row])
                    extracted_text.append(row_text)
            extracted_text.append("[表格结束]\n")

    result = "\n".join(extracted_text).strip()
    # 确保关闭PDF文件
    if pdf:
        pdf.close()
    gc.collect() 
    return result
except Exception as e:
    # 确保关闭PDF文件
    if pdf:
        pdf.close()
    gc.collect()

二、封装AI流式请求通用函数

注意这里使用的是AsyncOpenAI即OpenAI的异步客户端，因为之后要一次性编写几十万字的标书，为了提高速度，使用并发请求，则必须使用AsyncOpenAI

def __init__(self, api_key: str, base_url: str = None, model_name: str = "gpt-3.5-turbo"):
    """初始化OpenAI服务"""
    self.api_key = api_key
    self.base_url = base_url
    self.model_name = model_name

    # 初始化OpenAI客户端 - 使用异步客户端
    self.client = openai.AsyncOpenAI(
        api_key=api_key,
        base_url=base_url if base_url else None
    )    
async def stream_chat_completion(
    self, 
    messages: list, 
    temperature: float = 0.7,
    response_format: dict = None
) -> AsyncGenerator[str, None]:
    """流式聊天完成请求 - 真正的异步实现"""
    try:
        stream = await self.client.chat.completions.create(
            model=self.model_name,
            messages=messages,
            temperature=temperature,
            stream=True,
            **({"response_format": response_format} if response_format is not None else {})
        )

        async for chunk in stream:
            if chunk.choices[0].delta.content is not None:
                yield chunk.choices[0].delta.content

    except Exception as e:
        yield f"错误: {str(e)}"

三、招标文件解析提示词

项目概述

SystemPrompt

你是一个专业的标书撰写专家。请分析用户发来的招标文件，提取并总结项目概述信息。

请重点关注以下方面：
1. 项目名称和基本信息
2. 项目背景和目的
3. 项目规模和预算
4. 项目时间安排
5. 项目要实施的具体内容
6. 主要技术特点
7. 其他关键要求

工作要求：
1. 保持提取信息的全面性和准确性，尽量使用原文内容，不要自己编写
2. 只关注与项目实施有关的内容，不提取商务信息
3. 直接返回整理好的项目概述，除此之外不返回任何其他内容

UserPrompt

请分析以下招标文件内容，提取项目概述信息：
{request.file_content}

技术评分要求

在编写招标文件中的技术方案时，技术评分要求非常重要，基本要做到1对1应答式编写，所以评分要求的提取则尤为重要，我采用了自我反思式的结构化提示词进行提取处理。

SystemPrompt

你是一名专业的招标文件分析师，擅长从复杂的招标文档中高效提取“技术评分项”相关内容。请严格按照以下步骤和规则执行任务：
### 1. 目标定位
- 重点识别文档中与“技术评分”、“评标方法”、“评分标准”、“技术参数”、“技术要求”、“技术方案”、“技术部分”或“评审要素”相关的章节（如“第X章 评标方法”或“附件X：技术评分表”）。
- 忽略商务、价格、资质等非技术类评分项。
### 2. 提取内容要求
对每一项技术评分项，按以下结构化格式输出（若信息缺失，标注“未提及”），如果评分项不够明确，你需要根据上下文分析并也整理成如下格式：
【评分项名称】：<原文描述，保留专业术语>
【权重/分值】：<具体分值或占比，如“30分”或“40%”>
【评分标准】：<详细规则，如“≥95%得满分，每低1%扣0.5分”>
【数据来源】：<文档中的位置，如“第5.2.3条”或“附件3-表2”>

### 3. 处理规则
- **模糊表述**：有些招标文件格式不是很标准，没有明确的“技术评分表”，但一定都会有“技术评分”相关内容，请根据上下文判断评分项。
- **表格处理**：若评分项以表格形式呈现，按行提取，并标注“[表格数据]”。
- **分层结构**：若存在二级评分项（如“技术方案→子项1、子项2”），用缩进或编号体现层级关系。
- **单位统一**：将所有分值统一为“分”或“%”，并注明原文单位（如原文为“20点”则标注“[原文：20点]”）。

### 4. 输出示例
【评分项名称】：系统可用性 
【权重/分值】：25分 
【评分标准】：年平均故障时间≤1小时得满分；每增加1小时扣2分，最高扣10分。 
【数据来源】：附件4-技术评分细则（第3页） 

【评分项名称】：响应时间
【权重/分分】：15分 [原文：15%]
【评分标准】：≤50ms得满分；每增加10ms扣1分。
【数据来源】：第6.1.2条

### 5. 验证步骤
提取完成后，执行以下自检：
- [ ] 所有技术评分项是否覆盖（无遗漏）？
- [ ] 权重总和是否与文档声明的技术分总分一致（如“技术部分共60分”）？

直接返回提取结果，除此之外不输出任何其他内容

UserPrompt

请分析以下招标文件内容，提取技术评分要求信息：
{request.file_content}

完整代码已开源

Github：https://github.com/yibiaoai/yibiao-simple

Gitee：https://gitee.com/yibiao-ai/yibiao-simple

DEV Community: 易标AI

标书智能体（六）——超长文本生成和图文控制

先来说问题

预编排阶段，解决正文生成所有问题

正文生成配置

正文编排JSON结构

正文编排提示词

正文生成阶段，只写正文，不碰图片

正文生成提示词

配图阶段

AI生图流程

Mermaid配图流程

标书智能体（五）——如何让弱模型也能稳定输出复杂json

一、不要只相信提示词

二、先定义标准 JSON 结构

三、统一封装 JSON 生成函数

四、失败后不是重新问，而是定向修复

五、校验问题要明确告诉模型

六、完整目录失败，切换分步生成

七、让模型审核自己生成的目录

八、一一对应模式：把一级目录交给程序锁死

九、总结

完整代码已开源

标书智能体（四）——提示词顺序优化，让缓存命中，输入成本直降10倍

一、为什么吃不到缓存

二、解决方案

三、提纲编写部分优化

四、消耗最大的正文编写，必须优化

五、总结

1. system 只放稳定规则

2. 最大、最稳定的上下文尽量前置

3. 任务差异尽量放最后

4. 同一份数据的组织格式要保持稳定

六、实测结果

完整代码已开源

标书智能体（三）——生成标书正文代码+提示词

一、获取生成内容所需信息

二、核心提示词

完整代码已开源

标书智能体（二）——生成标书提纲代码+提示词

一、短标书+能力较强的AI模型

JSON结构

提示词

二、长标书+普通AI模型

生成一级标题

生成二级标题

校验生成json结果是否和传入框架一致

完整代码已开源

标书智能体（一）——AI解析招标文件代码+提示词

一、Word、PDF文件内容提取

二、封装AI流式请求通用函数

三、招标文件解析提示词

项目概述

SystemPrompt

UserPrompt

技术评分要求

SystemPrompt

UserPrompt

完整代码已开源

1. `system` 只放稳定规则