一、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：两个平台，两种定位

维度	Coze	Dify
核心定位	零代码智能体开发平台	低代码LLM应用开发平台
使用门槛	极低——拖拽+配置，无需编程	低——需理解工作流和节点概念
知识库	内置，配置简单	内置RAG，可精细调优分块/索引/召回
工作流	可视化编排，偏业务逻辑	Chatflow/Workflow，偏技术链路
模型支持	平台内集成多模型，开箱即用	自由接入任意模型API（OpenAI/国产/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实战：从知识库问答到Text2SQL

Dify比Coze深在工作流编排。每个环节是一个"节点"，节点之间用线连接，数据从上游节点流向下游节点。

5.1 知识库问答工作流

最基础的链路：开始节点→知识检索节点→LLM节点→回答节点。四步搭完一个RAG问答。

进阶版加意图识别：用户输入进来先判断是"闲聊"还是"专业问题"还是"转人工"——不同意图走不同路径。闲聊直接给通用LLM，专业问题走RAG检索再生成，转人工触发通知。

配置项	选项	FDE选择
分段模式	通用模式/父子模式	父子模式——父段落检索，子段落送模型，兼顾精度与上下文
索引方式	高质量/经济	复杂问答用高质量（向量索引），FAQ用经济（关键词）
检索方式	向量/全文/混合	混合检索——向量召回语义相关，关键词补充精确匹配
Rerank	开/关	必须开——二次排序把最相关提到前面，检索质量直接上一档
Top-K	3-10	3-5够了，太多噪声大、成本高

FDE判断：Dify的知识库配置比Coze精细得多，每个参数都在教程第四篇RAG里讲过——分块策略、索引模式、检索方式、重排序。区别是以前写代码配置，现在在界面上选。但选错了效果一样差，理解不能跟着界面简化。

5.2 Text2SQL：自然语言直接查数据库

RAG的痛点之一：统计类问题逐片段检索效率低。问"上月销量最高的地区是哪个"，知识库里没有实时数据，RAG答不了。

Text2SQL换了一条路：自然语言→LLM生成SQL→数据库执行→结果解读。不检索文档，直接查数据库。

Dify工作流：开始节点→时间插件（注入当前日期）→LLM节点（自然语言转SQL）→代码节点（提取纯SQL）→数据库节点（执行查询）→LLM节点（结果解读）→回答节点。

关键Prompt设计：系统提示词必须包含完整的数据库表结构定义（DDL）、字段业务含义、当前时间（处理"上月""今年"等相对时间），以及输出格式约束——仅输出可执行SQL，不附带解释。

踩坑五条：

1. LLM可能输出带markdown标记的SQL→代码节点必须清洗，去掉`sql包裹
2. 表结构必须完整准确→缺一个字段SQL就报错
3. 相对时间必须注入→不注入"上月"就不知道是哪个月
4. 安全红线→数据库只读权限，禁止INSERT/UPDATE/DELETE
5. SQL为空时的兜底→不能让工作流直接崩，必须有异常分支

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到低代码，没有捷径，只有精准。