被字节扣子的新功能戳到了。

即将过去的、我们无比熟悉的 2025 年，被称为是 Agent 的元年。

确实，这一年 Agent 很火，各个垂直的领域内，都涌现出一些不错的产品。雨后春笋的感觉。

具体到 Agent 开发平台，字节的扣子肯定是国内最出圈的产品。

甚至我一个和 AI 八杆子都打不着的老同学，前段时间咨询我扣子工作流相关的问题。这让我很诧异。看来，类似的产品确实是有需求的。

曾经，我还给朋友公司部署过一套类扣子这样的开源工作流平台。

说实话，站在从业者的角度看，这类产品已经很好用了。放在两三年前都很难想象。

1

但我也曾经不止一次的想过一个问题：Agent 工作流平台，和当年的低代码之间是什么关系？

只是加了 AI 的能力吗？以及它和 Vibe Coding 之间呢？是两条并行的路径？

不知道你是否有此疑惑。反正我困惑了很久。

上周，去上海参加扣子的活动。主题演讲中，他们负责人宣布，扣子开发平台正式升级为扣子编程。我瞬间有了自己的答案。

看来在字节的判断中，之前基于画布拖拽工作流的软件构建方式，只是过渡形态。Vibe Coding 才是他们真正想去往的下一站。

这个判断，其实挺激进的，但放在当下这个时间点，又显得非常合理。我很认同。

因为只要在企业里真正用过这些 Agent 工作流平台，就会发现一个现实问题：它们看起来很直观，但并不是真的低门槛。

对非 IT 从业者来说，哪怕是工作流，也依然绕不开一些底层认知。比如什么是函数的输入输出，什么是条件分支，什么情况下要拆成多个节点。

只要这些概念搞不清楚，那搭建起来也会是一头雾水。

或者即便把刚刚的基本概念搞清楚了，也还是很难搭建复杂应用。因为只要需求一复杂，就得在节点中写代码。

这一点，我之前给朋友公司做 Agent 工作流的培训时，感受特别明显。

大家不是不愿意学，而是学到某一步就会卡住，绝大多数人，都没有计算机基础。

基于画布拖拽工作流节点的构建方式，说到底还是更适合本来就懂软件的人。

而 Vibe Coding 则提供的是另一种可能。

它不再要求用户理解节点的输入输出，也不要求用户知道节点之间怎么连接，而是只关心一件事：我想做什么。

把需求用自然语言说清楚，剩下的事情交给系统。怎么拆计划，怎么选插件，怎么生成代码，怎么部署，这些都在后台完成。

对用户来说，交互的对象不再是画布或者其他图形界面，而是一个能理解意图的对话系统。

至此，扣子正式转向 Vibe Coding 的范式了。

如果站在 2025 年这个时间点往前看，我会觉得，明年国内外一大批同类产品，都会往这个方向靠拢。

当然，我也不太认同那种一句话就能写出一个软件的说法。真正好用的软件，依然是人在和 AI 的反复对话中，一点点磨出来的。扣子编程也是这样。

市面上很多 Vibe Coding 产品，解决的只是创作阶段的问题。

比如说一句话，它帮你生成一个网页，看起来像个应用。或者再往前一步，接个现成的 Supabase 后端服务。

到这一步为止，看上去已经很厉害了。

这事吧，写过程序的人都知道，后面真正的麻烦部分还没开始。

一旦真的要用在业务里，问题马上就暴露出来了：部署、扩容、版本、域名、发布、运维，这些环节一个都绕不开，最后还是要把东西交回给懂工程的人。

这也是为什么很多工程师不看好 Vibe Coding 的原因。

但扣子这次提出了 Vibe Infra 的概念，本质上它就是在为 Vibe Coding 这种新的软件构建方式，专门重新设计了一套云基础设施。

只是这个基础设施，不再要求用户理解服务器、部署流程或者运维细节，而是默认这些东西就应该被系统兜住。

2

我们上手操作下大家就能理解了。

今年我一直有个念头，想给孩子做一个小应用，专门用来帮他慢慢把作文这件事理顺。

我慢慢意识到，作文这件事，本身就不只是写字和拿分数。

它更像是一条很长的线，串着一个孩子怎么观察世界，怎么记录感受，怎么一点点学会表达内心。

如果能把这些过程留下来，其实特别珍贵。

过去要在扣子中做一个类似的工作流，我需要找到 OCR 的插件，识别到孩子的作文后，再存储到数据库中，最后再调用大模型，给出具体的作文反馈。

多少还是有点复杂。但现在，我们只需要用自然语言说出来自己的想法就可以了。

这是具体的生成过程，能够看到，它在理解需求后，会评估现有的项目结构，然后制定计划。

下面这是它整个计划的一部分：

类似的思考过程很长：

等了大概五分钟后，我在右侧预览界面看到工作流已经成形：

看起来很完整，从上传作文到 OCR 识别，再到保存作文记录，还有给孩子最终的反馈，这些关键节点都有了。

确实比之前一个个手动创建快很多，而且这一下，对于普通的小白用户来说，也没有门槛。

要是之前，类似的工作，对于一个没有编程基础的人来说，我觉得至少也得半天时间学习和试错才能搞定。

随便点开两个节点，我们看看是否准确。下面这是生成作文反馈的。不错，提示词都帮忙写好了。

再看看保存作文记录的节点，也没什么问题。

点击试运行，我们跑一次工作流，看看能否成功：

成功了：

下面这是生成的音频效果：

声音效果很不错，表达自然。但我觉得最好还是一个小孩子来读比较好。所以，咱们继续优化：

等了大概 30 秒后，我看到已经完成更新。点开查看修改记录，可以看到具体的修改详情。

也就是说，它已经内置了版本管理，我们可以随时回到过去的任何一个版本中。

继续试运行看看，这次我给大家录个屏：

我们再看看这次修改后的音频，效果好太多了：

搞定之后，我们部署看看。

已经部署成功了，可以通过 API 的方式调用：

除了工作流之外，扣子还可以生成智能体、网页应用、移动应用。

网页应用这里，我惊喜的发现，它可以绑定域名。这意味着我们可以在扣子中，端到端做一个真正面向最终用户的产品了。

3

回忆了一下，以前要搭一个类似的工作流，我通常得先把需求拆清楚，想好哪些步骤要单独拿出来做节点。

接着再去创建这些节点，比如存储、OCR、大模型调用、音频生成之类的能力。

等这些都准备好，最后才是把节点一一连起来，反复调试，看哪里还需要加判断，哪里顺序不对。

对我这种已经算熟手的人来说，这一整套下来，怎么也得一个小时起步。中间只要有一个环节想错了，就得推翻重来。

更别说那些没有编程基础的用户了，很多时候光是理解每个节点在干什么，就已经很吃力。

而这一次，用扣子编程的时候，我明显感觉节奏变了。

我没有从节点开始，也没有先画流程图，而是先把想做的事情完整说了一遍。系统很快给了我一个能跑的版本，流程已经帮我拆好了。

接下来我做的事情，更像是在校对和微调，而不是从零开始搭建。

这种变化带来的最大不同，不是速度有多快，而是心理负担小了很多。

我不需要一开始就站在工程师视角思考全局，而是可以边用边改，在对话中逐步把东西打磨到可用的状态。

对熟手来说，省时间。对非技术用户来说，可能是第一次真的可以简单的构建要给自己需要的东西。

像前面我构建的工作流，完全可以由一个运营或者产品同学来干，他们在具体的业务里，清楚需求，构建完之后，再把 API 给到研发同事就可以了。

再或者，如果不需要工作流，也可以直接创建一个网页应用。

扣子负责人说：告别拖拽，并不是否定过去探索，而是希望大家能够从机械的操作中解放出来，回到编程最本质的乐趣。

现在是周日的晚上，这篇文章我也基本写完了。到这里，我对扣子负责人的话有了更多共鸣。

编程最本质的乐趣，其实只有一件事：把一个模糊的想法，慢慢变成一个真实可用的东西。

创作的乐趣并不局限于写代码。

哪怕是用自然语言和系统反复对话，只要我们仍然在做判断、取舍、验证、修正，只要你能清楚地感受到因果和反馈，那种创造的快感就还在。

文章来自于“AI产品阿颖”，作者 “阿颖”。