Dify / 低代码工作流生产化高频问答
Dify 面试不要答成“我会拖节点”。真正高频的是：低代码为什么适合 PoC、生产化要补哪些治理、什么时候迁到代码、如何做权限/评估/成本/版本/灰度。框架基础见 Dify 与低代码智能工作流，工作流边界见 AI 工作流 vs Agent，跨环境发布时的评测、审批、灰度和回滚闭环见 LLM 评测与发布门禁实战。
工作流草稿进入真实流量后，如何做版本粘性、影子验证、灰度停止和配置漂移演练，见 LLM 线上评测、灰度实验与质量运营面试题。
怎么用这页
遇到 Dify / Coze / n8n / 低代码智能工作流问题，可以按这条线回答：
- 定位：低代码平台适合快速验证业务价值和让业务专家参与维护。
- 边界：不是所有 PoC 都能直接生产，核心链路要补工程治理。
- 治理：版本、权限、评估、观测、成本、灰度、审计、逃逸路径。
- 迁移：把 PoC 沉淀成 prompt、知识库策略、工具定义、bad case 和评估集，再迁到 Spring AI / LangGraph / 自研服务。
- 项目表达：讲清楚“Dify 做了什么，后端补了什么，哪些最终迁出了 Dify”。
可复述版本：
我把 Dify 定位成业务验证和轻量编排平台。它能快速把 Chatflow、Workflow、Knowledge、Tool 和模型接起来，但上线前必须补权限、版本、评估、监控、成本和审计。复杂状态机、高危写操作、高并发强 SLA 的核心链路，我会迁到 LangGraph、Spring AI 或自研服务，Dify 保留为业务配置和 PoC 平台。
追问链一：Dify 适合什么，不适合什么
面试官：为什么说 Dify 适合 PoC？
标准答法：
因为它把模型接入、Prompt、知识库、工具调用、可视化流程和应用发布整合在一起，业务专家可以直接参与调 prompt、补知识库和改流程，验证速度比纯代码快很多。
适合：
- 内部知识库问答。
- 客服 FAQ、制度助手、SOP 助手。
- 运营文案、表单处理、轻量审批流。
- RAG + 简单工具调用。
- 业务专家需要频繁调整 prompt 和知识库。
不适合直接硬上：
- 高并发、强 SLA、低延迟核心链路。
- 强合规写操作：付款、退款、删除、对外发布。
- 复杂状态机、长事务、多系统一致性。
- 严格代码审查、单元测试、灰度、回滚要求很高的系统。
反面回答：
“Dify 开发快，所以可以直接替代后端服务”是危险答案。开发快解决的是验证效率，不自动解决生产治理。
追问链二：Chatflow、Workflow、Knowledge、Tool 怎么分工
面试官：Dify 的核心模块怎么讲？
标准答法：
| 模块 | 面试表达 | 典型边界 |
|---|---|---|
| Chatflow | 面向多轮对话入口，处理用户持续交互 | 客服、问答、助手 |
| Workflow | 面向确定性任务编排，按节点处理输入输出 | 文档处理、审批前置、批处理 |
| Knowledge | 内置 RAG 能力，负责文档接入、切分、检索 | 知识问答、制度检索 |
| Tool | 外部 API / HTTP / 业务系统调用 | 查订单、查库存、查工单 |
| Model Provider | 管模型接入和参数 | 多模型切换、试验 |
| Logs / Dataset | 运行记录和样本沉淀 | bad case、评估集 |
继续追问：Workflow 和 Agent 有什么区别？
回答要点：
- Workflow 路径基本可预期，节点和条件由人定义。
- Agent 根据运行时反馈动态决定下一步，更灵活也更难控。
- Dify 里的可视化流程适合固定或半固定任务。
- 长任务、复杂状态、人审恢复、严格测试更适合代码化状态机。
一句话：
能画成稳定流程的先用 Workflow；路径高度不确定、需要长期状态和恢复时，再考虑 Agent / LangGraph。
追问链三：PoC 到生产要补哪些治理
面试官：Dify PoC 跑通后，怎么判断它不是 demo 好看，而是真的有生产化价值？
标准答法：
我不会只看“能回答几个样例问题”。PoC 成功至少要同时证明业务价值、质量指标、用户使用、成本可控和可治理性。否则只是 demo 成功，不等于能上线。
| 维度 | 判断标准 |
|---|---|
| 业务价值 | 是否解决高频真实问题，是否减少人工处理时间，是否提升响应速度 |
| 质量 | golden set 准确率、引用正确率、拒答正确率、bad case 收敛 |
| 覆盖 | 高频问题覆盖率、知识库缺口、工具能力缺口 |
| 使用 | 目标用户是否持续使用，是否愿意把它放进真实流程 |
| 成本 | 单次请求 token 成本、P95 延迟、模型调用次数是否可接受 |
| 风险 | 权限、审计、数据泄露、高危动作是否能被治理 |
可复述：
我会把 PoC 验收从“能不能跑”升级为“值不值得上线”：看真实问题覆盖率、人工节省、准确率、引用质量、用户留存、成本和风险闭环。
面试官：Dify PoC 跑通后，生产化要补什么？
标准答法：
我会从 8 个维度补治理：版本、权限、评估、观测、成本、灰度、审计、迁移路径。PoC 成功只证明业务可能有价值，不证明已经满足生产 SLA 和合规要求。
| 维度 | 要补什么 | 面试关键词 |
|---|---|---|
| 版本 | prompt、流程、模型参数、知识库配置版本化 | 可追溯、可回滚 |
| 权限 | 多租户、角色、文档 ACL、工具 ACL | 检索前过滤 |
| 评估 | golden set、bad case、RAG/生成分评 | 回归门禁 |
| 观测 | 节点延迟、token、错误码、命中文档、工具调用 | trace |
| 成本 | 应用/租户/用户/节点级成本报表 | 预算与限额 |
| 灰度 | 按用户、部门、场景发布新版本 | 小流量试验 |
| 审计 | 谁改了流程、谁调用工具、输出了什么 | 合规证据 |
| 迁移 | 核心链路可迁到代码服务 | 逃逸路径 |
继续追问：为什么不能只靠人工点几条样例测试？
回答要点：
- Prompt、模型、知识库、工具任何变化都可能影响输出。
- 人工样例覆盖有限，无法发现回归和权限问题。
- 必须把线上真实问题、业务高频问题、攻击样本沉淀成评估集。
- 至少要覆盖：正确性、引用、拒答、权限、工具失败、成本。
追问链四：权限怎么做
面试官：Dify 知识库如何做多部门权限隔离？
标准答法：
权限要前置到检索层，而不是检索后靠 prompt 保密。文档入库时带 tenant、department、role、owner、visibility 等元数据；查询时根据登录用户生成过滤条件，向量召回、关键词召回、rerank 和上下文组装都不能越权。
关键点：
- 文档元数据和企业 IAM / RBAC / ABAC 对齐。
- 知识库切分后，每个 chunk 继承文档 ACL。
- 缓存 key 要带租户和权限上下文。
- 引用页也要做权限校验，不能只保护答案文本。
- 日志和 trace 脱敏。
继续追问：Tool 节点权限怎么做？
回答要点：
- Dify Tool 不直接持有高权限万能 key。
- 通过后端 Tool API / MCP Server 执行真实业务。
- 后端按当前用户、租户、角色做鉴权。
- 写操作 prepare/commit 分离，高危动作人审。
- 工具调用写审计日志。
可复述：
Dify 负责触发工具意图，后端服务负责鉴权和执行。模型和可视化画布都不是安全边界。
追问链五：评估集怎么建
面试官：Dify 应用上线前怎么评估？
标准答法：
我会把评估拆成检索、生成、工具和安全四类。知识库问答要看检索命中、引用正确、答案 faithful；工具流要看工具选择、参数、错误恢复；安全要看越权、注入、敏感数据泄露。
评估样本建议：
{
"question": "销售部员工能否查看财务报销制度明细？",
"expected_behavior": "拒答或只返回销售部可见制度",
"required_citations": ["sales_policy_doc"],
"forbidden_citations": ["finance_policy_doc"],
"allowed_tools": ["search_policy"],
"forbidden_tools": ["export_finance_doc"],
"tags": ["acl", "rag", "permission"]
}上线门禁：
- 核心问题回答准确率达标。
- 引用可追溯率达标。
- 跨租户/跨部门越权命中 = 0。
- 高危工具未确认执行 = 0。
- bad case 回归不退化。
- P95 延迟和单问成本达标。
继续追问：Dify 的日志怎么变成评估集？
回答要点：
- 从运行日志抽取高频问题、低评分问题、人工纠错问题。
- 标注期望答案、期望引用、允许工具、禁止工具。
- 按场景打标签：权限、拒答、检索漏召、幻觉、工具失败。
- 每次改 prompt、知识库、工具或模型都跑回归。
追问链六：版本、灰度和回滚
面试官：Dify 里业务人员改了 prompt，线上效果变差怎么办？
标准答法：
生产环境不能让 prompt 和流程随改随发。要有草稿、评测、审批、灰度、发布和回滚流程。每个版本记录 prompt、模型参数、知识库配置、工具版本和发布人。
发布流程：
draft
-> run golden set
-> human review
-> canary by department / user group
-> monitor quality + cost + errors
-> full rollout or rollback必备字段：
- app_version。
- prompt_version。
- workflow_version。
- knowledge_version。
- model_provider / model_config。
- tool_version。
- publisher / approver。
反面回答：
“谁会用谁就能直接改线上流程”不适合生产系统。业务可参与配置，但发布要有门禁和审计。
追问链七：成本怎么控
面试官：Dify 应用 token 成本突然升高，怎么排查？
标准答法：
先按应用、租户、用户、节点、模型拆成本。看是否知识库召回过多、上下文过长、模型换成更贵、循环节点重复调用、工具失败导致重试、日志里出现异常高频用户。
排查维度：
| 维度 | 看什么 |
|---|---|
| 应用 | 哪个 app 成本增长 |
| 节点 | 哪个 LLM / Knowledge / Tool 节点最贵 |
| 模型 | 是否路由到高价模型 |
| 上下文 | Top-K、chunk size、历史轮数是否过大 |
| 重试 | 工具失败是否导致重复调用 |
| 用户 | 是否有异常用户或批量任务 |
治理手段：
- 应用/租户/用户级预算。
- 简单任务用小模型，复杂任务才用强模型。
- 限制 Top-K、历史轮数、最大输出 token。
- 对高频问答做缓存。
- 工具失败有限重试，超过转人工。
追问链八：什么时候迁出 Dify
面试官：什么信号说明应该从 Dify 迁到代码？
标准答法：
当流程开始需要强类型状态、复杂分支、长任务恢复、严格权限、高危写操作、单元测试、灰度发布、高并发 SLA 或深度系统集成时，就应该把核心链路迁到代码服务。Dify 可以继续做 PoC、轻量配置和业务运营入口。
迁移信号：
- 画布分支过多，没人能完整理解。
- 多节点共享隐式变量，改一处影响全局。
- 工具既读又写，失败后不知道是否产生副作用。
- 没有自动评估和灰度，发布靠人工试几条。
- 需要接企业 IAM、审计、成本中心、模型网关。
- 需要代码审查、单测、CI/CD 和回滚。
迁移路线：
Dify PoC
-> 导出 prompt / workflow / knowledge / tool 配置
-> 抽取线上日志和 bad case 做评估集
-> 后端实现 Tool API / MCP Server
-> 核心状态机迁到 LangGraph / Spring AI / 自研服务
-> Dify 保留为配置台、运营台或新场景 PoC系统设计题：企业 Dify 平台怎么做生产治理
题目：
公司内部多个部门都想用 Dify 搭知识库和工作流，你如何设计一套企业级治理方案？
需求澄清
- 是统一 Dify 平台，还是各部门独立部署？
- 是否接企业 SSO / IAM / 审批系统？
- 是否允许调用内部业务 API？
- 是否有外部用户访问？
- 是否需要私有化模型、模型网关或 MaaS？
- 审计日志保留多久，是否涉及敏感数据和跨境？
架构答法
企业门户 / SSO
-> Dify Workspace / App
-> Model Gateway / MaaS
-> Knowledge Service with ACL
-> Tool API / MCP Server
-> Eval & Trace Platform
-> Cost Center / Audit Log分层说明：
| 层 | 负责什么 | 不负责什么 |
|---|---|---|
| Dify 应用层 | Chatflow、Workflow、业务配置、轻量发布 | 企业最终鉴权和核心写操作事务 |
| 模型网关层 | 统一 Key、路由、配额、计费、fallback | 具体业务流程 |
| 知识服务层 | 文档接入、ACL、索引、删除一致性 | 用 prompt 弥补权限漏洞 |
| 工具服务层 | 业务 API 鉴权、幂等、审计、降级 | 让画布直接持有高权限 key |
| 评估观测层 | trace、golden set、bad case、成本报表 | 只靠人工点测 |
| 审计治理层 | 变更记录、发布审批、权限证据 | 无版本的线上热改 |
治理策略
- 模型统一入口：Dify 接模型网关，不直连各厂商 key。
- 知识库统一权限：文档入库带 ACL，检索前过滤。
- 工具统一执行：业务 API 由后端 Tool Service 执行鉴权和审计。
- 发布统一门禁：草稿、评估、审批、灰度、回滚。
- 成本统一报表：按 app、部门、用户、模型、节点统计。
- 日志统一脱敏：trace 可回放，但敏感字段不落明文。
项目讲法模板
企业知识库 PoC
我用 Dify 快速搭了制度问答 PoC，把 HR、财务、IT 文档接入 Knowledge，并在回答中要求引用来源。PoC 阶段重点验证高频问题覆盖率、切分策略、引用质量和业务反馈。上线前补了文档 ACL、bad case 评估集、日志脱敏、成本统计和灰度发布；对涉及工单创建的工具节点，改成后端 Tool API 统一鉴权和审计。
客服工作流
客服场景里，Dify 适合承载 FAQ、用户信息补全和标准话术生成。订单查询是只读工具，退款、改地址、补偿券这类写操作不会让 Dify 直接执行，而是生成待确认动作，后端服务做人审、幂等和审计。复杂状态和长任务如果增多，会迁到 LangGraph，Dify 继续给业务维护话术和知识库。
运营内容助手
运营内容助手用 Dify 的 Workflow 串起选题输入、资料检索、文案生成、合规检查和人工审核。它适合低风险、高频迭代的内容生产，但发布到外部渠道前必须有人审和审计。我们用评估集检查品牌语气、事实引用和敏感词，并按活动统计 token 成本。
反面回答清单
面试里尽量别这样说：
- “Dify 会拖节点就行。”太浅，没有生产治理。
- “低代码不用写后端。”错误，工具鉴权、审计、权限和核心写操作仍要后端。
- “PoC 跑通就能上线。”少了评估、灰度、回滚和成本。
- “权限靠 prompt 约束。”权限必须在检索和工具执行层做。
- “业务人员可以直接改线上 prompt。”生产环境要版本和发布门禁。
- “Dify 和 LangGraph 二选一。”更常见是 Dify 验证和运营，LangGraph/代码承载核心复杂链路。
面试前 5 分钟速记
- Dify 定位：PoC 快、业务可参与、低代码编排。
- 生产八件套：版本、权限、评估、观测、成本、灰度、审计、迁移。
- 权限原则：检索前过滤，工具后端鉴权。
- 评估四类：检索、生成、工具、安全。
- 发布流程：draft -> eval -> review -> canary -> rollout / rollback。
- 迁移信号：复杂状态、高危写、强 SLA、强测试、强合规。
- 项目讲法：Dify 验证价值，后端补治理，核心链路可迁出。