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

分享我开辟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、表格数目倾向等。
我如今用的设置布局大概是如许：

1. {
2.   "useAiImages": true,
3.   "maxAiImages": 6,
4.   "useMermaidImages": true,
5.   "tableRequirement": "heavy"
6. }

复制代码

字段也很直白：

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

这里我没有做什么复杂的规则，好比“标题里有流程就肯定画流程图”“标题里有架构就肯定生图”。这种硬编码规则看起来智慧，实际很轻易翻车。
我更倾向于让AI先判定，再由步伐做全局控制。
好比表格如果选择“少量”，就让AI先提名候选末节，然后步伐最多选 20%；选择“适中”，最多选 40%；选择“大量”，则保持比力宽松的战略。
AI生图也一样，AI可以提名许多候选，但终极只会按 maxAiImages 择优实行。
正文编排JSON布局

每个叶子节点都会天生一个编排效果，布局大概如下：

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

复制代码

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

• knowledge.item_ids：要引用哪些知识库素材
  
• table.needed：正文天生时要不要用表格
  
• mermaid.needed：是否得当天生Mermaid图
  
• image.needed：是否得当AI生图
  
• priority：保举分数，3体现有代价，4体现保举，5体现强保举
  

留意，这里的 needed: true 不是说肯定实行，只是说进入候选池。
真正实行时还会过一遍全局选择。
好比全文有80个末节，AI以为20个末节都得当生图，但用户只允许最多6张，那步伐就会把候选末节分段，然后在每一段里选优先级最高的。如许就能制止前面章节把图片额度全部用完。
正文编排提示词

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

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

复制代码

UserPrompt

1. 参考知识库轻量条目：
2. {knowledge_items}
4. 项目概述信息：
5. {project_overview}
7. 上级章节信息：
8. {parent_chapters}
10. 同级章节信息：
11. {sibling_chapters}
13. 当前章节：
14. 章节ID：{chapter_id}
15. 章节标题：{chapter_title}
16. 章节描述：{chapter_description}
18. 请为当前章节返回正文编排 JSON：
20. {
21.   "knowledge": {
22.     "item_ids": ["从参考知识库轻量条目中选择的 id；没有合适条目时返回空数组"]
23.   },
24.   "table": {
25.     "needed": true,
26.     "purpose": "说明表格在本小节中要表达什么；不需要表格时留空"
27.   },
28.   "mermaid": {
29.     "needed": false,
30.     "title": "Mermaid 图标题；不需要时留空",
31.     "code": "合法 Mermaid 代码，不包含 Markdown 代码围栏；不需要时留空",
32.     "priority": 3,
33.     "reason": "为什么适合或不适合 Mermaid 图"
34.   },
35.   "image": {
36.     "needed": false,
37.     "style": "engineering_diagram 或 realistic_photo；不需要配图时留空",
38.     "title": "图片标题；不需要配图时留空",
39.     "prompt": "用于生图模型的中文提示词；不需要配图时留空",
40.     "priority": 3,
41.     "reason": "为什么适合或不适合 AI 生图"
42.   }
43. }

复制代码

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

编排完成后，才开始真正天生正文。
这里的思绪和之前讲超长文本天生一样：不要指望一次哀求天生几十万字，而是按目次叶子节点拆开天生。
每个末节天生时，会带上这些上下文：

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

这里实在是一个很关键的小计划。
预编排效果不但是给步伐看的，也会传给正文天生模子。好比这个末节反面要配一张“体系摆设架构表示图”，那正文天生时AI就会知道：这段正文不是孤立的一段笔墨，反面还会有一张架构图来辅助分析。
如许天生出来的正文会更天然地为图片做铺垫，好比先把体系分层、网络界限、服务关系讲清楚，再由反面的图片承接这些内容。读者看到正文和图片时，会以为它们是一体的，而不是正文写完后硬贴了一张图。
正文天生提示词

SystemPrompt

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

复制代码

UserPrompt

1. 项目概述信息：
2. {project_overview}
4. 参考正文素材：
5. {knowledge_contents}
7. 上级章节信息：
8. {parent_chapters}
10. 同级章节信息（请避免内容重复）：
11. {sibling_chapters}
13. 正文编排决策：
14. 表格：{table_decision}
15. AI 生图：{image_decision}
16. 配图意图：{illustration_decision}
18. 当前章节信息：
19. 章节ID：{chapter_id}
20. 章节标题：{chapter_title}
21. 章节描述：{chapter_description}
23. 请根据项目概述信息和上述章节层级关系，生成详细的专业内容，确保与上级章节的内容逻辑相承，同时避免与同级章节内容重复，突出本章节的独特性和技术方案优势。
25. 直接返回编写的正文内容，不要输出标题、解释、总结等任何其他内容。

复制代码

这里我还加了一个小细节：同级章节信息会传给AI。
同时，正文编排决定里的配图信息也会传给AI。它不须要在正文里直接输出图片，但它会知道反面预备放什么图，于是正文可以围绕这张图的表达重点来写，制止正文和图片“两张皮”。
好比“实行方案”“进度操持”“质量保障”这些章节，很轻易相互串内容。如果不告诉AI同级章节有哪些，它就会把全部好听的话都塞进当前末节，反面末节就开始重复。
以是每个末节天生时，不但知道自己要写什么，也知道旁边的末节在写什么。
这对几十万字标书非常关键。
配图阶段

等全部正文末节天生完后，才进入配图阶段。
这里分两类：

• Mermaid 图
  
• AI 生图
  

Mermaid得当简单流程、层级、职责关系；AI生图得当工程现场、装备、体系架构、摆设拓扑这类更具象的画面。
我没有把它们混在正文天生里，是由于图和笔墨的失败资源不一样。
正文天生失败，这个末节就是真失败；但配图失败，不应该影响正文效果。最多就是提示“这张图没天生乐成，正文已生存”。
AI生图流程

AI生图用的是编排阶段天生好的 image.prompt。
体系会再补一段固定风格要求：

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

复制代码

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

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

复制代码

为什么要加这段？
由于生图模子很轻易天生那种“宣传海报风”“科技蓝大屏风”“到处都是发光线条”的图片，看着很炫，但放在标书里非常违和。
标书里的图，应该像工程资料，不应该像广告图。
Mermaid配图流程

Mermaid更得当流程图、构造布局图、职责关系图这类内容。
编排阶段已经让AI返回了 mermaid code，但这里还不能直接信赖它。
由于Mermaid对语法很敏感，AI经常会写出欣赏器渲染失败的代码，好比中文节点没加引号、毗连语法太随意、节点ID里带了特别字符。
以是配图阶段会先校验Mermaid能不能正常渲染。
如果不能渲染，就再让AI修复，修复提示词大概是如许：
Mermaid修复提示词

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

复制代码

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

1. ```mermaid
2. flowchart TD
3. A["需求确认"] --> B["方案设计"]
4. B --> C["实施部署"]
5. C --> D["验收交付"]
6. ```
8. *图：实施流程图*

复制代码

这里有朋侪大概会问：为什么不直接把Mermaid也转成图片插进正文？
由于在编辑页面里，Mermaid代码块更方便预览和修改，如果AI天生的mermaid内容不太符合，照旧可以自行修改的。
mermaid的实行链路如下：

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

这个链路会比一开始就存图片更机动。
终极生存的编排效果

为制止末节内图片太多，纵然AI判定本末节既可以用mermaid，也可以用AI生图，我们也要用步伐过滤掉，只生存一种图片范例。
终极生存的“实际接纳的配图范例”：

1. {
2.   "1.1.1": {
3.     "plan": {
4.       "knowledge": {
5.         "item_ids": ["knowledge_001"]
6.       },
7.       "table": {
8.         "needed": true,
9.         "purpose": "用于归纳实施步骤和输出成果"
10.       },
11.       "mermaid": {
12.         "needed": true,
13.         "title": "实施流程",
14.         "code": "flowchart TD\nA["需求确认"] --> B["方案设计"]",
15.         "priority": 3,
16.         "reason": "适合表达流程关系"
17.       },
18.       "image": {
19.         "needed": true,
20.         "style": "engineering_diagram",
21.         "title": "系统部署架构",
22.         "prompt": "生成一张专业克制的系统部署架构示意图...",
23.         "priority": 4,
24.         "reason": "适合表达部署关系"
25.       }
26.     },
27.     "illustration_type": "ai",
28.     "updated_at": "2026-05-15T10:00:00.000Z"
29.   }
30. }

复制代码

这里 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 APIKling v3 Omni Image1K $0.028/张约 ¥0.19外洋OpenAI APIGPT Image 21024×1024 Medium $0.053；High $0.211约 ¥0.36 / ¥1.44外洋Google Gemini API / Vertex AIGemini 3 Pro Image1K/2K $0.134；4K $0.24约 ¥0.92 / ¥1.64外洋Google Vertex AIImagen 4 Ultra$0.06/张约 ¥0.41外洋Black Forest Labs / DeepInfra / ReplicateFLUX.2 Max1MP 首张输出 $0.07；后续 MP $0.03/MP约 ¥0.48 起外洋xAI APIGrok Imagine Image Pro1K/2K $0.07/张；编辑输入图另 $0.002/图约 ¥0.48外洋Stability AIStable Image Ultra公开参考 8 credits≈$0.08/张约 ¥0.55外洋Ideogram API / fal / ReplicateIdeogram 3.0 Quality$0.09/张约 ¥0.62外洋Recraft APIRecraft V4.1 Pro Raster / VectorRaster $0.25；Vector $0.30约 ¥1.71 / ¥2.05外洋Runway APIGen-4 Image720p 5 credits=$0.05；1080p 8 credits=$0.08约 ¥0.34 / ¥0.55末了

原来只是想恣意分享一下自己开辟过程中的心得，没想到得到了广泛关注，也有许多朋侪给我提出了不少很好的改进发起，以是决定把项目认真重构。
使用更稳固的electron框架，开箱即用，力图做到做成AI写标书的小龙虾~~

完备代码已开源

GitHub： https://github.com/FB208/OpenBidKit_Yibiao
Gitee： https://gitee.com/yibiao-ai/OpenBidKit_Yibiao
AI写标书 #标书AI #AI标书智能体 #标书小龙虾


免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金.