人人能构建软件之后：Paul Copplestone 谈需求判断、个人数据库与智能体的执行能力

一、嘉宾背景

Paul Copplestone 是 Supabase 联合创始人兼首席执行官。嘉宾资料将 Supabase 介绍为一个基于开源 Postgres 的数据库与后端平台，服务于开发者和借助 AI 构建应用的人群。他在本集中的观察，主要来自平台的开发与经营，以及对仪表盘、API、代码和 CLI 等产品入口的持续调整。这些经验提供了一个平台经营者的视角，其范围并不覆盖整个软件行业。

Paul 强调，Supabase 的开源实践包括支持已有的生态工具。因此，他所讨论的面向智能体的产品开发，既涉及接口，也涉及工具兼容与社区采用。他还明确提到自己的工程背景：使用智能体时，他会刻意减少技术指示，尝试体验未来普通用户的使用方式，但理解需求、说明改动和检查结果的能力，仍受到已有经验的影响。

谈到个人动机，Paul 说，自己过去的几家创业公司曾围绕蓝领劳动者提供技术。他对 Supabase 的热情，则与在平台上看到更多人尝试创业、构建定制软件有关。这解释了他的乐观从何而来，尚不代表这些机会都已兑现。这场由 Y Combinator 发布、题为《What Happens When Everyone Can Build Software》的对话时长2925秒，约49分钟，将他的经营观察与主持人的个人构建实践放在一起，讨论软件构建方式和基础设施正在发生的变化。

二、本期主要内容

访谈从 Supabase 的增长谈起。Paul 称，平台已有1300万注册，一年前估计约为300万，并预计当年收入将增长至四倍；主持人则称，约70%的新增活动来自智能体。Paul 还表示，每周新建的数据库超过100万个，管理中的数据库接近5000万个，而一年前约为800万个。这几组经营数字衡量的是不同活动：注册量并不等于活跃用户数，数据库数量也不能直接换算为付费客户或独立应用数量。

Paul 更看重的是注册之后的变化。他表示，注册加速通常可能伴随激活率和转化率下降，但他观察到这两项指标也在改善。他将其归因于模型更有能力完成构建任务，以及越来越多非工程背景的构建者开始参与，同时强调软件工程师仍占相当大的比例。由于对话没有提供指标定义、分群数据或因果检验，这些观察更适合作为用户结构变化的线索，尚不能说明所有新增需求都具有同样的质量。

产品入口也随之改变。Paul 回顾，最初的 Supabase 希望通过类似 Airtable 的 Postgres 仪表盘降低使用难度。约2021年，集成方开始要求通过 API 批量创建数据库，后来 Bolt、Lovable 等工具也采用了这种使用方式。如今，他要求仪表盘中的功能同步提供代码入口，并重新设计了适用于沙箱的 CLI。从界面操作走向代码优先，意味着平台需要让智能体也能完整地执行操作。

需求端的一个变化是个人软件的出现。主持人构建的 Control Tower 集中处理邮件、财务、体重和运动记录。他原本偏好只通过 OpenClaw 聊天、使用 Markdown，无需 UI 或数据库，实际使用却改变了这一判断。对话降低了操作门槛，而记录、查看和整理生活数据，仍让他看到了界面与数据库的价值。这段个人经验呈现了不同交互方式如何互补，并不足以推断聊天能够取代所有界面。

平台还要同时应对轻量与大型负载。Paul 引用自己记忆中 ChatGPT 拥有12亿周活用户的数字，作了一个假设：如果每人每月构建一个应用，就可能对应每月12亿个数据库。这是对潜在容量需求的推演，并非已经发生的需求。他提出用 Spark 承接入门负载，并朝着从原型延伸至 PB 级规模的方向发展，也承认兼顾两端、扩充团队都很困难。转录中提及的相关收购对象与另一产品名称不够清晰，无法确定。增长数字、产品入口和负载规模最终汇成同一个经营问题：构建者越来越多、构建方式不断变化，数据库平台如何从用户第一次尝试起，就持续提供服务？

三、核心观点：推理、例子与边界

软件实现的门槛降低，让更多领域知识有机会转化为可用的软件。主持人提到，一位曾以超过10亿美元出售公司的金融科技创始人，过去只能拼接 Ruby 脚本、依赖工程师，如今已经能够编写银行集成、个人资产负债与财务追踪工具。Paul 则讲到一位约50岁的巴西出租车司机，用手机为本地市场构建小型出租车应用。前者熟悉专业流程，后者贴近具体市场；两者都表明，过去难以获得工程资源的需求，如今有了实现的可能。

这些案例能够说明参与构建的人群正在扩大，尚不足以说明其成果。Paul 坦言，他不知道那位司机为什么要做这个应用；对话也没有交代两个案例的用户量、可靠性或商业回报。嘉宾和主持人认为，领域专家更容易发现未被满足的细分需求。当实现变得更容易，知道什么值得构建、能够说明需求细节，并判断结果是否符合原意，就变得更有价值。

对工具提供方而言，被模型选中和让智能体顺利完成任务，是两件相连但不同的事。Paul 认为开源有助于 Supabase 获得采用，同时承认无法知道不开源会怎样。可检查的源码可能帮助智能体排查错误，也便于企业审查，但对话没有将这些机制与其他因素分离，验证其对增长的贡献。相比首次被推荐，他更关注出错之后能否留住智能体：错误信息如果直接给出修复步骤或文档位置，智能体就能据此继续操作。这样的设计着眼于减少任务中断，让一次选择最终变成一次完成。

个人软件的价值也体现在数据之间的连接上。Control Tower 的构建者自评，其财务功能至少已与 Mint、Monarch 相当。他给出的具体用法是，利用 GBrain 中的人物资料理解并分类交易；将体重记录与日历结合，则能把旅行纳入解释体重变化的背景。这些使用体验展示了跨数据源上下文的用途，但没有给出分类准确率，也不构成对通用财务或健康产品的系统比较。旅行在这里提供的是理解记录的线索，不能据此认定体重变化的医学原因。

GBrain 面对的进一步问题，是如何从大量资料中选出当前任务真正需要的内容。构建者称，他约有50万个 Markdown 文件，而一次任务可能只需要其中两页。即便上下文窗口达到百万 token，材料选择仍然是一个检索问题。他把 RAG、图遍历、向量搜索和动态 schema 组合成中间层：智能体提出寻找目标，中间层返回相关材料。Supabase 为其所描述的数十至数百 GB 语料提供托管 Postgres。存储容量、检索结果和最终装入的上下文各有作用，扩大窗口并不能直接解决相关性问题；这套方案也不能据此成为所有资料库的通用架构。

要持续改进检索，还需要可比较的评测。GBrain 构建者从生产 traces 中提取任务，建立了40类评测，覆盖检索类型、效率、成本和延迟。他授权智能体默认将改善内部评测的改动合入 master，同时用 Markdown 保存失败实验的解释，并让两个持续运行的智能体分别扩展评测类别、优化已有类别。这样既能比较改动效果，也能留下失败的经验。不过，对话没有交代独立验证或防止针对评测过度优化的方法，构建者本人也将这些工作称为早期探索。通过智能体优化索引、把10秒的查询压到1秒以内，仍只是讨论中的可能性，没有已实现的基准结果。

创业讨论则把问题带回经营。主持人观察到，ARR 约500万至1000万美元的垂直 SaaS 公司更难获得 A 轮融资，同时认为较小的团队可能支撑较高收入。对话以15人的团队、人均200万美元 ARR 和50%的利润率推算，每人对应的年利润约为100万美元。这是用于讨论资本需求与经营效率的假设算式，并非实际薪酬案例，也没有证明这种收入与利润组合普遍可达。减少融资需求可以是一种良好的经营结果，但前提仍是业务足以支撑目标；融资困难本身并不能证明效率提高。

四、学习与应用

规划个人软件，可以从一个反复出现、能够明确判断结果好坏的任务入手，再确定需要长期保存哪些记录。Paul 正在把日常流程和 CRM 数据从对单一个人智能体的依赖中抽离，让其他智能体也能连接同一批底层记录。这带来一个具体的设计问题：更换助手以后，联系人、交易和历史记录是否仍能读取？独立保存数据为更换入口创造了条件，但不同助手未必会以相同方式理解字段，仍需检查关键记录能否被正确使用。

文件如何进入系统，也需要单独考虑。主持人的做法是通过邮件转发或 UI 上传文件，由智能体解释文件用途，再将文件保存在 Supabase 的 S3 兼容存储中。这种方式可以延伸为一项设计原则：保留原始材料，使结构化记录能够回到对应文件。增加入口能带来便利，也增加了核对解释是否正确的环节。对话没有报告自动文件判断的准确率，成功演示因而不足以保证所有分类和后续动作都可靠。

开发者工具团队可以沿着一次真实任务，观察选择工具、执行操作、遇到错误、尝试修复和最终完成的全过程。这是对 Paul 区分“被选中”与“出错后留住智能体”的进一步应用。Supabase 采用多模型评测、Postgres 专项评测，并测试具体构建用例，说明评估可以围绕用户实际要完成的任务展开。团队可以先找出最常见的失败，检查错误信息是否提供了可执行的步骤或文档，再让智能体重试，以完成质量是否改善来判断效果。Paul 还提到，越来越复杂的 AI 编写的内部工程伴随着更多测试和测试工具；生成能力增强，也需要相应的验证投入。

对话式开发能够帮助人练习表达需求，但速度只是验收的一部分。Paul 在 openusd.dev 的案例中，先指出生态内容与用例之间的信息架构问题，选择建议，再让智能体实施。他称，约20秒后，内容关联和 SEO 相关工作便已完成。这个案例中可借鉴的是，先说明希望改善的内容关系，再检查结果是否体现了这些关系。Paul 有工程背景，也能够明确指定所需改动；完全没有技术背景的使用者，可能仍需协助判断架构或实现。一次修改完成得快，也无法说明后续维护成本同样低。

经营规划需要区分业务扩张与个人记录积累这两条增长路径。Paul 希望从客户第一天开始服务：创业客户可能随业务扩大而增加用量，个人用户则可能因为多年记录不断积累而持续使用。前者要求平台支持负载增长，后者更依赖长期记录的连续性。产品规划应明确所服务的增长路径，再检查资源投入是否匹配；数据库数量本身无法直接推算收入。

Paul 对适应性的要求，也落实在日常经营中：亲自使用新工具，找出自家产品中令人受阻的地方，听取生态伙伴的新需求，并为试验保留团队容量。他认为数据库是一个能够长期存在的品类，同时承认许多合作试验会失败。对品类的长期信心与对接口、产品尝试的持续调整可以并存。预留容量有机会成本，因此试验仍应围绕具体问题展开，也应允许缺乏证据支持的尝试结束。

来源

• 原始节目：What Happens When Everyone Can Build Software