中文精读
Dify两年复盘：把模型能力接进企业工作的产品选择
42章经单期精读 · AI产品
嘉宾：张路宇，节目当期介绍为Dify.AI创始人｜主持：曲凯
节目发布：2025年12月6日｜时长：79分25秒｜整理：2026年10月18日
收听原节目与查看官方介绍
这一期值得带走什么
2023年，Dify用可视化Prompt和RAG帮助用户理解新技术。到这次复盘时，路宇谈得更多的是业务人员、升级兼容、组织流程和人工反馈。这个变化提供了一条观察AI产品的线索：模型能力进入真实工作后，产品要承担的责任会不断增加。
本期适合正在做企业AI工具、工作流平台或Agent产品的人。最值得追问的是：谁拥有要被自动化的专业知识，哪些能力可以替换，以及业务人员怎样确认交付结果？
本文依据用户提供的完整文字稿和官方节目介绍重新组织。下文分别标明嘉宾经验与编辑判断；没有独立审计Dify经营数据，也没有将2025年的竞品评价作为当前选型结论。
1. 从功能竞争回到“谁能用它创造价值”
节目线索：01:40–10:40。 路宇把产品演变分成几个阶段：最初让Prompt和RAG可视化，后来面对企业用户增加Workflow（工作流）与插件，再适应多模型和多模态。他的解释是，有付费能力、真正在业务中生产结果的人，需要时间理解和采用新技术。
他也修正了自己对LangChain差异的早期回答。过去会强调体验和工程；这次更强调受众：编码能力较强的开发者，和掌握业务知识、希望少写代码的人员，需要的产品不同。至于各家产品当时处在什么位置，是他的竞争视角，需要结合版本和具体任务看。
更具体的一层，是用户凭什么做出有价值的应用。他列出硬技术、体验创意、特殊数据和流程理解四类资源。Dify看重企业业务人员已有的流程经验：同样处理报销、客户需求或审批，各组织会有不同规则和协作方式。
编辑判断：“能搭出一个Bot”可以作为上手结果；产品价值仍需落到一项真实工作。确定目标用户时，除了问“会不会写代码”，还应问他掌握什么业务判断、能否取得必要资料、谁会使用最终结果。路宇对流程可复用性的强调很有启发，但不能据此断言技术、创意或数据都没有复用价值。
2. 工程积累体现在升级时保住什么
节目线索：19:44–24:53。 一个具体例子是插件与RAG组件的替换：用户可以使用原生组件，也可以开发自己的组件；平台持续升级时，既有投入需要得到保护。
这让“模型中立”有了产品含义。企业长期投资开发平台，除了今天能接哪些模型，还会考虑组件是否独立升级、已有流程是否兼容、未来换供应商需要重做多少东西。
路宇也承认社区协作和快速迭代带来的测试难度，并区分社区版与更保守的企业版节奏。他对企业版稳定性的表述是供应方陈述，不能转写成零故障保证。
编辑判断：评估中间层的积累，可以检查一次真实升级：旧流程能否继续运行，关键字段是否保持含义，定制组件是否仍兼容，失败后怎样回退。界面上多了多少新节点，不足以回答这些问题。这些是从访谈提炼出的验收问题，并非本次已经对Dify执行过的测试。
3. Workflow留下了哪些人的责任
节目线索：25:22–29:34、34:27–34:57。 路宇认为企业始终需要可预测的结果。复杂任务可以压进一个大节点，也可以拆成多个节点；只要过程中需要确认、选择和复核，检查点就有价值。
主持人举生成图片反复尝试、最后挑出满意结果的例子。路宇指出，最终由人筛选的流程仍然有人值守。这个例子把人的工作揭示出来：模型生成了候选，结果判断依然有人承担。
另一个例子是发票。即使交互界面可以动态生成，需要长期保存的字段、结构与敏感信息边界仍要稳定。界面的灵活性，不应让结果的数据含义随意漂移。
编辑判断：设计工作流时，可以先标出三类节点：机器能够检验的步骤、需要人的业务判断、会改变外部状态的动作。再决定各节点用规则、模型还是人工。可靠性需要按任务损失、例外和恢复能力定义；节目提到的准确率数字不能直接变成所有企业的通用门槛。
4. 组织之间的非标准协作，可能比单个标准功能更有价值
节目线索：39:37–45:32。 路宇描述，一些客户把Dify用于连接不同组织、数据和既有系统。标准场景可能已有专业SaaS；更难处理的，是这些系统之间各不相同的协作关系。
他举客户复杂流程和Anker的例子，说明企业开始讨论某个能力节点该由人还是Agent承担，并设想由看板承接待审核、待反馈的任务。节目中的节点数、流程数和能力规模来自嘉宾，不能据此推断这些企业已经实现全部自主运营。
这里值得保留的产品问题很具体：谁设计流程？谁给出反馈？谁拿走结果？如果业务人员只能提交需求，无法理解失败发生在哪、也无法接住需要判断的任务，自动化仍然缺少一段组织协作。
5. 日本增长故事里，还有产品和承接能力
节目线索：45:42–54:35。 路宇将日本传播与较早提供日语版本、当地流程化工作和技术人才供给联系起来。他回忆，社区传播起来时，团队当地承接能力尚不充分，后来才补上。
“零销售”的故事容易被简化成“开源后自然增长”。这段访谈同时给出了更完整的线索：产品已有语言入口，场景存在需求，社区能够传播，而传播之后还要有人服务企业。它仍是一方回顾，不能证明每个因素各自贡献了多少增长。
全球化组织部分则谈到文档、异步工具、跨文化招聘和透明信息。可借鉴的是提前准备协作基础；不能把单个公司的财务制度或人才背景直接照搬。
把这期用到一项具体工作
下面是编辑根据访谈提出的应用练习，适合用来检查自己的AI产品：
| 先做什么 | 留下什么可复核结果 |
|---|---|
| 选一项已有真实需求的业务任务，明确目标用户与交付物 | 用户掌握的知识、必要资料、使用结果的人 |
| 将可替换能力与稳定约束分开 | 模型/插件替换点，以及字段、权限、兼容承诺 |
| 标出人工检查与外部动作 | 谁批准、何时停下、失败怎样恢复 |
| 用新版本重跑旧流程 | 升级前后结果、失败样例与回退记录 |
这期的价值，在于把产品定位一路连到工程兼容和组织交付。读者可以保留这个问题：当模型继续变化时，客户已经投入的专业知识、流程和信任，将由产品怎样承接？
回听导航与关联阅读
- 04:31：用目标用户解释产品差异。
- 21:40：组件替换与旧技术资产。
- 25:22：工作流、检查点与结果责任。
- 42:39：非标准组织协作。
- 46:24：日本传播与后续承接。
- 01:01:54：组织如何保存自己的经验与判断。
Agent架构与多Agent编排 · 同系列：Sheet0单期精读
资料边界：这是单期精读与编辑分析，非完整逐字稿转载或产品实测。姓名和术语按官方介绍及上下文校正；未逐句复听音频。经营规模、竞争判断与未来预测均保留访谈时点。
English edition
Dify’s Two-Year Review: Product Choices That Bring Models into Enterprise Work
42 Zhangjing episode analysis · AI products
Guest: Zhang Luyu, introduced in this episode as the founder of Dify.AI | Host: Qu Kai
Published: December 6, 2025 | Duration: 79 minutes 25 seconds | Prepared: October 18, 2026
Listen to the episode and read its official introduction
What to take from this episode
In 2023, Dify helped users understand new technology through visual prompt engineering and RAG. By this retrospective, Luyu was talking more about business users, upgrade compatibility, organizational processes and human feedback. That shift offers a useful way to examine AI products: as model capabilities enter real work, the product’s responsibilities expand.
This episode is useful for people building enterprise AI tools, workflow platforms and agents. Its central questions concern who holds the professional knowledge being automated, which capabilities can be replaced and how business users accept the delivered result.
This article reorganizes the complete supplied transcript and the official episode introduction. It distinguishes the guest’s experience from editorial interpretation. Dify’s business figures were not independently audited, and competitive opinions from 2025 are not presented as current purchasing advice.
1. Ask who can create value with the product
Episode reference: 01:40–10:40. Luyu describes several stages: making prompts and RAG visual, adding workflows and plugins for enterprise users, then adapting to multiple models and modalities. In his account, paying users who produce actual business results need time to understand and adopt new technology.
He also revisits an earlier explanation of Dify’s difference from LangChain. Previously he emphasized experience and engineering; here he emphasizes audiences. Developers with strong coding skills and people who hold business knowledge but want to write less code need different products. His placement of competitors reflects his perspective at the time and needs to be read against particular versions and tasks.
The more concrete question is what enables a user to build a useful application. He identifies four resources: technical capability, experience design and creativity, distinctive data, and process knowledge. Dify values business users’ existing understanding of processes. Organizations handling the same reimbursements, customer requests or approvals can have different rules and ways of working together.
Editorial interpretation: Building a bot can demonstrate initial usability; product value still needs to appear in a real task. When defining users, ask what business judgments they possess, whether they can obtain the required material and who will use the result, alongside whether they can code. Luyu’s emphasis on reusable process knowledge is useful, but does not establish that technology, creativity and data lack reusable value.
2. Engineering investment shows up in what survives an upgrade
Episode reference: 19:44–24:53. One concrete example concerns replacing plugins and RAG components. Users can adopt native components or develop their own, and the platform should protect that investment as it evolves.
This gives model neutrality a product meaning. Enterprises making a long-term platform investment consider which components can be upgraded independently, whether existing workflows remain compatible and how much work a future supplier change would require, as well as which models connect today.
Luyu acknowledges the testing difficulty created by community contributions and rapid iteration, distinguishing the community release cadence from a more conservative enterprise edition. His account of enterprise stability is a supplier statement, not a zero-failure guarantee.
Editorial interpretation: Examine a real upgrade to assess an intermediary platform’s accumulated value. Do old workflows still run? Do important fields retain their meaning? Are custom components compatible? How can a failed upgrade be rolled back? Counting new interface nodes cannot answer these questions. These are acceptance questions derived from the interview, not tests performed on Dify for this article.
3. Which human responsibilities does a workflow retain?
Episode reference: 25:22–29:34 and 34:27–34:57. Luyu argues that enterprises continue to need predictable outcomes. A complex task may be compressed into one large node or split into many. Wherever confirmation, selection or review is required, checkpoints retain value.
The host describes repeatedly generating images and eventually selecting a satisfactory result. Luyu observes that a person making the final selection is still supervising the work. The example makes the human contribution visible: the model generated candidates, while a person retained responsibility for judging the outcome.
Invoices provide another example. Even if interfaces can be generated dynamically, fields and structures that must be retained over time, together with sensitive-information boundaries, need stability. Interface flexibility should not allow the meaning of stored results to drift arbitrarily.
Editorial interpretation: Begin workflow design by identifying steps a machine can check, steps requiring human business judgment and actions that change external state. Then choose rules, models or people for each step. Define reliability through task consequences, exceptions and recovery. Accuracy figures mentioned in the episode are not universal enterprise thresholds.
4. Nonstandard coordination may matter more than one standard feature
Episode reference: 39:37–45:32. Luyu describes customers connecting organizational units, data and existing systems through Dify. Specialized SaaS may already serve a standard task; coordination between those systems varies from organization to organization.
He cites complex customer workflows and Anker to illustrate enterprises considering whether a person or an agent should perform a particular capability, and imagines dashboards collecting tasks that need review or feedback. The node, workflow and capability counts are his account. They do not demonstrate fully autonomous enterprise operations.
The practical product questions are specific: who designs the process, who provides feedback and who takes delivery of the result? If business users can only submit requests, cannot understand where a failure occurred and cannot take over a decision, the organizational handoff remains incomplete.
5. The Japanese growth story also involves product access and service capacity
Episode reference: 45:42–54:35. Luyu associates adoption in Japan with an early Japanese-language version, process-oriented work and local technical staffing conditions. He recalls community distribution taking off before the team had sufficient local capacity to serve the demand, with that capacity added later.
The “zero sales” story is easily reduced to organic growth after open-sourcing. The interview provides a fuller sequence: a language entry point existed, the task fit local demand, the community could spread the product and enterprise interest subsequently needed service. This remains one participant’s retrospective, not a causal measurement of each factor’s contribution.
The discussion of global operations covers documentation, asynchronous tools, cross-cultural recruitment and transparent information. Preparing collaboration infrastructure early is transferable; one company’s financial policies or preferred hiring backgrounds should not be copied wholesale.
Apply the episode to one real task
The following editorial exercise can help examine an AI product:
| Start here | Keep a reviewable result |
|---|---|
| Choose a real business task, its user and its deliverable | The user’s expertise, required material and the people using the result |
| Separate replaceable capabilities from stable constraints | Model/plugin substitution points and commitments about fields, permissions and compatibility |
| Mark human checkpoints and external actions | Who approves, when execution stops and how failures are recovered |
| Rerun existing workflows with a new version | Before-and-after results, failure examples and rollback records |
The episode connects positioning with engineering compatibility and organizational delivery. It leaves a useful question: as models continue to change, how will the product support the expertise, processes and trust in which customers have already invested?
Listening guide and related reading
- 04:31: Explaining product differences through target users.
- 21:40: Component replacement and existing technical assets.
- 25:22: Workflows, checkpoints and responsibility for results.
- 42:39: Nonstandard organizational coordination.
- 46:24: Distribution in Japan and subsequent service capacity.
- 01:01:54: Preserving an organization’s experience and judgments.
Agent architecture and multi-agent orchestration · From this series: Sheet0 episode analysis
Source boundary: Episode analysis and editorial interpretation, not a full transcript republication or product test. Names and terminology were corrected against the official introduction and context. Audio was not replayed sentence by sentence. Business scale, competitive opinions and forecasts remain anchored to the interview date.