一、Agent讲清楚了但搭出来的门槛还没降前六篇拆了一条完整链路Prompt→RAG→LangChain→Agent。每一步的原理、适配、落地坑都讲透了。但交付现场有个现实问题客户说给我搭一个试试你跟他说我需要先搭LangChain环境、写Python代码、配置向量数据库、编排Agent工作流——客户听完就走了。不是每个场景都值得从代码开始搭。很多客户需求本质是先验证这个场景AI能不能做——快速搭原型、拿客户数据跑通、确认效果可行再决定要不要工程化。Gartner预测2026年75%的新应用将基于低代码平台构建。趋势很明确低代码不是偷懒是效率。问题是低代码平台降低了门槛但FDE的理解门槛不能跟着降——你必须穿透可视化界面知道黑盒里面在干什么、问题出在哪里。本篇拆两个主流平台Coze和Dify。不是平台教程而是FDE视角的平台选型与落地判断。二、低代码平台是什么把写代码变成拖积木传统开发链路需求→写代码→调模型→搭RAG→编排Agent→测试→上线。周期以周计。低代码平台链路需求→拖组件→配参数→测试→上线。周期以天计甚至以小时计。本质把Prompt、RAG、工具调用、Agent编排这些在前六篇一个一个拆开讲的能力打包成可视化组件。你拖一个知识检索节点到画布上它底层帮你跑分块向量化检索重排——你看不到细节但效果是这些能力的集成。不是替代代码是封装代码。封装越厚搭建越快但出问题时越需要有人能穿透封装定位根因。这个人就是FDE。三、Coze vs Dify两个平台两种定位维度CozeDify核心定位零代码智能体开发平台低代码LLM应用开发平台使用门槛极低——拖拽配置无需编程低——需理解工作流和节点概念知识库内置配置简单内置RAG可精细调优分块/索引/召回工作流可视化编排偏业务逻辑Chatflow/Workflow偏技术链路模型支持平台内集成多模型开箱即用自由接入任意模型APIOpenAI/国产/Ollama适合场景快速搭建问答Bot、客服助手企业级RAG、Text2SQL、数据分析部署方式云端版/开源本地部署Apache 2.0开源自部署FDE的选型判断客户要快——两天内出Demo→Coze。零代码拖拽写Prompt建知识库挂载最快1小时搭完一个智能客服Bot。客户要深——知识库需要调分块策略、检索要加Rerank、流程要有条件分支→Dify。工作流编排粒度更细每个环节可独立配置和优化。客户要安全——数据不能出内网→两个平台都支持本地部署。Coze 2025年7月开源Apache 2.0协议可商用Dify一直是开源的。2核4G即可部署硬件门槛极低。实际项目中Coze做快速验证Dify做深度交付。两个平台不是替代关系是适配不同场景。四、Coze实战1小时搭一个智能家居问答助手Coze的核心逻辑创建Bot→写人设→建知识库→挂载→测试→发布。全程零代码。第一步创建Bot。命名功能描述1分钟。第二步写人设与回复逻辑。在人设与回复逻辑中写系统提示词——定义角色、回答范围、边界。比如你是智能家居客服只回答设备相关问题不回答无关内容。第三篇讲的Prompt五原则在这里直接写进去。第三步建知识库。上传产品手册、设备说明书等文档。Coze自动完成分块和索引。这是关键步骤——分块设置决定检索质量不调好后面全白搭。第四步挂载知识库。把知识库关联到Bot上对话时自动检索。第五步测试发布。调试对话效果一键发布到多渠道。看起来简单但FDE必须知道一个坑Coze默认的分块策略是递归文本分割基本按段落和固定字数硬切句子可能被拦腰斩断、语义断裂。第四篇讲过分块不当是RAG最大坑之一——在Coze里这个问题同样存在只是被界面封装了你看不到。FDE的价值客户用Coze搭了Bot说效果不好你得知道问题可能出在分块——去知识库设置里调分段策略而不是换个平台重来。五、Dify实战从知识库问答到Text2SQLDify比Coze深在工作流编排。每个环节是一个节点节点之间用线连接数据从上游节点流向下游节点。5.1 知识库问答工作流最基础的链路开始节点→知识检索节点→LLM节点→回答节点。四步搭完一个RAG问答。进阶版加意图识别用户输入进来先判断是闲聊还是专业问题还是转人工——不同意图走不同路径。闲聊直接给通用LLM专业问题走RAG检索再生成转人工触发通知。配置项选项FDE选择分段模式通用模式/父子模式父子模式——父段落检索子段落送模型兼顾精度与上下文索引方式高质量/经济复杂问答用高质量向量索引FAQ用经济关键词检索方式向量/全文/混合混合检索——向量召回语义相关关键词补充精确匹配Rerank开/关必须开——二次排序把最相关提到前面检索质量直接上一档Top-K3-103-5够了太多噪声大、成本高FDE判断Dify的知识库配置比Coze精细得多每个参数都在教程第四篇RAG里讲过——分块策略、索引模式、检索方式、重排序。区别是以前写代码配置现在在界面上选。但选错了效果一样差理解不能跟着界面简化。5.2 Text2SQL自然语言直接查数据库RAG的痛点之一统计类问题逐片段检索效率低。问上月销量最高的地区是哪个知识库里没有实时数据RAG答不了。Text2SQL换了一条路自然语言→LLM生成SQL→数据库执行→结果解读。不检索文档直接查数据库。Dify工作流开始节点→时间插件注入当前日期→LLM节点自然语言转SQL→代码节点提取纯SQL→数据库节点执行查询→LLM节点结果解读→回答节点。关键Prompt设计系统提示词必须包含完整的数据库表结构定义DDL、字段业务含义、当前时间处理上月今年等相对时间以及输出格式约束——仅输出可执行SQL不附带解释。踩坑五条LLM可能输出带markdown标记的SQL→代码节点必须清洗去掉sql包裹表结构必须完整准确→缺一个字段SQL就报错相对时间必须注入→不注入上月就不知道是哪个月安全红线→数据库只读权限禁止INSERT/UPDATE/DELETESQL为空时的兜底→不能让工作流直接崩必须有异常分支5.3 数据分析平台自然语言生成图表在Text2SQL基础上再往前一步查询结果不是返回文字而是自动生成可视化图表。工作流自然语言→LLM生成SQL→执行→LLM将数据转为ECharts配置JSON→ECharts插件渲染图表→回答节点输出图表文字解读。用户输入请查询各地区销售额并生成柱状图——系统自动完成SQL→查询→图表→解读全程零代码。两种ECharts集成方式Dify市场一键安装ECharts插件简单快捷或代码执行节点自定义图表样式灵活但需写Python。FDE实战点数据分析平台是低代码的杀手级场景——非技术人员用自然语言完成以前需要数据分析师BI工具才能做的事。这个场景在客户现场极其容易Demo出效果是FDE快速验证场景可行性的利器。六、RAG三大痛点在低代码平台中的解法第四篇详细讲了RAG的落地坑在低代码平台里这些问题依然存在但解法变成了配置而非写代码。痛点传统解法写代码低代码解法配参数分块粗暴语义断裂自定义分块函数Dify选父子模式CherryStudio切换语义分块检索不准返回不匹配混合检索Rerank代码Dify检索方式选混合开启Rerank节点统计类问题答不了写SQL查询接口Dify搭Text2SQL工作流绕开RAG走数据库痛点没变解法的门槛降了。但FDE必须理解选混合检索不是因为菜单里有个选项而是因为你理解关键词检索和语义检索各有所长、混合互补。理解在前选择在后。在低代码平台里不理解原理的配置者和理解的配置者做出来的是两个东西。七、FDE的终极判断低代码是加速器不是替代品低代码平台对FDE的四层价值第一层快速验证。客户说我想用AI做XX以前需要一周搭原型。现在用Coze或Dify半天搭完拿客户数据跑一遍能做就做不能做趁早换方向。先验证再交付——这个原则从第五篇讲到现在低代码平台是最佳的验证工具。第二层降低交付门槛。不是每个客户项目都需要从零写代码。简单问答场景、知识库场景低代码平台直接交付。省下开发资源投入复杂项目。第三层可视化沟通。客户看不到代码但能看到工作流图——节点怎么排、数据怎么流、条件怎么分。这是跟业务人员沟通的最佳语言比PPT讲架构图有效十倍。第四层穿透封装。这是最关键的——低代码封装得越厚FDE越需要穿透。客户搭了Dify说效果不好你得判断是分块问题还是检索问题还是Prompt问题还是模型选错了。不知道底层原理就只能在界面上瞎调。FDE不必成为开发者但必须成为配置者调试者——知道分块怎么调、检索怎么优化、Prompt怎么写、工作流怎么排。八、技术栈决策框架终局版七篇系列收官完整技术栈层级解决什么什么时候用Prompt怎么回答场景简单、数据稳定RAG凭什么回答需要知识检索、有文档依据LangChain怎么串起来从原型到工程的链路Agent怎么干起来需要自主决策、工具编排低代码平台怎么快起来快速验证、降低交付门槛不是每层都得上。FDE的核心价值从第一天就没变过为这个场景选最适配的技术组合——不是会用所有技术不是追最新的技术而是用最合适的技术把效果调到客户满意。从Prompt到低代码技术栈逐步升级但FDE的底层判断逻辑始终如一适配适配适配。九、总结七篇系列走到终点一条完整链路从原理到落地Prompt解决了怎么回答——FDE的第一道门槛。RAG解决了凭什么回答——FDE对抗幻觉的工程武器。LangChain解决了怎么串起来——FDE从原理到落地的工程骨架。Agent解决了怎么干起来——FDE打通落地的最后一公里。低代码平台解决了怎么快起来——FDE从原型到交付的加速器。但加速器不能替代驾驶员。低代码平台封装了技术复杂度FDE对底层原理的理解不能随之简化——因为封装越厚出问题时越需要有人能穿透定位根因。模型内卷无出路落地能力定输赢。而落地能力的终极形态就是把每一层适配做到位——从Prompt到低代码没有捷径只有精准。
一、Agent讲清楚了但搭出来的门槛还没降前六篇拆了一条完整链路Prompt→RAG→LangChain→Agent。每一步的原理、适配、落地坑都讲透了。但交付现场有个现实问题客户说给我搭一个试试你跟他说我需要先搭LangChain环境、写Python代码、配置向量数据库、编排Agent工作流——客户听完就走了。不是每个场景都值得从代码开始搭。很多客户需求本质是先验证这个场景AI能不能做——快速搭原型、拿客户数据跑通、确认效果可行再决定要不要工程化。Gartner预测2026年75%的新应用将基于低代码平台构建。趋势很明确低代码不是偷懒是效率。问题是低代码平台降低了门槛但FDE的理解门槛不能跟着降——你必须穿透可视化界面知道黑盒里面在干什么、问题出在哪里。本篇拆两个主流平台Coze和Dify。不是平台教程而是FDE视角的平台选型与落地判断。二、低代码平台是什么把写代码变成拖积木传统开发链路需求→写代码→调模型→搭RAG→编排Agent→测试→上线。周期以周计。低代码平台链路需求→拖组件→配参数→测试→上线。周期以天计甚至以小时计。本质把Prompt、RAG、工具调用、Agent编排这些在前六篇一个一个拆开讲的能力打包成可视化组件。你拖一个知识检索节点到画布上它底层帮你跑分块向量化检索重排——你看不到细节但效果是这些能力的集成。不是替代代码是封装代码。封装越厚搭建越快但出问题时越需要有人能穿透封装定位根因。这个人就是FDE。三、Coze vs Dify两个平台两种定位维度CozeDify核心定位零代码智能体开发平台低代码LLM应用开发平台使用门槛极低——拖拽配置无需编程低——需理解工作流和节点概念知识库内置配置简单内置RAG可精细调优分块/索引/召回工作流可视化编排偏业务逻辑Chatflow/Workflow偏技术链路模型支持平台内集成多模型开箱即用自由接入任意模型APIOpenAI/国产/Ollama适合场景快速搭建问答Bot、客服助手企业级RAG、Text2SQL、数据分析部署方式云端版/开源本地部署Apache 2.0开源自部署FDE的选型判断客户要快——两天内出Demo→Coze。零代码拖拽写Prompt建知识库挂载最快1小时搭完一个智能客服Bot。客户要深——知识库需要调分块策略、检索要加Rerank、流程要有条件分支→Dify。工作流编排粒度更细每个环节可独立配置和优化。客户要安全——数据不能出内网→两个平台都支持本地部署。Coze 2025年7月开源Apache 2.0协议可商用Dify一直是开源的。2核4G即可部署硬件门槛极低。实际项目中Coze做快速验证Dify做深度交付。两个平台不是替代关系是适配不同场景。四、Coze实战1小时搭一个智能家居问答助手Coze的核心逻辑创建Bot→写人设→建知识库→挂载→测试→发布。全程零代码。第一步创建Bot。命名功能描述1分钟。第二步写人设与回复逻辑。在人设与回复逻辑中写系统提示词——定义角色、回答范围、边界。比如你是智能家居客服只回答设备相关问题不回答无关内容。第三篇讲的Prompt五原则在这里直接写进去。第三步建知识库。上传产品手册、设备说明书等文档。Coze自动完成分块和索引。这是关键步骤——分块设置决定检索质量不调好后面全白搭。第四步挂载知识库。把知识库关联到Bot上对话时自动检索。第五步测试发布。调试对话效果一键发布到多渠道。看起来简单但FDE必须知道一个坑Coze默认的分块策略是递归文本分割基本按段落和固定字数硬切句子可能被拦腰斩断、语义断裂。第四篇讲过分块不当是RAG最大坑之一——在Coze里这个问题同样存在只是被界面封装了你看不到。FDE的价值客户用Coze搭了Bot说效果不好你得知道问题可能出在分块——去知识库设置里调分段策略而不是换个平台重来。五、Dify实战从知识库问答到Text2SQLDify比Coze深在工作流编排。每个环节是一个节点节点之间用线连接数据从上游节点流向下游节点。5.1 知识库问答工作流最基础的链路开始节点→知识检索节点→LLM节点→回答节点。四步搭完一个RAG问答。进阶版加意图识别用户输入进来先判断是闲聊还是专业问题还是转人工——不同意图走不同路径。闲聊直接给通用LLM专业问题走RAG检索再生成转人工触发通知。配置项选项FDE选择分段模式通用模式/父子模式父子模式——父段落检索子段落送模型兼顾精度与上下文索引方式高质量/经济复杂问答用高质量向量索引FAQ用经济关键词检索方式向量/全文/混合混合检索——向量召回语义相关关键词补充精确匹配Rerank开/关必须开——二次排序把最相关提到前面检索质量直接上一档Top-K3-103-5够了太多噪声大、成本高FDE判断Dify的知识库配置比Coze精细得多每个参数都在教程第四篇RAG里讲过——分块策略、索引模式、检索方式、重排序。区别是以前写代码配置现在在界面上选。但选错了效果一样差理解不能跟着界面简化。5.2 Text2SQL自然语言直接查数据库RAG的痛点之一统计类问题逐片段检索效率低。问上月销量最高的地区是哪个知识库里没有实时数据RAG答不了。Text2SQL换了一条路自然语言→LLM生成SQL→数据库执行→结果解读。不检索文档直接查数据库。Dify工作流开始节点→时间插件注入当前日期→LLM节点自然语言转SQL→代码节点提取纯SQL→数据库节点执行查询→LLM节点结果解读→回答节点。关键Prompt设计系统提示词必须包含完整的数据库表结构定义DDL、字段业务含义、当前时间处理上月今年等相对时间以及输出格式约束——仅输出可执行SQL不附带解释。踩坑五条LLM可能输出带markdown标记的SQL→代码节点必须清洗去掉sql包裹表结构必须完整准确→缺一个字段SQL就报错相对时间必须注入→不注入上月就不知道是哪个月安全红线→数据库只读权限禁止INSERT/UPDATE/DELETESQL为空时的兜底→不能让工作流直接崩必须有异常分支5.3 数据分析平台自然语言生成图表在Text2SQL基础上再往前一步查询结果不是返回文字而是自动生成可视化图表。工作流自然语言→LLM生成SQL→执行→LLM将数据转为ECharts配置JSON→ECharts插件渲染图表→回答节点输出图表文字解读。用户输入请查询各地区销售额并生成柱状图——系统自动完成SQL→查询→图表→解读全程零代码。两种ECharts集成方式Dify市场一键安装ECharts插件简单快捷或代码执行节点自定义图表样式灵活但需写Python。FDE实战点数据分析平台是低代码的杀手级场景——非技术人员用自然语言完成以前需要数据分析师BI工具才能做的事。这个场景在客户现场极其容易Demo出效果是FDE快速验证场景可行性的利器。六、RAG三大痛点在低代码平台中的解法第四篇详细讲了RAG的落地坑在低代码平台里这些问题依然存在但解法变成了配置而非写代码。痛点传统解法写代码低代码解法配参数分块粗暴语义断裂自定义分块函数Dify选父子模式CherryStudio切换语义分块检索不准返回不匹配混合检索Rerank代码Dify检索方式选混合开启Rerank节点统计类问题答不了写SQL查询接口Dify搭Text2SQL工作流绕开RAG走数据库痛点没变解法的门槛降了。但FDE必须理解选混合检索不是因为菜单里有个选项而是因为你理解关键词检索和语义检索各有所长、混合互补。理解在前选择在后。在低代码平台里不理解原理的配置者和理解的配置者做出来的是两个东西。七、FDE的终极判断低代码是加速器不是替代品低代码平台对FDE的四层价值第一层快速验证。客户说我想用AI做XX以前需要一周搭原型。现在用Coze或Dify半天搭完拿客户数据跑一遍能做就做不能做趁早换方向。先验证再交付——这个原则从第五篇讲到现在低代码平台是最佳的验证工具。第二层降低交付门槛。不是每个客户项目都需要从零写代码。简单问答场景、知识库场景低代码平台直接交付。省下开发资源投入复杂项目。第三层可视化沟通。客户看不到代码但能看到工作流图——节点怎么排、数据怎么流、条件怎么分。这是跟业务人员沟通的最佳语言比PPT讲架构图有效十倍。第四层穿透封装。这是最关键的——低代码封装得越厚FDE越需要穿透。客户搭了Dify说效果不好你得判断是分块问题还是检索问题还是Prompt问题还是模型选错了。不知道底层原理就只能在界面上瞎调。FDE不必成为开发者但必须成为配置者调试者——知道分块怎么调、检索怎么优化、Prompt怎么写、工作流怎么排。八、技术栈决策框架终局版七篇系列收官完整技术栈层级解决什么什么时候用Prompt怎么回答场景简单、数据稳定RAG凭什么回答需要知识检索、有文档依据LangChain怎么串起来从原型到工程的链路Agent怎么干起来需要自主决策、工具编排低代码平台怎么快起来快速验证、降低交付门槛不是每层都得上。FDE的核心价值从第一天就没变过为这个场景选最适配的技术组合——不是会用所有技术不是追最新的技术而是用最合适的技术把效果调到客户满意。从Prompt到低代码技术栈逐步升级但FDE的底层判断逻辑始终如一适配适配适配。九、总结七篇系列走到终点一条完整链路从原理到落地Prompt解决了怎么回答——FDE的第一道门槛。RAG解决了凭什么回答——FDE对抗幻觉的工程武器。LangChain解决了怎么串起来——FDE从原理到落地的工程骨架。Agent解决了怎么干起来——FDE打通落地的最后一公里。低代码平台解决了怎么快起来——FDE从原型到交付的加速器。但加速器不能替代驾驶员。低代码平台封装了技术复杂度FDE对底层原理的理解不能随之简化——因为封装越厚出问题时越需要有人能穿透定位根因。模型内卷无出路落地能力定输赢。而落地能力的终极形态就是把每一层适配做到位——从Prompt到低代码没有捷径只有精准。
