种子轮拿到数百万美元融资、估值近千万，朱啸虎的金沙江创投、高瓴创投和 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 编辑整理。

---

超 17000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。

邀请从业者、开发人员和创业者，飞书扫码加群：

 

 

进群后，你有机会得到：

• 最新、最值得关注的 AI 新品资讯；
• 不定期赠送热门新品的邀请码、会员码；
• 最精准的AI产品曝光渠道

---

 

01

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

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

 

02

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

 

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 里快速选出最相关的那一个？这些都有非常明确的优化空间，也都有清晰的反馈指标，推动产品持续迭代，这就是我们所说的「数据飞轮」。

 

03

从画布到 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」的产品形态，才算彻底想明白。

 

04

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

 

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

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

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

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

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

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

我们的原则是：

• 在「非重度」方向，每个方向至少招一个特别优秀的人，把这件事完整跑通，只有在确实需要扩张时才上第二个、第三个。
• 在「重度」方向，比如研发、算法、模型调优，会投入更多人力。

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

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

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

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

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

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

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

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

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

• 方向未来一定会变化；
• 会遇到各种突发情况，比如核心同学离职，或者突然有一个新的大模型出来，你需要快速兼容、改造；
• 很多机会窗口期很短，人不够就会明显跟不上节奏。

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

 

05

站在模型肩膀上做产品，

才不会被取代

 

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。所以我觉得第一次创业不要搞那么大，简单点，先搞出来，人生还很长，一点点来。

 

06

创业早期可以慢一点，

关键是「别做错事」

 

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