简介一份面向售前与投标人员的 Dify 工作流示例用于把“写标书”拆分成可控步骤输入需求信息后分模块生成章节自动执行风险校验最终输出 Markdown 标书与独立风险审查结果。适用于企业级软件项目投标草案、售前快速产出初稿、商务技术法务联动前的准备阶段尤其适合希望用低代码方式落地 AI 项目模板的进阶学习者。资源包共 6 个文件压缩后约 15KB以 1 个 Dify DSL.yml为核心配 2 个 Python 脚本用于本地校验与自动化测试另含 2 份 Markdown 文档用于人工测试用例与说明。结构紧凑便于直接导入 Dify 后按需修改。已有 157 人浏览学习。通过该资源可以掌握 Dify 工作流的模块拆分、参数传递和风险校验思路拿到可直接运行的示例 DSL、验证脚本及测试用例是一套完整的“标书生成”参考实现。学习时可按 DSL、测试脚本与说明文档三条线对照阅读快速迁移到其他文档生成场景。1. 标书智能生成助手为什么单轮对话写不出能用的标书标书智能生成助手这个方向第一反应都是用大模型聊天框生成但真拿通用聊天模型写标书的人都知道出来的东西字面漂亮、一条都对不上招标文件。标书是强结构、强约束的文本资格条件、评分项、工期、业绩证明每一项都要能和投标方自己的材料精确对应。Dify 工作流的做法是把“读招标文件→抽关键要求→检索企业资质业绩→分节生成→格式转换”编排成一条固定流水线让 AI 只干它擅长的生成把检索和约束留给流程。它适合投标专员、售前方案这些靠人肉堆标书初稿的团队用来把“攒标书”的时间从两三天压到半小时。2. 把标书拆成工作流从招标文件到成稿的三段式设计2.1 先认清标书结构哪部分能自动化哪部分不能碰标书看着是一份文档拆开是三种完全不同的内容。商务资格部分本质是“证据集合”营业执照、资质证书、财务状况、业绩合同每一条都要能和招标文件里的资格要求对应上技术方案部分是“能力叙述”结合项目需求写实施思路、重难点分析、进度保障报价部分是“计算加决策”涉及成本测算和竞争策略我不建议让大模型去算风险太高。所以标书智能生成助手的自动化边界应该划在“商务资格初稿加技术方案初稿”生成之后由人工逐条核验。这决定了整个 Dify 工作流的结构不是“一个提示词生成全部”而是三段式先让 LLM 解析招标文件把资格要求、评分项、工期、项目概况抽成结构化字段再拿着字段去知识库检索投标人自己的资质和业绩最后把检索结果和字段一起喂给生成节点按章节模板产出成稿。这种解析、检索、生成的顺序不能乱乱了就退化成“聊天框里写标书”的老路。这里有个选型问题值得单独说为什么不用 Dify 的 Agent 应用而用固定工作流Agent 的卖点是模型自己规划调用哪些工具适合目标开放、路径未知的探索型任务标书生成的目标是封闭的章节结构、资格响应顺序、输出格式全都预先知道路径越固定越不容易出错。我见过同事先搭 Agent 版本模型能自己决定先查知识库还是先写方案看起来灵活实际上每次生成的结构都不一样商务拿去改都没法改。工作流把路径钉死结果的可复现性才是提效的前提。2.2 节点选型Dify 里哪些节点承担标书环节Dify 工作流画布上可用的节点类型不少做标书场景真正常用的其实就六个。开始节点定义输入项招标文件全文和投标人名称从这进第一个 LLM 节点做解析输出结构化 JSON知识检索节点查资质库和业绩库条件分支节点判断检索结果是否覆盖了全部资格要求没覆盖就标记“需要人工补材料”变量聚合器把并行生成的商务章节和技术章节合并结束节点输出成稿。我在画布上搭第一条流水线时没用 HTTP 请求和外部工具把依赖先控制在 Dify 内部跑通了再加企业内部系统的通知动作。各节点在标书场景里的职责和关键参数我习惯用一个表格记下来后续调参基本围绕这三列节点标书职责必配参数开始定义 tender_text、bidder_name 等输入变量类型、是否必填LLM解析抽取项目、资格、评分字段模型名、提示词、输出格式知识检索查资质证书、历史业绩数据集、TopK、Score 阈值条件分支判断资格是否全覆盖条件表达式、分支出口变量聚合器合并商务、技术章节聚合变量列表、分隔符结束输出全文输出变量、格式先不用 HTTP 节点还有一个原因标书工作流的第一版最重要的是把数据流跑通。外部系统接得越早排查问题时的变量越多你不知道报错来自 Dify 配置、模型供应商还是外部接口。把内部节点连顺再考虑对接 OA 或投标管理平台每一层新增依赖都要单独验证。2.3 提示词与变量设计把招标要求变成可替换的参数这里有个新手常踩的坑提示词里全是固定的招标描述换个项目就废。正确做法是提示词只写“怎么做”项目相关内容全部走变量。我会在开始节点定义五个标准变量tender_text招标文件全文、bidder_name投标人名称、project_name项目名称、bid_deadline截止时间、extra_requirements补充要求。生成节点的提示词模板大致长这样你是{{ bidder_name }}的投标方案编写人员。当前投标项目为{{ project_name }} 投标截止时间为{{ bid_deadline }}。请严格按招标文件要求编写技术方案章节。 需要响应的资格要求如下 {{ qualification_reqs }} 可引用的企业资质和业绩材料如下 {{ retrieved_docs }} 编写要求 1. 每条资格要求都要有明确响应不得遗漏。 2. 业绩描述必须使用检索到的真实项目不得编造项目名称。 3. 技术方案按“理解、方案、实施、保障”四个部分展开。 4. 输出 Markdown 格式。模板里 qualification_reqs 和 retrieved_docs 这两个变量不是手动填的。qualification_reqs 来自第一个 LLM 节点的 JSON 解析输出retrieved_docs 来自知识检索节点的文本拼接。在 Dify 画布上它们的来源是在 LLM 节点的提示词输入框里点“添加变量”从上游节点输出里选而不是手写一个同名变量这也是新手最常混淆的地方手写变量名会导致运行时取到空字符串。bidder_name 这类固定信息则是开始节点的输入项由发起人在运行工作流时填写。变量分层清楚之后换个项目只需替换开始节点的输入提示词一行都不用改。3. 在 Dify 上搭一条标书生成流水线知识库、画布与交付格式3.1 建知识库先把历史标书和资质文件变成可检索片段知识库是这条工作流的地基。常见做法是建两个独立的 Dify 知识库一个装资质材料营业执照、资质证书、人员证书、财务报告一个装历史业绩往期中标通知书、合同关键页、验收报告。分库建的收益是检索时语义更干净不会出现“在营业执照里检索到施工方案”的情况。上传文档时Dify 的分段设置按文档类型来资质证书这类短文档分段长度设置偏小便于精确命中历史标书这类长文档分段长度调大到 500 token 左右重叠设 20 到 50 token避免关键句恰好被切断。分段长度的核心参数有三个分段长度、分段重叠、检索模式。分段长度决定每块文本多大太大则一个片段里混着多条信息检索命中不精准太小则上下文语义不完整模型只能看到半句话。Embedding 模型在自托管环境里一般选开源的 bge-m3 或 m3e接口格式是 OpenAI 兼容Dify 的模型供应商配置里填好 Base URL 和 Key 就能用。上传文档时文件名起得规范一点比如“业绩-2023-智慧园区EPC-中标通知书”后面检索时能靠文件名做粗过滤这是花钱都买不到的经验。知识库建完还要做权限约束。标书的资质证书和业绩合同涉敏感信息Dify 自托管环境里可以按成员或团队分配知识库访问权限不要用默认的全员可读。我一般会把资质库设为仅投标小组成员可读历史业绩库对售前和投标开放。权限边界划清楚后面把工作流开放给多个部门才不会有数据泄露的隐患。自托管部署时知识库数据落在自己的对象存储里这一点对投标材料尤其重要发到公共平台再回收就晚了。3.2 画布连线从开始到结束的完整编排顺序从零搭这条工作流我一般按六步走。第一步新建项目应用类型选“工作流”而不是“Agent 或对话型”这直接决定了有没有固定的画布路径。第二步配置开始节点的输入变量tender_text 类型选“段落”支持大文本粘贴。第三步拖入第一个 LLM 节点提示词用 2.3 的解析模板输出要求里明确“以 JSON 返回字段”。第四步拖入两个知识检索节点分别绑到资质库和历史业绩库TopK 先按 5 设。第五步拖入条件分支判断解析出的资格要求列表是否全部有对应检索结果。第六步拖入生成用 LLM 节点再拖入结束节点输出。发布导出 DSL 时文件里会保留完整的节点和连线定义。简化后的结构大概是下面这样重点看节点顺序和变量引用实际动手时不需要手写 DSL画布上拖好导出即可version: 1.0 kind: app app: mode: workflow nodes: - id: start type: start vars: - variable: tender_text type: paragraph - variable: bidder_name type: text - id: parse_llm type: llm prompt: 你是投标文件解析员从招标文件抽取 qualification_reqs、score_items 等字段以 JSON 输出。 outputs: - qualification_reqs - score_items - id: retrieve_qualification type: knowledge-retrieval dataset_ids: [资质库ID] top_k: 5 - id: output type: end参数说明里有三个地方容易看走眼。LLM 节点里的 outputs 是后面其他节点引用变量的唯一入口拼错一个字母就会拿到空值knowledge-retrieval 节点的 dataset_ids 要填知识库 ID不是知识库名称ID 在知识库设置页能看到end 节点输出的变量类型要和前面 LLM 节点的输出保持一致否则 Markdown 内容会被截断或丢失换行。画布上每连一条线我都会先点开上游节点看输出变量名再在下游提示词里引用这个习惯替我挡掉了大半黑匣子问题。运行时如果某一步输出为空Dify 的运行记录页会列出每个节点输入输出 JSON从结束节点逆着往上看问题通常出现在变量名拼写上。3.3 把生成结果变成交付件Markdown 转 Word 的两个落地方式Dify 工作流默认输出的是 Markdown 文本能看但不是投标方要的格式。标书最终要套模板封面、目录、页眉页脚、章节编号、签字盖章页。常见做法是让工作流输出正文 Markdown再由代码执行节点或外部脚本转成 Word人工套封面和签章页。代码执行节点里可以直接跑 Python对应工具是 python-docx核心逻辑就是把 Markdown 的标题和段落映射成 Word 样式# -*- coding: utf-8 -*- from docx import Document from docx.shared import Pt def md_to_docx(md_text: str, output_path: str): doc Document() # 为正文设置中文字体避免导出后中文乱码 style doc.styles[Normal] style.font.name Times New Roman style.font.size Pt(12) for line in md_text.splitlines(): line line.strip() if not line: continue if line.startswith(# ): doc.add_heading(line[2:], level1) elif line.startswith(## ): doc.add_heading(line[3:], level2) elif line.startswith(### ): doc.add_heading(line[4:], level3) else: doc.add_paragraph(line) doc.save(output_path)这段脚本在本地 Python 环境跑通常没问题但塞进 Dify 代码执行节点时执行环境必须安装了 python-docx否则会报 ModuleNotFoundError。我的习惯是在代码执行节点里只做轻量拼接重一点的模板套用放到导出后本地跑。另一个更省事的办法是把整条工作流的输出接到 HTTP 请求节点发送给内部的文档转换服务由那边做格式转换这种方式适合已经有文档中台的公司。对于刚起步的团队先把 Markdown 导出本地跑一次上面的脚本再人工套模板是投入产出比最高的路径。工作流发布后Dify 会生成 API Key外部投标管理平台可以用这个 Key 提交招标文件和投标人名称跑完后拿回 Markdown 初稿这就是把标书助手嵌进业务系统的标准姿势。这一步不复杂但要求团队里有一个人能管好 Key 的权限和调用频率否则就是裸奔的系统入口。4. 必调参数与验证清单从“像标书”变成“是标书”4.1 知识检索的 TopK 与 Score 阈值检索结果不是越多越好知识检索节点有两个最影响结果的参数TopK 和 Score 阈值。TopK 是返回多少段给生成节点标书场景我不是默认设 10而是 3 到 5。原因很直接标书生成要的是“精准引用”不是“广泛参考”。TopK 太高检索结果里混进来的不相关内容会挤占上下文窗口生成时模型反而不知道哪个是真的资质项开始幻觉编造业绩。Score 阈值按向量相似度打分经验值是 0.5 到 0.7具体看 Embedding 模型的分值分布我一般先跑几个真实招标文件观察每次命中的最低分把阈值卡在“有效结果的最低分”附近宁可少一条不可错一条。参数判断有一部分是玄学但标书领域可以把玄学变成工程方法。我习惯在每次跑完工作流后把检索到的片段和对应分值导出来看一眼。如果每次命中的前三条高度一致说明切片和 Embedding 匹配得好如果每次结果都不一样先怀疑分段长度再怀疑 Embedding 模型最后才怀疑阈值。顺序反了会浪费大量时间而且容易被一次偶然的成功误导。4.2 上下文窗口与分段重叠先把上下文超长的根堵住很多人在 Dify 工作流里第一次跑标书生成就碰到上下文超长的报错根子通常不在 LLM 节点而在知识库的分段参数。假设分段长度 1000 tokenTopK 设 10光检索结果就有 10000 token再加提示词模板、招标文件全文直接顶穿模型上下文窗口。解决办法有三个按优先级排。第一分段长度降到 300 到 500 token让单段文本只装下一层信息第二TopK 降到 5 以内第三把“招标文件全文”从生成节点的上下文里挪走只让生成节点引用解析后的结构化字段比如资格要求和评分项。这一条能解决掉八成“上下文超长”。我的建议是先看工作流里每个节点实际传了多少 tokenDify 画布上点开节点能看到输入内容预览不用猜。分段重叠是另一个相关的参数设为 20 token 左右即可让相邻两段有一点信息重叠避免一句话被拦腰切断。标书的资格条款往往是一整条长句切断了语义就废了重叠太小模型会拿着半句话去响应资格要求。4.3 温度与模型选择文本一致性和成本怎么平衡生成节点的温度设置在标书场景非常保守解析节点温度 0.1 到 0.2生成节点温度 0.3 到 0.5几乎不用 0.7 以上的高温。标书文本要的是一字不差的资格条款和无歧义的技术描述温度高了会出现“字面痛快但数字对不上”的问题这是投标里最忌讳的。模型选择要看团队预算常见做法是接一个 OpenAI 兼容接口的商用模型保证质量自托管环境可以接一个能跑长文本的开源模型控制成本。注意解析和生成可以用不同模型解析用小模型省钱生成用强模型保质量Dify 的每个 LLM 节点可以分别选模型不需要全局统一这个细节容易被人忽略。批量跑多个投标项目时成本控制会更明显。解析节点每天跑几十次用小模型生成节点一个项目只跑几次用强模型。总成本比全程强模型低一截输出质量却没有明显差别。4.4 验证清单怎样才算“能用的初稿”生成完不是直接导出交给商务而是先过一遍验证。我的验证清单很简单四步。第一步核对招标文件首页的项目名称、招标编号、截止时间和工作流输出是否一字不差第二步把资格要求逐条拿出来到输出里查找响应找不到的就是“资格缺失”第三步对照评分表看每个分值点在成稿里有没有对应章节标书拿分靠的是“每分必争”第四步抽查业绩描述凡是模型写的项目名称、合同金额、年份必须和知识库里的原始材料一致不一致的一律改回。检查项方法通过标准项目名称与招标编号对比招标文件首页完全一致资格要求覆盖率逐条对照资质要求每条都有响应评分项覆盖对照评分表各分值点有章节回应业绩时间有效性核对合同日期与金额与原始材料一致这四步走下来初稿就达到了“能交给商务做最终排版”的程度。验证过程靠人眼过一遍会累但第一次跑通时这一步不能省跑熟后再考虑把校验规则写进代码执行节点里自动化。办法是加一个代码执行节点对生成结果做关键词和正则检查比如搜“绝对”“100%”这类词命中就标记为待人工复核。第一次人工验证是给模型定标准第二次自动化是解放人标书初稿能做到什么程度取决于沉淀下来的验证规则有多少。5. Dify 工作流落地中的 5 个典型坑与排查5.1 模型供应商校验失败an error occurred during credentials validation现象在 Dify 后台配置模型供应商填完 API Key 点校验网页直接报 an error occurred during credentials validation模型列表里什么都看不见。原因分三类API Key 字符错误或权限不足模型名和供应商实际提供的模型标识不一致OpenAI 兼容 Base URL 填错比如漏了 /v1 后缀。解决先用 curl 单独测一下这个地址能不能通能通再看 Dify 配置测地址是我排查这个问题的第一步curl -X POST https://your-api-host.example.com/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer your-api-key \ -d {model:your-model-name,messages:[{role:user,content:ping}]}curl 返回正常 JSON问题就在 Dify 的供应商配置里curl 返回 401 或 404问题就在 Key 或模型名上。自托管环境里还要检查容器能不能访问到该 API 地址公司内网模型服务域名解析不通也会报同样的校验错误。5.2 工作流跑到一半报上下文超长现象画布上点“运行”A 节点正常B 节点直接报错提示内容超出模型的最大上下文。原因最常见是知识检索节点返回的片段过多、单段过大再加上提示词把招标文件全文都塞给了生成节点。解决按 4.2 的顺序来把分段长度从 800 调到 400TopK 从 10 降到 5生成节点的提示词里去掉招标文件全文、只引用解析后的结构化字段。改了这三个地方还超长就把一个生成节点拆成两个商务章节一个 LLM 节点技术章节一个 LLM 节点最后用变量聚合器合并彻底解决长文本问题。变量聚合器的配置方式是把两个节点输出按顺序拼接concat(commercial_node.output, tech_node.output)分隔符用两个换行后续排版才不用重新拼接。注意聚合器本身不处理内容它只负责把多个变量合成一个输出名要起得直观比如 full_draft后面结束节点引用时一眼能认出来。5.3 自托管环境频繁出现 SSL 错误现象Dify 本地部署跑起来接入外部模型 API 时报 SSL 相关错误时好时坏重启容器后又出现。原因通常是容器内的 CA 证书不完整或者外部模型 API 使用了自签 HTTPS 证书容器没有信任该证书。解决不要先怀疑 Dify 本身先看模型 API 的证书链。自托管部署时给容器挂载宿主机的 ca-certificates 目录是最省事的办法如果外部地址是自签证书要么换掉证书要么把自签证书追加到容器的信任区。网上搜到“dify ssl错误”相关内容时绝大多数都是这个套路真正是 Dify 程序问题的情况反而很少按这个顺序走一遍就能确认。5.4 知识库检索答非所问生成内容驴唇不对马嘴现象检索“近三年智能化工程业绩”返回的是 2016 年的一份合同生成节点照着这份合同写出了过时案例。原因是没让知识库按时间或类型过滤向量检索只认语义相近不认年份。解决用一套组合拳第一上传文件时就按年份和项目类型放进不同知识库业绩库只放近三年第二在知识检索节点加 Metadata 过滤只检索指定年份区间第三分段开头带上年份关键词例如“2024年 智慧园区 EPC项目 中标通知书”让切分后的每段都自带时间戳。标书里的业绩是硬性评分依据年份错太离谱这份初稿基本等于报废。5.5 变量未定义结束节点输出一片空白现象工作流运行成功结束节点却输出空字符串或只有开头几个字检查画布看不出问题。原因多半是生成节点输出的变量名和结束节点引用的变量名不一致Dify 的变量名区分大小写节点输出引用拼错一个字符就取不到值。解决画布上点开每一个节点在“输出”里复制它生成的变量名再粘贴到下一节点的提示词或输出引用里不要手敲。这里还有一个小技巧先用模板转换节点把生成结果强制赋给一个固定变量再交给结束节点相当于做一次变量名校验能挡掉大多数黑匣子问题。这个错我踩过排查花了半小时最后发现只是少写了一个字母属于最气的坑。6. 把标书助手从“能生成”推进到“能交付”三条进阶经验工作流跑通只是第一步。真正让这个方案在团队里活下来的是后面三条经验。第一条给工作流加内容审核节点。Dify 的 LLM 节点后面可以挂一个分类节点把生成结果按“含违规承诺、数字存疑、正常”分三类含违规承诺的章节直接拦下来打回重新生成。标书里常见的违规承诺是“绝对满足”“百分百实现”评审专家看到这种词会直接扣印象分。第二条把每一次成稿回写进知识库。项目验收后把最终中标版标书按项目名、年份、行业标签上传回业绩库下一次投标检索时模型能引用到高质量样本标书资产的复利从这里开始积累。前提是回写前做脱敏涉及报价和联系人信息要清理干净。第三条人工核对流程不能省尤其报价部分。技术方案可以放手让模型出初稿报价单一律人工填。部署方式上如果团队有条件优先用 Dify 自托管版本做整套数据私有化。标书材料涉企业资质和业绩敏感度不低私有化部署后模型 API 和知识库都在自己可控范围才敢往里面沉淀历史标书。如果暂时不具备条件至少把知识库权限按团队隔离不要全员可见。我第一次让工作流生成完整标书时报价部分数字表面对得很整齐实际算起来差了一位数幸好核验环节兜住了。从那以后工作流里只生成技术和商务初稿报价永远留白由人填这条边界建议一开始就划清楚。参数层面把第 4 章的四个参数调好配合第 5 章的排查顺序出问题半小时内能定位。希望帮到你。本文还有配套的精品资源点击获取