企业官网建设流程全解析

简介：面向售前、商务及项目经理的标书智能生成助手，是一份基于 Dify 平台的 Workflow DSL 工作流示例，解决了标书撰写耗时、易漏项的问题。工作流将繁琐的标书任务拆解为输入招标需求、项目信息与公司介绍，分模块生成章节，自动执行风险校验，最终输出完整 Markdown 标书和独立风险审查结果。资源包共 6 个文件，大小仅 15KB，包含一个可直接导入 Dify 的 YAML 工作流定义、两个 Python 脚本（分别用于 DSL 本地校验与自动化测试）、两个 Markdown 说明文档及人工测试用例，类型清晰，便于按需取用。读者可将其导入 Dify 直接运行，通过测试用例核验生成链路是否完整，也可以参考校验脚本对自有 DSL 做检查，结合分模块设计快速适配企业投标、售前初稿、法务技术联动前的初稿与风险预审等场景。该资源已有 157 人学习/下载，适合希望用 AI 工作流提升标书撰写与审查效率的团队和个人。

1. 标书智能生成助手：为什么选 Dify 工作流而不是单纯调 API

做标书这件事，最花时间的从来不是写，而是把几十份散落在不同目录里的公司资质、业绩合同、人员证书、技术方案片段找出来，再按照招标文件的章节顺序重新组织成一份格式规整的文件。一个售前工程师一整天耗在复制粘贴里，最后出来的标书还是经常漏项。标书智能生成助手要解决的就是这个“信息查找与组装”的成本问题，而 Dify 工作流恰好把知识库检索、大模型生成、格式转换这些环节串成了一条能被业务人员自己改的流水线，不需要每次生成都去改代码。

我最早也试过直接调大模型接口写标书，但很快发现一个问题：模型对“我们公司”的情况一无所知，每次都要在提示词里塞大段背景资料，塞得越多越容易把关键信息漏掉，而且输出格式不稳定。Dify 的做法是把这些背景资料先切好存进知识库，生成时通过检索自动捞回来拼进上下文，再用工作流把“先查资质、再写章节、最后转格式”的步骤固定下来。这篇笔记就按这个思路展开：怎么设计节点、怎么调知识库参数、怎么处理格式输出，以及我在落地过程中踩过的几个坑。适合正在用 Dify 做企业级生成工具，或者想把手动写标书流程改造成半自动流水线的从业者看。

2. 拆解标书生成的任务链：Dify 工作流节点的编排思路与变量设计

2.1 标书任务的第一原则：先拆章节，再谈生成

标书和普通文章生成的差异在于，招标文件对章节结构有硬性要求，少一个章节就是废标。所以工作流一定要按“章节级”拆，不要指望一个 LLM 节点把整份标书一次写完。常见做法是先把招标文件里要求的章节清单读出来，然后让工作流逐章生成，每章一个 LLM 节点，这样生成的上下文会短很多，命中率也高。

拆解之后的工作流大致是这样一个结构：开始节点接收项目名称、招标编号、投标人名称这几个原始变量，然后用知识检索节点把每个章节需要的资料从知识库里捞出来，接着进入 LLM 节点生成正文，最后用代码节点把所有章节拼成一个 Markdown 文件输出。Dify 可视化的画布上从上到下把节点连起来，任何一个中间节点失败都能单独重跑，这是单次 API 调用做不到的。

2.2 开始节点该传什么变量：别把提示词写死在节点里

开始节点是整个工作流里最容易被忽视但最值得设计的地方。以标书场景为例，至少要传以下变量：

{ "project_name": "某市智慧园区弱电工程", "bid_no": "T2024-0312", "company_name": "中科云建科技有限公司", "bid_section": "技术方案", "bid_deadline": "2024-11-20 17:00" }

这些变量在后续每个 LLM 节点里都可以通过{{变量名}}的方式引用，比如写报价说明时引用{{bid_deadline}}，写技术偏离表时引用{{project_name}}。我把这一层设计叫“数据与文案分离”：Dify 的开始节点承担了数据入口的职责，后续节点只关心怎么写，不关心数据从哪来。

2.3 条件分支在标书里的实际用法：有没有这一章是两套逻辑

标书工作流里最常遇到的情况是“这一章可能没有”。比如不是所有项目都要求“项目经理答辩”，有些招标文件只要求“项目团队配置表”。如果两个章节不存在，生成的时候强行去填充，就会在技术方案里出现一段违和的文字。Dify 的条件分支节点（IF/ELSE）能处理这种不确定性，判断的依据一般是开始节点传入的布尔变量。

我一般会这样设计：开始节点增加一个“是否包含售后方案”的布尔变量，条件分支判断为“是”就走售后方案生成节点，判断为“否”就跳过这一节。这样做的好处是同一套工作流能覆盖多个标段，不用为每种招标要求单独复制一遍工作流。要注意的是，跳到“否”分支时，结束节点的输出结构必须保持一致，否则下游拼章节的代码节点会报错。

2.4 LLM 节点参数的工程确认：Temperature 与上下文长度的选择

在 Dify 的 LLM 节点里，除了选择模型和写提示词之外，有几个参数直接影响标书生成质量。Temperature 建议设到 0.3 到 0.5 之间，低于 0.3 文案会显得生硬，高于 0.5 容易让技术方案出现夸张的承诺表述，“保证系统 100% 稳定”这类话在标书里是要避免的。上下文长度建议用模型支持的最大值，因为知识检索节点返回的命中片段往往就有 2000 到 3000 字，加上提示词和已有章节内容，太短的上下文窗口容易把前面的资料挤出去。这个参数每调整一次，建议同时在草稿区留一个对照输出，不要只凭感觉调。

模型选择上，国内可用的开源或商用模型都能跑通，关键是看长文本能力和中文标书术语的掌握程度。我一般用上下文窗口在 32K 以上的模型，因为实际生成时提示词、检索片段和历史正文经常累积到一万字以上。

3. 把企业资料喂进 Dify 知识库：分段、召回与命中率的调参路径

3.1 标书知识库的数据源与导入策略：不要一股脑全塞进去

知识库是标书智能生成助手的“弹药库”。存储内容大致分三类：公司资质类（营业执照、资质证书、获奖证明）、业绩类（历史项目合同、验收报告）、能力类（技术方案模板、专利软著）。这三类数据的特征差异很大。资质类是事实型信息，要求检索后原文引用，不能改动；技术方案模板是半成品，允许大模型改写。如果混在一个知识库里，容易导致检索时把技术方案片段当成资质引用，输出就“看着对但实际错”。

我一般会在 Dify 里按一级分类建三个独立知识库，工作流里用三条知识检索节点分别查，然后在 LLM 节点的提示词里用“根据以下资质信息回答：{{资质检索结果}}，根据以下业绩信息回答：{{业绩检索结果}}”来区分引用边界。如果只有一个知识库，也要在文档命名前缀上做区分，比如资质-XXX.pdf和方案-XXX.docx。

3.2 分段长度与重叠：检索命中率最先要调的两个参数

知识库分段（Chunk）设置直接影响召回质量。Dify 里默认分段长度是 500 字符、重叠 50 字符，这个配置在标书场景下经常不够用。标书资料里有大量表格，一段文字从表头到表尾往往超过 500 字符，切断了表格再检索回来就是残缺的。我一般把分段长度调到 800 到 1000，重叠设到 100 左右，这样既能保留表格结构的完整性，又不会因为单段太长导致向量检索时命中得分被稀释。

需要说明的是，分段参数不是越大越好。超过 1200 字符后，向量检索的精度会下降，因为一段里包含多个主题时，Embedding 向量会趋向平均化，检索“弱电工程业绩”时返回的段落里可能同时混着“软件开发业绩”，命中得分排序就不准了。

3.3 召回模式怎么选：混合检索比纯向量更稳

Dify 知识库的检索模式有向量检索、全文检索和混合检索三种。标书场景强烈建议用混合检索，并把 Rerank 打开。原因很直接：向量检索适合语义匹配，但标书里大量的资质证书编号、合同编号是精确词，比如“CMMI5 级证书”，用向量检索时这个关键词的精确匹配优势体现不出来，全文检索反而能直接命中。

混合检索加 Rerank 是一个比较稳的组合，Rerank 会对两种方式召回的结果做一个统一排序，把最相关的排到前边去。我在 Dify 里设置检索结果数量是 5 条，匹配阈值调到 0.4。阈值低于 0.3 会召回大量无关内容，高于 0.6 又会漏掉一些关键资料，这个范围是我在多个项目上试出来的结果。还有一个容易被漏掉的操作：召回结果要开启“引用原文”输出，这样 LLM 节点能拿到带来源标识的片段，后续人工核对时能知道哪句话出自哪份文件。

3.4 检索不到资料时的兜底逻辑：宁可明说没有，也不能编造

标书工作流里最危险的情况不是检索结果少，而是检索结果不相关但大模型强行输出。因此工作流的提示词里必须加一条硬约束：“如果检索到的资料与当前章节主题不相关，请直接注明‘该章节需要线下补充资料’，不要在无依据的情况下编造数据。”这条约束不能只写在 LLM 节点里，还要在知识检索节点之后加一个代码节点，统计召回结果的数量和平均得分，低于设定的阈值时，让代码节点返回一个特定标记，后续的 LLM 节点读到这个标记就直接输出待补充文案。这一步的工程价值在于把大模型的“幻觉”兜在了工作流边界上。

4. 从工作流到正式标书：Markdown 输出与格式转换的落地链路

4.1 为什么要先在 Dify 里生成 Markdown，而不是直接生成 Word

直接让大模型输出 Word 是不现实的，模型生成的 docx 结构极不稳定。常见的做法是让 Dify 工作流的结束节点输出一个结构完整的 Markdown 文档，再利用后续的转换脚本或其他服务把它转成 Word。这套链路的好处是，Markdown 是一种极简的纯文本格式，Dify 的 LLM 节点天然擅长生成它，而且生成的中间结果可以在画布下方直接预览，不需要在模型输出和最终文件之间来回倒腾。

在工作流里，代码节点承担的是“拼接章节”的职责。开始节点和各 LLM 节点产生的内容是分散的，需要按“章节顺序”和“标题级别”组装。我在代码节点里做的工作是维护一个顺序数组，每一轮 LLM 节点生成完就把结果追加进数组，结束后拼接成完整 Markdown 字符串，输出给结束节点。

4.2 用代码节点把各章节拼成完整 Markdown：核心代码与参数说明

def main(chapter_1: str, chapter_2: str, chapter_3: str, chapter_4: str) -> dict: sections = { "1. 项目概述": chapter_1, "2. 技术方案": chapter_2, "3. 项目管理": chapter_3, "4. 售后服务": chapter_4, } md_lines = [] for title, content in sections.items(): # 跳过内容为空的章节，避免标书出现空页 if not content or len(content.strip()) < 10: md_lines.append(f"## {title}\n\n（该章节内容待补充）\n") continue md_lines.append(f"## {title}\n\n{content.strip()}\n") full_md = "\n".join(md_lines) return {"markdown_content": full_md}

这个代码节点的逻辑并不复杂，但有几个细节需要说明。len(content.strip()) < 10是过滤掉 LLM 节点可能返回的“空壳”内容，比如只输出了章节标题而没有正文。标题前缀用统一的“数字序号”能方便后续转 Word 时自动识别目录结构，不需要在 Markdown 里再写一遍目录文本。代码运行后输出的markdown_content变量就是结束节点的最终输出。

4.3 用 Dify 外部工具把 Markdown 转成 Word：Pandoc 是轻量方案

Markdown 转 Word 可以有很多手段，常见做法是 Pandoc。它支持从 Markdown 直接转出带样式的 docx，也支持自定义参考模板reference-doc，让输出的字体、标题样式、页边距符合投标格式要求。具体命令不在这里展开，因为 Dify 本身不内置这个转换，通常是把 Markdown 内容 POST 到一个自己维护的文件转换接口，接口内执行转换后返回下载链接。

值得留意的是，标书场景里“表格”的转换体验。Markdown 表格转到 Word 后，默认样式的表格线可能很细，打印出来不清晰。解决办法是在 Pandoc 的reference-doc模板里预定义一套中文字体和表格样式，这个参考模板可以从一份格式良好的 docx 模板生成，Pandoc 会把内容填入对应样式的框架里。这条链路跑通之后，新增一个章节格式只需要改模板，工作流主体不用动。

4.4 结束节点的结构设计：输出可追溯，不要只给一段文字

结束节点建议输出一个 JSON 对象，不要输出单一字符串。我的习惯是至少包含三部分：markdown_content（全文内容）、chapter_count（章节数）、created_at（生成时间）。另外再把每个章节的标题和对应内容单独作为一个数组字段导出，这样后续如果要接文件转换服务，可以直接定位到某个章节单独改，而不需要整个重新生成。JSON 结构化输出对后续接企业微信机器人、邮件发送、OA 集成也方便，这些场景都只需要解析 JSON 字段就能拿到目标内容。

5. 避坑：标书生成工作流最常见的 5 个翻车现场与排查路径

5.1 知识库检索结果把资质证书年份搞错

现象：生成的公司资质描述里，软件企业证书的获批年份和实际差了两年，评审专家一眼就能看出问题。原因：知识库里同一份证书有多个版本，旧版扫描件和新版电子件都被分段入库，向量检索时把旧版文档的片段也召回了，LLM 在汇总时取了“多数派”信息而不是最新版本。解决：在知识库文档列表里勾选“仅索引最新版本”，或在检索到的内容中增加“文档更新时间”字段，并在提示词里强约束“如果同一名称证书出现多个年份，取年份最大的那个”。

5.2 提示词里的公司简称导致生成内容前后不一致

现象：技术方案正文里一会儿写“我公司”，一会儿写“我方”，还有一段写成了公司全称的一半。原因：LLM 节点提示词里没有把公司简称固定下来，模型在长文本生成时自己换了表述习惯。解决：在每个 LLM 节点的提示词开头统一加入“公司简称定义段”，并在开始节点增加一个company_short_name变量，所有节点统一引用。代码节点拼接章节前可以跑一个正则替换，把所有公司全称统一替换为简称，这是一个保险手段。

5.3 某一章 LLM 节点超时导致整个工作流失败

现象：生成技术方案第三章时，工作流一直转圈，最后红色报错。原因：知识检索节点返回的内容过长，加上大段提示词和上下文累计超过模型单次请求限制，或者网络请求超时。解决：在知识检索节点限制召回条数及片段长度，不要把 5 条完整片段都一次塞给 LLM，而是先做截断或摘要。另一个思路是把“技术方案”这类长章节拆成“技术方案-总体架构”“技术方案-功能设计”“技术方案-实施计划”三个独立 LLM 节点，每个节点耗时短且互不影响，失败也能单独重跑。

5.4 Rerank 模型未配置导致的排序混乱

现象：知识库召回的结果里，第一段是完全不相关的资质证书介绍，真正有用的业绩信息排到了最后，生成的标书内容牛头不对马嘴。原因：混合检索开启后没有选 Rerank 模型，导致两种检索结果只是机械拼接，排序得分不统一。解决：在知识库设置里确认 Rerank 模型已启用，并设置一个较低的返回条数，让 Rerank 只保留最前面的相关片段。如果没有可用的 Rerank 模型，建议退回纯向量检索，而不是用无排序的混合检索。

5.5 迁移工作流后变量引用断裂

现象：同一个工作流在测试环境跑得好好的，迁移到生产环境后开始节点报“变量不存在”。原因：Dify 工作流里开始节点的变量名称是可改的，迁移过程中如果换了变量名，LLM 节点和代码节点里引用的旧变量名会失效。解决：迁移后先在草稿模式下把所有引用变量名的节点打开检查一遍，重点关注开始节点和 LLM 节点的交接处。如果有条件，把开始节点的变量设计做成“约定式”，统一用project_name、bid_no这类固定命名，不要在一套工作流里出现大小写混用。

6. 让标书生成助手从“能跑”到“好用”：批量生成、人工审核与版本管理

工作流跑通之后，真正决定它能提多少效的是生成后的使用机制。我自己在使用过程中摸索出一个流程：先对同一份招标文件生成三个不同方向的版本，一个偏技术深度、一个偏交付速度、一个偏成本优化，然后人工挑选最合适的一个作为基础版，再在这个基础版上做局部修改。Dify 的并发能力支持同时跑多个工作流实例，所以批量生成不是问题，难的是怎么把人工审核沉淀回知识库——每次标书里被人工修订过的段落，都是下一次生成的“最佳参考”。

我养成了一个习惯：每完成一份标书，就把被甲方认可的章节片段单独存一份进“优秀方案库”，在知识库里单独建一个集合。这样迭代几次之后，知识库的内容已经不是网上搜来的通稿，而是自己公司真正中过标的方案。这个积累远比调参更值钱，因为 Dify 工作流的底层逻辑是“让检索结果去引导模型表达”，库里的资料越好，模型输出的下限就越高。

版本管理方面，Dify 工作流本身就带有版本发布能力，每次改动后发布一个新版本就行，但建议在发布描述里写清楚这次改了什么参数、为什么改。否则两周之后回看，会忘了当时把召回阈值从 0.4 调到 0.5 的背景。我自己吃过这个亏，后来每次参数调整都在描述里加一句备注，比如“降低阈值以召回更多技术方案片段，解决生成内容重复问题”。这是我在这个项目上最大的教训：工具的坑都填得完，最难的是让团队成员知道为什么要这么填。

如果你也在做标书方向的 Dify 落地，这一篇的参考价值是帮你避开了检索质量、变量断裂和格式链路三个最大的坑。剩下的，就靠你们公司自己的行业积累往知识库里填了，希望帮到你。

本文还有配套的精品资源，点击获取