尧图网站建设 
简介这是一份面向售前、商务与技术团队的 Dify 工作流示例资源聚焦企业级软件项目投标场景把「写标书」拆解为需求输入、分模块章节生成、风险校验与 Markdown 输出四个可控步骤帮助团队快速产出第一版标书草案并在商务、技术、法务联动前完成风险点预审与漏项筛查。资源包共 6 个文件以 yml 工作流定义、Python 校验脚本与 Markdown 测试用例为主另含少量缓存文件压缩包约 15KB可直接导入 Dify 使用。其中 DSL 文件承载完整工作流逻辑校验脚本与自动化测试用于检查 DSL 规范人工测试用例则覆盖典型输入输出场景便于读者理解节点编排与提示词设计思路。目前已有 156 人学习下载适合希望用 AI 提效标书撰写、或研究 Dify 工作流搭建的初中级用户参考借鉴。1. 标书智能生成助手把 Dify 工作流变成能落地的投标文档产线投标季最折磨人的不是写方案是同一套公司资质、业绩、技术参数要在几十份标书里反复粘贴格式还各不相同。这套「标书智能生成助手」就是冲着这个场景去的——它基于 Dify 工作流搭建把招标文件解析、要点抽取、章节生成、格式校验串成一条自动化链路输入一份招标文件输出一份结构完整的标书初稿。适合经常投标的售前、商务、技术方案岗也适合想拿 Dify 练手 AI 工作流的开发者。它解决的不是「AI 帮你写作文」而是「把重复的文档组装工作交给流程」人只做审核和补关键数据。下面按「这是什么 → 怎么搭 → 坑在哪 → 怎么用得更狠」拆开讲。2. 拆解标书生成链路Dify 工作流里每个节点到底干什么Dify 的工作流本质是一张有向图节点之间靠变量传递数据。标书生成这条链路核心是把「非结构化的招标文件」一步步变成「结构化的标书章节」。常见做法是拆成五段文档摄入、要点抽取、知识库检索、章节生成、格式组装。每一段对应 Dify 里的一类节点理解节点职责比背配置更重要。2.1 文档摄入把 PDF/DOCX 招标文件变成可检索文本招标文件基本是 PDF 或 DOCXDify 的文档提取节点能直接吃这两种格式但前提是文件已经上传到知识库或通过文件变量传入。我一般会在工作流开头放一个「文件上传」变量类型选 File然后在文档提取节点里引用它。# Dify 工作流起始节点变量定义在编排界面配置非代码 variables: - name: tender_file type: file label: 招标文件 required: true accept: .pdf,.docx,.doc逻辑说明tender_file是整条链路的入口变量后续所有节点都从它派生。参数上accept限制格式能减少用户传错文件的概率如果招标文件是扫描件文档提取节点拿不到文字需要先走 OCR这一步 Dify 社区版默认不带得在外部处理好再上传。提取出来的文本通常很长直接塞给大模型会超上下文。常见做法是接一个「文本分割」节点按 500800 字符切块重叠 50 字符保证条款不被切断。分割后的块再进知识库或直接进 LLM 节点。2.2 要点抽取用 LLM 节点把招标要求转成结构化字段招标文件里真正要抓的是项目名称、投标截止时间、资质要求、技术参数、评分办法、需提交的材料清单。这些字段散落在几十页里人工找容易漏。用一个 LLM 节点做抽取提示词里明确要求输出 JSON。# LLM 节点提示词模板在 Dify 提示词框里填写 你是一名投标专员。从下面的招标文件片段中抽取以下字段输出严格 JSON不要解释 { project_name: 项目名称, deadline: 投标截止时间, qualification: [资质要求列表], tech_params: [技术参数列表], scoring: [评分办法要点], materials: [需提交材料清单] } 若某字段在片段中不存在填 null。文件片段 {{#context#}}逻辑说明{{#context#}}是 Dify 的上下文变量占位符指向前一个节点传入的文本。参数上温度建议设 0.10.3越低越稳定模型选长上下文版本因为招标片段可能一次传几千字。输出 JSON 后后面用「代码节点」或「参数提取节点」解析成独立变量供后续章节生成引用。这里有个选型理由为什么不用知识库检索代替 LLM 抽取因为招标文件每份都不一样检索只能找到相似段落抽不出精确字段。LLM 抽取虽然慢一点但字段准确率在结构化提示词下能到可用水平。2.3 知识库检索把公司资质和过往业绩挂进生成链路标书里大量内容是公司自己的营业执照、资质证书、类似业绩、人员配置。这些不该让大模型编应该从知识库里检索。Dify 的知识库节点支持在生成前先检索相关片段把结果作为上下文传给 LLM。# 知识库文档准备把公司资质整理成 markdown 再上传 # 每份资质一个文件文件名即标题便于检索命中 company_qualification.md past_projects_2023.md personnel_certificates.md逻辑说明知识库检索节点要设「召回数量」和「相似度阈值」。召回数量一般 35 条太多会挤占上下文相似度阈值 0.5 起步低于这个值的片段基本不相关。参数上如果发现检索结果总是跑偏先检查文档分块是否太大——资质类文档按条款切别整篇塞进去。2.4 章节生成按标书目录逐段生成而不是一次性输出一次性让模型写完整本标书结果一定是前面详细后面敷衍。正确做法是按章节拆成多个 LLM 节点每个节点只负责一节比如「技术方案」「项目实施计划」「售后服务」。每节的提示词里带上抽取的要点和检索到的公司资料。# 技术方案章节生成提示词 根据以下招标要求和公司资料撰写「技术方案」章节约 800 字分点论述语言正式。 招标技术参数{{tech_params}} 公司类似业绩{{retrieved_projects}} 要求逐条响应技术参数每条先复述要求再给方案。逻辑说明tech_params来自 2.2 的抽取结果retrieved_projects来自 2.3 的检索结果。参数上每个章节节点单独设 max_tokens避免某一节吃掉全部额度。章节之间用「变量聚合」节点汇总最后统一输出。2.5 格式组装把生成文本拼成可提交的文档结构Dify 本身不生成 DOCX但可以输出 Markdown再用外部脚本转 Word。常见做法是工作流最后输出一个 Markdown 字符串变量名final_doc然后本地用 pandoc 或 python-docx 转换。# 本地把 Dify 输出的 markdown 转 docx import subprocess markdown_content {{final_doc}} # 实际使用时从 API 响应取 with open(bid_draft.md, w, encodingutf-8) as f: f.write(markdown_content) subprocess.run([pandoc, bid_draft.md, -o, bid_draft.docx])逻辑说明这段脚本不在 Dify 里跑是拿到工作流输出后的后处理。参数上pandoc 默认样式够用如果要套公司模板加--reference-doctemplate.docx。注意 Markdown 里的表格语法要规范否则转出来会乱。3. 从零搭一条能跑的工作流Dify 编排实操与参数设置上一章讲的是链路逻辑这一章落到具体操作。假设你已经有一个能访问的 Dify 环境本地 Docker 或社区版都行从新建工作流到跑通第一份标书按下面步骤走。3.1 新建工作流与变量定义进入 Dify 工作室选「工作流」不要选「聊天助手」——标书生成是批处理任务不需要多轮对话。新建后第一件事是定义起始变量。变量名类型必填说明tender_fileFile是招标文件 PDF/DOCXcompany_nameText是投标公司名称bid_sectionsText否指定生成章节逗号分隔逻辑说明bid_sections留空时默认生成全部章节填了则只生成指定章节方便快速出初稿。参数上File 类型变量在 Dify 里要确认文件大小限制默认单文件 15MB超了要在环境变量里调。3.2 文档提取与文本分割节点配置拖入「文档提取器」节点输入选tender_file输出变量命名raw_text。后面接「文本分割」节点。# 文本分割节点参数 splitter: recursive chunk_size: 600 chunk_overlap: 60 separator: \n\n逻辑说明recursive分割器会按分隔符逐级切优先在段落处断开。chunk_size600 是经验值太小丢上下文太大检索不准。chunk_overlap60 保证跨块句子不被切断。如果招标文件表格多分割后表格会散建议先在外部把表格转成文字描述再上传。3.3 LLM 抽取节点的提示词与模型参数拖入 LLM 节点模型选你环境里可用的长上下文模型。提示词用 2.2 的模板。关键参数温度0.2最大 token2000输出格式JSON如果模型支持 response_format逻辑说明温度 0.2 是为了字段稳定标书抽取不需要创造性。最大 token 2000 够放抽取结果超了说明提示词让模型话太多要加「不要解释」。如果模型不支持 JSON 模式就在提示词里强调「只输出 JSON」再用代码节点做容错解析。# 代码节点容错解析 LLM 输出的 JSON import json def main(llm_output: str) - dict: text llm_output.strip() # 去掉可能的 markdown 代码块标记 if text.startswith(): text text.split(\n, 1)[1].rsplit(, 1)[0] try: return json.loads(text) except json.JSONDecodeError: return {error: parse_failed, raw: text}逻辑说明这段代码处理模型偶尔加 markdown 标记的情况。参数上返回 dict 后 Dify 会自动拆成多个变量后续节点按字段名引用。如果解析失败error字段会暴露问题方便排查。3.4 知识库检索节点与召回参数拖入「知识库检索」节点选择你提前建好的公司资质知识库。查询内容用抽取出的tech_params拼接project_name。# 知识库检索节点参数 query: {{project_name}} {{tech_params}} top_k: 4 score_threshold: 0.5逻辑说明top_k4 是平衡召回率和上下文长度的值。score_threshold0.5 过滤掉弱相关片段。如果发现检索不到业绩检查知识库文档里是否用了招标文件里的同义词——比如招标写「智慧园区」你文档写「智能园区」检索会漏需要在文档里补同义词。3.5 章节生成节点与变量聚合每个章节一个 LLM 节点输入引用抽取字段和检索结果。全部章节节点后面接「变量聚合器」把各节输出拼成一个final_doc。# 变量聚合器配置 groups: - name: final_doc variables: - tech_section - implementation_section - service_section separator: \n\n逻辑说明聚合器按顺序拼接separator用两个换行保证章节间有空行。参数上如果某节生成失败返回空聚合结果会缺一块所以每个章节节点要设重试次数 23 次。4. 避坑与排查标书工作流跑不通时先看这几处这条链路我搭过几版翻车基本集中在下面几个地方。每条按现象、原因、解决写照着排查能省不少时间。4.1 文档提取返回空文本现象工作流跑完raw_text是空字符串后面全挂。 原因招标文件是扫描件或图片型 PDFDify 文档提取器只认文字层。 解决先在外部做 OCR把结果存成 DOCX 再上传。常见做法是用系统自带 OCR 或开源工具转一遍确认能选中文字再进 Dify。4.2 LLM 抽取字段时好时坏现象同一份文件有时抽出完整 JSON有时缺字段或格式错乱。 原因提示词不够硬模型自由发挥或者文本块太大关键信息被截断。 解决提示词里加「若字段不存在填 null不要编造」把 chunk_size 降到 400 再试温度压到 0.1。如果还飘换模型。4.3 知识库检索结果不相关现象生成的章节里引用了完全不相关的业绩。 原因知识库文档分块太大一个块里混了多个主题或者相似度阈值太低。 解决把资质文档按条款重新切分每块只讲一件事阈值提到 0.6查询语句里加上项目类型关键词。4.4 章节生成内容重复或前后矛盾现象技术方案和实施计划里出现同样的段落。 原因各章节节点独立生成没有共享已生成内容模型不知道前面写过什么。 解决在后续章节的提示词里加入前面章节的摘要或者用「对话历史」变量传递已生成内容。简单做法是每个章节提示词末尾加一句「不要重复以下已生成内容{{previous_sections}}」。4.5 输出 Markdown 转 Word 后格式乱现象pandoc 转出来的 DOCX 表格错位、标题层级不对。 原因Markdown 里用了非标准语法或者标题层级跳级。 解决生成时强制用标准 Markdown标题从##开始表格用管道语法转换前用 markdownlint 检查一遍。5. 进阶玩法把标书助手接进 API 和批量任务跑通单份标书只是起点。真正提效的是把它变成可批量调用的服务。Dify 工作流发布后会给一个 API 端点用脚本批量提交招标文件自动产出多份初稿。import requests API_URL http://your-dify-host/v1/workflows/run API_KEY your-workflow-api-key def generate_bid(file_path, company): with open(file_path, rb) as f: files {tender_file: f} data {company_name: company, response_mode: blocking} headers {Authorization: fBearer {API_KEY}} resp requests.post(API_URL, filesfiles, datadata, headersheaders) return resp.json() result generate_bid(tender_001.pdf, 某某科技有限公司) print(result[data][outputs][final_doc])逻辑说明response_mode选blocking会等全部节点跑完再返回适合批处理如果标书很长怕超时改streaming分块拿。参数上API_KEY 在工作流发布页生成别硬编码在脚本里用环境变量。批量跑的时候加个 sleep避免把 Dify 服务打满。验证工作流是否稳定我一般会拿三份不同类型的招标文件跑一份文字版 PDF、一份扫描件转的 DOCX、一份表格特别多的。三份都能出结构完整的初稿才算可用。如果扫描件那份挂了说明 OCR 环节没接好回去补。还有个技巧把每次生成的标书和人工修改后的版本存下来定期对比找出模型总写不好的章节针对性改提示词。这比盲目调参有效得多。从那以后我每次改完提示词都强制拿同一份招标文件跑一遍对比确认没退化才发布。希望帮到你。本文还有配套的精品资源点击获取 基于Dify工作流的标书智能生成助手：从招标文件到标书初稿的自动化实践
简介这是一份面向售前、商务与技术团队的 Dify 工作流示例资源聚焦企业级软件项目投标场景把「写标书」拆解为需求输入、分模块章节生成、风险校验与 Markdown 输出四个可控步骤帮助团队快速产出第一版标书草案并在商务、技术、法务联动前完成风险点预审与漏项筛查。资源包共 6 个文件以 yml 工作流定义、Python 校验脚本与 Markdown 测试用例为主另含少量缓存文件压缩包约 15KB可直接导入 Dify 使用。其中 DSL 文件承载完整工作流逻辑校验脚本与自动化测试用于检查 DSL 规范人工测试用例则覆盖典型输入输出场景便于读者理解节点编排与提示词设计思路。目前已有 156 人学习下载适合希望用 AI 提效标书撰写、或研究 Dify 工作流搭建的初中级用户参考借鉴。1. 标书智能生成助手把 Dify 工作流变成能落地的投标文档产线投标季最折磨人的不是写方案是同一套公司资质、业绩、技术参数要在几十份标书里反复粘贴格式还各不相同。这套「标书智能生成助手」就是冲着这个场景去的——它基于 Dify 工作流搭建把招标文件解析、要点抽取、章节生成、格式校验串成一条自动化链路输入一份招标文件输出一份结构完整的标书初稿。适合经常投标的售前、商务、技术方案岗也适合想拿 Dify 练手 AI 工作流的开发者。它解决的不是「AI 帮你写作文」而是「把重复的文档组装工作交给流程」人只做审核和补关键数据。下面按「这是什么 → 怎么搭 → 坑在哪 → 怎么用得更狠」拆开讲。2. 拆解标书生成链路Dify 工作流里每个节点到底干什么Dify 的工作流本质是一张有向图节点之间靠变量传递数据。标书生成这条链路核心是把「非结构化的招标文件」一步步变成「结构化的标书章节」。常见做法是拆成五段文档摄入、要点抽取、知识库检索、章节生成、格式组装。每一段对应 Dify 里的一类节点理解节点职责比背配置更重要。2.1 文档摄入把 PDF/DOCX 招标文件变成可检索文本招标文件基本是 PDF 或 DOCXDify 的文档提取节点能直接吃这两种格式但前提是文件已经上传到知识库或通过文件变量传入。我一般会在工作流开头放一个「文件上传」变量类型选 File然后在文档提取节点里引用它。# Dify 工作流起始节点变量定义在编排界面配置非代码 variables: - name: tender_file type: file label: 招标文件 required: true accept: .pdf,.docx,.doc逻辑说明tender_file是整条链路的入口变量后续所有节点都从它派生。参数上accept限制格式能减少用户传错文件的概率如果招标文件是扫描件文档提取节点拿不到文字需要先走 OCR这一步 Dify 社区版默认不带得在外部处理好再上传。提取出来的文本通常很长直接塞给大模型会超上下文。常见做法是接一个「文本分割」节点按 500800 字符切块重叠 50 字符保证条款不被切断。分割后的块再进知识库或直接进 LLM 节点。2.2 要点抽取用 LLM 节点把招标要求转成结构化字段招标文件里真正要抓的是项目名称、投标截止时间、资质要求、技术参数、评分办法、需提交的材料清单。这些字段散落在几十页里人工找容易漏。用一个 LLM 节点做抽取提示词里明确要求输出 JSON。# LLM 节点提示词模板在 Dify 提示词框里填写 你是一名投标专员。从下面的招标文件片段中抽取以下字段输出严格 JSON不要解释 { project_name: 项目名称, deadline: 投标截止时间, qualification: [资质要求列表], tech_params: [技术参数列表], scoring: [评分办法要点], materials: [需提交材料清单] } 若某字段在片段中不存在填 null。文件片段 {{#context#}}逻辑说明{{#context#}}是 Dify 的上下文变量占位符指向前一个节点传入的文本。参数上温度建议设 0.10.3越低越稳定模型选长上下文版本因为招标片段可能一次传几千字。输出 JSON 后后面用「代码节点」或「参数提取节点」解析成独立变量供后续章节生成引用。这里有个选型理由为什么不用知识库检索代替 LLM 抽取因为招标文件每份都不一样检索只能找到相似段落抽不出精确字段。LLM 抽取虽然慢一点但字段准确率在结构化提示词下能到可用水平。2.3 知识库检索把公司资质和过往业绩挂进生成链路标书里大量内容是公司自己的营业执照、资质证书、类似业绩、人员配置。这些不该让大模型编应该从知识库里检索。Dify 的知识库节点支持在生成前先检索相关片段把结果作为上下文传给 LLM。# 知识库文档准备把公司资质整理成 markdown 再上传 # 每份资质一个文件文件名即标题便于检索命中 company_qualification.md past_projects_2023.md personnel_certificates.md逻辑说明知识库检索节点要设「召回数量」和「相似度阈值」。召回数量一般 35 条太多会挤占上下文相似度阈值 0.5 起步低于这个值的片段基本不相关。参数上如果发现检索结果总是跑偏先检查文档分块是否太大——资质类文档按条款切别整篇塞进去。2.4 章节生成按标书目录逐段生成而不是一次性输出一次性让模型写完整本标书结果一定是前面详细后面敷衍。正确做法是按章节拆成多个 LLM 节点每个节点只负责一节比如「技术方案」「项目实施计划」「售后服务」。每节的提示词里带上抽取的要点和检索到的公司资料。# 技术方案章节生成提示词 根据以下招标要求和公司资料撰写「技术方案」章节约 800 字分点论述语言正式。 招标技术参数{{tech_params}} 公司类似业绩{{retrieved_projects}} 要求逐条响应技术参数每条先复述要求再给方案。逻辑说明tech_params来自 2.2 的抽取结果retrieved_projects来自 2.3 的检索结果。参数上每个章节节点单独设 max_tokens避免某一节吃掉全部额度。章节之间用「变量聚合」节点汇总最后统一输出。2.5 格式组装把生成文本拼成可提交的文档结构Dify 本身不生成 DOCX但可以输出 Markdown再用外部脚本转 Word。常见做法是工作流最后输出一个 Markdown 字符串变量名final_doc然后本地用 pandoc 或 python-docx 转换。# 本地把 Dify 输出的 markdown 转 docx import subprocess markdown_content {{final_doc}} # 实际使用时从 API 响应取 with open(bid_draft.md, w, encodingutf-8) as f: f.write(markdown_content) subprocess.run([pandoc, bid_draft.md, -o, bid_draft.docx])逻辑说明这段脚本不在 Dify 里跑是拿到工作流输出后的后处理。参数上pandoc 默认样式够用如果要套公司模板加--reference-doctemplate.docx。注意 Markdown 里的表格语法要规范否则转出来会乱。3. 从零搭一条能跑的工作流Dify 编排实操与参数设置上一章讲的是链路逻辑这一章落到具体操作。假设你已经有一个能访问的 Dify 环境本地 Docker 或社区版都行从新建工作流到跑通第一份标书按下面步骤走。3.1 新建工作流与变量定义进入 Dify 工作室选「工作流」不要选「聊天助手」——标书生成是批处理任务不需要多轮对话。新建后第一件事是定义起始变量。变量名类型必填说明tender_fileFile是招标文件 PDF/DOCXcompany_nameText是投标公司名称bid_sectionsText否指定生成章节逗号分隔逻辑说明bid_sections留空时默认生成全部章节填了则只生成指定章节方便快速出初稿。参数上File 类型变量在 Dify 里要确认文件大小限制默认单文件 15MB超了要在环境变量里调。3.2 文档提取与文本分割节点配置拖入「文档提取器」节点输入选tender_file输出变量命名raw_text。后面接「文本分割」节点。# 文本分割节点参数 splitter: recursive chunk_size: 600 chunk_overlap: 60 separator: \n\n逻辑说明recursive分割器会按分隔符逐级切优先在段落处断开。chunk_size600 是经验值太小丢上下文太大检索不准。chunk_overlap60 保证跨块句子不被切断。如果招标文件表格多分割后表格会散建议先在外部把表格转成文字描述再上传。3.3 LLM 抽取节点的提示词与模型参数拖入 LLM 节点模型选你环境里可用的长上下文模型。提示词用 2.2 的模板。关键参数温度0.2最大 token2000输出格式JSON如果模型支持 response_format逻辑说明温度 0.2 是为了字段稳定标书抽取不需要创造性。最大 token 2000 够放抽取结果超了说明提示词让模型话太多要加「不要解释」。如果模型不支持 JSON 模式就在提示词里强调「只输出 JSON」再用代码节点做容错解析。# 代码节点容错解析 LLM 输出的 JSON import json def main(llm_output: str) - dict: text llm_output.strip() # 去掉可能的 markdown 代码块标记 if text.startswith(): text text.split(\n, 1)[1].rsplit(, 1)[0] try: return json.loads(text) except json.JSONDecodeError: return {error: parse_failed, raw: text}逻辑说明这段代码处理模型偶尔加 markdown 标记的情况。参数上返回 dict 后 Dify 会自动拆成多个变量后续节点按字段名引用。如果解析失败error字段会暴露问题方便排查。3.4 知识库检索节点与召回参数拖入「知识库检索」节点选择你提前建好的公司资质知识库。查询内容用抽取出的tech_params拼接project_name。# 知识库检索节点参数 query: {{project_name}} {{tech_params}} top_k: 4 score_threshold: 0.5逻辑说明top_k4 是平衡召回率和上下文长度的值。score_threshold0.5 过滤掉弱相关片段。如果发现检索不到业绩检查知识库文档里是否用了招标文件里的同义词——比如招标写「智慧园区」你文档写「智能园区」检索会漏需要在文档里补同义词。3.5 章节生成节点与变量聚合每个章节一个 LLM 节点输入引用抽取字段和检索结果。全部章节节点后面接「变量聚合器」把各节输出拼成一个final_doc。# 变量聚合器配置 groups: - name: final_doc variables: - tech_section - implementation_section - service_section separator: \n\n逻辑说明聚合器按顺序拼接separator用两个换行保证章节间有空行。参数上如果某节生成失败返回空聚合结果会缺一块所以每个章节节点要设重试次数 23 次。4. 避坑与排查标书工作流跑不通时先看这几处这条链路我搭过几版翻车基本集中在下面几个地方。每条按现象、原因、解决写照着排查能省不少时间。4.1 文档提取返回空文本现象工作流跑完raw_text是空字符串后面全挂。 原因招标文件是扫描件或图片型 PDFDify 文档提取器只认文字层。 解决先在外部做 OCR把结果存成 DOCX 再上传。常见做法是用系统自带 OCR 或开源工具转一遍确认能选中文字再进 Dify。4.2 LLM 抽取字段时好时坏现象同一份文件有时抽出完整 JSON有时缺字段或格式错乱。 原因提示词不够硬模型自由发挥或者文本块太大关键信息被截断。 解决提示词里加「若字段不存在填 null不要编造」把 chunk_size 降到 400 再试温度压到 0.1。如果还飘换模型。4.3 知识库检索结果不相关现象生成的章节里引用了完全不相关的业绩。 原因知识库文档分块太大一个块里混了多个主题或者相似度阈值太低。 解决把资质文档按条款重新切分每块只讲一件事阈值提到 0.6查询语句里加上项目类型关键词。4.4 章节生成内容重复或前后矛盾现象技术方案和实施计划里出现同样的段落。 原因各章节节点独立生成没有共享已生成内容模型不知道前面写过什么。 解决在后续章节的提示词里加入前面章节的摘要或者用「对话历史」变量传递已生成内容。简单做法是每个章节提示词末尾加一句「不要重复以下已生成内容{{previous_sections}}」。4.5 输出 Markdown 转 Word 后格式乱现象pandoc 转出来的 DOCX 表格错位、标题层级不对。 原因Markdown 里用了非标准语法或者标题层级跳级。 解决生成时强制用标准 Markdown标题从##开始表格用管道语法转换前用 markdownlint 检查一遍。5. 进阶玩法把标书助手接进 API 和批量任务跑通单份标书只是起点。真正提效的是把它变成可批量调用的服务。Dify 工作流发布后会给一个 API 端点用脚本批量提交招标文件自动产出多份初稿。import requests API_URL http://your-dify-host/v1/workflows/run API_KEY your-workflow-api-key def generate_bid(file_path, company): with open(file_path, rb) as f: files {tender_file: f} data {company_name: company, response_mode: blocking} headers {Authorization: fBearer {API_KEY}} resp requests.post(API_URL, filesfiles, datadata, headersheaders) return resp.json() result generate_bid(tender_001.pdf, 某某科技有限公司) print(result[data][outputs][final_doc])逻辑说明response_mode选blocking会等全部节点跑完再返回适合批处理如果标书很长怕超时改streaming分块拿。参数上API_KEY 在工作流发布页生成别硬编码在脚本里用环境变量。批量跑的时候加个 sleep避免把 Dify 服务打满。验证工作流是否稳定我一般会拿三份不同类型的招标文件跑一份文字版 PDF、一份扫描件转的 DOCX、一份表格特别多的。三份都能出结构完整的初稿才算可用。如果扫描件那份挂了说明 OCR 环节没接好回去补。还有个技巧把每次生成的标书和人工修改后的版本存下来定期对比找出模型总写不好的章节针对性改提示词。这比盲目调参有效得多。从那以后我每次改完提示词都强制拿同一份招标文件跑一遍对比确认没退化才发布。希望帮到你。本文还有配套的精品资源点击获取