从复制代码到重组工作：Paul Graham 与 Amjad Masad 谈 Replit 的价值演变

一、嘉宾背景

本集由 Paul Graham 与 Amjad Masad 对谈。Masad 代表 Replit 介绍平台的产品理念、工程积累与发展历程，讨论从 AI 编程和自主执行延伸到企业工作：在线编程平台如何将用户自行组合的 AI 工作流程发展为 Agent，又如何面对企业内部的价值创造与资源配置问题。

Replit 提供 AI 编程与应用部署能力，平台还包括数据库、沙箱和基础设施配置。因此，Masad 所谈的应用生成涵盖了代码之外的运行条件：程序需要执行环境，也可能需要数据存储和托管。这些能力构成了他判断平台优势的背景，也使他的论述带有明确的产品立场。

Masad 对在线编程的关注由来已久。他回忆，约在 2008 年便希望能用智能手机编程。Graham 将他识别机会的能力与多年反复思考在线编程联系起来。这段经历有助于理解他的长期方向，但不足以将后来的每项成功都归因于早期远见。对谈更具体地呈现了这一兴趣如何经过用户观察与工程实践，逐渐成为可以交付的产品能力。

二、本期主要内容

Replit 的 Agent 起于一套用户已经自行拼出的工作流程。Masad 说，团队邀请用户到办公室，发现没有编程经验的人会在 ChatGPT 和 Replit 之间反复切换：复制生成的代码，运行程序，把错误信息送回 ChatGPT，再复制修复方案。用户已经在投入时间完成这些操作，平台尚未将它们连成一个完整过程。

Graham 追问的是，这个过程自动化之后，系统究竟要承担什么。免去复制粘贴只是其中一步；系统还要理解错误、修改程序、重新执行，持续推进，直到程序能够工作。Masad 将其描述为让语言模型运行到完成。两人的讨论由此从一次回答转向持续接收反馈的执行过程。不过，怎样判断程序已经能够工作，对话没有给出严格的正确性验收标准。

Replit 已有的平台能力为这条路线提供了基础。Masad 介绍，AI 可以通过工具调用配置数据库和托管资源；原有协作系统则允许早期 Agent 作为另一名用户进入同一项目，与人共同工作。团队分工也随之调整：Replit 在代码执行、云服务、连接层和 IDE 团队之间加入 Agent 团队，让其他团队为 Agent 提供工具。自然语言交互由此连接到已有基础设施，也改变了各团队之间的协作方式。

早期模型并不能可靠地完成这些动作。Masad 回忆，模型会虚构行号，也会留下未完成的函数。团队必须自建稳健的编辑工具，检测遗漏，再让任务继续循环。要让 Agent 持续执行，既需要模型生成内容，也需要编辑、检查和恢复执行的机制，使不稳定的输出仍能被后续步骤处理。

对话随后从应用开发延伸到企业工作。Masad 用“自动驾驶公司”描述 Replit 的扩展愿景，并称 Replit 自身是 customer zero，用自己的组织探索工作方式和企业结构的变化。当软件创建变得更容易，哪些工作可以重新安排，成为他关心的下一层问题。节目呈现了这一探索方向，尚未证明企业运营已经实现全面自动化。

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

模型进步既扩大产品能力，也可能削弱既有工程优势。Masad 估计，Replit 在 2024 年用于组织模型、工具和执行过程的 Agent harness，比访谈时复杂十倍。他承认，模型进步也让竞争者更容易进入。早期模型虚构行号、留下未完成函数的经历说明，部分工程工作是在弥补模型缺陷；随着模型改善，这些补偿机制可能不再稀缺。十倍是他的回忆性估计，不能视为按统一口径测得的行业规律。不过，哪些复杂性会随模型进步而消失，确实关系到产品下一阶段的价值。

另一些复杂性来自软件运行本身。Masad 介绍，Replit 自建了支持事务和完整回退的文件系统，并认为基础设施的深度有助于争取重视可靠性与安全的企业客户。按这一逻辑，代码越容易生成，执行环境、部署和恢复等工作的价值就越突出。但这些能力也有代价：他承认，护栏有时会增加延迟和成本。访谈没有提供独立安全评测，因此不足以据此判断 Replit 相对所有竞争产品的可靠性优势。

早期产品的吸引力，需要结合用户原有的选择来理解。谈到测试版时，Masad 将最初较高的粗略失败估计修正为约三成。Graham 认为，对原本不会编程的人来说，即使只在部分情况下能完成程序，也可能显著改善其实际选择。这个判断取决于两个条件：失败可以承受，成功做出的程序确实有用。它不能说明所有场景都应接受相同程度的不稳定，回忆中的粗略比例也不能充当正式性能基准。

成本比较同样需要保留条件。Masad 举出请人开发应用花十万美元、使用 Replit 花一千美元的比较，又转述企业客户的说法：一个原估算一千万美元的项目，在 Replit 上花了二十五万美元。这些叙述反映了他所看到的购买动机——用户需要成果，而原有替代方案可能昂贵。但节目没有交代项目范围、验收质量、维护成本和后续责任，不能仅凭金额推导同等条件下的普遍节省幅度。这些故事可以帮助理解需求，尚不足以核验节省比例。

Replit Bounties 的经历则说明，已有需求未必能支撑一种交付方式长期存在。Masad 回忆，平台曾让开发者借助早期 AI 承接开发需求，后来判断用户会直接向 Agent 请求完整成果，于是关闭了这项业务。他预期改变的是交付过程中的中介环节，而非需求本身。这个判断值得用于审视产品的位置，但不能据此认定所有服务或外包工作都会以同样方式消失。

进入企业后，推动采用的往往是主动解决内部问题的员工。Masad 以销售负责人为部门制作工具为例，将这些人视为 Replit 使命的延续。然而，使用者并不独自决定采购。管理员需要控制权限、预算和规则，IT 与安全要求有时又会损害使用体验。企业客户内部存在不同目标：产品既要支持愿意动手解决问题的人，也要满足组织的管理要求。

token 额度集中体现了这种张力。Masad 反对按人统一分配每月额度，主张关注投入回报率（ROI），并声称客户内部的回报呈幂律分布。两人谈到的百倍、千倍贡献没有配套测量方法，不能直接作为预算依据。Graham 进一步提出，帮助企业辨认哪些个人项目值得投入，可能触及大公司难以识别个人贡献的管理问题。产品机会由此延伸到成果识别与资源分配，但如何衡量、如何归因，在对谈中仍是有待探索的问题。

“自动驾驶公司”的愿景也受这些未解问题约束。Replit 将自身作为实验场，表明它正从内部工作方式入手探索，但这不意味着价值识别或组织自动化已经解决。Graham 提醒，“成为 AI 进入企业的通道”很容易成为空泛表述。Masad 的回应是保持总体方向，沿着客户需求逐步推进，让客户成果说明变化。这个愿景能否成立，最终要看具体工作是否得到改善。

四、学习与应用

产品团队可以从观察用户完成整项任务入手。让用户用自己的工具处理一次真实工作，记录代码、错误信息和修复方案如何流转，哪些步骤需要等待，失败后怎样恢复，比单独询问功能需求更能揭示重复劳动。Masad 描述的办公室观察提供了一个实例。他也坦言，看到用户困惑或遇到错误会让自己感到痛苦，而公司逐渐形成了持续接近、联系用户的文化。这样的观察要求团队保留令人不适的证据，找出用户反复承担的工作，再决定自动化应覆盖哪些环节。

设计 Agent 时，需要把终止目标落实为可检查的交付条件。内部工具试点可以事先约定必要功能、允许操作的数据、失败后的恢复方式，以及需要人工确认的环节。这些是从对谈中的执行循环推导出的实施建议，并非节目已经验证的方案。它们会增加设置和检查时间，但仅凭程序成功启动，无法判断实际需求是否得到满足。对于结果难以验收或失败代价较高的任务，应先缩小范围，避免依靠不断延长循环来追求完成。

企业采用可以从明确的部门问题开始。销售负责人为部门制作工具的例子，提示团队寻找既理解工作、又愿意动手的使用者，并提前让管理员确认权限、预算和规则。预算讨论则应落到具体项目的预期结果、实际使用和维护负担上。统一额度便于管理，却可能限制高价值项目；允许追加投入，又需要更充分的证据。访谈中百倍、千倍贡献的判断，以及客户提供的金额比较，都不能替代组织自己的核算。

评估采用障碍时，还需要分别检验能力与交互形式。Masad 承认低估了短信式 Agent 交互的影响，并表示这一认识尚未影响当时的 Replit 产品。由此可以提出一项产品检查：即使底层任务相同，也要观察用户是否理解入口、知道如何提出要求，以及能否判断任务已经结束。生成质量只是其中一部分。若新界面降低了学习成本，却让执行状态变得不清楚，就需要补充状态展示和确认机制。相似的功能未必具有相同的使用门槛。

对未来能力的判断，可以通过记录和复盘预测来改进。Masad 说自己会主动预测、回顾并修正预测；团队可以据此写下能力假设、尚缺的条件，以及下一次检查时要观察的信号，再用用户行为判断是否继续投入。以技术仍会变化为前提，有助于避免把当前缺陷视为永久限制，但不能因此无限推迟验收。长期方向需要与持续纠错共同发挥作用。

学习和转型也可以通过范围明确的亲自使用来推进。Masad 强调灵活性、适应力和终身学习，表示愿意放弃熟悉的工作方式、重新开始。他还转述了一次未具名大型电信企业的活动：参与者使用 Replit 一小时后，从约八成焦虑变为约八成乐观。这段叙述可以为小范围体验活动提供启发，却不能证明长期就业影响或普遍态度变化，因为节目没有说明样本量、问卷设计或长期追踪结果。活动之后，更有用的检查是参与者能否独立完成下一项任务、识别错误，并知道何时求助。

平台能力与代办服务的责任也需要说清楚。Masad 回忆，早期有企业要求 Replit 代为重写 COBOL，他选择教客户使用平台，而非替客户编写代码。采用生成工具，并不会自动转移系统维护和验收责任；产品方是否亲自承接交付，也会改变业务边界。提前明确这些责任，才能将支持用户自主开发的主张落实为具体的合作安排，避免到项目结束时才发现双方对交付责任理解不同。

来源

• 原始节目：How To Build The Future: Paul Graham & Amjad Masad