朱啸虎投资，Refly.AI黄巍：n8n、扣子太难用，Vibe Workflow才是更大众的解决方案

种子轮拿到数百万美元融资、估值近千万，朱啸虎的金沙江创投、高瓴创投和 Classin 共同投资。

Refly.AI 给自己的定位是更适合大众的 Vibe Workflow 产品。

为什么要做 Vibe Workflow？原因很简单，现在的 Workflow 产品 n8n、扣子都太难用，以及团队对于 Workflow 价值的认可。

他们的目标，是让不会技术的人也能轻松把自己的流程经验复制并分享给其他人，实现价值。

不仅仅是用 AI 来降低搭建 Workflow 的难度，Refly.AI 还把 n8n 中的节点升级成为单独的 agent，每个 agent 配上 2-3 个工具。在保留 agent 动态性的同时，获得传统 Workflow 的可控性与稳定性。

看起来有些激进，但 Refly.AI 确信这样的方式才是有效利用模型能力的最好方式。

为什么如此笃定？既然做 Workflow，怎么控制成本，怎么保证完成度？Refly.AI 取代 n8n 的底气又来自哪里？

在 Refly.AI 的新版本发布之际，我们和创始人& CEO 黄巍聊了聊，想搞清楚，AI-native 的 Workflow 应该长什么样。

以下内容经 Founder Park 编辑整理。

Vibe Workflow：

agent 的智能+workflow 的可控

Founder Park：Refly.AI 现阶段的功能定位，也就是 Vibe Workflow，应该怎么理解？

黄巍：从 AGI 发展主线来看，一端是以 Manus 为代表的 Agent 形态，本质上这是一套基于自然语言驱动的 Workflow：用户给出一句指令，系统自动完成后续任务。另一端则是以 n8n、Dify 或纯代码为代表的传统 Workflow，更强调精确性，可以对程序行为进行细致建模。

在实际使用中，这两种都存在明显问题。以 Manus 为例，整体成本高、稳定性不足、执行时间难以预期，更关键的是，同一位用户多次提交相同指令时，产出的结果往往并不一致。而在 n8n 或 Dify 等工具中，一旦流程稍微复杂，就需要通过编写代码来维护 if-else 等控制逻辑，对非程序员用户非常不友好，也抬高了使用门槛。

我们认为 Workflow 本身有价值，希望在保留 Agent 动态性的同时，获得传统 Workflow 的可控性与稳定性，所以把 Agent 和 Workflow 结合，统称为「Vibe Workflow」。

它的核心特点有几层：

首先，搭建成本无限降低，一句话就可以搭 Workflow。产品的核心在于将 Agent 进行白盒化，提供一套「Agent Editor」，并在此基础上对 Workflow 的底层结构进行了重构：每一个节点本身都是一个 Agent，用户只需为 Agent 编写 prompt、选择合适的 tools，系统即可完成多步规划与问题求解；相比之下，传统 Workflow 中的单个节点往往只负责调用一个 API 或执行一段代码。

第二，我们给每个 Agent 一台沙箱，让它操作电脑去写代码、根据我们给的 tools 做数据拉取等操作，再做可视化呈现，解决 if-else 逻辑。传统 Workflow 里复杂的 code 流程，现在全都可以省略，变成一个节点。内部测试显示，在相同任务下，一个 Refly.AI 节点可以替代大约 20 个 n8n 节点的功能。

Refly.AI 的交互形式

这样，用户面向的 Workflow 被极大地简化了，所有操作都是自然语言表达，不需要懂搭建逻辑。同时，我们让每个节点任务足够简单，即使像 Kimi K2 这样的模型，也能近乎 100% 完美解决问题。再通过稳定的编排引擎串联起来，只要我们的节点数量和复杂度上去了，理论上我们可以解决无限的问题。在我们内部有一个说法，Refly.AI 已经达到了所谓的 AGI。

Founder Park：如果每个节点都是一个 Agent，成本会比 n8n 贵很多，会比 Manus 便宜很多吗？

黄巍：整体算下来，通过 copilot 配合，用 n8n 搭一个 8 到 10 个节点的流程，可能要花 3 到 6 个小时，加上中间的调试成本，估计至少也是大几十万 token 的消耗。但是在 Refly.AI，一句话生成 Workflow 本身消耗的 token 是非常低的，可能也就几千甚至上万个 token，现在 Kimi K2 这样的模型已经能够非常好地完成这个任务。

执行层面，我们让每个任务都变得简单，每个任务被简化为简短具体的 Prompt，可一次性执行完毕。该过程仅消耗 1 至 2 个积分，成本约 0.1 至 1 元。相比 Manus 单任务数美元的成本，这降低了至少 5 至 7 倍，而且其他人可以复用这个成果。后续调用时，token 消耗可能仅为原本的 50% 甚至 10%。

Founder Park：传统 n8n 的很多节点有确定的结果。但你们的 workflow 有四五个 Agent 节点，如果每个节点输出确定性达不到 100%，四五个节点下来，折损就会比较大。这个怎么解决？

黄巍：这是这是产品选择上的一个折中。既然选择了 Vibe Workflow，并且每个节点都是 Agent，肯定达不到 n8n 的准确度。我们放弃了一部分的准确性和稳定性，去换取更大用户规模的使用。

核心策略在于通过大幅降低使用成本与门槛，来平衡用户对准确率的诉求。本质上，这是试图用门槛降低 10 倍的优势，去换取稳定性降低 1 到 2 倍的代价。

我们的场景和 n8n 也不一样。n8n 多用于 RSS 监听与分析，而我们更强调内容产出。用户组合多模态、音频、视频模型，产出一篇报告或一个数字人视频。这些模态对准确率的要求不高，只要 70% 内容是对的，听上去有用，用户就觉得 OK。

我们完全放弃算了数字或企业自动化操作这种非常准确的场景。虽然是 workflow，但更强调为用户产出一个创作结果，比如小红书文案或概念讲解 PPT，用户获取结果后可下载并进行二次微调。

我们希望为用户提供 80% 有用的结果，用户愿意为它付费，并做二次编辑。未来我们还会提供大量的编辑能力，让用户闭环地完成编辑工作，但这是长远考虑。

Founder Park：也就是说，Refly.AI 现在能满足大部分 C 端用户有 AI 参与的一些内容生成型的任务。

黄巍：对，我们不是做那种企业里需要 100% 稳定的 automation 任务。

Founder Park：那你们现在定义的核心用户画像大概是什么样子的？

黄巍：早期，我们更倾向于那些有 n8n、Dify 使用经验，但觉得搭建很复杂，或者在寻求简单替代方案的用户。以前他可能用了别人的 Workflow，或者复刻某个大 V 的 Workflow，觉得挺好用，但自己不会改。

我们希望这群人来到我们平台，为此，我们在产品设计里有一个非常重要的动作，就是把 n8n、Claude Skills 或者其他 Workflow 平台做迁移，甚至是产品化的迁移功能。也就是说，你可以一键把那边的东西导过来，放在我们平台上运行。这是我们的第一批用户。

第二个场景，是我们自己有体感、也确实能解决问题的场景，就是现在定义的自媒体场景。为什么选这个？因为我们发现，现在模型每天都在更新，今天是 Gemini，明天是 Claude Opus。这些模型单点使用不会产生多大作用，但很多自媒体用户想把它们串起来，比如把 Claude Opus 和 Gemini 串成两到三个节点的工作流，做一个完整的产出，然后拿它去写文章、录视频。这类需求非常多。

另外，还有很多用户觉得每天跟热点压力很大，经常跟不过来。那能不能用 Refly.AI 搭一个工作流，每天自动抓热点，再按照自己的风格，批量生成文章或播客内容，然后去做推广和投放？我们自己也活跃在 Twitter，有大概 3 万粉丝，对这个场景有比较强的实感，也看到这里确实需要这样的工具。所以这是我们第二波重点的小规模场景：一方面我们有体感，另一方面用户确实有需求。

第三个方面，是这个方向的 ROI 和放大效应都非常大。如果有一个自媒体用户觉得这个工具有价值，用起来了，其实就相当于把他的粉丝一并覆盖和辐射到了。这也是我们早期重点面向的用户群。

在这个基础上，如果我们能把自媒体场景打深打透，还可以继续向外扩张。比如教育场景，或者职场白领场景，像写报告、监控内容、做产品分析等；再比如偏金融场景：某个财报发布了，希望基于它，用「巴菲特视角」写一篇财报分析等等。我们往外扩的时候，会更多聚焦在这类偏赚钱、偏职场、偏教育的场景。

用户的行为数据才是真正的数据飞轮

Founder Park：你们希望用足够多的 Workflow 模板来帮助很多普通用户解决他们的痛点问题。用 Workflow，是现阶段解决这个问题比较好的方式吗？

黄巍：从长期来看，理想状态当然是：用户只需要说一句话，系统就能端到端帮他把事情做完。这是一个大家都在追求的美好愿景。但就目前来说，大家对模型的发展和能力边界都有一个基本共识：模型可以解决一部分问题，但仍然离不开人的参与。

所以现在会有「Context Engineer」这样的角色，强调要充分感知用户丰富的 context 和 memory。模型有能力解决问题、调用工具、写代码，但前提是：它要真正理解你的 context，要「活在」你的 environment 里，跟你保持同频协作，才能更好地帮你解决问题。

我们提出 Vibe Workflow，就是希望先把这个环境 build 出来：用户来到 Refly.AI，可以把自己的知识，以及更重要的——自己的行为（action）沉淀下来。

Action 是最关键的。

在传统的 Dify 时代，大家更多只讲「知识库」：你把知识丢进来，但知识本身的价值有限，因为模型不知道用户在真实完成一个任务时，具体的执行步骤是怎么走的，用户的思考路径是什么。缺少行为，这些知识其实很难发挥真正价值。

在 Refly.AI 里，从技术底层看，用户在跟 AI 交互的过程中，其实是在同步沉淀知识 + 行为。举个例子：你有一个需求，要抓 Product Hunt 上的内容发到自己邮箱。在这个过程中，你会不断表达个性化偏好：想抓周榜、日榜还是月榜？你希望抓完之后不仅生成音频，还想生成一个「双口相声」版本发给你？这些都是你的 preference。

在这个过程中，模型帮用户完成了第一层冷启动，而用户把个性化知识融进了自己的行为里，这整套交互就构成了用户和 Workflow 之间的一种「个性化经验 + action」。

对平台来说，这意味着：我们采集到了你最有价值的数据——你是如何围绕一个任务，完成一系列行为的。这有点类似今年大家常提到的 DeepSeek 的「思维链数据」：即模型在完成一个任务时，每一步的思考和执行路径。我们其实就在帮助用户沉淀这种「思维链行为数据」。

Refly.AI 目前推荐的 Workflow 模板

第二点是：一个用户在工作场景中的思维模式，其实是相对有限且可枚举的。比如一个内容工作者，日常工作大体就是几条路径：关注热点 → 做选题 → 产出内容 → 做分发。这些行为是可以被枚举出来的。

这就意味着，一旦平台能够把你的这些行为路径都枚举出来，真正感知到你作为内容创作者，在这个环境里可能产生的各种动作，我们就可以对「你这个人」做一个建模：在下一个时间点，出现类似情境时，你大概率会采取什么 action，我们是可以去做「predict next action」的。

有了这样的数据和预测能力，本质上我们就是在收集大规模用户在工作场景中的行为数据。

当数据量足够大，再配合持续的算法设计和尝试，我们就可以迈向下一步：在未来的移动端场景里，用户来到 Refly.AI，只需要表达一句话，我们就可以真正实现端到端、无接管地帮他把任务做完，而且结果是高度符合他个人习惯和预期的——因为我们掌握的是他最关键的行为数据。

这就是我们的一个更长远的目标：通过持续收集和建模用户的 action 行为数据，在工作场景下，有可能率先实现一种真正意义上的 AGI——一句话，端到端、无接管地帮你把工作执行完。这是我们长期的思考方向。

Founder Park：也就是说，Workflow 只是你们切入这个事情现阶段的一种方式。

黄巍：对，它既是一种切入方式，也是收集用户 action 和思维链数据的最好方式。我们是在搭建一个环境，用来收集用户最有价值的数据。

如果只是一款 chatbot 产品，跟用户简单聊几句，没有任何真实的行为交互，你几乎收集不到他的行为数据。你最多知道他喜欢什么、不喜欢什么、现在在哪里，这类数据是非常浅的。我们希望走得更深一层，真正感知用户的 preference、action，以及他是如何完成一项工作的。我们认为，Workflow 是一个非常好的环境和媒介。

所以我们的出发点就是：把 Workflow 这件事做得足够简单，让更多人进来用。比如用户量从 20 万扩展到 2000 万，一旦有了这种规模的数据和偏好，我们就有能力去做「predict next action」——预测用户下一步行为。 这其实就是我们在技术层面更底层的意义。

Founder Park： 如果用户需求的 Workflow 是由模型给他生成的，那你们想要收集的 action 具体是指哪些？

黄巍： 如果你让 AI 帮你完成一件事，模型一次性就搞定了，那我们其实收集不到什么有价值的数据。我们真正希望看到的是那些中长程、复杂问题的解决过程。

在 Refly.AI 里，一个节点大致相当于 n8n 里的很多节点，我们等于是把底层那些细碎、价值不高的 action 屏蔽掉了。真正有价值的是：当用户要完成一个动作，需要很多步，而模型一次性解决不了，他就不得不和模型持续交互。

模型先生成一个 Workflow，如果用户去改某个节点的 tool 或 prompt，这其实就是在给模型做「审阅和反馈」——这是第一层反馈。

第二层是：以模型当前的能力，一次生成不到你想要的结果是很常见的。你在第二阶段、第三阶段继续生成，这些新生成要怎么基于现有的内容去参考和调整？这里面又会产生一轮反馈和交互。

最后，当你经过多次生成和修改，觉得这个 Workflow 差不多达到了目标，就会去运行它。如果这次运行没有报错、结果符合预期，这本身就是一次非常强的正反馈：说明你和 AI 之间围绕这个任务的整个交互路径，是成功的。

对我们来说，这意味着我们拿到了用户在完成一个中长程、甚至更复杂任务的过程中，如何和 AI 交互，以及如何判断任务对不对、好不好的一整套强反馈信号。

而且，这个 Workflow 还可以被发布成模板到社区。其他用户来跑，如果觉得解决了自己的问题，会去评分、点赞，这又形成了新一层反馈。

所以在这个环境里，我们可以持续拿到多维度的反馈数据：

• 这个任务最终有没有价值？完成过程中需要人接管多少次？

• 整体完成效率高不高？比如：

• 之前他要一个小时才能做完，下次是不是能缩短到半小时？

• 现在要消耗 80 万个 token，未来能不能优化到 40 万？

• 之前必须用 Claude Sonnet 4，能不能在不损失效果的前提下换成 Kimi K2？

在这些维度上，其实都有非常多可以优化的空间和场景。

Founder Park：这些 action 数据可以形成数据飞轮吗？

黄巍：简单来说有几个层面：如果模型一次性生成，用户觉得结果很好，直接分享出去，这本身就是一个正向反馈；但如果用户需要反复交互、多次人工接管，或者觉得使用成本很高，这些也是非常有价值的反馈信号，会促使我们去优化产品，比如：能不能把原来需要三次接管，优化成一次甚至零次？

和传统 chatbot 不同的是，在那里用户问完一个问题转身就走，你很难拿到完整的反馈链路。而在我们的产品里，用户是带着一个明确目标来的：从提出需求，到完成目标，中间必须走完一条清晰的路径，整个流程会在系统里被完整记录。

在这个过程中，用户一方面会贡献自己的经验，另一方面也会直接给 AI 反馈：哪里错了、哪里没有满足预期。可能一开始，用户和 AI 需要三轮交互才能达成目标，我们的目标就是把这个交互次数、时间成本不断往下压，让效率越来越高。

基于这些数据，我们可以持续优化 prompt 和我们自己微调的小模型。比如：AI 怎么更好地根据用户意图拆分任务？怎么在上千个 tools 里快速选出最相关的那一个？这些都有非常明确的优化空间，也都有清晰的反馈指标，推动产品持续迭代，这就是我们所说的「数据飞轮」。

从画布到 workflow，

做能 scale、低门槛的产品

Founder Park：Refly.AI 从之前的画布定位到现在 vibe workflow，这中间经历了哪些变化？

黄巍：现在这个产品形态，跟我之前在飞书的经历有很大关系。

我在飞书负责过字节最早一批「大模型 + 低代码 + Workflow」的项目 Aily，Coze 的核心成员也来自那支团队。所以，我们这批人对「AI + Workflow」有比较系统的认知。我自己在飞书做过程序员、产品、销售、设计和运营等各种岗位，等于把第一代低代码 Workflow 的全链路都跑了一遍：数据建模、流程编排、界面搭建、发布运营和权限体系。

第二阶段，是我们在飞书内部做的「AI 前沿 + 低代码」项目。简单说，就是用 AI 重构低代码的所有模块：AI 生成数据模型、生成流程、生成界面，甚至生成全栈应用。后来这个方向产品化，变成了 Aily。我们当时有一个判断：在 AI 时代，低代码会长出一种新形态——只要有一个足够强的 Workflow，就能承载搭建 App 的全过程。界面可以交给 AI 生成，数据可以作为 Workflow 的一个 tool，在流程运行过程中读写。

但产品对外之后，我们发现一个现实问题：即使给 Workflow 加了 AI，故事很美好、内部体验也不错，普通用户依然用不起来。本质形态还是传统 Workflow，只是加了一些 AI 节点，更像是 n8n 的进化版。我的总结是两点：

第一，Workflow 的价值是确定的，但要真正规模化，一定要让普通人能用得上；

第二，用户愿意为「先进的生产经验和流程」付费——飞书之所以能卖出去，很重要的一点是，大家希望买到的是字节跳动这家公司的先进流程。

这也是 Refly.AI 商业化的核心假设：如果一个流程本身有价值，把它封装起来，是可以被规模化销售的。

即使不会搭建 Workflow，也可以找到自己需要的直接运行。

回到创业。我们一开始就想做 Workflow，但两个人团队上来就啃这么大的工程不现实，所以先从一个更小的切口做起：围绕「用户的 context 很有价值」这个命题，做了一个剪藏插件，让用户保存文章，再基于文章做总结和每日归档。后来发现最大的问题是 data connection 很难规模化，这条路就暂时放下了。

紧接着，随着 ChatGPT Canvas 和 Claude Artifacts 出来，我们意识到：如果已经收集了那么多 context，只做「总结」太浪费了，应该让用户在这上面写东西、创作内容，也就是 DeepResearch 的最初形态。但我们很快发现，这种形态要管理大量复杂 context，对普通用户的门槛非常高。

于是我们切到「画布」形态，把这个产品推向市场，结果火得很快，也顺利拿到了一轮融资。融资之后我开始反思：虽然有一批愿意付费的用户，但大多是专业用户，小白用户还是看不懂、用不顺。这时候我们有了资源，就回到最初想做的事情——Workflow。

接下来，我们做了几层降复杂度的尝试：

• 第一步，把原来一个画布里可能上百个节点，收敛成只针对一个具体问题的 5–8 个节点的 Workflow；

• 第二步，在此基础上引入 agent，让 AI 来生成 Workflow 本身，进一步降低搭建成本。

再往下，就是现在的路径：从「深度画布」到「可落地的 Workflow」，再到「把 Workflow 封装成一个个模板」。这意味着，大部分用户只需要消费别人封装好的流程，少部分高阶用户来生产和分享流程。通过这一系列演进，我们一边降低复杂度，一边放大使用的泛化性，让「AI + Workflow」真正有机会被更广泛的人用起来。

Founder Park：这算是你们几次不同方向的探索吗？还是在你看来核心方向是一致的？

黄巍：对我来说，这是一个从模糊到逐渐确定的过程。

我决定创业，一个很直接的原因是参与了字节第一批超大规模的「AI + Workflow」项目。那段时间节奏非常高强度，项目结束后再回到常规的上班状态，明显有种「打完仗又回去种田」的不适应，所以干脆选择出来试一试。

刚出来的时候，其实并没有想清楚要做什么方向。因为在飞书期间做过浏览器插件，就先把这段经验用起来，再加上看到 Monica 这类产品，有些被「点燃」了，就先动手做起来。具体要做到哪里、产品最终会长成什么样，当时并不明确。

后面更多是边做边学，通过不断和用户交互，一点点看清哪些是真需求、哪些有机会被更多人用，于是产品方向也就从一开始的模糊，逐步收敛到后来相对确定的形态。

Founder Park：也就是说，一开始从字节出来时，你其实还没下定决心要继续做 workflow，只是先往前走。做到画布这个形态时，验证出了一些基础的 PMF，你们觉得这条路可以走下去，而这条路又刚好和你之前对「用 Workflow 形式来承载」的想法接上了。

黄巍：对，是这么一个思考的过程。

Founder Park：整个团队在这个产品上真正「找到感觉」，大概是哪个时间点？

黄巍：如果说一个明确的时间节点，是 8 月上旬。那时候投资人提醒我们，今年要再做一轮融资，我们也在想：下一轮要讲什么故事？当时我们手里有一款生成式画布产品，用户和收入都不错，但我心里一直觉得，有点「解释不清楚」。这个形态很复杂，我很难想象它的长期走向，直觉上它不是一个能 scale 的好形态。

其实这款画布之前在市场上是爆过的。大概在 3 月份，推特上有好几周大家都在讨论 Refly.AI，很多投资人来找我们。但说实话，我们当时也没完全搞清楚它为什么会爆，只是顺着用户需求一路做下来，做着做着就火了，然后去拿融资。等融资回来、冷静下来再看，问题就很清晰：这个产品很难 scale。

再加上 8 月份的压力，我们之前有这个经历，又从画布过渡到 Workflow，有了一些技术上和产品上的积累，觉得这个事情是很容易去做的，就试着去做一下。

但实践下来没有那么容易。从 8 月确定要做，到 9 月初我们做出了第一个版本，但那个版本问题非常多。之后一个多月，我们一边修 bug，一边在这些问题中找平衡点。画布转到 Workflow，本身就有很多历史债务要清，同时还要重新思考：这个形态怎么 scale、怎么商业化。折腾到 11 月底，整体才算相对稳定下来。

有了这次转型的经历，我们发现这条路在逻辑上非常自洽，而且和团队背景高度匹配。后面我们招人也是往这个思路上靠。我们这支团队现在在「Vibe Workflow」的赛道里面，可能就是全球最有竞争力的团队。我们对这个事情的理解是最深的，做的产品也最超前。

Founder Park：现在这个 Vibe Workflow 的产品，彻底想清楚的时候，是有什么特殊契机吗？

黄巍：大概是 8 月初有了一个模糊的想法，到 8 月底整个产品架构才真正被想清楚。

这个产品本身是分层的，工程复杂度非常高：

• 第一层，是让 agent 来生成 Workflow，本身 Workflow 的设计就得适合被 agent 生成。现在像 n8n、Dify，要做到这一点会有比较重的历史包袱。

• 第二层，是把 Workflow 设计成「每个节点本身就是一个 agent」，再通过执行引擎把这些 agent 串起来，这一层工程量也很大。

• 第三层，要让 Workflow 真正有价值，就必须有成规模的 tools 体系，覆盖 input、action、output 等不同类型。光 tools 这一层，单独拎出来都可以是一个创业方向。在此基础上，我们又给 agent 配了一台「虚拟电脑」，让它能写代码、调用 tools、操作文件，从而把类似 n8n 那种搭建复杂度进一步压下去。

这几层叠在一起，不是一个普通团队可以轻易抄过去就跑起来的。

我们当时的思路是从画布产品一路推演过来的。那时候我们已经把多模态能力都加进来了，可以在画布里生成视频、音频等各种东西。但问题也很明显：堆了这么多能力在一个画布里，用户进来根本不知道第一步要干什么、下一步该怎么走。一方面是产品引导本身有问题，另一方面，我当时心里其实已经隐约在想 Workflow 这条路，但还没下决心去落地。

转折点是，我们招了一些很优秀的同事进来。有一次我把这个 Workflow 的想法讲给他听，他周末花了两天，把一个完整方案写了出来。我们看完之后觉得：这件事情是说得通的，那就开始干吧。

后面边做边验证，大概半个月左右，我们发现这个方案不仅在工程上是闭环的，还把我们之前很多的疑惑都解释清楚了：哪些方向其实不适合我们做，哪些地方是我们真正有竞争力的。这时候，我们对「Vibe Workflow」的产品形态，才算彻底想明白。

我们不相信「一人公司」的通才理论

Founder Park：你们团队现在大概十三四个人，分工是什么样子的？

黄巍：我们在测试这件事上踩过很大的坑。

我之前在公司里很多角色都干过，唯独没做过测试，写代码也基本不写测试，所以一开始对测试的价值是有偏见的。扩团队时，我理想中的研发同学是那种端到端的人：既懂用户需求，又能写代码、自己测、自己上线，看结果复盘。后来发现，这种人早期很难大规模招到，要么在明星创业公司，要么在大厂里，我们又没做 PR，在市场上声量有限。

其次，我们的产品因为是 Workflow，很复杂，好多 bug。我们发了一版测试版给用户去用，全是 bug。当时痛定思痛，觉得得招个测试进来。两天之内就招到了人，进来之后，整个节奏立刻不一样：测试同学每天 push 我们修问题，产品质量稳定性肉眼可见地上来了。

在这个基础之上我懂得一个道理，现在大家鼓吹的所谓「一人公司」，或者一个人可以把所有事情干完，我觉得是很美好的愿望。但互联网分工这套方法论，已经被无数家公司验证过，我们不应该把它丢弃掉。

我们的教训是：团队职能一定要尽量完备——产品、运营、增长、设计、测试、研发、算法都要有人，才不会在关键环节出现盲区。

我们的原则是：

• 在「非重度」方向，每个方向至少招一个特别优秀的人，把这件事完整跑通，只有在确实需要扩张时才上第二个、第三个。

• 在「重度」方向，比如研发、算法、模型调优，会投入更多人力。

现在团队大致的分工是：所有方向上至少有一个能把事情落地的人。在研发层面，一部分人做偏运营向的开发，大概两个人；做模型和工程调优的，两到三个人；再做底层的 workflow 和 tools 基座开发的，三到四个人。大概是这么一个分工。

Founder Park：现在大家讲究 AI 时代的团队是招一些通才，但你这边好像是要招一些在确定岗位上很擅长的人，这会有矛盾吗？

黄巍：我们是从 0 开始摸爬滚打过来的，对这一点的感受非常直接：通才当然重要，但前提是你真的能招到通才。这有点像「通用 agent」——大家都在说，但现实里没那么多。

现实情况是，模型的能力没有大家鼓吹的那么厉害，没达到替代一个人的地步。比如模型不会让一个写代码的人去搞设计，他能搞点轻微的设计，但搞不了生产型的设计。所以我们更强调的是，招这个领域的专才，然后我们给他加一层 AI，他比所谓的通才要好几个数量级。这一点我们现在在团队里已经验证得比较充分了。

比如我们招一个设计同学，给他配非常完备的 AI 工具，他只需要专注在把整个产品的框架设计好，尽量的兼容通用，其他的细节可以让 AI 帮他完成。我们觉得这种是一种非常高效率的协作方式。

所以对我们来说，最理想的状态就是招专才，并且是非常专、非常优秀的人，我们给他配最强大的 AI，让他把这个事情干到之前 3 到 5 倍甚至 10 倍的效果。

Founder Park：那你们现阶段还需要再扩招吗？

黄巍：会，而且是持续扩招。

我最近有一个比较坚定的结论：不管是在大公司还是创业公司，团队在人力配置上应该是「饱和式」的，而不是刚刚好够用。原因有几个：

• 方向未来一定会变化；

• 会遇到各种突发情况，比如核心同学离职，或者突然有一个新的大模型出来，你需要快速兼容、改造；

• 很多机会窗口期很短，人不够就会明显跟不上节奏。

另外，我们内部有一个共识：做好产品，和做好增长、商业化，是同等重要的事情。所以在增长这块，我们也会搭一个相对完整的团队：投放、内容、KOL 运营、增长产品经理、增长工程师，这些角色我们都会补齐。

站在模型肩膀上做产品，

才不会被取代

Founder Park：现在的大模型，给它太多工具之后会陷入不知道怎么选的地步。这个问题现在你们是怎么解决的？

黄巍：我们对 AI 的使用方式不同，我们是让它从 1000 种工具里「选择」工具，而不是直接用这些工具去「执行」。「选择」和「执行」这两个任务的复杂度是不一样的，「选择」这个任务非常简单。

要模型一边从几百上千个工具里挑，一边把活干完，这个事情太复杂了。所以我们把任务拆成两块：一个模型专门负责挑工具、写 action 和 workflow；另一个模型只负责执行具体任务。

我们每个 agent 节点实际能用的工具不超过 3 个，通常只有一到两个，对应的 prompt 也非常简单。我们的目标是：每个 agent 节点只做一件非常具体的小事，一到两个工具就能搞定，然后把复杂任务拆成 5～10 个这样的小任务。

这样做有两个好处：

• 不同模型各司其职。像 Kimi K2 这种适合执行的模型，就专注把单个步骤做好——便宜、准、稳定、速度快；像 GPT-5、Claude Sonnet 4.5 这种更强的模型，就负责从成千上万的工具中筛选、规划，把任务拆解成一条条可执行的 workflow。
• 我们可以用一个稳定的编排引擎，把这些简单节点串起来，完成非常复杂的任务，而不是指望某一个「大而全」的 agent。

本质上，这是我们对模型边界的一种利用方式：不用去强碰模型当下还「不擅长」的能力，而是把问题拆到模型能稳定发挥的区间，让产品形态和模型能力「贴合」增长，而不是被拖着走。

我们的产品做了一件非常巧妙的事情：让贵的、强的模型去做拆任务，让简单的模型去做执行。

这样模型能力的增长不会吃掉我们，而是会让我们变得更强。一旦我们收集到可用的数据，钱和人到位，拆任务这一层完全可以用自研或微调模型替代；执行层也可以不断优化，比如原来要 4 个节点，现在压缩到 1 个节点。

这个过程极度考验我们对模型能力、边界的认知，以及怎么去提前几个月把我们的产品放在这个点上，等待模型的增长。比如后面发了新的模型、新的 API，我们很快就可以接入，并且让用户可以一句话生成流程，去做自媒体传播。这就是我们怎么去设计产品和做增长的一些思考。

Founder Park：对 Refly.AI 来说，现在阶段的核心壁垒，是技术壁垒还是运营壁垒？

黄巍：现阶段，在我们产品还没有完全大规模面世之前，我们可能对自己的技术壁垒会有一些信心。

首先，我们可能是这个地球上最懂「AI + Workflow」的那批人。第二，我们在正式对外之前，已经组建了一支非常能打仗的团队。这是我刻意为之的，我不希望我们还没准备好就草率地暴露出去，结果这个方向火了，后续却和我们无关了，团队组织能力一定要到位。

在这个基础上，我们有一个比较清晰的产品判断：AI 越往前走，真正有价值的产品，一定是在非常复杂的系统工程之上，让用户「感知到的体验」尽可能简单。不是说产品本身要做成一个很简单的小玩具，而是底层可以极其复杂，但呈现给用户的路径要是顺滑、低门槛的。这中间要始终顺着 AI 能力的演进做设计，而不是逆势搞一些反人性的形态。

以我们目前的工程复杂度，任何一家小公司，比如 15-20 人的团队，很难在 3-6 个月之内超过我们。即便短期某些功能形态看上去追上来了，也很难知道我们下一步会做什么迭代。对大厂而言，我自己有大厂经历，要在内部复刻一个同等复杂的系统，至少得拉一个 50–100 人的团队，全力干一两年。除非我们已经证明这是一个千亿级甚至更大的市场，否则大多数大厂不会一上来就投这么重的资源。

所以，我们会给自己一个 3–6 个月的「加速窗口期」。在这段时间里，只要资金到位、增长团队到位，技术和产品这套复杂度放出去，短期应该是没有特别直接的对手，我们也有机会在市场上快速完成一轮增长和商业化验证。

Founder Park：这么设计，会不会被某一个模型厂商绑架？比如受限于单一模型的成本或能力？

黄巍：不会，反而可以说，我们现在的做法在某种意义上是偏「激进」的。

我之前跟一些字节同事聊，他们会觉得我们的方向挺超前：现在就把每个节点都改成一个 agent，再去编排 agent，这个路径是不是太早了？一开始我们自己也有类似的疑问——和 n8n 那种相对静态的 Workflow 比，我们的做法一开始确实不够稳定、成本也偏高，早期 bug 特别多，那个阶段我们也反复在问：这条路到底是不是可行的？

但一路走下来，我们会发现，这件事是说得通的：

• 每个节点都是一个 agent；

• 每个节点做尽量简单的事；

• 整条链路通过编排引擎串起来

无论未来模型怎么迭代，我们都是在模型之上再加了一层抽象，相当于「站在模型肩膀上」：模型越强，我们越强；模型越便宜，我们越便宜。同时，我们还会沉淀自己的行为数据，可以进一步优化自研模型和商业模式。

更重要的是，这个抽象层可以天然兼容不同模型、不同模态，统一放到同一套 workflow 架构里，完成数据的 INPUT、PROCESS 和 OUTPUT。这让我们不会被某一个模型厂商锁死。

Founder Park：如何不被模型所取代，除了跑得快以外，还有其他补充吗？

黄巍：我觉得核心还是认识到模型的边界。模型厂商非常懂模型，他只切了他看起来显而易见的那部分能力。但实际上，模型是一个巨大的宝藏，你可以从里面剥离出对你这个行业最有价值的那部分能力。

比如我们做 Vibe Workflow，是因为当时看到一个趋势，GPT-5 发布之后，ChatGPT 把所有的功能选择都收到了一个按钮里，希望用户只需要表达需求，它自动做路由。这对我最大的震撼是，这么大的一个产品竟然能做这个事情，意味着现在整个模型的工具调用（tool use）的速度和准确性已经迈过了那个极限。我们认识到这一点之后，就选择了 Vibe Workflow，我们觉得这个事情是一定可行的。

这个能力不像生成 PPT 那么花哨，但是它对你的产品有用，并且能产生巨大的化学效应。也就是说，模型是一个巨大的宝藏，它有很多切面。你如果能从里面找到一个切面，对你的产品产生杠杆效应，即使不需要和模型厂商竞赛也是可以的。你不要去打它的主方向，你从里面抽点皮毛出来，把你这个产品做好，至少也是一个几十亿、数百亿美金的规模。早期你的野心不要那么大，能做到 Canva 那样，就意味着我们的目标没有那么高，我们也可以切到模型的一个切面，切到自己的一块肉。

去挑选一个差异化的赛道，在这个赛道里面我们做到最大，也能活得非常好。比如马斯克的第一次创业，也不是做了特斯拉或者 SpaceX。所以我觉得第一次创业不要搞那么大，简单点，先搞出来，人生还很长，一点点来。

创业早期可以慢一点，

关键是「别做错事」

Founder Park：想象一下 Refly.AI 的终局，会成为一个 Workflow 的分发平台，还是大家创作内容的一个新平台？

黄巍：短期内，我们觉得它有可能是一个新的原生内容平台的机会。

AI 来了之后，大家都在想 AI 时代的社区和内容平台是什么样子的。AI 最大的能力在于它可以生成内容，以及它的主动性和自动化。那未来的 AI 内容平台，是不是内容可以极度个性化地定制？用户表达一句话可以生成内容，并对它做编辑、消费和修改。内容是丰富多样的，不只是视频。比如我现在需要听个播客，平台就可以实时为我生成一段只服务于我的播客, 有点像 OpenAI 现在推的 ChatGPT Pulse。

长期的终局，就像我们说的，我们拿到的是用户在一个工作生命周期里所有的行为和意图数据。那未来是不是我们能给用户一个更简单的交互方式？他只需要一个无时不在、感知不到的硬件，就能去和 AI 做交互，完成自己的任务。比如他走在路上说「你帮我开一辆特斯拉去接我的女儿」，他可以去做这种侵入到物理世界的 action，并且这个 action 本身的价值、准确率和个性化都非常高。

这是我们认为长远的、Refly.AI 希望达到的终局。我们设置了一个环境和媒介，去承接用户全方位、多维度的意图和行为数据。我们希望这些数据最终能够构建一个用户的数字化版本，能帮助用户进入到物理世界去干一些事情。

短期内，我们希望可能是在做一个 AI 原生的内容平台的机会。但更加现实一点，我们就是在卖模板，做一个很土的生意，卖 AI 时代的 Workflow 模板。

Founder Park：那你预期明年整个 AI 行业有哪些新的技术和发展，会对你们有助力？

黄巍：我自己有两个非常期待的方向。

第一，是让「修小问题」这件事真正被 AI 自动化掉。我们每天都有大量细碎的小 bug，要改代码、测、上线。理想状态是，这些小问题可以端到端地被 AI 自动修复和发布，让人从重复劳动中彻底解放出来，去做更有创造性的事情。

第二，是模型在「编辑能力」上的进步，而不只是生成。

现在模型在生成上已经很强了，但生成完一个 PPT、视频或网页之后，我还要为它造一个编辑器，让用户去细调。如果未来模型能以很低的成本精准理解 input，做细粒度的编辑，那么 Refly.AI 这类工具的上限会被大幅抬高——很多我们今天需要自己造的「编辑能力」，都可以交给模型。

那 Refly.AI 会变成什么？它会变成 AI 时代的创作者工具。以前你剪一个视频用的是剪映，发布的载体是抖音。未来，你去做内容创作，跑的是一个流程，这个流程产出的结果就是一个视频、一个音频、一个文本，甚至是一个网页。

一旦模型的编辑能力变得非常强，未来所有内容的载体其实都是一条流程，这会催生出一个 AI-native 的原生内容平台。这个内容平台相比之前最大的变化就是，它的内容是实时生产、实时更新，并且每个内容都可以由人去做个性化甚至「入镜」，按需消费。这是我们看到的，可能是下一代内容平台的机会。

Founder Park：如果现在有大厂的人或者创业者也是做 AI 应用，你会给他们什么建议？

黄巍：我只能从我自己的经验出发。我觉得看一个事情，可能要把它拉长到一个维度去看。一个事情在半年这个维度可能看上去很有价值，但拉到 1～2 年，你要问自己：这个产品还能活吗？现在大家都在讲快速落地、快速试错、快速拿结果，但从我的视角，早期可以慢一点，关键是「别做错事」。

假如我们今天来一个概念就抄，明天来一个概念就抄，没有自己的产品主张，就容易陷入「热度成瘾」。我们宁愿早期慢一点，但是一定要拉长时间维度，在这个行业内做到不可替代，把事情做对。

第二点，就是老生常谈的，它会不会被模型吃掉？这个事情一定要想清楚。你是不是在做一个模型之上的东西，还是会被模型吃掉的东西？有些人可能偷懒就不去想了，比如 OpenAI 做了浏览器，你也去做个浏览器，甚至比他做得还慢，这种是不值得去做的。

我们内部有一个心法：产品一定要比模型的能力迭代要快 3-6 个月，并且要在 3-6 个月之内把自己的想法实践落地，并推向市场和商业化。如果我们能不断地重复这样的周期，我们就能跑赢这个市场，跑赢模型厂商。

第三点建议，招人层面的，就是早期一定不要有偏见。历史上被证明有价值的分工和合作一定有它的道理，存在即合理。不要因为自己的偏见，或者因为他人表达的所谓「通才」的看法，就觉得一定就是那样的。还是要回归常识、回归本质。

早期一定要找到那种价值观和想法对齐的团队。我们也面过、发过很多背景非常优秀的人的 offer，包括给一些斯坦福的学生发过 offer。但我们会发现，虽然他们的背景和履历非常优秀，但如果把他们放在一个高压、要去战斗的环境之下，他们学校里的履历是很难派上用场的。放到一个战争的环境之下，考验的不是你答一道题的能力，而是你怎么去面对全方位的竞争，去找到自己的道路。

早期团队，确实要找到那种调性相投的，而不是一味地去看名校背景或光鲜履历。真正能打仗的人，他不一定是履历光鲜的，可能就是普普通通，但他确实能把事情干成。

注：Refly.AI 本身是开源项目，开源仓库地址：

https://github.com/refly-ai/refly

文章来自于微信公众号 “Founder Park”，作者 “Founder Park”