上次带一个刚开始做AI产品的新人熟悉全流程他问我想做个内部知识问答机器人最快需要多久我说如果只做最简版本不加花活一个下午就能跑通。他没有信结果我们一起创建、调优、发布到能分享给同事用确实没用完半天。他盯着浏览器里的对话窗口愣了几秒然后说了一句“我之前觉得这至少得折腾一两周。”这就是Dify这类低代码AI应用平台的价值它不是让你“少写代码”而是把整个AI应用从模型接入、提示词编排、知识库挂载到对外发布的部分都整合到一个可视化环境里。今天这篇就围绕“Dify第一个应用”展开完整记录从零开始创建和发布一个AI可用的应用包括每一步的选择逻辑、参数配置、踩坑复盘。无论你是完全没接触过LLM的运营同学还是写过不少Python的开发者都能照着操作并理解每一步背后的原因。1. 开始之前为什么要用Dify搭你的第一个AI应用很多人第一次接触AI应用开发时有个误区觉得要做AI应用就必须从模型API对接开始写代码。能用SDK调用当然可以但那只是“调接口”离真正的“应用”还差很远。你需要考虑提示词放哪里、用户输入怎么传、上下文怎么管理、历史记录怎么留存、权限怎么控制、界面怎么给到用户。这些需求在纯代码环境里要全部自己造轮子。Dify解决的正是这一层问题。它把常见的“LLM应用开发链路”——模型供应商配置、提示词编排、上下文管理、知识库接入、插件、发布渠道——做成了可视化的平台。开发者可以在里面把应用拼出来也可以用它的API接口把应用嵌入到自己的系统里。对于第一个项目来说合适的路线是先在可视化界面里把逻辑跑通再考虑要不要走代码路线。它的定位更像是“AI应用的操作系统”应用类型、模型、提示词、内置变量、外部渠道、权限管理都是“组件”你可以自由组合。相比直接用LangChain这类框架Dify最大的优势是门槛低、反馈快——你在界面上改一句提示词点保存立刻就能在调试窗口看到效果变化。这种即时反馈对调优非常重要。我用它做过的第一个正式应用就是一个内部咨询助手。当时带着一个明确目标让同事通过网页对话问一些常见制度与流程问题AI用我们提供的资料回答答不上来的能引导联系人工。这类需求如果走代码路线从建立对话上下文到写后端接口再到搭前端页面保守估计一周。但用Dify当天下午就交付了可用的版本。所以我的建议是如果你正处于“想做一个AI应用但不确定从哪开始”的阶段直接拿Dify开一道。它不是玩具生产环境也完全够用。要做的第一件事不是写代码而是把思路想清楚这个应用要服务谁、对话场景是什么、回答需要限定在哪个范围内。想清楚这几件事后面的操作会顺手很多。2. 环境准备与基础认知部署、模型接入、三个核心概念2.1 部署方式选择云端版与自部署如果你急着体验最直接的方式是使用云端版本注册完就能进工作台省去安装的时间。但如果你对数据有自己的要求或者想把这个应用给内部特定人群持久使用我更建议自部署。两个选择其实不冲突先用云端跑通逻辑摸熟操作之后再在本地环境搭一套。自己部署Dify最常用的方式是Docker Compose。前提是机器上装了Docker和Docker Compose然后拉取项目代码在项目根目录执行这个cd dify cp .env.example .env docker compose up -d第一次启动会拉取一堆镜像包括API服务、Worker、数据库、缓存中间件等时间取决于网络环境可能需要几分钟到十几分钟。启动完成后访问服务器的HTTP端口就能看到安装引导页设置管理员账号即可进入。自部署的优势不止“数据在自己手里”这一项。你可以在环境变量里配置模型供应商的全局Key也可以让不同成员用自己的Key接入你还能在服务器上挂代理、接网关、做日志采集。对于企业环境这些都很关键。缺点也很明显你要自己维护一套数据库和中间件偶尔要处理升级、备份的问题。从我的实践来看建议这样安排个人学习和初期Demo直接用云端免费额度或订阅额度正式交付或者团队协作时仍然用自部署。因为自部署环境里权限拆分、应用共享、日志审计这些能力是团队使用的基础。2.2 模型接入Key的选择与参数认知Dify本身不带模型它是一个编排和调度层真正的“智力”来自你接入的大模型服务商。在“设置—模型供应商”里你可以配置各类模型服务商的API Key。这一层有个设计很值得说它把模型供应商和应用解耦了。意思是你在应用编排里指定用“哪个模型”但模型商家的Key只配置一次全局生效不需要每个应用重复填。第一个应用建议选一个能力均衡、成本可控的通用对话模型。如果你有国内可直接访问的模型服务直接用它们的APIKey如果是开源模型厂商或者国际服务商配置也类似区别主要在Base URL和Key字段。下面是常见配置项的含义配置项含义建议API Key调用模型的凭证注意保管别提交到公开仓库Base URLAPI请求地址自建网关或中转时需要修改模型名称具体调用的模型标识要和服务商控制台里的名字完全一致一个常见误区是把模型名称填错。比如控制台里叫“某模型V2”你在Dify里填“某模型V2.0”结果必然报错。这类问题的排查思路很简单回到模型服务商的控制台把准确的名字复制过来而不是凭记忆输入。关于参数第一次写应用时最容易忽略的是“温度”这个参数。它控制在生成文本时的随机性调低一点回答更稳定、更贴合提示词设定调高一点更有发散性但容易跑题。做客服、知识问答类应用建议温度设置在0.3左右做创意文案、头脑风暴类应用可以调到0.7以上。后面调试时嫌回答太死板或太飘优先改的就是这个值。2.3 三个核心概念应用类型、编排方式、插件与工具进入Dify工作台创建应用时会看到几种应用类型聊天助手、文本生成、Agent、工作流。对第一个应用来说最常选的是“聊天助手”。它的特点是多轮对话、有上下文管理、适合交互式的问答场景。文本生成则适合一次性输出文章、摘要、翻译等没有多轮概念。Agent会在聊天基础上加入工具调用能力让模型可以调外部API、查数据库。工作流则更偏底层你可以把节点拖拽成一条组装线控制每一步的输入输出。对于刚入门的人我的建议是第一个应用选“聊天助手”不要一上来就挑战工作流。原因很简单聊天助手的编排界面自带完整的提示词、上下文、变量配置足够覆盖大部分QA场景。等你理解了“提示词—变量—上下文”这三者的关系之后再看工作流的节点式编排会轻松很多。插件和工具则是进阶功能。聊天助手可以挂载知识库检索插件也可以挂一些自定义API工具。第一个应用如果只是“有问必答”可以暂时不碰这些东西。先跑通主流程后面在第五节我会讲怎么给它加上“只回答指定知识库内容”的约束。3. 创建第一个聊天助手手动从0到1的实操全过程3.1 进入创建流程与基础信息配置登录后点击“创建应用”选择“聊天助手”给它起一个有意义的名字比如“内部制度问答助手”。应用类型选定后先不用纠结后面可以在应用设置里转换类型只是转换会丢失部分编排所以初期还是先想清楚。进入编排界面后会看到左侧是应用编排区、右侧是预览调试窗口。这个“左边配置、右边立刻生效”的布局是整个产品最舒服的地方。你改的每一行提示词、每一个变量右侧都能实时模拟对话并给出反馈不需要等编译、不需要刷新页面。第一步先做基础配置设置“对话名称”和“对话描述”。描述建议写清楚“这个助手能做什么、不能做什么”例如“仅回答关于公司制度的问题不闲聊、不回答无关内容”。这段描述会在多个地方被读取——包括模型预处理的上下文里。很多新手忽略这一点但好的描述能显著减少非法提问的出现。3.2 模型选择与对话状态配置在编排界面里找到“模型”一栏选择你配置好的模型。如果没配置任何模型这里会是空的需要先回到模型供应商页面完成接入。选好模型后系统会给出几个参数开关温度、最大回答长度、上下限等。这些参数在前文提过这里重点说一个“对话状态”里的注意点。“对话状态”里可以开启“记忆”功能让多轮对话时模型能记住前文。默认开启一定轮数或自动管理。这里要强调的是记忆会占用模型的上下文窗口轮数越长消耗越大。做一个知识问答类应用建议把记忆轮数控制在4到6轮既能满足多轮追问的需求又不至于浪费上下文空间。如果用户问的长文本动辄几百字还可以考虑调整成“保留摘要”让模型把历史对话做压缩摘要再参与后续对话。3.3 系统提示词设计决定应用上限的关键一步在“提示词”编辑框里要做的事情是给模型定义一个“人设能力约束”。这是整个应用最核心的一步。很多第一次接触Dify的人会顺手写一句话“你是一个问答助手”结果效果非常普通。实际上系统提示词设计得越具体、越结构化模型的行为越可控。以下是我用过的提示词结构分享出来供参考你是公司的内部制度咨询助手名称小度。 你的任务基于知识库内容回答员工关于考勤、报销、请假、绩效等制度问题。 回答规则 1. 优先参考知识库内容引用相关条目并说明出处 2. 如果知识库中没有对应内容请明确回答“抱歉我没有找到相关资料”并提供人工咨询联系方式 3. 如果用户提出与制度无关的问题礼貌拒绝并引导回主题 4. 回答做到简洁、条理清晰优先使用列表或短段落 5. 不要编造制度和数值不确定的内容不要猜测。这个结构的关键在于“约束前置”。它明确告诉模型你有边界你不能答的就别答千万别编。实际运行中这句话能把幻觉率压得非常低。模型是对概率做采样你越明确告诉它哪些话不能说、哪些行为不能做它就越不容易越界。写提示词时多用“不要”“只能”“必须”这类强约束词比“请尽量”强得多。另外要注意提示词里的“不要”类指令要具体。比如写“不要编造”模型可能会在部分场景忽略写“如果知识库中没有对应内容请明确回答‘抱歉我没有找到相关资料’并提供人工联系方式”模型就知道具体该做什么、说什么。把行为指令和可执行动作绑定在一起准确率会高很多。3.4 内置变量与用户输入让应用能“记住”你是谁第一次运行聊天助手时你会发现对话体验相对“发散”。想让回答更贴合业务就要引入“内置变量”。Dify默认提供几个系统变量比如当前时间、用户ID、对话ID。你可以把它们塞进提示词里让模型获得更多上下文回答更自然。更常用的做法是添加一个自定义变量。比如在用户首次发消息时让系统收集用户的“部门”或“身份”提示词里这样引用用户所在部门{{department}} 如果用户询问的问题不属于该部门职能范围请在回答中提示其咨询对口部门。这个变量需要在“对话开场白”或“流程配置”中绑定。Dify的编排界面允许你在右侧预览窗口先以“用户身份”模拟对话。变量没有填充时模型读取到的是空字符串可能会导致异常回答所以最好在提示词里加一句兜底话术比如“如果部门为空可不做限制”。这一处细节在后期实测中非常频繁出现值得留意。3.5 调试预览与迭代从“回答能用”到“回答很稳”点击右侧“调试”按钮就能以用户身份和你的AI应用对话了。第一次测试建议从最简单的提问开始逐步补充边界情况。比如问“报销额度怎么算”再问“我没听清楚再讲一遍”再问“昨天的股市怎么样”。逐条检查模型回复是否符合提示词里的约束。调试窗口右上角有一个“对话记录”和“上下文”面板可以查看当前对话给模型传了哪些内容。如果你的提示词里引用了变量这里会显示变量的值方便排查为什么某次回答跑偏。调试界面还有“模型参数”的即时调节功能改完保存再测能快速对比不同参数下的效果。这个调试迭代过程是整个开发中最花时间的环节。我的习惯是准备一张测试对照表正常提问、离题提问、含敏感词提问、空输入提问、超长文本提问。每个类型测5次把回答结果记录下来。出现问题时回到提示词看是“约束不够”还是“参数太高”还是“上下文缺失”逐项排除。4. 发布上线让应用的部署与访问像开灯一样简单4.1 发布为Web应用一键生成可分享的对话页面编排调试通过后下一步就是发布。右上角点击“发布”按钮你会看到“更新”选项。这会为应用生成一个独立的在线访问链接该链接不需要登录Dify后台直接打开就能和AI对话。发布前建议检查一遍这些事项应用名和描述是否正确设置这会在页面标题和分享卡片里显示建议开启“保留开发者身份”选项这样你从分享页面进入时依然可以查看后端的一些调试信息确认“临时分享链接”开关是否符合预期。如果只是内部使用不建议开启匿名公开分享。发布后把链接发给几个朋友或同事让他们各自打开页面试了试。你可以问他们三个问题加载时间快不快、回答能不能满足需求、有没有回答反常识问题的“翻车”。这三条反馈能帮你在正式推广之前发现很多问题。我就是在这一轮测试中发现有个同事一句话带了好几个长尾词模型回答时上下文里没有识别出来最后靠调整内置变量和分段规则解决。4.2 访问凭证与API接入把应用的能力嵌入任何系统发布只能让普通用户通过网页版使用。更常见的项目需求是把对话能力嵌入自己的产品、公众号、企微、钉钉等。Dify为这类场景预留了API接入方式路径是“访问API密钥”页面。在这里你可以新建多个属于不同“调用者”的API密钥每个密钥可以独立控制权限、配额、频率。这样管理的好处是某个系统出问题时可以单点禁用对应密钥不影响其他调用方。密钥就像一张门禁卡每一张卡管一片区域。API兼容OpenAI接口风格用少量代码即可完成接入。以Python为例接入对话补全接口的核心代码如下import requests url 你的Dify地址/v1/chat-messages headers { Authorization: Bearer 你的应用密钥, Content-Type: application/json } payload { inputs: {}, query: 请帮我查一下报销流程, response_mode: blocking, conversation_id: , user: abc-123 } response requests.post(url, headersheaders, jsonpayload) print(response.json()[answer])这段代码的作用就是调用你刚刚编排好的应用。注意两点一是user字段建议用你的业务系统里的真实用户标识这样Dify能识别谁在提问日志里可追踪二是conversation_id首次为空返回结果里会带着后续对话要把它回传以维持多轮记忆。API接入的详细程度完全取决于你的需求。如果是内部工具一个简单的Python脚本就够如果是生产系统则需要考虑高并发、超时重试、限流、日志。Dify的API网关本身处理了大部分模型调用的排队和并发问题你只需要关注上游调用频率即可。4.3 嵌入页面与更多发布渠道Dify还提供“嵌入应用”功能可以给一行JavaScript代码直接把对话窗口嵌入到自己的网页里。若你的业务后台、官网、博客是用Web开发用这种方式能省掉不少前端开发时间。嵌入的方式有两种一种是以弹窗组件的形式点击浮标弹出聊天窗口另一种是直接以iframe方式嵌入到页面。选择哪种取决于页面布局弹窗不占页面空间iframe适合作为页面的一个独立面板。需要注意的是嵌入脚本只是“召唤”了云端应用的界面你的应用仍然需要保持对外发布状态。如果应用被下架或密钥被禁用嵌入的窗口也会随之无法工作。所以发布以后千万别忘了维护这个应用的“在线状态”。5. 进阶扩展为你的应用添加知识库与内置工具5.1 创建知识库与上传文档第一个聊天助手如果只靠模型自身的知识来回答问题效果会很飘。模型并不了解你公司的具体制度也不认识你产品背后的细节。要让回答更可靠正确的做法是给它挂一个知识库。路径是“知识库—创建空白数据集”上传文档后Dify会自动做文本切片、清洗、嵌入向量。嵌入向量这个概念稍微解释一下系统把你上传的文档切成一段段文本每段通过嵌入模型转换成一串数字向量之后用户提问时系统会把“理解后的提问向量”和这些“文档向量”做相似度比对找出最相关的段落。所以上传资料的质量、切片的粒度、查询的匹配度都会直接影响回答准确率。切片长度建议控制在400到600个字之间。太短会导致检索结果碎片化模型拼不出一段完整信息太长则会让检索结果包含太多无关内容稀释了关键信息权重。Dify提供了“自动分段”模式也可以手动调整分隔符和切片大小。我通常先自动分段再检查几个关键文档的切分点是否合理有明显断错的地方再手动切。5.2 让提示词与知识库联动配置好知识库后回到聊天助手的提示词编辑界面在“知识库”区域选中这个数据集。此时提示词里要相应改动明确要求模型“优先使用知识库内容回答”。一个常见错误是明明挂载了知识库提示词却还在说“请基于你的内部知识回答”导致模型绕过了检索结果自己发挥。你可以这样设置引用条件条件设置建议回答与检索结果不匹配时提示词中明确“如果检索不到相关知识回答‘暂无资料’”。多文档混合引用打开“引用并汇总”让模型综合多个片段作答。检索相似度阈值默认值即可回答质量差时再调高。这里还要提示一点知识库的更新频率和你业务的贴切程度直接相关。制度改版、文档新增后都要回到知识库重新上传或更新内容。否则检索到的永远是旧版资料回答反而误导人。5.3 内置工具与执行类应用聊天助手也能挂上“工具”比如通过网络请求查询某个接口的数据、发送通知到企业聊天工具等。这块再展开就要进入AI应用的高级玩法了对于第一个项目我建议可以了解启动方式在编排界面左侧“工具”区域添加一个HTTP请求工具配置请求URL和参数然后在提示词中描述工具的作用及触发规则。举个例子你做一个“订单查询助手”用户问“我的订单到哪了”模型可以把你传入的订单号拿来请求内部订单API再基于返回结果给用户一个一句话总结。这个场景中模型更像是一个“翻译官和信息路由”而不是“凭经验生成回答”。工具化让AI应用从只能说话变成能办事。6. 常见问题与避坑实战拿真实体验换来的排查清单以下问题是我和身边同事在使用Dify过程中反复遇到的按出现频率和对体验的影响程度排了序。可以说做完一个应用的成功率很大程度取决于你会不会处理下面这几类“小毛病”。6.1 首次访问缓慢与冷启动自部署后第一次从分享链接打开对话页面响应时间可能会很长。这不是应用本身出了问题而是容器环境在执行一些初始化操作比如拉取镜像首次运行模型相关的网络请求等。同样长时间无人访问后再次打开也会有一段重新初始化的加载过程。解决方法是设置容器为“始终运行”并在反向代理层做缓冲或者接受“偶发冷启动”的现实。如果你希望第一次访问就很流畅给服务器配置足够的CPU和内存、把数据库和缓存都纳入Docker Compose管理、并考虑加一层CDN或服务器端缓存。个人项目对延迟要求不高时可以忽略这条但团队正式使用最好处理一下。6.2 模型回答风格不稳定同一套提示词和参数两次回答风格截然不同。原因通常是“温度”设置太高或者没有在提示词里固定回答风格。建议把温度从默认值调到0.4或更低同时在提示词里加上一句“始终保持正式、简洁、客观的语气”。把风格写进提示词降温和约束双管齐下。还有一种情况是多轮对话后风格漂移。原因是模型在后几轮对话里被用户带了节奏。解决办法是调整记忆轮数并在系统提示词里强调“无论用户说什么你都保持初始设定的语气”。如果还是不稳定把“记忆”改成“保留摘要”只保留关键信息不带情绪性对话。6.3 密钥失效与权限问题密钥失效在自部署环境里时有发生。最常见的原因是首次创建应用时用了临时环境变量生成容器重启后与后台存储的密钥不同步。建议在正式使用前创建专门的应用密钥不要依赖默认值。密钥权限控制也值得注意“阅读理解”密钥只能读数据适合给只读场景完整的“写入密钥”则适合可对话、可创建会话的调用方。按需分配权限别图省事全开。另一个隐藏风险是密钥被提交到公开仓库。有些朋友把API密钥写死在代码里后一键push很快就能收到账单通知。如果你发现这种事故第一件事就是撤回密钥、禁用泄漏的Key然后再去改仓库历史里的硬编码字符。6.4 上下文窗口与多轮长对话对话越长模型越容易“失去初设定”。这是因为上下文里塞满了用户输入和模型回答早期信息被挤出了窗口。对此有两个解决办法一是限制对话轮数把记忆改成最近几轮二是在提示词里加上“如果用户问题与前文无关请基于系统设定回答”。这个方法在客服类应用里尤其管用它能保证即使话题被带偏模型也不至于完全失控。如果你有大量文本需要对话比如让AI读一份几千字的PDF再提问建议先把文档放进知识库而不是直接塞进对话输入框。一个几千字的对话输入会占掉几乎整个上下文窗口回答质量必然下降。只将最新问题发送到模型配合对检索知识片段的引用可以极大提高回答准确度。6.5 知识库检索不到内容知识库挂载了但用户提问后模型却说“没找到资料”。先别急着怀疑制造幻觉大概率是检索结果相似度太低或者切片内容不够精确。你可以在调试窗口里查看检索到的片段及相似度分数。如果相似度和答案都符合预期但模型仍然“找不到”检查提示词里有没有“仅回答知识库内容”的强约束会不会因为过度约束抑制了正确回答。还有一种情况是文档本身格式太复杂。PDF里的图片、表格、特殊符号经过文本提取后可能变成乱码检索时当然匹配不上。建议在预处理阶段把复杂的PDF转成纯文本文档检查一遍内容完整度再上传知识库。这一步能避免70%的“知识库不生效”问题。一份实用速查表问题排查方向解决建议首次访问很慢冷启动预留资源、动态预热回答时而准时而飘温度过高下调温度、强化提示词多轮后被带偏上下文过载限制轮数、开启摘要密钥报401Key错误或过期重置Key、校验权限知识库不生效切片或相似度问题优化文档、检查引用片段结尾从“第一个应用”到“稳定的生产应用”我的几点体会做完第一个应用之后再看整个链路里最花时间的不是配置环境、不是接模型而是把提示词打磨到“符合业务预期”。环境问题一小时能解决模型接入半小时能搞定但真正让它像个“懂业务的人”在回答问题需要在调试窗口里反复对话、反复调整。另一个体会是Dify把工程门槛降低但没有降低思考门槛。整个链路里还有大量需要业务经验的地方——知识库的文档怎么清洗、回答风格怎么定调、哪些问题必须人工兜底这些都要你基于对业务的理解来做取舍。可以说工具提供的是“发动机”而你是那个“开车的人”。如果你正准备做自己的第一个应用别追求大而全先从一个小场景切开内部制度查询、常见问题答疑、资料检索助手都可以。跑完一个完整流程之后再升级成带知识库、带工具的正式应用。那种快速交付的感受是看再多文档也体会不到的。每踩一个坑就离真正的生产级应用近了一步。
