我厌倦了把拼凑的脚本称作“workflow automation”。

Source: Dev.to

我多年来构建并维护了大量的“自动化”。它们大多数遵循同一种模式：

• 这里写点 JavaScript，那里写个 Python 脚本，配上一些环境变量，或许还有一个 cron 任务，或许还有一个 webhook；
• 然后把它们串在一起，祈祷没有人会频繁触碰它。

这种方式在一段时间内还能凑合使用。直到它不再起作用。

当脚本不再可扩展时

通常被称为 “workflow automation” 的东西，今天往往只是营销更好的脚本。

• 你把 JS 和 Python 代码片段粘合在一起。
• 你在步骤之间传递 JSON 数据块。
• 你依赖运行时行为来判断各部分是否匹配。

一开始，这感觉很灵活。后来，它变得脆弱。

• 重构令人害怕。
• 调试意味着阅读日志并猜测是哪一步修改了数据。
• 有人改了字段名，整个流程仍然运行——只是运行错误。

那不是自动化。那是带有调度器的累计技术债务。

Source: …

我想要行为像软件的工作流

Flow‑Like 起源于一个相当简单的想法：

如果工作流至关重要，它们就应该表现得像真实的软件系统。

这意味着：

• 明确的输入和输出
• 早期验证，而不是后期失败
• 可预测的执行
• 能够在不阅读五个脚本的情况下了解工作流的作用

在 Flow‑Like 中，工作流是可视化的图，但它们也是 类型化 的。连接不仅仅是“数据放在这里”；它们有具体含义。如果两个步骤在交换内容上不一致，你不会在后期运行时遇到崩溃——而是会立即得到反馈。

仅此一点就消除了在许多自动化设置中被视为“正常”的大量错误。

可视化并不等于简化

很多工具把可视化工作流当作隐藏复杂性的手段。我不喜欢这种做法。

Flow‑Like 使用可视化来 展示结构，而不是假装结构不存在。你可以看到执行顺序、依赖关系和副作用。如果工作流很复杂，图表会显示出来——这是一件好事。

作为开发者，我希望系统能够诚实地呈现其复杂性。

默认稳健

在底层，Flow‑Like 是用 Rust 编写的。这并不是潮流选择，而是实用的决定。

工作流引擎需要处理 I/O、并发、长时间运行的任务以及故障。崩溃或未定义行为是不可接受的。Rust 为你提供了默认快速、可预测且安全的运行时。

更重要的是，它使系统具备可移植性。同一工作流可以在本地、桌面应用或服务器上运行，而行为保持一致。

Source: …

隐私与本地优先执行

许多自动化工具让我感到困扰的一点是，它们很快就假设“把所有东西都发送到云端”。

Flow‑Like 是 本地优先 的。你可以在自己的机器上完整地构建和执行工作流。没有强制性的后端，也没有隐藏的 SaaS 依赖。

这并不是反对云，而是提供一种选择。

本地执行意味着：

• 更容易调试
• 开发期间使用真实数据
• 在隐私和合规性方面更少意外

如果以后想在服务器或 Kubernetes 上运行工作流，也完全可以。但这不应该是必须的。

无胶带的 AI 工作流

AI 现在已经成为许多自动化流水线的一部分。但这往往意味着在脚本中嵌入提示词，并寄希望于不会出现奇怪的情况。

在 Flow‑Like 中，AI 步骤仅仅是工作流图的一部分。它们拥有与其他节点相同的类型化输入和输出。你可以清晰地看到数据的来源、转换过程以及最终生成的内容。

这让 AI 工作流不再神秘——也更容易获得信任。

为什么我在构建这个

（原文在此继续…）