五度妙笔
API商城
数据库对谈CREAO：20人团队、每天上线8个功能，在Pivot产品之前，我们先Pivot了组织
CREAO 的上一个产品是一款 Vibe Coding 产品，当时的想法很明确，帮助普通人搭建他们需要的工具。
之后转型的原因也很简单，「我们公司自己做出来的产品，自己人都用不起来。」
「如果未来是 AI 来工作，AI 应该自己给自己构建工具，自己来解决问题——而不是用 AI 给人构建一个传统的软件界面。」
想明白这件事后，他们决定 pivot，但先对组织进行了 pivot。从开发流程到团队分工，全部围绕 AI 重新打造，把 95% 的工作真正交给 AI 来做。
「技术是公开的，模型是公开的，但你的组织能不能真正围绕 AI 的能力去重新构建，这才是决定胜负的东西。」
这才有了今天这款 Super Agent 产品形态的 CREAO，仍然是以 Coding Agent 为底座，但更通用、更主动、更能交付结果。
在创始人程凯看来，今天所有的 AI 产品可能都是中间态，能活到最后的，不是在某个时刻做出了最好产品的公司，而是在每一个变化节点都能最快转身的公司。产品不是护城河，组织效率和 pivot 速度才是。
CREAO 团队目前 20 人左右，新产品上线两周，目前已经完成三轮融资，累计超过 3000 万美元。
我们与 CREAO 的创始人兼 CEO 程凯、CTO Peter Pang、增长负责人 Clark Gao 聊了聊，想知道他们是如何进行 AI 组织改造，以及怎么看待通用 Agent 的竞争及未来。
产品官网：https://creao.ai/
采访 | 万户
编辑 | 夏天
Founder Park 正在持续寻找值得被看见的 AI 团队与项目。
我们将通过「AI 产品市集」、内容报道、社群分发等方式，帮你触达早期用户、获得真实反馈，以及建立关键连接。
如果你正在做 AI 相关的事，欢迎和我们聊聊。
01
「我们公司自己做出来的产品，
自己人都用不起来」
Founder Park：先聊聊团队和创业的过程，你们是怎么走到今天这个方向的？
程凯：公司是 2025 年 1 月底成立的，但 95% 以上的人是 6 月份才到位。之前方向没搞清楚，没必要招那么多人。核心团队六七个人，有中国人也有外国人。
我们几个人有一个共识：AI 的估值泡沫很大，但如果这些能力没有办法被应用在真实的工作环境里，它就没有太大价值，配不上这些估值。社会对 AI 的期待，本质是「能提升生产力和效率」，但企业端和工作场景里用不起来，一切都没有意义。
这是我们做 CREAO 最初的出发点。
我们一直想做的就是一件事：让所有人用 AI 把自己的工作任务给自动化。这个事情虽然听起来普通，但这就是今天 OpenAI、Anthropic 都在做的方向——只有把这个方向真正解决了，技术才能带来本质的效率提升。
但为了解决这个问题，我们走了一条很曲折的路。
最早，我们觉得 AI 是个辅助工具，像用 ChatGPT 聊天，让它回答问题，做一些辅助性工作等。这个阶段很快就过去了，因为 AI 能力在快速提升，能做的事情越来越复杂。
我们意识到，如果你想在工作场景里帮人解决任务，最根本的能力是一个 Coding Agent——这也是我们产品最核心的底层。为什么是 Coding Agent？因为它是最小单元的自由度：通过写代码，你可以实现任何东西的自定义，可以帮任何人构建他们需要的工具。
但在 25 年 6 月那个时间点，我们的认知还停留在「给人构建传统工具」上。
我们做了第一版产品，类似 Vibe Coding 平台，9 月份上线。核心逻辑是：用 Coding Agent 帮普通人快速搭建 SaaS 应用、CRM、各种工具软件。但做出来之后发现：就算应用搭出来了，也没有那些专业 SaaS 公司做的软件好，有各种 bug，需要很长时间调优，我们自己用起来也很复杂。
问题在哪？我们当时没想明白的是：如果未来是 AI 来工作，AI 应该自己给自己构建工具，自己来解决问题——而不是用 AI 给人构建一个传统的软件界面。
那些传统 SaaS 软件，本质是给人用的，才会有交互、有界面、有各种各样的操作元素。但如果未来是 AI 主导工作，它为什么需要这些？AI 不需要理解 UI，AI 不需要交互界面。
产品一直在变：最早是类似 Dify 的工作流工具，去年 6 月做了 Vibe Coding 平台、9 月上线，今年 1 月把整个平台变成 Super Agent。
Founder Park：什么时候你们意识到要转方向？
程凯：转折点很简单——我们公司自己做出来的产品，自己人都用不起来。
我们花在「构建这些应用」上的时间，远远大于「最后用这个应用」的时间。Vibe Coding 那版产品，我们公司可能连两三个真正能用的应用都很难搭出来。而一个好的 AI 产品，应该是像我们今天这样——90% 以上的工作流都可以用 AI 来完成。
Peter：从技术和市场的角度，Vibe Coding 这条路有几个问题。
第一，大家做出来的产品还是传统的 Web 应用，本身缺乏 AI 能力。随着 agent 越来越成熟，这类有界面的产品需求是逐渐萎缩的，是一个在缩小的市场。
第二，SaaS 行业基本上赢者通吃，你很快做出来的原型，作为一个正式产品来说，并没有太大的长远可持续性——因为愿意认真打磨这类产品的公司，会把它做得越来越好，而你这个原型的价值就有限了。并且这个赛道上已经有 Lovable 这样的公司站在那里了。
所以从市场未来的发展、竞争者的情况来看，在 Vibe Coding 路径上持续投入，不是一个明智的选择。
Founder Park：所以回头来看，面向普通人的 Vibe Coding 其实是绕弯路？
Peter：大部分人想要的是解决自己的问题，这是知识工作者的核心需求。「给别人开发一个 App」是金字塔顶端极少数人才有的诉求。Notion 很早就走过这条路了，但这整个赛道本身有一个限制：有这种需求的人是少数，而且一年也不会天天想着给别人开发新服务。这是一个低频场景。
Clark：从产品形态和市场认知角度讲确实是这样。但对我们公司来说，这是一条必经的路。我们的 Coding Agent 作为核心产品模块，需要学习如何构建它、如何驯化它，才能为今天直接交付结果的产品形态服务。所以对我们来说不是弯路，反而让我们有了更好的经验。
但从大众认知角度讲，如果对 Vibe Coding 的幻想是希望它构建有价值的软件产品，那确实是绕弯路——大家更关注的是结果的交付。
程凯：而且你看 Bolt、Lovable 这些工具越做到后面，加的功能越多，各种各样的功能都往里塞——加 Server、加客户端数据库、加各种东西，它就变成下一代的开发软件了。这和 AI 本质的目的是反方向的。AI 应该让技术门槛越来越低，用起来越来越简单。
02
在产品 pivot 之前，
先完成了组织的 AI Native 改造
Founder Park：怎么说服团队进行转型的？
程凯：大的分歧没有，核心目的没变——解决工作问题的自动化，只是之前那个方法解决不了，得用新的方法。但从 marketing 角度、产品思考角度，肯定会有想法。比如那么激进的策略出来以后，大家会担心用户用不起来，之前的用户可能就丢了。
Peter：转型最难的不是方向完全不行的时候——那时候大家不会反对。最难的是之前的东西看起来还行，但风险也在逐渐显现。任何团队在这个过程中都会有犹豫。
不过对创业公司来说，小就是优势。大公司或稍微大一点的创业公司可能永远做不出这个转型，因为有太多阻力。在 AI 发展这么快的情况下，有些机会稍纵即逝，多讨论一个月整个格局就完全不一样了。
我们的 pivot 从表面上看是产品方向的 pivot，但从内在讲，我们 pivot 的是整个开发方式。
以前开发一个产品可能需要几个月，现在经过我们内部的 Harness 系统重新定义开发流程后，能缩减到几周就可以交付一个原型让大家试起来。如果按以前的方式还需要几个月才能拿出新东西，中间的讨论和团队内耗可能让转型永远也进行不下去。
Founder Park：大概从什么时候，开始确认「这个方向做对了」？
程凯：有两个信号，一个内部的，一个外部的。
内部信号：2 月份完成团队内部 AI-first 改造之后，我们 1 个月里把整个新产品的基础版本重构了一遍。这个时间周期本身就很夸张。更关键的是，第一周早期测试版本出来，我们 marketing 团队自己用，就发现这个产品真的好用，基本上 95% 的工作流都可以用 AI 来完成。
如果你自己做的是偏 ToC 或重度用户的产品，自己团队都用不起来，产品一定有问题；但如果自己团队能用得像我们今天这么好，这个产品可能不一定能卖 1 亿美金，但在市场上卖几千万美金，一定是能做到的——因为你自己就是最好的应用样板。
外部信号：3 月 31 日上线，产品在海外迅速扩散，Revenue Run Rate 提升了 4 倍，有用户一周下来额外付了五六千美元，因为他发现 agent 能把他大量的手工工作都自动化了。
我们现在的 ARPU 大概是其他普通 C 端 AI 工具的六七倍。这个数字也说明了，用户一旦真的会用，会发现原来有那么多工作可以被 AI 做得那么好——这个「aha moment」，是一切的起点。
03
AI Native 的产品开发：
围绕 AI 能力打造新流程
Founder Park：提到组织的 pivot，你们团队的 AI Native 改造具体是怎么做的？
Peter：以前的开发分三个阶段。第一阶段是产品设计，产品经理需要非常仔细地想各种边界情况，把东西设计得非常完善，通常需要接近一个月。第二阶段是开发实现，占时间最长，一两个月。第三阶段是 QA 检测，再花几周。整个迭代周期在一到两个月。
但现在随着 AI 能力的提升，开发阶段可以从几个月缩减到几个小时。如果中间只要几个小时，你还花几周做产品设计、再花几周做 QA，整个流程就不合理了，最大的瓶颈反而是你的包装。
所以我们要做的就是把这两头也用 AI 自动化。规划阶段，AI 已经能访问所有代码库、所有日志、Harness 系统提供的上下文，大概半个小时就能做出相对完善的规划。开发完成后，我们重点构建的一个很重要的部分是怎么做测试——做集成测试，保证 AI 写的代码满足质量要求，不会搞坏线上环境或带来回退。
从规划、开发到日志反馈再到 AB testing，整个过程完全自动。而且上线只是第一步，更重要的是上线后你要知道效果怎么样。我们搭建了 AB testing 系统，日志怎么反馈回去，怎么自我改进，这个叫做 Harness——你怎么修复这个系统，怎么让这个系统自己进化。
Founder Park：你们这个改造是什么时候完成的？
程凯：2025 年 1 月开始转型，但最开始转得不彻底——因为团队自身的 AI-first 改造还没有完成。到 2 月，Peter 对整个开发团队做了彻底重构，完全用 AI 来驱动开发。那之后，迭代效率发生了质变。
我们用了一个月，把整个新产品的基础版本从头重构了一遍。然后 3 月 31 日正式上线 Super Agent 版本。
Founder Park：那在这个流程里，人的角色是什么？
Peter：现在主要分两种人。
一种是架构师，一个公司可能只需要一到两个，他们负责对整体方向的把控，做规划阶段的判断——AI 生成了很多待处理的需求任务，由架构师来决定哪些在这个阶段推进，整体方向有没有偏，和产品主线有没有对齐。
其他人基本上是在接收 AI 分配的任务——要么去修复一个 bug，要么去做一个 UI 的调整。大家工作的方式，是从 AI 那边接一个任务来完成。
Clark：这里的架构师跟传统意义的软件架构师不一样。这个角色要求是个通才，对产品的品味、对商业的认知、对行业的理解、对技术的掌握，都要有一定程度。他是一个六边形战士，才能去做 planning，做整个 harness 这件事情。
Founder Park：具体到你们的功能迭代流程，举一个例子？
Clark：比如说上个月，我们 AI 系统在扫描行业动态的时候，发现有几个竞品刚上线了一个关于文档处理的新功能，效果不错。它自动生成了一个需求任务：「我们是否要针对 PDF 的批量处理场景做一个优化？」
Peter 这边的架构师看了一眼：这个方向和我们的产品主线是对齐的，而且有几个付费用户正好在做类似的工作流。于是确认做。
从确认到功能上线，大概两天。AB test 跑了一周，结果是：使用这个功能的用户，使用时长提升了 23%，付费续订率有明显提升。留下这个功能，继续优化。
以前这件事需要开一个需求评审会，排期，分配工程师资源，可能要三周以上。现在是 AI 发现问题、人做判断、AI 实现、上线看结果——两天。
Founder Park：新需求和功能的提出，也是 AI 在主导了？
Peter：对。我给 AI 系统构建了持续更新的 context——让它去关注行业里的新发展，比如去 GitHub 上看流行的新 repo：Harness agent 最近是怎么做的？OpenClaw 是怎么做的？和我们之间的差距在哪里？有什么东西可以优化？
这个系统会自动生成很多待处理的需求任务。然后负责 planning 的人来看：哪些任务我想在这个阶段加进产品里？确认之后就交给 AI 去开发实现，然后上线看 AB test 结果——能不能提升我们的核心指标。
这本质上就是一个提假设、做实现、看结果、验证或证伪的循环。当开发实现的成本可以忽略不计的时候，很多东西就不需要太多讨论了，直接上线看效果就可以。
以前软件开发最大的矛盾，是工程师资源的争夺：A 功能和 B 功能哪个先做？谁的优先级高？现在这个问题基本不存在了，都上呗，让 AI 去实现，看结果谁更好。
Clark：很多公司号称自己做 AI 开发，但实际上只是在现有的流程上用 AI 的工具。而我们是围绕 AI 工具的能力去重新打造了一套新的流程，这是本质上的改变，所以才能带来极致的效率提升。
过去 14 天我们平均每天会有 5-8 个新功能上线。这在传统开发模式下是不可能的。核心就在于：你是围绕 AI 的能力打造新流程，还是在现有流程里添加 AI 工具，这是两个完全不同的思路。
04
一个更主动的，
可以稳定完成重复任务的 Agent
Founder Park：你们怎么定位自己的产品？通用 Agent 还是专注某类任务？
程凯：通不通用其实不重要。为什么今天会有「通用」的感觉？是因为一个好的 Coding Agent，什么都能编——什么都能编意味着什么任务都能解决。
一个哲学一点的比喻：人为什么能解决任务？因为人有三个能力——理解和规划任务、制作工具、使用工具来解决任务。人和其他生物的区别，是我们会规划、会制作工具，所以我们才形成了文明。
如果你希望 AI 也是一个真正的「智能体」，它也需要这三个能力。而我们想构建的，就是一个未来工作场景的入口平台：帮你构建 agent、让 agent 执行任务、拿到结果，并且把这些 agent 工具管理起来，让它们可以互相协作——就像我们有一个仓库，把所有工具都存好，让工具之间能互相配合，让工作流水线自动运转。
Peter：我们产品里有一个很重要的理念，叫 proactive（主动性）。
大多数用户对 agent 是没有概念的，他可能听过这个词，但不知道它是什么，也不知道该如何创建一个 agent。所以我们的产品逻辑是：你只是在完成一个当下的任务，比如你是一个知识工作者，在处理一个法律文件，写了一份分析报告，结果很好。
我们的 agent 系统会主动发现这件事，然后主动建议你：「把这个转化成一个日后可以复用的 agent」。
这样用户不需要一开始就知道「什么是 agent」。他在使用平台的过程中自然会有这个「aha moment」——然后发现，我以后每周、每天都可以让这个 agent 自动帮我做这件事，不需要每次都重新来过。
Founder Park：为什么选择云端而不是本地？本地端不是能更快地拿到用户的上下文。
Peter：这是一个基础设施层面的难题，但我们已经解决了它。我们可以在云端实现和本地一样快的上下文获取速度，延迟基本感知不到。一个 agent 执行一个任务通常需要比较长的时间，几百毫秒的延迟对整个任务来说根本没有太大影响。
而且 AWS 这样的云服务也在不停地演进。上周 S3 做了 20 年里最大的一次改动，可以像一个真实的文件系统一样直接挂载到沙盒上。整个行业对云端的支持在持续提升，这个差距只会越来越小。
云端还有一个本地端无法比拟的核心优势：任何一个用户在基础设施层面发现了一个问题，我们修了，所有用户都会受益。但如果每个人都是装在本地，A 用户的经验没有办法传导给 B 用户。
更重要的是：协作。不管是人与 agent 协作，agent 与 agent 协作，还是整个循环如何形成闭环——这些场景都需要一个共享的 context 环境。两台不同的本地电脑之间要协作，最终还是要通过云端来走。
Clark：我们要解决的核心是「知识工作者在企业里把 AI 用起来」这件事。工作场景天然是协作的，agent 与 agent 之间的协作、人与 agent 之间的闭环，都需要一个云端环境才能更好地实现。这也是我们持续在云端方向上投入的原因。
Founder Park：为什么你们更推荐把用户的工作流固化成 Agent，而不是 Skill？
Peter：Skill 也是我们 Agent 运行的一个单元，可以把它理解成 Agent 的 Runbook，Agent 按照这个 Skill 去执行。但一个 Agent 之所以成为 Agent，在 Skill 之上还有很多东西：Memory、Widget（展示层）、Schedule（调度机制）——也就是怎么触发这个 Agent、怎么定期运行它。这些都是在 Skill 之上的概念。Skill 只是一个文档文件，让 Agent 能从基础设施层面正常运行，是更底层的一层设计。
我们的核心理念是：在构建 Agent 的时候，我们已经帮用户生成了 Skill，但在 Skill 之上，我们还帮他构建了很多其他东西，让他能够在之后去定期运行这个 Agent，复现之前的结果。
05
Coding Agent，
才是通用 Agent 时代的基础设施
Founder Park：你们一直坚持以 Coding Agent 为底层，这个技术判断背后的逻辑是什么？
Peter：我先说一下我对 Coding Agent 这个概念的理解，因为很多人听到这个词会以为它就是「写代码」这一件事。
对于一个 Super Agent 或者 General Agent 来说，写代码只是其中一个能力。但更重要的是：文件系统的访问、memory 的管理、工具的调用、API 的调用，以及如何长时间稳定地运行来执行一个复杂任务，这些加在一起，才是 Coding Agent 的全貌。
写代码的能力让 agent 变得更通用，是因为大部分任务在遇到边界情况的时候，需要 agent 自己现写一段代码来解决。
举个例子：你想拿到最新 10 封邮件，可以直接调用 connector 来实现。但如果你想拿到邮件之后，再做一些定制化的处理呢？在没有 Coding Agent 的情况下，这是一个「边界情况」——软件没有提供这个接口，就解决不了。但有了 Coding Agent，它现写代码、现编译、现运行，直接把结果交付给你。
这就是 Coding Agent 能覆盖长尾 general 问题的原因——它的覆盖范围比「调接口」要宽得多。
程凯：最底层的逻辑是这样的：人类社会的所有运转，从电脑系统，到我们用的各种工具，到机器人，本质上都是程序在驱动。整个虚拟世界是程序，就算是现实世界，比如机器人里面的东西也是一段程序。基本上人类社会所有东西都是程序去驱动的。
如果你拥有 Coding Agent 能力，相当于是你可以以最底层、最小单元化地去构建和改造各种工具来解决任务。但如果你不是 Coding Agent，你的回答更多是生成一段人能理解的文字——它可以描述一个方案，但执行不了。
能描述方案，和能执行方案，是两件完全不同的事。
举一个我们自己公司实际碰到的例子。我们的数据分析平台是 Amplitude，里面有大量用户行为数据。原来这些数据只能在 Amplitude 上查看，我们的 agent 没有办法直接获取。按以前的做法，我们需要自己开发 Amplitude 的 connector，提供接口让用户授权。如果我们公司不做这个 connector，用户的 agent 就永远连不上 Amplitude。
现在是怎么做的？用户跟 agent 描述需求，agent 会自己一步步写出连接代码，然后告诉用户：「你登录 Amplitude，把一个 TOKEN 给我」，拿到 TOKEN 之后，就可以直接 access 所有数据了。
用户所有基础工具的连接，现在都可以实时完成，不再依赖平台方提前把所有 connector 都做好。这才是 Coding Agent 让工作任务执行更强、更自定义、更高效的核心逻辑。
Founder Park：这种「Coding Agent 现写代码解决长尾问题」的能力，对普通用户来说是什么体感？
程凯：我们内部一个做 Marketing 的同事，他每天需要生成一份竞品分析报告——去抓竞品的官网、看他们最近的更新、分析竞品的市场定位变化。
这件事对大多数 AI 工具来说都很难稳定完成，因为每个竞品网站的结构都不一样，你不可能提前把每个网站的 parser 都准备好。
但 Coding Agent 可以现场为每个网站写抓取代码，遇到阻碍就自己调整策略，最后把结果整理成报告。这个流程跑通之后，就可以变成一个 rerun 的 agent——每天定时自动跑，他只需要看报告就好了。
以前这件事要么雇人做，要么找外包公司，要么自己花几个小时去手动整理。现在是一个 agent 定时自动完成，他的精力可以全部放在决策上。
Founder Park：今年越来越多的产品开始用 Coding Agent 做底座，你们怎么看？
程凯：这是必然的趋势。去年 9 月，用 Coding Agent 做底层的产品，要么本来就是 Vibe Coding 工具，要么是像 Cursor 这样专门给开发者用的产品。但今年，越来越多的通用产品开始把 Coding Agent 作为驱动整个产品的底层了。
为什么大家都在往这个方向走？因为如果你想让任务执行得更复杂，就需要 Coding Agent。不管是连数据库、做数据分析，还是接入各种工具——单靠生成 token 来描述问题，在今天的商业环境和基础设施里，是很难真正执行的。
06
Harness + Sandbox，
环境稳定比「智商高」更重要
Founder Park：你们经常提到 harness 和 sandbox，能具体说说这两个东西在解决什么问题？
Peter：我把 harness 分成两个层面来理解。
第一个层面：用户怎么 harness 自己的 agent——也就是用户层面的配置和定制。比如 Anthropic 的 Skill 系统，类似于 Agent 的 Runbook，让 Agent 按照这个 Skill 去执行，并根据用户的 Memory 不断更新。这是用户层面的 Harness。
第二个层面：我们怎么 harness 整个开发 agent 的系统——也就是平台层面的基础设施。
很多公司，包括 OpenClaw、Cowork，还有一些开源 agent 框架，它们的 harness 主要停留在第一个层面：帮用户创建 agent 执行手册，或者在 memory 里记住一些信息，让用户能更好地适应这个系统。
这就像 Android——开放，可以做很多自定义，但高度碎片化。用户在搭建自己的 agent 系统时有太多选择：用什么数据库？SQL 还是非关系型数据库？每个人选的都不一样，结果每个人的系统都不稳定、难以维护。
我们的方式更像 iOS——我们掌控整个 agent 架构。
包括数据库的选择、文件系统的设计、memory 系统的构建、connector 和 agent 之间的协议——这些全部由我们来定义。我们不给用户随意自定义的权限，但我们承诺：交付给用户的结果是可靠的、流畅的、可稳定复现的。
就像 iOS 的逻辑：你虽然不能做很多自定义，但我们保证你有一个稳定的使用体验，能拿到一个好的结果。对于 agent 系统要实现大规模普及，这个「保证」是前提条件。
我甚至觉得，做到最后就是对整个硬件系统的掌控，我用什么样的 GPU，我怎么优化推理速度这些都是封闭系统才有的优势。我可以优化每一个环节，向用户交付最终的结果。
Founder Park：Sandbox 机制具体是怎么回事？
Peter：这是我们一个很重要的技术优势：每一个用户请求，我们都会给它启动一个独立的 sandbox 环境。
大部分产品，比如 Manus、Claude、ChatGPT 的工作方式是：你发一个请求，进入一个公共的 agent 服务节点来处理。不是一个专属于你的独立运行环境。
而我们能做到的是：任何一个用户请求，都会进入一个专属的独立沙盒，在这个完全隔离的环境里稳定运行。
为了做到这件事，我们必须对自己的 agent 系统做深度优化。一个很具体的例子：我们早期直接用 Claude Code，但它的启动时间要 10 到 20 秒。对我们来说这是不可接受的。如果每一个用户请求都要等 10 秒，用户体验完全无法接受。
于是我们在自己的架构上做了深度优化，把 sandbox 的启动时间压到了 5 秒以下。
这件事只有当你充分了解自己的整套架构时才能做到。OpenClaw 这样的开源框架，因为要面向各种各样的人和运行环境，没有办法对任何特定场景做性能优化。而我们可以，因为我们掌控整个系统。
程凯：还有一个关键问题：agent 之间的运行环境必须隔离。
想象这样一个场景：你有很多 agent 在同时运行，而它们的运行环境不是隔离的。A agent 安装了三个工具包，B agent 启动时可能修改了其中某一个工具的属性——A agent 的工具就不稳定了。然后你会陷入无限的「调优循环」里——你调 B 把 A 修好了，你调 A 又把 B 搞坏了。
这就是为什么大家用 OpenClaw 这种本地化工具，很难在工作场景里真正稳定高效产出的核心原因。
这也是为什么我们做的是完全云端化，并且在 sandbox 这一层做了非常多的 harness——让 agent 的运行尽可能稳定、高效、可重复。
环境的稳定、基础设施的能力，基本上就可以把 AI 能力从 50 分提到 90 分。剩下那 10 分，才是真正有追求的人才需要去做的事。
Founder Park：使用 sandbox 机制，用户的长期 Memory 和整体的知识积累怎么管理？
Peter：我们有三个层级的 Memory 管理机制。
第一层：Thread 内的 Memory。当一个 Thread 的 Context 接近模型 Context Window 的上限时，我们会做一次压缩——用模型对这个 Thread 进行总结，把应该记住的内容存到文件系统里。
第二层：跨 Thread 的 Memory。每次用户请求结束后，我们有一个独立的服务，用模型去判断这次对话里有没有值得长期记录的内容（比如用户做出的决定、个人信息等），如果有，就存储下来，并和之前的 Memory 做去重处理。
第三层：新 Thread 启动时的 Memory 注入。在每个新 Thread 开始时，我们会把和当前用户请求最相关的前 15 条历史 Memory，提前加载到上下文里——这样即使在全新的 Thread 里，Agent 也能利用之前积累的 Memory。
Founder Park：一个能跑长时间任务的 Agent，关键是模型能力的保证，还是 Harness 环境的支撑？
程凯：从普通用户的角度来讲，大多数普通人的工作其实并不复杂。我们为什么觉得 Excel 和飞书文档这类产品很重要？是因为大多数人的工作，本质上都是基于文档的高阶操作——总结、分类、打标、可视化，几乎就这四种类型。
所以我觉得：真正需要"长时间执行"的单一任务，其实很少。更多的是"长时间的多次工作"，比如投资人做一份大的汇报，本质上是把很多小任务拆解开来，每个模块都是一个独立的任务，不是一个任务需要持续执行。
当然，大企业里那些非常严肃的场景，比如复杂的计算、预测——的确需要长时间执行，但这类任务今天也很难完全让 AI 自主去做，因为一旦出错，承担的经济损失非常大，必须有人参与。
所以今天能商业化的任务范围，已经被收窄了很多，基本上都是那些短暂但高频发生的重复性任务。这类任务需要的，是一个稳定的环境，而不是特别复杂的智能。今天你有多少人是完全利用到了大模型所有的智商的？很少，因为大多数人还是在做一些基础工作——环境稳定比"智商高"，在今天这个阶段更重要。
07
从 ChatGPT 重度用户切入做增长
Founder Park：你们现在的用户画像是什么样的？
Clark：地区来讲，主要分布在美国、加拿大和巴西，这是三个最大的市场。其他还有澳大利亚、韩国、西欧一些国家。人群画像上，大概 70% 是男性用户，年龄在 20 到 35 岁，但在往更大年龄段扩展。
我们花费最多的一个用户，两周花了 5000 到 6000 美金，是一个大学教授。从用例来看，早期用户主要做文件处理这类基础任务，但现在深度在增加——有人用来写回忆录，有人在构建生物医学的研究 pipeline。
增长策略上，我们先瞄准「ChatGPT 重度用户」——那些付 200 美金月费但还觉得不够用的人，比如处理 PDF 不行、做复杂工作流不行。然后按职能细分：SEO、文案、内容创作。再往上走，把单一职能方案打包成端到端的业务解决方案，比如电商从设计到营销到 SEO 到法务，全链路覆盖。从个人任务到职能负责人再到公司管理层，自下而上渗透。
从这群人开始，获客成本最低，反馈质量也最高。
Founder Park：用户深度使用之后最大的变化是什么？
程凯：最大的变化是用户开始用 Agent 做他以前根本想不到的事情。早期投资人测试的时候，我给了很多人试用。他们之所以用得多，是因为平台不是让他们聊完天就走，我们通过聊天帮他快速构建 Agent，把他的方法论记忆下来，这些方法论在后续 build 其他 Agent 的时候都会体现出来。他们会觉得这个平台越用越懂他。
而且关键是 rerun。有些用户之前每天花两三个小时做数据分析、做行业 research，现在设好 Agent 之后，Agent 自动跑，他只看结果。这种从「每天花两三个小时亲自做」到「只看结果、只做决策」的转变，一旦体验过就回不去了。
Founder Park：你们会上线 Agent Marketplace，让用户互相分享和买卖 agent 吗？
Clark：这里有一个重要的区分：我们做的是团队协作内的 agent 共享，不是公开的交易平台。
Marketplace 或 Skill Store，是一个商业闭环的交易平台——用自己的 agent 去换取经济回报。但这里面有一个根本问题：每一个用户的工作流都是高度个性化的，你的 agent 依赖你的 harness、你的 sandbox、你的上下文环境——这些东西在别人那里不能直接复用。
我们做的协作逻辑是：在同一个 workspace 或 team 内，把自己的 agent、skill、context 共享给同事，一起在同一套基础设施上跑。这是协作，不是交易。这两件事的基础设施要求完全不同。
这也是为什么「Agent OS」这个方向，今天有没有人提，未来大家都会去做。只是现在时机还没到，但这个方向一定会来。
程凯：在工作场景里，每家公司做事情的最后一公里都是无法被标准化的——比如同样是金融公司做交易，90% 的工作流可能一样，但剩下 10% 是每家公司独有的。Marketplace 可以存在，但对于真正会用产品的用户，它的价值可能更多是启发作用，而不是核心功能。
现在需要 Marketplace，是因为大家不知道怎么开始，或者想学习别人的最佳实践；未来 AI 自己就会知道这些，甚至能基于你的具体需求提出更好的最佳实践。
08
产品不是护城河，
组织效率和 pivot 速度才是
Founder Park：你们怎么看现在的 AI 产品竞争格局？
Clark：竞争是多维度的。
智能层面在和模型提供商竞争，他们在不断提升模型能力，让用户直接用原生接口就能完成越来越多的事情。产品形态上和其他 Agent 创业公司竞争，大家都在探索下一代 AI 产品应该长什么样。价值交付上和垂直 SaaS 竞争，因为很多垂直行业的软件公司也在加 AI 能力。
程凯：我觉得今天创业公司最大的机会不是说你有机会做一个产品干掉谁。今天创业公司最大的机会是你比大公司都简单。
如果你的效率是所有同行竞争对手的 100 倍到 1000 倍，你基本上死不了。为什么？因为别人一个月发一个功能，你一个月可以发 1000 个，你堆都可以堆死他。
这个效率从哪来？来自你可以成为一个纯粹的 AI 驱动的公司。大公司做不到——你要改造几千几万人的组织，让他们接受 AI 分配工作、接受很多岗位被替代，这在大公司里几乎不可能。但创业公司可以从一开始就这样建。
今天所有 AI 产品都是中间态。没有任何一个产品能以现在的形态存活到最后。能活到最后的，是那个在每一个变化的阶段都能以最快速度转身的公司。产品不是护城河，组织效率和 pivot 速度才是真正的护城河。
Founder Park：每个 AI 产品都是中间态，怎么理解？
程凯：很简单。你看今天的 ChatGPT 和两年前的 ChatGPT，完全不是一个东西。Cursor 和一年前的 Cursor 也不是一个东西。每家公司的产品都在不断变化，因为底层模型能力在变，用户需求在变，市场认知也在变。所以你今天看到的任何一个 AI 产品形态，它都不是最终形态。
那既然所有产品都是中间态，拼的就不是谁在某一个时刻做出了最好的产品，而是谁在每一个变化点都能最快地转身。这就是为什么组织效率和 pivot 速度比产品本身更重要。你的产品可以不是最好的，但你的公司必须是反应最快的。
除非有一家公司能永远走在技术最前沿，以最好的技术持续提供核心价值——帮人在工作场景落地。这两个点是不会变的，因为 AI 替代人来解决工作场景任务的终局是确定的。在这个确定的终局里，谁能撑到最后，谁就能赢——因为未来的经济体规模是现在的几万倍，只要能撑到那个时候，一定能分到一杯羹。
Founder Park：所以你们其实在押的是一个「AI 主导工作」的未来，而不只是「人借助 AI 工作」的未来？
程凯：对，我觉得可以稍微从更宏观的视角来讲这件事情。
未来的经济体其实只有两种。一种还是以人为主导的，就跟现在一样，所有的工具是给人用的，整个经济体的主导还是人。但是另一种，是 AI 主导的经济体，所有的工作场景的任务，都是由 AI 来完成的。所有的交易对手也是 AI，大家都在 遵循一套标准化的协议进行交易和交互。
在这样一个 AI 主导的经济体里，它的增量会以指数级的倍数增长——因为人有工作效率上限，但 AI 没有。
今天你让 AI 帮你刷信用卡买东西，很多人会担心：我的 AI 是不是被骗了？是不是交易不安全？原因很简单——你的交易对手还是人主导的规则体系。但如果你的交易对手也是 AI，大家都遵循同一套协议，这个问题就消失了。整个 AI 主导的经济体才能真正运转起来。
所以今天所有的创业公司，其实都在押这两个方向之一：要么我在做一个给人用的产品，未来也是人去用的 AI 工具；要么我在押 AI 主导的经济体，我的产品是给 AI 用的——让 AI 能更好地在这个经济体里工作、交互、交付结果。
我们押的是后者，这也是为什么我们在硅谷做这件事。我们赌的是一个更前沿、更有价值的方向。
Founder Park：你说的这个 AI 经济体，离落地还有多远？
程凯：有些场景已经在发生了。比如在我们公司内部，AI 发起需求、AI 写代码、AI 测试、AI 部署——整个链路上 AI 是主导者，人只在关键节点做审核。这不就是一个 AI 经济体的微缩版吗？
当然完整的 AI 经济体需要更多基础设施——标准化的协议、AI 之间的信任机制、交易体系。但方向是确定的。今天你看到的不管是 Agent 平台、Coding Agent 还是企业自动化，都在往这个方向走。区别只是谁走得更快，谁走得更对。
09
AI 创业，
先把公司变成一个 AI Native 公司
Founder Park：AI 创业到现在，你们觉得最大的误区是什么？
程凯：最难的不是选对方向——AI 的终局大家都看得到。最难的是怎么去构建组织的形态。今天人是最难的一个问题。很多有经验的人，他的经验反而是包袱，思维方式和工作习惯都建立在旧范式上。
今天很多创业公司效率提升不上去，我觉得不是产品的问题，是组织的问题。你怎么让所有人接受这个变化，怎么让整个团队真正变成 AI first，这个转变比你想象的难得多。
Peter：残酷一点说，未来大部分人是不需要的。一个团队之中只有少部分能拥抱 AI 的人才能存活下来，大部分人会被取代。所以在转型过程中会有很多阻力，这不是态度问题，是客观现实。
但 AI 也给了我们解决这个问题的机会。以前你需要整个团队的人来转型，现在用更少的人、更快的时间就能交付新方向，转型的成本大大降低了。如果你是大公司，这个转型可能永远也做不出来。对创业公司来说，小就是最大的优势。
Clark：我觉得另一个误区是，大家对于 AI 市场的认知存在偏差。行业里可能过于乐观地估计了用户对新技术的接受速度。人类历史上没有任何一个时间段，能在两年甚至三年之内完成一个新技术从研发到部署到大规模上线且大规模分发。互联网从诞生到普及用了十几年，智能手机也是。AI 也不会例外，大规模的用户教育和习惯转变需要时间。
OpenAI 已经 8 亿用户了，但那也只占全球人口的 10%，而且大部分人并没有把 AI 真正用好。说白了，圈内人在自嗨。我们从产品的愿景和定位来讲就是希望普通人能把 AI 用好，但实际上这个问题挺难解决的。大家不要以为 AI 发展了三年，全世界就该人人都会用了——离那一天还远着呢。
程凯：回到组织的问题，我觉得这个才是最本质的。你看今天很多创业公司，创始人可能方向看得很对，产品思路也对，但公司效率就是提不上去。为什么？因为团队里的人没法做到真正的 AI first。
什么叫真正的 AI first？不是嘴上说说，也不是在现有流程里加几个 AI 工具，而是 95% 的工作都交给 AI 去做，人只做 AI 做不了的那 5%。这个转变听起来简单，实际操作中阻力极大。团队里有人写了十年代码，你告诉他以后 AI 来写、你来审核，很多人是接受不了的。
Founder Park：作为创始人，今年最焦虑的是什么？
程凯：两个焦虑。
第一是资源，做得好，最怕你拿不到该有的结果。这个时代有没有拿到足够的资源做想做的事情，不管国内还是国外，融资环境都很混乱。
第二是速度，我们的迭代速度已经很快了，但还是担心不够快。我们不想 miss 一些极为重要的技术转折点，希望在转折点之前就已经布局了，而不是之后才追。
Founder Park：如果给其他想做 AI 创业的人一条建议，会是什么？
程凯：先把自己的公司变成一个 AI 驱动的公司。不是买几个 AI 工具，是真的让 AI 来主导你的工作流程，从需求发现到产品开发到市场推广。如果你自己的公司都做不到 AI first，你凭什么做出一个帮别人 AI first 的产品？
我们自己就是这么走过来的。从一月份改造不彻底、产品感觉不对劲，到二月份完全转向 AI 驱动的开发 pipeline，到三月底新产品上线用户反馈极好——这个过程的核心不是技术有多强，而是组织有多愿意改变。技术是公开的，模型是公开的，但你的组织能不能真正围绕 AI 的能力去重新构建，这才是决定胜负的东西。
Clark：补充一点，从 GTM 的角度看，AI 创业最容易犯的错误是把产品做好了但用户教育没跟上。很多人以为产品好用户自然会来，其实不是。你得手把手教用户怎么用，怎么从旧的工作方式转到新的，怎么打破他们原有的预期建立新的。这个比做产品本身更耗精力，但也更重要。
Peter：对。多种因素汇聚在一起才能做成这件事——AI 能力够了、团队足够小、决策足够快。我们能做的就是保持小、保持快、保持变。
Canva可画联合创始人独家专访：2.65亿用户的Canva，用自研模型，解决了设计的审美问题
一款好的 AI Native 硬件，硬件只是脚手架，真正壁垒一定是 Agent
对话 Ribbi：所有人都在做创作工具，我们在做一个有品味、会进化的「人」
对话寻影：大家都在解决怎么拍得更好，我们想干掉「拍」这件事
转载原创文章请添加微信：founderparker
