低代码平台的黄昏：为什么 Claude Agent SDK 会让 Dify 们成为历史

"最好的工具，是符合人类思维方式的工具。" —— 一个从 Dify 逃出来的开发者

一、开局一个场景：你会怎么布置任务？

想象你是一个餐厅老板，需要教新员工处理客户投诉。你会怎么做？

方式A：画流程图

[开始] → [听客户说] → [判断：是菜凉了吗？]
           ↓ 是                ↓ 否
      [重新加热] → [道歉] → [判断：是上菜慢吗？]
                                ↓ 是      ↓ 否
                            [送小菜] → [判断：是态度问题吗？]
                                          ↓ 是    ↓ 否
                                      [换服务员] → [...]

然后告诉员工："按这个流程图操作，每个节点都不能错。"

方式B：直接说

"小王，处理投诉很简单：先听客户说什么问题，如果是菜凉了就重新加热，如果是上菜慢就送个小菜道歉，如果是服务态度不好就换个人接待。总之，让客户满意就行。具体情况你自己判断。"

你会选哪个？

我猜 99% 的人会选方式 B。

因为人类几千年来就是这么传递知识的：用语言描述意图和原则，让对方理解后灵活执行。

没人会画一个 100 个节点的流程图来教徒弟做事。

但讽刺的是，当我们开始用 AI 时，整个行业却选择了方式 A。

这就是 Dify 等低代码平台的根本问题。

二、大模型的第一性原理：它是语言智能，不是流程图执行器

让我们回到原点思考：大模型是什么？

大模型的本质是：理解和生成自然语言的智能体。

它在数万亿个自然语言文本上训练
它理解人类的意图、上下文、隐含逻辑
它的核心能力是语言理解和推理

这意味着什么？

意味着大模型天生就懂"人话"。

当你说"处理客户投诉"，它理解这是什么意思。当你说"如果是菜凉了就重新加热"，它理解这个逻辑。当你说"让客户满意"，它理解这个目标。

它不需要你把这些转换成流程图。

就像你不会给一个懂中文的人布置任务时，先翻译成英文，再翻译成流程图，最后让他执行。

你直接用中文说就行了。

三、人类的原始行为模式：自然语言传递流程

人类几千年来是怎么传递工作流程的？

师傅教徒弟

"学徒，做木工活要这样：先量尺寸，然后画线，用锯子按线切，最后打磨光滑。记住，切的时候要稳，不能歪。"

没有流程图，没有节点，只有自然语言描述。

老师教学生

"写作文要有开头、正文、结尾。开头要吸引人，正文要有逻辑，结尾要点题。具体怎么写，看你的题材。"

没有固定模板，只有原则和示例。

老板布置工作

"去处理一下那个客户的投诉，先了解情况，该赔钱赔钱，该道歉道歉，反正别让事情闹大。"

没有 SOP 文档（好吧，现代大公司有，但那是另一个话题），只有目标和方向。

这就是人类的原始行为模式：用自然语言描述意图、原则、流程，让执行者理解后灵活处理。

为什么自然语言更自然？

因为自然语言有几个其他方式无法替代的优势：

保留上下文："该赔钱赔钱"隐含了"合理范围内"
允许灵活性："具体情况你自己判断"给了执行空间
传递意图：不只是步骤，还有"为什么这么做"
易于理解：任何人都能懂，不需要学习特殊语言

流程图是什么时候出现的？

工业革命之后。

为什么？因为机器不懂人话，只能执行固定指令。

所以我们发明了流程图、SOP、标准化作业——把人类的灵活性抹掉，让流程变得机械化。

但大模型不是机器，它是智能体。

它懂人话，为什么还要用工业时代的流程图来约束它？

四、Dify 的本质问题：用图形化对抗语言智能

现在我们理解了：

大模型是语言智能
人类用自然语言传递流程

那 Dify 在做什么？

Dify 要求你把自然语言意图翻译成图形化节点和连线。

举个例子：

你的原始意图（自然语言）：

"处理订单投诉：先查订单信息，分析投诉类型，如果是延迟问题就计算补偿并退款，如果是质量问题就联系供应商，最后记录处理结果。"

在 Dify 里，你需要：

拖一个"数据库查询"节点，配置查询参数
拖一个"AI 分析"节点，配置 prompt
拖一个"条件判断"节点，设置判断规则
拖两个分支，分别处理延迟和质量问题
每个分支里再拖 3-5 个节点
配置所有节点之间的连线和变量传递
测试、调试、修改、再测试...

最终你得到一个 20 个节点的流程图。

问题在哪？

增加了翻译成本：自然语言 → 图形化节点（这一步完全多余）
丢失了上下文：节点只能表达"做什么"，很难表达"为什么"
限制了灵活性：必须预先设计所有分支，AI 不能灵活决策
维护噩梦：节点一多，改一个地方要检查十个连线

更关键的是：这完全对抗了大模型的核心能力。

大模型天生就懂自然语言描述的流程。你却强迫它去理解图形化抽象。

这就像给一个懂中文的人布置任务，你先把中文翻译成火星文，再让他执行。

为什么要多此一举？

五、Skill 的本质：用自然语言描述流程

现在我们来看 Claude Agent SDK 的 Skill 是怎么做的。

Skill = 一个 .md 文件

没错，就是一个普通的 Markdown 文件。

handle-order-complaint.skill.md：

# 处理订单投诉流程

## 目标
妥善处理客户的订单投诉，确保客户满意并记录处理过程。

## 可用工具（MCP）
- database.query: 查询订单信息
- ai.analyze_sentiment: 分析投诉类型
- payment.calculate_compensation: 计算补偿金额
- payment.apply_refund: 执行退款
- supplier.contact: 联系供应商
- logging.log_event: 记录事件

## 处理流程
当收到订单投诉时：

1. 使用 database.query 查询订单详细信息
2. 使用 ai.analyze_sentiment 分析投诉属于哪种类型（延迟、质量、服务等）
3. 根据投诉类型采取相应措施：
   - 如果是延迟问题：
     - 使用 payment.calculate_compensation 计算补偿金额
     - 使用 payment.apply_refund 执行退款
     - 向客户道歉并说明补偿方案
   - 如果是质量问题：
     - 使用 payment.calculate_refund 计算退款金额
     - 使用 payment.apply_refund 执行退款
     - 使用 supplier.contact 联系供应商反馈问题
   - 如果是服务态度问题：
     - 向客户道歉
     - 如果客户仍不满意，可以转人工客服
4. 使用 logging.log_event 记录整个处理过程（用于合规）
5. 总结处理结果并通知客户

## 注意事项
- 始终保持礼貌和同理心
- 补偿金额要合理，不能超过订单金额的 50%
- 重大投诉（超过 1000 元）需要升级到高级客服
- 所有操作必须记录日志以符合合规要求

就这样。

这就是 Dify 需要 20 个节点才能实现的流程。

但这里只有自然语言描述。

Skill 可以调度子 Skill 和 MCP 工具

Skill 不是孤立的，它可以：

调度 MCP 工具（原子能力）
- database.query：数据库查询
- payment.apply_refund：支付接口
- logging.log_event：日志记录

调度其他 Skill（子流程）

# 处理订单投诉流程（总流程）

如果投诉金额超过 1000 元：
- 调用 escalate-to-senior.skill（升级到高级客服）

如果需要计算补偿：
- 调用 calculate-compensation.skill（计算补偿金额）

这就像函数调用一样自然。

总 Skill 描述整体流程，子 Skill 处理具体步骤，MCP 工具提供原子能力。

层次清晰，组合灵活。

AI 理解自然语言，智能执行

当客户投诉"我的订单等了三天还没发货"时：

AI 读取 Skill.md 文件，理解了：

这是订单投诉场景，应该用 handle-order-complaint.skill
先查订单信息（调用 database.query）
分析投诉类型（调用 ai.analyze_sentiment），判断是"延迟问题"
按照延迟问题的流程处理：计算补偿、执行退款
记录日志（调用 logging.log_event）
通知客户

AI 自己做决策，灵活执行，不需要你画流程图。

对比：Dify vs Skill

维度	Dify Workflow	Skill.md
描述方式	图形化节点 + 连线	自然语言 Markdown
创建方式	拖拽、配置、连线	写一个 .md 文件
维护难度	节点多了难以理解	一目了然
灵活性	固定路径	AI 灵活决策
学习成本	学习平台特有概念	自然语言，零门槛
可迁移性	平台专有	纯文本，任何平台可用
符合人类思维	❌	✅
符合 AI 能力	❌	✅

六、为什么这是本质区别和范式转变？

1. 回归人类原始行为模式

几千年来，人类用自然语言传递流程。

Dify 要求你用图形化描述流程（工业时代的产物）。

Skill 让你回归自然语言（人类的原始模式）。

这不是技术的倒退，而是理念的进步。

2. 发挥大模型的核心能力

大模型是语言智能，不是流程图执行器。

Dify 限制了大模型的能力（只能按固定路径执行）。

Skill 释放了大模型的能力（理解意图、灵活决策）。

这才是 AI 的正确打开方式。

3. 降低真正的门槛

Dify 说它降低了编程门槛，但它创造了一个新门槛：学习图形化编排。

Skill 真正降低了门槛：你只需要用人话描述你想要什么。

不需要学编程，不需要学平台，不需要学新概念。

你会说话，就会用 Skill。

4. 符合第一性原理

Dify 的逻辑：

编程太难 → 用图形化降低门槛 → 创造新的复杂性 → 学习曲线陡峭

Skill 的逻辑：

编程太难 → 让 AI 理解人话 → 用自然语言描述流程 → 零学习曲线

哪个更符合第一性原理？

5. 范式转变

旧范式（Dify）：人类适应机器

把自然语言意图翻译成图形化流程
把灵活的逻辑固化成节点连线
把人类思维塑造成机器可理解的形式

新范式（Skill）：机器适应人类

AI 直接理解自然语言描述
AI 根据上下文灵活决策
人类用最自然的方式表达意图

这就是 AI 时代的本质：不是让人类更像机器，而是让机器更懂人类。

七、Workflow 的复杂性陷阱

还有人说："我的业务很复杂，需要 Workflow。"

让我们看看"复杂业务"在 Dify 里是什么样：

一个真实的电商客服 Workflow：

147 个节点
89 条连接线
处理 20+ 种客户意图
每种意图 3-5 个分支
加上异常处理、日志、合规、A/B 测试...

维护这个 Workflow 的体验：

改一个节点要检查 10 条连线
加一个功能要测试 2 天
新员工看 3 天也看不懂
像在玩扫雷游戏

如果用 Skill 呢？

主 Skill（总流程）：

# 电商客服流程

当客户咨询时：
1. 理解客户意图
2. 根据意图调用相应的子 Skill：
   - 价格咨询 → price-inquiry.skill
   - 订单查询 → order-status.skill
   - 投诉处理 → handle-complaint.skill
   - 退款申请 → process-refund.skill
   - ...
3. 记录对话日志
4. 如果客户问题未解决，升级到人工

子 Skill（具体流程）：

# handle-complaint.skill
处理投诉的详细步骤...

# order-status.skill
查询订单状态的详细步骤...

每个 Skill 简单清晰，组合起来处理复杂业务。

这就是函数式编程的思想：把复杂问题分解成简单模块。

八、MCP 协议：标准化的原子能力

还有一个关键点：MCP (Model Context Protocol)。

MCP 工具 = 标准化的原子能力

# Skill 可以调用的 MCP 工具

## 数据库操作
- database.query: 查询数据
- database.insert: 插入数据

## 文件操作
- filesystem.read: 读取文件
- filesystem.write: 写入文件

## 第三方集成
- slack.send_message: 发送消息
- email.send: 发送邮件
- payment.process: 处理支付

Skill 通过自然语言描述如何组合这些 MCP 工具。

AI 理解这些描述，智能调用相应的工具。

这就像：

MCP 工具是"乐高积木"（标准化组件）
Skill 是"搭建说明书"（自然语言描述如何组合）
AI 是"聪明的建造者"（理解说明书，灵活搭建）

九、给 Dify 用户的建议

如果你现在还在用 Dify，我不是说你要立刻放弃。

但我建议你思考：

你是在描述流程，还是在画流程图？
- 如果是前者，Skill 可能更适合你
- 如果是后者，问问自己"为什么要画图"
你的 Workflow 有多少个节点？
- 少于 10 个：还能维护
- 10-50 个：开始痛苦
- 50+ 个：考虑重构成 Skills
你花更多时间在开发还是调试？
- 如果是调试，可能是工具的问题，不是你的问题
试试用自然语言描述你的流程
- 如果能清楚描述，就不需要图形化
- 如果描述不清，那画图也画不清

十、结语：回归自然，才是未来

人类用了几千年自然语言来传递知识和流程。

工业革命发明了流程图，因为机器不懂人话。

AI 时代，大模型懂人话了。

我们为什么还要用流程图？

Claude Agent SDK 的 Skill 机制，让我们回归到最自然的方式：

用自然语言描述你想要什么，AI 理解后智能执行。

不需要学编程，不需要学平台，不需要画流程图。

你会说话，就会构建 Agent。

这不是技术的倒退，而是回归人类的原始行为模式。

这不是工具的升级，而是范式的转变。

从"人类适应机器"到"机器理解人类"。

这才是 AI 时代应该有的样子。

你怎么看？欢迎在评论区分享你的观点。

如果你还在纠结要不要学 Dify 的 147 种节点配置，我的建议是：

别纠结了，写一个 .md 文件，用人话描述你想要什么，剩下的交给 AI。