# 为什么 AI 工作流一定要“填字段”？

我用了 Dify、n8n 一段时间之后，终于忍不住自己做了一个。

不是因为它们不好。

恰恰相反，它们都很强。

但我一直有一个特别难受的感觉：

**做个工作流，为什么我要一直找字段？**

这个节点要填什么？

这个参数在哪？

这个函数叫什么？

这里为什么还要再配置一层？

尤其是 n8n，对英文不太好的我来说，有时候真的像在做阅读理解😂

插件很多、生态很大，但很多节点、文档和服务本身就是围绕海外生态来的。

后来我突然想到：

**为什么不能像 ComfyUI 一样？**

不要让我找字段。

**直接把所有输入输出变成端口。**

需要什么，就连什么。

```text
网页
 │
 ▼
内容提取 ───→ AI总结 ───→ 邮件
                 │
                 ▼
              保存文件
```

我想要的工作流就应该这么简单。

所以我开始做 ChengOS。

---

### 但 ComfyUI 也不是答案

ComfyUI 给我的最大启发，就是：

**“端口 + 连线”真的很适合表达复杂工作流。**

但它的整体体量对我来说又太重了。

我想做的是一个更通用的版本：

**不只做图片，也不需要为了跑一个简单自动化就背着一整套庞大的系统。**

所以 ChengOS 从第一天开始就有一个很朴素的目标：

> **轻。**

不是“轻量级”三个字写在 README 上。

而是真的尽可能轻。

现在它已经可以跑在：

**1 核 CPU / 512MB 内存的 VPS**上。

对于我来说，这比堆几十个功能更有成就感。

---

### ChengOS 到底想做什么？

一句话：

**一个像 ComfyUI 一样，通过端口和连线搭建 AI 工作流的轻量工作流引擎。**

我希望你看到一个节点的时候，不需要先研究：

“这个字段叫什么？”

而是直接看到：

```text
        ┌────────────┐
输入 ──→│ AI 总结     │──→ 输出
        └────────────┘
```

然后：

**连线。**

就这么简单。

---

### MCP 也不是为了“蹭热点”

ChengOS 会支持 MCP。

但我更希望 MCP 在这里扮演的是：

**把外部能力接进工作流。**

一个 MCP 能力可以变成一个节点。

一个工作流也可以被复用、组合，甚至分享给别人。

所以以后你可能看到的是：

**一个人做一个工作流 → 分享这个工作流 → 别人直接拿来组合自己的工作流。**

而不是每个人都重新从零搭一遍。

---

### 为什么用 Rust？

因为我不想做一个“能跑就行”的网页应用。

我希望它最终可以非常小、非常快，而且真正适合：

* 本地电脑
* 家用服务器
* 小型 VPS
* 私有化部署

AI 已经够重了。

**工作流引擎就别再跟着一起变重。**

---

所以 ChengOS 并不是：

“我要做一个比 Dify 更强的平台。”

也不是：

“我要重新造一个 ComfyUI。”

更准确地说：

**我只是一直没找到一个自己真正喜欢的 AI 工作流交互方式。**

于是决定：

**那我自己做一个。**

如果你也讨厌“找字段、填字段、看参数”，

可能你也会喜欢这种方式。

接下来我会持续把 ChengOS 的开发过程、工作流案例和各种踩坑记录发出来。