企业官网建设流程全解析

简介：这是一份面向企业售前、商务与投标团队的可直接导入 Dify 的 Workflow DSL 示例，把“写标书”拆解为需求输入、分模块章节生成、自动风险校验与 Markdown 标书输出四个可控步骤，适用于软件项目投标草案生成、售前快速产出第一版标书、商务技术法务联动前的初稿准备以及风险点预审与漏项筛查。资源包共 6 个文件，以 yml 工作流定义、Python 校验脚本与测试用例、Markdown 说明文档为主，另含少量缓存文件，压缩包约 15KB，结构轻量便于快速导入与二次修改。目前已有 156 人学习下载。读者可借此获得一套可运行的标书生成流程模板、本地 DSL 校验脚本与自动化测试思路，以及人工测试用例参考，帮助理解 Dify 工作流编排方式，并在此基础上按自身业务调整章节结构与风险审查规则。

1. 标书智能生成助手：把 80 页重复劳动压进一条 Dify 工作流

做过投标的人都懂那种感觉：招标文件 200 页，技术标要求 60 页，商务标格式固定，可真正能复用的内容不到三成，剩下的时间全花在复制粘贴、改公司名、对齐目录、检查废标项上。标书智能生成助手要解决的正是这件事——用 Dify 搭一条工作流，把「读招标文件 → 拆评分点 → 匹配素材库 → 生成章节初稿 → 输出 Word」串成自动化链路。它适合经常投标的技术负责人、售前、以及想用 AI 工作流提效的中小团队。核心不是让 AI 替你写标书，而是让它把结构化、重复性的部分先铺好，人只做判断和润色。下面按我实际落地的顺序，从环境到工作流到踩坑讲清楚。

2. 为什么选 Dify 而不是 Coze、n8n 来搭这条链路

2.1 标书场景对工作流的三个硬要求

标书生成不是聊天，它对工作流有三条硬指标。第一是长文档处理：一份招标文件动辄十几万字，需要分段、向量化、按评分项召回，普通对话窗口塞不下。第二是私有素材库：公司资质、过往案例、技术方案这些不能上传到不可控的云端，必须本地或私有部署。第三是可控的输出格式：最终要落到 Word 的固定章节结构，不能是自由发挥的一段话。

这三条决定了选型方向。Coze 工作流上手快、插件丰富，但数据落在平台侧，私有素材库和本地部署是短板；n8n 强在系统集成和定时触发，做 RPA 式的流程编排很顺，但它本身不是为 LLM 长文本和知识库检索设计的，向量检索要自己接。Dify 的定位刚好卡在中间：它自带知识库流水线、变量赋值、条件分支、LLM 节点，社区版可以 Docker 本地部署，数据不出内网，同时工作流编排的可视化程度足够让非程序员改。

我一般会这么判断：如果标书素材全是公开信息、团队没有运维、只想快速试，Coze 够用；如果核心诉求是「把公司十年积累的方案库喂进去、还要接内部 OA 审批」，那 Dify 社区版自部署是更稳的选择。n8n 更适合放在 Dify 后面做「生成完自动发邮件、写回 CRM」这类外围动作，两者不冲突。

2.2 Dify 社区版本地部署：Docker 一条命令起服务

热词里 dify 安装、dify 本地部署教程、docker + dify、dify 安装 windows 出现频率很高，说明卡在部署这一步的人不少。我推荐 Linux 服务器上用 Docker Compose，Windows 用 WSL2 跑同一套，别在纯 Windows 环境硬装。

# 1. 拉取 Dify 社区版源码（用官方仓库，版本以你拉取当天为准） git clone https://github.com/langgenius/dify.git cd dify/docker # 2. 复制环境变量模板，按需改端口和密钥 cp .env.example .env # 3. 启动全部服务（api、worker、web、db、redis、向量库等） docker compose up -d # 4. 查看容器状态，确认没有反复重启的 docker compose ps

逻辑说明：Dify 社区版是一组容器，api负责后端逻辑，worker跑异步任务（知识库索引、工作流长任务都靠它），web是前端，db是 PostgreSQL，redis做队列，向量库默认用 Weaviate。docker compose up -d会按依赖顺序拉起全部服务，第一次启动会拉镜像，慢是正常的。

参数说明：.env里重点看三个——EXPOSE_NGINX_PORT决定你访问的端口，默认 80，被占用就改；SECRET_KEY生产环境必须换成随机长串，否则会话不安全；向量库相关配置如果要用外部库（比如已有 Milvus），在这里切换VECTOR_STORE。启动后浏览器访问http://服务器IP:端口，第一次会让你设管理员账号。

提示：docker compose ps里如果worker一直 restart，九成是.env里数据库密码和db容器不一致，或者内存不足被 OOM kill，先看docker compose logs worker。

2.3 知识库流水线：把招标文件和素材库分开建

Dify 的知识库流水线是这条工作流的地基。我的做法是建两个独立知识库，不要混在一起。

第一个叫「招标文件库」，按项目建，每个项目上传当次的招标文件，切分粒度细一点（比如 500 字符、重叠 50），因为要精确召回评分条款。第二个叫「公司素材库」，长期积累，放资质证书说明、技术方案模板、过往案例、人员简历，切分粒度可以粗一些（800 字符），因为它是被「按主题检索」而不是「按条款定位」。

上传时注意：PDF 扫描件必须先 OCR，Dify 自带的解析对纯图片 PDF 无能为力，热词里dify unstructured api url is not configured for doc file processing这个报错就是解析器没配好导致的。要么在.env里配好 Unstructured API，要么上传前自己用工具把 PDF 转成带文字层的格式。索引方式选「高质量」用向量检索，标书这种语义匹配场景比关键词检索召回准得多。

3. 工作流拆解：从招标文件到章节初稿的五个节点

3.1 节点一：文档提取与评分点结构化

工作流第一步不是直接让 LLM 写，而是先把招标文件「读薄」。用一个 LLM 节点，输入是招标文件全文（从知识库召回或直接传文档变量），提示词要求它输出结构化的评分点清单。

你是一名投标分析专家。请从下面的招标文件中提取所有评分项，按以下 JSON 格式输出，不要输出任何解释文字： { "items": [ {"category": "技术分", "item": "项目实施方案", "score": 15, "requirement": "需包含进度计划、人员配置、风险控制"}, ... ] } 招标文件内容： {{#context#}}

逻辑说明：这一步的价值在于把非结构化的招标文件转成机器能遍历的评分点数组。后面每个评分点单独走一遍生成，比让 LLM 一次性写完整本标书质量高得多，也不会因为上下文超限丢内容。

参数说明：LLM 节点建议用长上下文模型，温度调到 0.1～0.3，因为提取评分点要的是准确不是创意。输出格式一定要在提示词里写死 JSON，Dify 支持结构化输出解析，解析失败会走异常分支，方便你排查是哪份文件格式太乱。

3.2 节点二：按评分点召回素材

拿到评分点数组后，用迭代节点（Iteration）逐个处理。每个评分点作为查询词，去「公司素材库」检索最相关的 3～5 段素材。

检索查询：{{item.category}} {{item.item}} {{item.requirement}} 召回条数：5 相似度阈值：0.5

逻辑说明：迭代节点让工作流对数组里每一项重复执行同一套子流程。这里把评分点的类别、名称、要求拼成查询串，比只用一个词召回准。相似度阈值设 0.5 是经验值，太低会召回无关内容污染生成，太高在素材库不够丰富时又召回不到东西，可以先设 0.5 跑一批看效果再调。

参数说明：召回条数不是越多越好，5 条左右够用，太多会把 LLM 上下文塞满还引入噪声。如果某个评分点召回为空，说明素材库缺这块内容，工作流应该标记出来提醒人工补，而不是硬生成——这是避免「一本正经胡说」的关键设计。

3.3 节点三：分章节生成初稿

每个评分点召回素材后，进入生成节点。提示词要约束三件事：只基于召回素材写、按评分点要求组织、输出 Markdown 便于后续转 Word。

你是投标文件撰写专家。请针对以下评分项撰写章节初稿。 评分项：{{item.item}} 分值：{{item.score}} 要求：{{item.requirement}} 可参考的公司素材： {{#retrieved_docs#}} 要求： 1. 只使用上述素材中的事实，不得编造资质、业绩、人员信息 2. 结构清晰，用二级标题分小节 3. 篇幅与分值匹配，15 分的项不少于 800 字 4. 输出 Markdown 格式

逻辑说明：把「不得编造」写进提示词是血泪经验。标书里编造业绩一旦被查是废标甚至更严重的后果，所以生成节点必须被素材约束死。分值决定篇幅这条也很实用，让 AI 自己分配笔墨，15 分的重点项和 3 分的形式项不该一样长。

参数说明：温度可以比提取节点高一点，0.4～0.6，让文字通顺些。如果发现生成内容总是超出素材范围，把温度降到 0.2 并加强提示词约束。max_tokens 要设够，长章节别被截断。

3.4 节点四：变量赋值汇总与格式校验

所有章节生成完后，用变量赋值节点把结果拼成一个完整文档变量，同时做一轮格式校验——检查有没有空章节、有没有明显占位符没替换。

# 伪代码示意汇总逻辑，实际在 Dify 变量赋值节点里配置 full_doc = "" for section in generated_sections: if not section.content or len(section.content) < 100: full_doc += f"\n## {section.title}\n[待人工补充：素材库未匹配到相关内容]\n" else: full_doc += f"\n## {section.title}\n{section.content}\n"

逻辑说明：这一步是质量闸门。生成节点可能因为召回为空而输出空内容，汇总时统一标记成「待人工补充」，比让空白悄悄溜进最终文档强。变量赋值节点在 Dify 里可以写表达式，把数组拼成字符串。

参数说明：长度阈值 100 字符是经验值，低于这个基本是无效生成。标记文案要显眼，方便人工一眼扫到哪些地方需要补。

3.5 节点五：输出与转 Word

最后把汇总好的 Markdown 输出。Dify 工作流可以直接返回文本，也可以接一个代码节点调用转换库生成 docx。

# 代码节点：Markdown 转 Word（需在环境里装 python-docx 和 markdown 相关库） import subprocess # 实际生产建议用 pandoc，稳定且支持复杂格式 subprocess.run(["pandoc", "input.md", "-o", "output.docx"], check=True)

逻辑说明：Markdown 转 Word 最稳的是 pandoc，它处理标题层级、表格、列表都比自己写解析强。Dify 代码节点里可以调外部命令，前提是容器里装了 pandoc。如果不想在容器里装，就把 Markdown 返回出来，在本地或另一个服务里转。

参数说明：pandoc 转换时可以用--reference-doc指定一个模板 docx，这样输出的字体、页边距、标题样式直接符合公司标书规范，省去后期排版。这一步是提效的关键，很多人忽略模板，结果生成完还要手动调格式，白省了。

4. 避坑与排查：标书工作流最容易翻车的五个地方

4.1 现象：知识库检索召回全是无关内容

原因：切分粒度太粗，一段里混了好几个主题，向量化后语义被平均掉了。或者相似度阈值设太低，把勉强沾边的都召回了。

解决：把招标文件库的切分粒度调到 300～500 字符，重叠 50；素材库按主题重新整理，一个文档只讲一件事。阈值从 0.5 起调，观察召回质量。Dify 知识库支持召回测试，改完切分先测一批再上工作流。

4.2 现象：LLM 生成内容里出现公司没有的资质和业绩

原因：提示词约束不够，或者召回了相似但属于别家公司的素材，模型顺手就编了。

解决：提示词里明确「只使用素材中的事实，缺失就写待补充」；素材库严格只放本公司资料；生成节点温度降到 0.3 以下。上线前必须人工抽检，这条没有后悔药，标书造假代价太大。

4.3 现象：工作流跑到一半卡住，worker 日志报超时

原因：迭代节点处理几十个评分点，每个都调 LLM，总时长超过默认超时；或者某个 LLM 调用卡住没返回。

解决：把长任务拆成多批，或者调大 worker 的超时配置。Dify 的异步任务在 worker 里跑，.env里相关超时参数可以调。另外给 LLM 节点设重试次数，偶发失败自动重试比整个工作流挂掉强。

4.4 现象：上传 PDF 后知识库一直显示「处理中」或报解析错误

原因：扫描件没有文字层，或者 Unstructured API 没配。热词里那个unstructured api url is not configured就是这个。

解决：扫描件先 OCR 再上传；需要 Unstructured 的在.env里配好服务地址。实在搞不定解析，就本地用工具把 PDF 转成 txt 或 docx 再传，绕开解析器。

4.5 现象：Docker 部署后访问报 SSL 错误或证书问题

原因：前面挂了 Nginx 或反向代理，证书配置和 Dify 的端口转发没对齐。热词里dify ssl错误属于高频。

解决：先确认直连 IP 端口能访问，排除 Dify 本身问题；再查反向代理的证书路径和proxy_pass指向。内网使用其实可以先用 HTTP，证书问题留到对外时再处理，别在部署阶段卡太久。

5. 让生成质量再上一档：模板锚定与人工回填的配合技巧

工作流跑通只是及格线，真正决定标书能不能用的是「生成内容像不像你们公司写的」。我踩过的最大坑是：AI 生成的东西语法没问题，但读起来就是不像自家标书，评标专家一眼能看出拼接感。解决办法是模板锚定——在素材库里放几份公司写得最好的历史标书章节，生成时不仅召回事实素材，还召回「写作风格样本」，在提示词里要求模仿其语气和结构。

具体做法是在生成节点的提示词里加一段：

请参考以下公司历史标书的写作风格（语气、句式、专业术语习惯）， 但不要照抄其中的具体项目信息： {{#style_samples#}}

风格样本从素材库里单独检索，查询词用评分点名称加「方案 范例」。这样生成出来的文字会带上公司的表达习惯，人工润色量能少一半。

另一个技巧是人工回填闭环。工作流输出里那些标记「待人工补充」的章节，人工补完后不要丢掉，定期把这些补充内容清洗后回灌到素材库。跑几个项目后，素材库越来越厚，待补充的地方越来越少，这才是这条工作流真正的复利所在。我一般建议每完成一个项目做一次回灌，坚持三个月效果就很明显。

验证生成质量别只看通顺度，要拿评分标准逐条对：每个评分点是否都有对应章节、分值高的项篇幅是否够、有没有出现素材库里不存在的事实。我习惯在最终输出前加一个人工检查清单，把这三条过一遍再交。这套流程跑顺之后，一份 60 页技术标的初稿从两天压到半天，剩下半天做判断和润色，比全程手写踏实得多。希望帮到你。

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