--- id: "vl7HiMdGfjo" title: "人人都能构建软件后，会发生什么？" channel: "Y Combinator" host: ["Gary"] guests: ["Paul Copplestone"] date: "2026-10-30" updated: "2026-10-31" duration: "48:45" duration_seconds: 2925 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=vl7HiMdGfjo" canonical: "https://pod-exp.pages.dev/vl7HiMdGfjo/" transcript_jsonl: "https://pod-exp.pages.dev/vl7HiMdGfjo/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["AI 智能体","AI 编程","AI 基础设施","开源软件"] series: ["AI 软件"] --- # 人人都能构建软件后，会发生什么？ > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** Supabase 联合创始人兼 CEO Paul Copplestone 回顾了公司从仪表盘、API 到代码优先的三次转型，以及 AI 智能体带来的增长：注册用户一年从约 300 万增至 1,300 万，每周新建数据库超过百万个。他认为，AI 正让非工程师也成为创造者，个人数据库和个性化应用将成为新市场。节目还讨论了 Supabase 如何通过开源、CLI、错误提示和智能体评测服务 AI 构建者，如何同时支持从原型到 PB 级的工作负载，以及创业团队如何通过自用验证、保持灵活和选择长期赛道应对快速变化。 ## [0:03] 开场 · YouTube **Paul Copplestone：** 我真心期待，未来会给很多人带来什么。我特别喜欢 Supabase 的一点是，这个平台催生了很多创业者。我确实相信，只要能用上 AI，世界上的每个人都会成为某种意义上的创造者。你可以打造任何东西，也可以按自己的需要定制；想改一款应用、调整界面，都不必再受制于别人。说实话，我很期待 2027 年。 **Gary：** 欢迎收看新一期《Lightcone》。今天请到 Supabase 联合创始人兼 CEO Paul Copplestone。Supabase 是一个开源 Postgres 后端，已经成了 Cloud Code、Coda 等工具默认使用的数据库。如今 Supabase 有 1,300 万用户，每周新建数据库超过一百万个。Paul，欢迎来到《Lightcone》。 **Paul Copplestone：** 谢谢邀请。 **Gary：** 先从一件事说起：YC 会在第一天发一件 T 恤，上面写着“做人们想要的东西”。但现在大家越来越意识到，应该做“智能体想要的东西”。你们公司很能说明这一点。现在新增活动里大约有 70% 来自智能体，这不挺惊人吗？ ## [1:18] 增长与营收四倍 · YouTube **Paul Copplestone：** 是啊，太惊人了。今年的数据尤其明显，趋势大幅转向智能体。 **Gary：** 为了让大家理解你们增长有多快，能说说你们关注哪些数字吗？去年这个时候是什么情况，现在又到了什么水平？ **Paul Copplestone：** 去年这个时候吧，现在我们有 1,300 万注册用户，往前推 12 个月，大概是 300 万。今年营收会增长到原来的四倍。现在每周大约新建一百万个数据库。 **Gary：** 是每周创建一百万个数据库？ **Paul Copplestone：** 超过一百万。 **Gary：** 去年这个时候有多少？ **Paul Copplestone：** 现在托管的数据库快到 5,000 万个了；去年这个时候是 800 万个，增长拐点非常明显。 **Gary：** 是什么推动了这个增长？ **Paul Copplestone：** 第一，软件工程师们正在毫无顾忌地大量构建。第二，越来越多的新型创造者开始出现。过去通常得有软件工程背景才能做的事，现在非工程师也能在 Supabase 上真正做出产品。 **Gary：** 这确实是个很大的转变。你们具体做了什么，推动这种转变？软件工程师当然会继续选择 Supabase，但你们怎么让智能体一开始就用上它？ ## [2:37] Supabase 的三个阶段 · YouTube **Paul Copplestone：** 我们大致经历了三个阶段：最初是仪表盘公司，后来转向 API，现在则是以代码为先。我们努力提供智能体喜欢的构建方式，也就是代码优先；它们大多数时候特别喜欢用命令行工具。另一个因素是，我们成了大语言模型里的默认选项。我觉得我们很大程度上受益于时机：我们恰好在那个阶段成为数据库的默认选择。 **Gary：** 你觉得开源也起了作用吗？智能体很喜欢开源项目。 **Paul Copplestone：** 很难知道如果不开源会怎样，但我认为这至关重要。我们做的所有东西都是开源的，这似乎给了我们很大帮助。而且我们的开源做法很开放：不只支持 Supabase 自己的工具，也支持 Postgres 这类已有工具。我们参与维护 Postgres，因此在许多社区里都有广泛的影响力。 **Gary：** 我猜智能体确实喜欢开源，因为出了问题，它们可以直接查看源代码。 **Paul Copplestone：** 对。 **Gary：** 我发现智能体喜欢自己能掌控局面，也喜欢数据。最让人沮丧的，就是碰到一堵墙，既不知道发生了什么，也没办法修复。 **Paul Copplestone：** 我觉得开源会越来越重要。现在安全问题这么受关注，很多企业会想检查源代码，确认它是否安全。如果代码是闭源的，他们可能就不愿意采用那个供应商。 ## [4:34] “创造者”与传统开发者 · YouTube **Gary：** 到 2026 年，开发者还算是你们瞄准的核心用户吗？你们现在怎么理解这件事？ **Paul Copplestone：** 我觉得我们正在进入一个“创造者”大量涌现的时代，至少今年看到的是这样，而且人数多得惊人。通常，漏斗顶端的注册数加速增长时，激活率、转化率等其他数字往往会下滑。但今年这些指标却全都在往上走，有点不可思议。模型越来越会构建产品，过去没有软件工程背景的人也开始能做东西。 **Gary：** 所以“创造者”指的可能不是软件工程师，而是有个东西要做的人。他们打开 Cloud Code，但光靠文件很快就不够用了。 **Paul Copplestone：** 嗯，是的。从某种角度看，这些人心里有很多想法，以前怎么也说服不了软件工程师帮忙做；现在他们不用说服任何人，就能把想法一个个做出来。软件工程师仍然占很大一部分，但创造者群体的增长速度相当快。我也不知道这个增长的上限在哪。早期投资人曾说，PLG（产品驱动增长）到某个营收规模就会碰到天花板，然后得转向市场里的另一个细分领域；但到现在似乎还看不到天花板，我也不知道它会在哪里停下来。 **Gary：** 这在一两年前大体上还成立，但今年显然不是这样。我上周末刚和一个人聊过，他是金融科技公司的创始人，刚以超过十亿美元的价格退出。他一直比较靠近产品，在 YC 本科时学数学，也能拼出一些 Ruby 脚本，但过去总得找工程师来开发软件。现在他在做副业，开始自己做东西，还能用上经营金融科技公司的经验，为个人财务搭建相当复杂的资产负债表、追踪软件，也知道怎么接银行接口，所有集成都从头写起。这种软件哪怕两年前都不可能有人做出来。 **Paul Copplestone：** 这类人正是很理想的创造者。我这种开发者想到的多半是开发者工具，但还有那么多领域专家，清楚自己所在的细分行业有哪些没解决的问题。现在他们可以直接动手解决，不用再说服别人加入。我记得你们在 YC 也聊过，加入创业营的创始人画像是不是正在变化？ **Gary：** 回头看 2022 到 2025 年，大家的想法确实有过变化：既然 AI 要来了，创业团队无论如何都必须有技术联合创始人。这种观念在 YC 当时特别突出。它一直有道理，但那几年大家格外强调这一点。可过去一年，我们开始看到“创造者”的崛起。更难的事情是知道该做什么；如今，构建能力几乎成了每个人随手可用的东西，这很棒。想想以前那些永远不会被做出来的产品：明明知道有人会买，也知道问题确实存在，但边缘需求就是找不到工程师愿意做。 ## [8:36] “创造者”与传统开发者（续） · YouTube **Gary：** 你能举些例子吗，Paul？比如人们用 Supabase 做了哪些以前根本不会有人开发的应用？哪怕只是给自己用的也行。 ## [8:43] 个性化应用 · YouTube **Paul Copplestone：** 有个挺酷的例子。我们开完大会后，一个来自巴西的人来找我。他用手机做了一整套出租车应用，有点像服务当地市场的小型 Uber。他自己就是出租车司机。我也不知道他为什么想做这个，但他真的做出来了，而且特别感激自己能做到。他大概五十岁，却突然有了像十几岁少年一样动手构建的劲头，这很棒。 如今工作会变成什么样，仍有很多不确定性；但对这些创造者来说，未来也带着令人兴奋的机会。这正是我喜欢 Supabase 的地方：人们可以进来发现新的技能和机会。以前有些人只是蓝领劳动者，如今也能开始做东西。 **Gary：** 最近你也在做一些个人软件。能聊聊你在做什么吗？ **Paul Copplestone：** 我最近越来越沉迷于用 OpenClaw 来构建。大概六个月前，我还说以后不会有界面，一切都只通过 OpenClaw 聊天完成。现在回头看，我都不好意思提这话了。我当时也很坚决地不想用数据库，想把所有东西都放在 Markdown 里。但实际用下来发现，到了某个阶段，数据库和界面确实都很有用。过去几周我一直在搭这些东西，把它叫作“控制塔”——就是给生活各个方面做界面。比如我有个界面帮我分流邮件，不用逐封看收件箱；还有财务支出追踪、健康记录，包括体重、锻炼等等，全都放在一处。 最神奇、也让我觉得不可思议的是，我给自己做的财务模块，功能至少能和 Mint 或 Monarch 这些产品打平，有些方面甚至更好，因为它能结合我的个人背景。比如查一笔交易时，它可以从我的 G Brain 里查出那个人是谁，然后正确分类。过去有好几家创业公司专门做个人理财，而我现在可以直接给自己做一个，不用考虑别人需不需要，也不用管别人的看法。这感觉真不错。 **Gary：** 我们看到很多这类项目，尤其是财务和健康这两个领域，大家都希望掌握自己的数据。人们会把不同设备上的信息同步到同一个数据库里，再让智能体跨设备建立关联，这能力很神奇。 **Paul Copplestone：** 是啊，拿健康来说，我的两套数据库里存着这些数据，同时它还能访问我的日历。它知道一些背景，比如体重最近涨了，但因为我在旅行，所以没关系，下周再回到正轨就好。理解这些上下文非常有价值。 ## [12:14] 个人数据库与数据所有权 · YouTube **Paul Copplestone：** 我有点担心，把所有习惯、日常流程和 CRM 都塞进一个智能体里。现在我正慢慢把这些数据抽出来，这样以后想接入不同的智能体时，可以自由换用任何一个。CRM 对我来说也非常关键。 **Gary：** 这正是你们有价值的地方。真正有价值的是作为权威记录的数据库。我们应该拥有自己的数据库，再在上面搭应用或智能体，而不是把所有东西放在别人的数据库里。 **Paul Copplestone：** 这想法确实挺不可思议。回顾数据库的历史，过去世界上只有少数几家大公司运营着规模巨大的数据库。我记得 Supabase 刚起步时，你们就有个想法：让所有人都能轻松创建数据库。当时不太容易理解为什么那么多人会想这么做，因为如果不会写代码，数据库能拿来干什么？会写代码、能做个人 CRM 的人也没那么多；在 AI 出现之前，对大多数人来说这活儿太费劲了。 **Gary：** 还有个例子能说明 Supabase 对我有多重要：我有个文件上传区，听起来很简单，但我可以把任何文件通过邮件转发给自己，或者直接扔进这个界面；我的智能体会判断文件是什么、和我的生活有什么关系、该怎么处理。所有东西都存在 Supabase 上。最后，Supabase 可能会集中保存我生活里的全部数据。一年前我根本想不到自己会需要个人数据库，因为那时这听起来毫无意义；现在我觉得它才是最有价值的东西。 **Paul Copplestone：** 你用的是兼容 S3 的 Supabase 文件存储，所有东西都放在那里？ **Gary：** 对，G Brain 里默认就是这个。 **Gary：** 你觉得未来会是这样吗，Paul？世界上几乎每个人，而不只是开发者，都会有一个 Supabase 数据库，存着自己生活、健康、财务和人际关系的信息？ **Paul Copplestone：** 我们当然希望如此。我确实相信，只要能用上 AI，世界上的每个人都会成为某种创造者。你可以构建任何东西，也可以按自己的需要定制；想改一款应用或界面，就不用再受制于别人。当然，我们把自己看作一家“索引”公司。加入 YC 时，我们只盯着 YC 的创业公司，希望赢得所有 YC 客户，因为我们知道，企业刚成立的第一天就得在场。我们的使命没变，只是服务范围大幅扩大了。现在越来越多创造者出现，我们得服务他们，这要解决的是完全不同的问题，但也很令人兴奋。 **Gary：** 你说扩大了很多，是一千万倍？ **Paul Copplestone：** 我们现在每周新建一百万个数据库。简单算一下，假设 ChatGPT 有 12 亿周活用户，而且每个人每个月都想启动一个项目，那就是每月 12 亿个数据库。我们正在走向这样的规模，必须准备好相应的架构；数据库领域以前从没遇到过这种规模。 ## [15:56] 扩展到数十亿规模 · YouTube **Gary：** Postgres 真能做到吗？还是说，要每周扩展到十亿个新数据库，你们得自己造一套数据库引擎？ **Paul Copplestone：** 我觉得可以……如果我们能和 AWS 谈到更好的条件，也许就行。不过现在大家都想要算力。很多这类工作负载可能并不需要法拉利级别的性能。我们最近收购了 Turso，它采用一种兼容 Postgres 的架构，也兼容 SQLite。我认为 SQLite 是一款很出色的数据库。我们会推出一个叫 Supabase Spark 的层级，主要服务刚起步的工作负载。使用体验保持一致，之后可以一路扩展到 PB 级。我们的标语大致是“从原型一路走到 PB 级”。作为一家公司，我们要确保每个人都能用；如果用户的业务持续增长，我们也要让他们一路用得顺畅。 **Gary：** 我好奇你们怎么想这件事。传统软件公司可能先服务 YC 这样的早期创业公司，同时把企业客户当作长远目标。尤其数据库公司，在 AI 出现之前，大家想成为 Oracle，就会尽快进军企业市场，因为钱在那里，于是不断开发企业功能。你们转向 SQLite，似乎是在往相反方向走。你们是两头都看吗？ **Paul Copplestone：** 是的，两头都得做，难度非常大。我们实际上有两个产品服务两端：Multigress 可以扩展到 PB 级，Turso 则适合缩小到原型和 SQLite 这类工作负载。在增长这么快的时候还得持续招人，即使有了 AI，这仍然是个很大的挑战，不过也是个有趣的挑战。 ## [17:58] Supabase 内部采用 AI · YouTube **Gary：** 你们最近做过一个调查：六个月前，只有 10% 的工程师会用编程智能体写出自己 80% 的代码；最近这个比例升到了 60%。这是怎么发生的？接下来会怎样？ **Paul Copplestone：** 我们内部没有 AI 政策，大家想用什么工具就用什么，我们也会给他们相应的访问权限。现在大家相信模型能把很多工作做得更好、做得更多，所以采用速度非常惊人。他们内部构建的东西并不是随便拼凑出来的小玩具，而是相当复杂的项目。转向 AI 编程之后，我们做的测试更多，也采用了不少测试工具，确保最终结果确实可靠。 **Gary：** YC 的创业公司里也能看到这种情况，比如 Blacksmith、Depot、UbiCloud，它们都在做 CI，因为大家都在用 CI。测试数量也暴涨了。 **Gary：** 这很疯狂。是不是模型终于够好了，大家花足够时间试用之后，就发现“这确实挺好”？ **Paul Copplestone：** 还得让人信服。尤其工程师，年初时可能觉得模型还不怎么样。模型确实进步了，但工程师也开始看到，原来用这些模型真能做出很棒的成果。Navier–Stokes 方程等方面的进展，也在让市场相信我们确实能在这里开创新局面。我觉得我们正在走向这样的阶段：大家已经相信这就是未来的工作方式。 ## [19:58] 一路走来的经验 · YouTube **Gary：** Supabase 经历了三个阶段：在 YC 用 100 天做出的仪表盘公司、API 公司，现在又到了“做智能体想要的东西”这个阶段。每个阶段有没有一两件事，让你觉得“这就是让我们在那个时期成事的关键”？ **Paul Copplestone：** 你刚才提到，Supabase 刚进 YC 时，别人会问为什么要有一家数据库公司？ **Gary：** 对，当时这想法听上去相当反主流。 **Paul Copplestone：** 是的。我们发现，哪怕对开发者来说，数据库也很难用。所以最初做仪表盘，是想在 Postgres 上面做个类似 Airtable 的界面。我当时就很喜欢 Airtable，觉得如果它背后直接是 Postgres 数据库，不是很棒吗？这是第一个阶段：意识到软件工程师自己都觉得数据库难用。 后来转向 AI API，是因为有个集成方跟我们说：“我们想启动很多数据库，需要一个 API 来完成这些事。”那大概是 2021 年。结果到了 2024 年，这个决定刚好派上用场，Bolt、Lovable 等产品都开始构建在我们上面。 今年我发现，已经没人来仪表盘了（笑）。智能体要怎么构建？我给团队写了一份产品备忘录：必须代码优先、原生支持代码。Supabase 得转向代码优先；仪表盘上能做的事，代码里也必须同步可用，本质上就是基础设施即代码。我们也重新设计了很多 CLI，让它能在代码沙箱里运行。 **Gary：** 你们最初是不是受 Parse 这家 YC 公司启发？ **Paul Copplestone：** 是的，我很喜欢 Parse 和 Firebase。这些浪潮挺有意思：它们做后端，后来 Firebase 被 Google 收购，Parse 被 Meta 收购。从某种意义上说，它们为我们铺了路，让数据库业务变得可行。2014 年时，如果不用 RDS 做数据库简直不可思议。后来有公司开始转向 Atlas，大家逐渐证明，数据库公司不一定只能是三大超大规模云厂商之一，也可以是一门正经生意。时机对我们很关键。 **Gary：** 大家有点忘了，但 Parse 是个做得很好的产品。我刚开始做 iPhone 应用时，他们正好推出，能用上体验不错的 REST API，真的很方便。 **Paul Copplestone：** 这些转变总是伴随市场拐点。那时市场上发生了两件事：MongoDB 不知怎么让大家相信 NoSQL 是很棒的数据存储方式；另一件事是移动互联网。我们也很幸运，赶上了几波浪潮。现在我们正处在浪潮中心。 **Gary：** 这也让我想起之前问过的企业与早期用户问题。再往前看，Heroku 提供了很好的开发者体验，让人先开始用、再逐步扩展。但要跟着用户一起扩张确实不容易。我觉得 Heroku 没能完全跨过这道坎：应用变大、性能要求提高之后，怎么让用户继续留下？不过每家公司历史上都得解决这个问题。你们也在考虑，但也许不一定非得靠这个市场；如果从零到十这一端的市场继续按现在的速度扩张，规模会非常大。 ## [24:00] 一路走来的经验（续） · YouTube **Paul Copplestone：** 我们要把整个市场都拿下来（笑）。也许不一定非做不可，但肯定会做。也要肯定 Heroku 的贡献，我认为他们让 Postgres 普及起来了。不过当时 Postgres 还很新，也有扩展性限制。所以我们必须在 Postgres 外面加上一层工具，让它能够持续扩展。 **Gary：** 对你们来说，更好的类比可能是 AWS：它能从早期就吸引用户，并一路扩展。你们从中学到什么？怎么确保能够无限扩展？ **Paul Copplestone：** 我听到过一个数据，可能记错了，欢迎帮我核实：AWS 的营收大约 40% 来自那些最初在 AWS 起步、后来成长起来的创业公司。这正是我们想要的客户。要说服用户从一个数据库供应商迁移到另一个，几乎不可能。所以我们想从第一天就在场，让他们用得开心，并且不想离开。 **Gary：** 这和 Stripe 的商业模式一样。如果能做到，这大概是地球上最好的商业模式：第一天就吸引他们，然后随着全球增长最快的公司一起无限扩张。 **Paul Copplestone：** 你只要这样做一代人的时间，就会成为一家世代级的企业，差不多就是这么回事。难的是“第一天”如今变化太快。以前我觉得第一天就是 YC 的创业公司；现在第一天意味着人人都是创造者。那他们会用什么？会用什么方式构建？又会怎么选数据库？这些问题都很棘手。 **Gary：** YC 下一期创业营现已开放申请。你心里有个创业点子吗？去 ycombinator.com/apply 申请。永远不嫌早，填申请表也能帮你把想法打磨得更清晰。好，我们回到节目。 **Gary：** 客户群体也变了。你们刚开始时，个人数据库市场几乎不存在；一家数据库公司做面向消费者的生意，听起来简直像语法错误。 **Paul Copplestone：** 对。 **Gary：** 但现在你们实际面对两个群体：早期创业公司可以带来类似 Stripe 那种很有价值的商业模式；你们也直接服务消费者，甚至服务他们的智能体。 **Paul Copplestone：** 是的。 **Gary：** 个人用例可能不会像创业公司那样扩展，但他们也许一辈子都会用你们，因为 Supabase 支撑着他们的个人理财软件、出租车公司之类的东西。 **Paul Copplestone：** 对。随着他们的生活发展、积累更多信息，这些数据基本上就是个人成长的索引。人们会收集更多数据，因此这个“专业消费者”市场对我们来说是很好的增长方向。 **Gary：** 从个人智能体的角度，你们怎么理解下一阶段？既然编程智能体已经很明确地选择 Supabase，假设每个人都有个人数据库，你们需要专门做些什么，才能让个人智能体更容易接入吗？还是基本一样？ ## [27:29] 面向个人智能体构建与自用验证 · YouTube **Paul Copplestone：** 一周前我的行政助理休假，我亲自体验了它们能做什么，现在我对个人智能体非常看好。我开始着迷于为个人智能体构建产品。我跟公司说，我们是代码优先，服务的是用代码构建的人；但实际上我们是在为智能体构建，因为很快那些人就不再直接操作了。 我现在的做法是用 Dots。我一直和它通电话、聊天，让它帮我改东西。为了确认自己真的在用产品、在做“吃自己的狗粮”式验证，我给自己定了个标准：不看代码，也不检查架构，除非我想确认它确实按预期构建。平时要改东西时，我只想和它说话，看它能完成什么。 **Gary：** 自己人！ **Paul Copplestone：** 这东西做出来的效果太惊人了。两年前看起来像科幻电影里的东西，现在却已经发生在我身上。我不断遇到这种让人目瞪口呆的时刻。六个月前给别人看，他们肯定会觉得不可能。 **Gary：** 我几周前去了你们的 Supabase Select 大会，办得很棒。我当时突然想到：如果我在 Supabase 上开发应用，也许我自己根本不必了解那些新功能。我可以派智能体去 Supabase Select 听完所有新功能，再让它想办法集成到我的代码库里。 **Paul Copplestone：** 这想法太疯狂了。我们该办一场真正的虚拟大会，专门给智能体参加。 **Gary：** 一场智能体大会（笑）。 **Paul Copplestone：** 它们可以实时到场。 **Gary：** 实时交流、互相分享使用 Supabase 的技巧。哇。 **Paul Copplestone：** 可以搭个桥，把 Markdown 文件空投给它们，但你得坐在观众席里才能拿到。 **Gary：** 就叫“Artifactory”吧。 **Paul Copplestone：** 哈哈，这名字我喜欢。 **Gary：** 节目开始前我们还聊到一些能让智能体更喜欢你们的做法，比如错误提示。你们当时意识到的关键是什么？还有哪些事情看起来很明显，但其实还没什么人在做？ ## [30:01] 面向智能体的设计与评测 · YouTube **Paul Copplestone：** 你刚才提到错误提示。我在波士顿参加 dbt Labs 的活动时，对方问到这件事，我很意外大家没觉得它显而易见。我们认真改进了错误消息。比如有人想开发一个应用，通常开发者工具遇到错误只会给个 500 之类的状态码，告诉你出了问题；现在我们希望智能体自己能修复。因此错误消息里会直接写清怎么修，或者去哪里看文档。关键是选定使用场景，不断迭代错误提示，让智能体尽量一次就把事情做对。 **Gary：** 对，过去人遇到错误得自己去 Google、做一堆排查；现在可以直接告诉智能体“你是 inode 用完了，应该这样处理”。 **Paul Copplestone：** 让智能体选中你们只是第一步。第二步是它们遇到问题时，别让它们转去别处；它们迟早会卡住，所以你得给它们解决问题的工具。这并不复杂。它们现在足够聪明，能自己想明白很多事；但过去为人类和开发者设计的产品，确实得重新为智能体设计。 **Gary：** 你们会针对智能体测试产品吗？让智能体尝试使用 Supabase，然后反馈哪里遇到困难？ **Paul Copplestone：** 会。我们在 Evals 网站上评测各种模型，看哪些模型构建效果最好；内部也有自己的评测套件，测试哪些模型更擅长使用 Postgres。这对整个行业有参考价值。我们还围绕它们构建技能，让智能体能采用并实际使用 Postgres。现在工程投入很大一部分都用于测试具体场景，而不只是构建产品。我们会想清楚大家怎么构建，再围绕这些场景做测试集。 **Gary：** Gary，你做 G Brain 时把它建在 Supabase 上。你当时为什么选择 Supabase？自己作为用户的体验怎么样？ **Gary：** G Brain 是我以前写的一系列东西提炼出来的。我最早做的是 Gary's List，一个智能体新闻编辑室；我为它搭了研究系统，支持 RAG、政策和论文研究，能阅读某个主题下的每篇新闻，再尝试综合起来。之后我把它提炼成 OpenClaw 的开源检索系统。 当时我把它放在 Rails 里，像一座给智能体用的富士康工厂：每次调用大语言模型都特别昂贵，也极其危险。看到 OpenClaw 后，我觉得它让人用 AI 的方式完全不同。AI 很聪明，也不是要害你，所以应该让它去做事，给它数据和能力。 我意识到，百万 token 的上下文其实是很惊人的工作记忆。大多数人脑子里只能同时记住七个上下、正负两个概念；百万 token 相当于三本《哈利·波特》。但对智能体来说还是有局限：每次都把正确的三本书放进上下文，本身就是个难题。所以公司知识库或个人知识库需要一个介于两者之间的方案。 ## [34:01] 面向智能体的设计与评测（续） · YouTube **Gary：** 我有五十万个 Markdown 文件，记录了我经历过的所有沟通，因此它确实掌握了我的背景和关心的事。但在某个具体时刻，智能体可能只需要其中两页。这是检索问题。数据量达到三四十 GB 时，就需要 pgvector 和 Postgres；用 SQL 也很容易做图数据库。所以 G Brain 就是 RAG 检索，加上一个能把非结构化数据整理成结构的图数据库，支持动态 schema，有点像我记忆中的早期 Palantir。 核心想法是，中间有这样一层，智能体可以说“我要找这个”，系统就遍历图结构、做向量搜索，然后返回一份报告，告诉它把什么放进上下文。这就是 G Brain。Supabase 则很直接：我需要托管的 Postgres，而且得能很快支持 50、100 甚至 300 GB 的数据库。它表现很好，自动扩缩容也很好用。现在最有意思的是，我用侧边栏浏览器来调用浏览器功能，OpenClaw 可以自己进入 Supabase，使用数据库或你们的新 API，自己就能管理起来。 **Gary：** 你还得提示它怎么设计数据结构吗？比如图结构、RAG 之类？ **Gary：** 有意思的是，我记得当时在 Cloud Code 里只说：“用 Exa 找到并下载所有 AI 研究论文，然后给它们做说话人分离。”今天我可能会用 AlphaSignal 之类的工具。我让它找出所有关于 RAG、图数据库和文本检索的研究，再结合我的场景做总结：怎样才能让智能体访问这些资料？它做完后就告诉我：“好，我们可以这样实现。” **Gary：** 前几天我参加了一场数据库未来主题的晚餐会。有人提出，数据库本质上是数据检索机制；你可以加索引，让它按图结构或 RAG 等方式搜索。还有一个特别有意思的想法：让智能体不断循环，为检索创建最合适的数据结构。如果某个数据集被反复查询，每次都要十秒，为什么不让智能体循环运行，创建一种新索引，找到最合适的索引，把响应时间降到一秒以内？ **Paul Copplestone：** 只要代码生成足够聪明，动态检索显然就会出现。 **Gary：** 目前我用它来服务 OpenClaw：用生产环境实例，再把运行轨迹提取成评测数据集。我有个单独的仓库叫 G Brain Evals，分成四十种类别，覆盖不同检索类型、检索效率、成本效率和延迟。评测的好处是，你可以让智能体循环、自主研究；只要能改善评测指标，就直接合并到主分支。 **Gary：** 试过但没奏效的办法，也写成 Markdown 文件，解释你觉得为什么不行，再放进 G Brain Evals 里。我用 Cappy。它有个叫 captain 的概念，类似 Grok bots；你给它一些上下文就行。我有一个 captain 一直在想新的评测类别，另一个每天遍历所有评测类别、自动研究，尝试提升内部评测成绩。 ## [38:02] 面向智能体的设计与评测（续） · YouTube **Gary：** 它就一直这样运行。这是针对某个具体场景的非常原始的递归自我改进（RSI）版本。但如果把抽象层级提高一点，就能把它用于所有人的检索场景，而不只是我的 OpenClaw 用例。会变化的只有具体场景、运行轨迹和数据集。 **Paul Copplestone：** 嗯。 **Gary：** 你也可以让它每天尝试改进这些指标，自动研究每个评测类别。 ## [38:42] 编程的未来 · YouTube **Gary：** 你了解评测，也知道怎么用一整套框架改进软件。你觉得未来的创造者也得懂这些吗？ **Gary：** 也许不用。说实话，我觉得现在还很早，我只是在自己摸索，也把做法开源出来。希望别人看到后能说：“这个方法我也能用。”我们现在其实是在一起摸索使用这些工具的基本方法。今年早些时候我读过 Steve Yegge 写的工厂之类的东西，当时完全没弄明白。现在我觉得自己至少拼出了一套对我有用的东西。 **Gary：** Boris Turney 来做节目时，他描绘的编程未来更像是：你把 Claude 当朋友一样聊天，不必懂评测或其他复杂东西，Claude 自己就会琢磨怎么把你脑子里的东西做出来。 **Paul Copplestone：** 我有个域名 openusd.dev，因为 OpenUSD 是一种文件格式，而且我平时会收集域名。后来 Stripe、Visa 等公司突然都宣布了 OpenUSD，我就想：得把这个域名用起来。但我一直没时间。于是我开始和 Dots 聊，它帮我开发了一个面向开发者的生态站点。起初我在电脑上和它聊天，收工时又用手机打给它，躺下准备睡觉时还在聊——听起来有点可疑（笑），我保证我只是在和它写代码。 我跟它说，不喜欢生态系统链接到使用场景的信息架构，能不能提些建议？它提了方案，我说好，就按这个做。二十秒后它说已经完成，问我要不要刷新。我刷新网站，内容写得很好，各部分也都串起来了，连 SEO 相关的东西都做好了。传统上得做的那些事我一样没做，只是一直和它聊天。那一刻我仿佛看到了未来。 **Gary：** 你能做到这一点，是因为你知道自己想做什么。 **Paul Copplestone：** 对。我有工程背景，大概知道怎么给它提示，但我在努力什么都不告诉它，也不把它引到 GitHub 等地方。我想像普通人——或者明年才开始用的人——那样来写代码，这样我才能用自己的产品验证：一年后用 Supabase 的体验会不会很好？ **Gary：** Boris 说过，他希望模型自动完成这些事。等它们真正普及以后，模型会把能力直接学进权重里；在那之前，我们还得给一些 Markdown 指引，其实不需要很多提示，少量提示它就能完成。我们正在进入一个很奇特的时期：递归自我改进似乎真的来了，AI 研究正在通过 Cloud Code、Codex 等系统里的循环，从完成 20% 快速走向 80%。与此同时，社会里还没有足够多像你，Paul 这样知道要做什么、知道该怎么问的人。这就像势不可挡的力量遇上不可移动的物体：模型能力正在指数级攀升，真正知道怎么用它改变社会的人数却基本没变。 ## [42:36] 让更多人创业 · YouTube **Paul Copplestone：** 我觉得人们还应该愿意为未来感到兴奋。很多人开始焦虑，但我真心期待未来能给很多人带来什么。我以前做的很多创业项目都关注蓝领工人，也就是那些一生中必须辛苦工作的人。我特别喜欢 Supabase 的一点，是我看到这个平台催生了许多创业者。我能想象未来会有更多人创业，而且对很多人来说，这会是一种很有满足感的生活方式。所以我很期待 2027 年。只要我们能保持现在的节奏，别遇上几件离谱的大事，对很多人来说都将是一段有趣的旅程。 **Gary：** 我们正看到这样一个阶段：垂直 SaaS 创始人很难融到 A 轮。过去，年经常性收入（ARR）达到 500 万到 1,000 万美元，就已经很高了，九到十二个月前几乎保证能拿到 A 轮；现在投资人似乎不太看好垂直 SaaS。横向软件和 AI 投资看起来倒是一路绿灯。但与此同时，十到十五个人的团队，往往能做到 1,000 万到 1,500 万美元营收，有时甚至达到 2,500 万、3,000 万或 5,000 万美元。这种规模已经很赚钱了。 **Paul Copplestone：** 对。如果团队只有 15 人，人均 ARR 200 万美元、利润率 50%，每个人一年就能分到 100 万美元。这对很多人来说已经是很棒的结果。 **Gary：** 是啊。与此同时，我们做了很多创业咨询。有些人拿到了“金环”，却因为融不到 A 轮而沮丧。我常跟他们说，回头看这可能是件好事，因为你并不需要这笔钱。过去要做到年营收 3,000 万美元，可能得先融 1 亿美元，因为必须雇很多人；现在不必如此。 **Paul Copplestone：** 创业圈确实把融资当成一种勋章。我刚开始拿到融资时也觉得自己成就很大。但现在在我看来，不融资反而是一种成就。所以我有点羡慕那些已经走到这一步的公司。 **Gary：** 世界变化太快了，但你们 Supabase 一直能乘上每一波浪潮。你对想效仿你们的人有什么建议？ **Paul Copplestone：** 数据库已经存在五十年了，我觉得还会再存在五十年。无论 AI 最后发展成什么样，我相当确定数据库依然会在。你可以从中自己得出结论：选择足够长久的领域。如果要把一辈子押进去——我基本就是这么做的——那就选一个你认为值得投入的领域。 另一个建议是，事情变化太快，我们不会假装 Supabase 什么都知道，而是尽量保证自己适应得最快。我很喜欢很多开发者工具公司，它们最初服务开发者，后来逐渐走向企业市场，变得很企业化、停滞下来，也失去了原来的热情。 ## [46:38] 让更多人创业（续） · YouTube **Paul Copplestone：** 至少在我看来，Stripe 这类公司有个很特别的地方：创始人真正在意新的构建方式。如果你要为下一波浪潮做产品，就得始终关注下一步会发生什么，而现在变化周期特别短，发展非常快。你必须高度灵活，确保团队有余力迅速转向。这是我们明年要重点做的事。 **Gary：** 你经历了好几次拐点：最初的 vibe coding、Opus 4.8，还有代码生成。下一波浪潮到来时，你们会做些什么，让自己准备得更充分？ **Paul Copplestone：** 首先，自用验证非常重要。我一直用自己的工具来试，看看哪里有缺口。没有什么反馈比自己被自家工具卡住更直接。另一个关键是留出余力。我们努力和行业里的关键参与者合作，这种生态合作很有帮助，他们会告诉我们正在做什么。我们也尽量给团队留出一些产能，虽然很难，但这样他们有新想法时我们就能试一试。很多尝试看起来很酷，最后其实都失败了；但有些尝试确实奏效，于是我们就能一起乘上很棒的浪潮。 **Gary：** 这是个很好的结尾。Paul，太感谢你了，回头见。