超级组织解剖:Replit“自动驾驶公司”启示录

过去六个月，Replit（那家你可能用它"用嘴写代码"的在线编程平台）的工程师团队，代码产出涨了将近3倍。

正常情况下，产出涨这么快，代码审核会跟不上，返工会变多，线上事故也容易一起往上走。Replit 公布的数据却是： PR 审核耗时没有变长，撤销率和新事故数的趋势基本持平；代码量增长后，相对质量指标反而改善，发布速度也更快了。

你能想到的那些“鱼与熊掌不可兼得”的权衡，至少从 Replit 公布的数据看，这次没有发生。

代码只是看得见的部分。看不见的部分是：Agent 开始排查线上事故、审核代码、回答业务问题、分析经营数据、处理客服工单、调研销售线索，甚至参与改进 Replit Agent 自己。

CEO Amjad Masad 在公司博客里把这种状态称为 “自动驾驶公司”（The Self-Driving Company）。它不是没有人的公司。人依然决定去哪里、什么问题值得解决、如何取舍、谁为结果负责；只是越来越多时候，人不再亲自完成抵达终点所需的每一步。

这半年到底发生了什么、背后是什么在起作用、别人能抄走多少——值得完整拆开看一遍。

实录：一家公司如何学会自己开车

转折点：从“工具”到“系统”

变化始于 2025 年末的圣诞假期前后。Replit 团队发现，模型开始能在更长的任务里持续工作了。

过去反复失败的任务，比如告警分诊、根因排查，突然能跑通了；一些棘手的 bug，AI 也开始能够解决。于是，他们不再把 Agent 当成一个活在编辑器或聊天窗口里的工具，而是开始把它接进公司真正使用的系统。

一月底，团队先搭起 Agent 运行环境（microVM）和远程文件系统，让工程师可以编排一支 Agent“舰队”并行工作。随后，团队再用访问策略、令牌代理、审计日志和零信任网络把它们围起来。护栏搭好以后，GitHub、GCP、Azure、Linear、Notion、Slack、Zendesk 这些核心业务系统，才向 Agent 开放。

工程团队最先感受到冲击

三月 Agent 4 发布前，Replit 工程团队通常会进入冲刺：会议清空、范围明确，工程师一天工作最长 16 小时，全面转入“纯执行模式”。

但这一次，曲线不只是冲刺带来的尖峰。按 Replit 自己的归因，产出曲线的拐点可以追溯到新的内部 Agent 系统。

从 1 月初到 6 月底，工程团队贡献的代码变更行数涨到了 5.8 倍，团队同期接近翻倍。为了尽量控制人员扩张的影响，Replit 又观察了固定的 30 名活跃工程师——他们在统计首周和末周都至少合并过 5 个 PR。同一批人的每周代码变更行数，仍然涨到了 2.9 倍。

团队变大，协作成本通常也会上升。但这 30 名固定样本并没有被拖慢。

代码写得快了，审核会不会变成新瓶颈？

没有。Agent 会先做风险评估，只有真正需要人判断的部分，才交给第二位人工审核者。超过三分之一的合并 PR 已经由 Agent 批准。另一个口径是：Replit 称，人工审核时间节省了 30%。

质量有没有因此下滑？PR 撤销率和新事故数的趋势基本持平。至少从这两个指标看，质量没有为速度让路。

事故发生后，也有 Agent 先去调查根因。Replit 称，平均缓解时间（mean time to mitigation，MTTM）也在下降。再看业务交付：Linear 记录的月度工程项目完成数，已经超过原来的三倍。销售和市场团队也能更及时地告诉用户：“我们上新了。”

这些数字都来自 Replit 自报，目前没有独立审计；代码变更行数也不等于完整生产力或用户价值。

“Agent 调度 Agent”：Loop Engineering 规模化

工程师的工作方式也变了。他们开始“跑 loop”：让一个 Agent 调度多个 Agent，并行完成一项可以验收的任务。

每位员工都能使用一个“管理者 Agent”。它可以继续派生多个子 Agent，代表员工在不同任务里并行工作。 Replit 把这种模式称为 loop engineering。

几个例子很具体：一名工程师用它跑通了搁置已久的 CSS 系统迁移；另一名工程师完成了产品的多语言本地化迁移；还有人把长期不稳定的（flaky）测试维护交给 Agent；CTO 本人则调度一组 Agent，攻克了一个与 PSC 网络和 fd 关闭有关、困扰团队很久的底层 bug。

原文的说法是：

“All of our assumptions about what is possible have changed.”

“我们对于‘什么是可能的’这件事，所有假设都被改写了。”

AI 团队又把这套思路用回了 Agent 自身。他们搭了一套 持续学习系统：Agent 分析真实用户反馈，提出候选改动，再结合基准测试和 A/B 实验，判断这些改动是否真的有效。

Replit Agent 正在“自我改进”，而不再完全依靠人工团队逐项迭代。 但“自我改进”不等于“自己上线”。Replit 在 另一篇技术文章 里写得很清楚：它可以找问题、写候选修改、跑评测，正式发布仍由工程师决定。

所以，Replit 所说的“自动驾驶”，连驾驶系统本身也包括在内。

Build 还是 Buy 的对话变了

Replit 一直在评估市面上的 AI 工具。成熟产品能省时间，所以外部采购始终是选项。

但内部 Agent 接进知识库、代码和业务系统以后， 买和建之间的账被重新算了一遍。

一款帮工程师做告警分诊和根因排查的商业工具，Replit 认为质量与内部版本相当，成本却是内部版本的 10 倍；一款自动化渗透测试产品，找到的漏洞比内部版本更少，成本同样是 10 倍。

两套内部方案最终都上线了，事故缓解更快，关键系统的防护也更扎实。更直接的例子是，公司停掉了一项七位数规模的 SaaS 方案——员工已经自发迁移到用 Replit 自己平台搭出的内部应用，体验反而更好。

当 AI 真正嵌入企业自己的知识库、系统和使用习惯，外部方案可能会显得“不够懂自己”。

这些比较仍是 Replit 自报，原文也没有披露内部研发和维护的完整成本。但它至少提醒企业：过去算过的 Build 还是 Buy，到了 Agent 时代，值得重新算一遍。

工程团队先拿到了第一轮可见结果。Replit 的原文随后并列写到数据、销售、市场和服务支持四个场景。

它没有公开四个部门的上线日期，也没有披露一条“不经审批”的特殊通道。但有两件事写得很清楚：用法走出工程部门，主要靠 Slack 里的可见结果；新的 skills 和 integrations，则来自公司不同部门。

本文把这叫作“复制”。 复制的不是现成权限，而是一套已经跑通的工作方式：共用 Agent 底座，各部门补自己的知识和流程，拿不准的工作再交给人。

二、六条组织定律：从产研验证到业务扩散

一种常见做法，是先给员工发 AI 账号。可账号人人有了，如果 Agent 进不了真实流程，组织照样不会变快。

Replit 更有意思的地方，是先在产研拿到可以检查的结果，再让同一套底座进入四个差异很大的业务场景。产研阶段对应三条奠基定律；四个业务场景合起来，又能抽出三条“破圈”定律。

先说明： 下面六条是本文从 Replit 案例中提炼出的组织判断，不是 Replit 官方发布的方法论。

起点·产研：地基怎么打，杠杆怎么放大

定律一：护栏先于权限，信任是攒出来的

一种常见的危险顺序是：先开权限，出了事再补规则。Replit 反过来——先把访问策略、令牌代理、审计日志和零信任网络这套“刹车系统”装好，才向 Agent 开放 GitHub、Notion、Zendesk 等核心系统。

护栏要搭在权限开放之前，而不是事故发生之后。顺序一旦反了，一次严重事故就可能把试点拉回原点。

定律二：从“对错分明”的地方破局，不从“重要”的地方破局

工程最早跑出效果，不是因为写代码“最重要”。一个重要原因是，代码、测试、PR 撤销和事故都能留下相对清楚、可以检查的信号。 可验证性，才是 AI 最快证明自己的地方。

一上来就冲最复杂、最主观的战略决策，反而容易把试点做成一场说不清成败的实验，更快消耗组织对 AI 的信任。

定律三：杠杆不在“问答”里，在“调度”里

Replit 称，最显著的变化出现在员工开始拆任务之后：把一个大任务拆成可以并行、分别验收的子任务，再交给一支 Agent 舰队。

CTO 用并行 Agent 啃下困扰团队许久的底层网络 bug，靠的不是问得更聪明，而是 把自己从执行者变成了调度者。

这不证明 2.9 倍和 5.8 倍的增长都由 manager agent 单独造成。但它揭示了 Replit 工作方式里最值得抄的一处变化：人开始管理结果，而不是亲手完成每一步。

产研也因此最先攒下可见证据，为其他部门采用同一套底座降低了门槛。

破圈·四个业务场景：能力如何被复制

本文所说的“复制”，是业务团队沿用同一套 Agent 底座，再补上自己的知识、流程和验收标准。Replit 没有披露四个部门的上线日期，因此不能把它理解成同一天上线或权限原样照搬。

定律四：渗透靠可见的结果，不靠行政命令

原文明确说，用法走出工程部门，主要靠 Slack。工程师在群里 @Agent，其他部门看见它真的能做事，也开始自己试。

Slack 只是这家公司的具体入口。可复制的原则是： 把 Agent 放进团队已经在用的工作流，让使用结果自然可见。 企业微信、飞书、Teams 或内部业务系统，都可以承担同样的角色。

最先流行起来的用法很朴素：直接提问。Agent 同时掌握公司知识库和代码库的当前状态，员工不必每次都等工程团队解释，就能先弄清产品逻辑。

原文没有说 Replit 从未做过行政推广。但它强调的主要传播动力，是 Slack 里看得见的效果。说白了， 这种用法更像是被“眼馋”出来的。

定律五：定义权下放，业务团队自己补知识和流程

Replit 写道，新的 skills 和 integrations 来自公司各处。这不等于中心 AI 团队完全没有参与，却说明了一件事：业务用途不能只由中心团队定义。

• • 数据团队 接入数据仓库的语义层，让 Agent 知道哪些表是权威数据源、字段如何关联。员工可以直接问经营问题；一名产品经理还自助完成了复杂的产品发布分析。博客里的图表，也由这套系统生成。
• • 销售团队 让 Agent 调研和丰富潜在客户线索，再结合产品使用情况、活跃项目、额度使用与合同约定的匹配情况，生成定制化会前材料和品牌化演示文稿。
• • 市场团队 根据跨部门会议记录和产品文档起草产品规格，不必为了跟上信息参加每一场会。
• • 支持团队 给 Agent 配上问题排查流程（playbook）。它可以准备一版符合客服口吻的回复，也可以带着工单摘要和调查结果升级给工程师。

四个场景各不相同，底层逻辑却一致： 通用能力可以统一提供，具体做什么、什么算完成，必须由最懂业务的人参与定义。

定律六：人不退出，只是换了岗位

最能看清这道边界的，是直面用户的服务支持。Replit 公开的做法不是让所有工单都无人处理。Agent 先调查、准备回复；拿不准时，连同调查结果一起升级给人。

对于最终仍要升级给人的困难工单，月度中位完整关闭时间下降了约 60%。

代码审核也保留了同样的出口：Agent 先评估风险，必要时再找第二位人工审核者。

自动驾驶和无人值守的区别，就在这道安全阀上。 人没有被自动化出局，而是从“每一步都要亲自做”，变成“只在真正需要判断力的地方出现”。

Replit 的说法更直接：人被“升职”了，而不是被自动化出局。

工程提供证据，业务团队定义场景，人工安全阀守住风险。六条定律共同指向的是： 把 Agent 从个人工具变成组织能力，靠的不是多发几个账号，而是底座、业务知识和责任边界一起改变。

一个工程类比：组织也在“云原生化”

说实话，“组织云原生化”不是 Replit 的用词，而是本文用来帮助理解的技术类比，并非严格的架构映射。

这里不是说公司真的变成了一套云平台。这个视角只是在提醒我们：Agent 一旦进入真实流程，组织就需要 清楚的权限边界、可编排的任务、贴近业务的所有权，以及随时能退回人的失败出口。

Replit 没有把这些实践包装成一套组织理论，但它们确实带着很强的工程思维。也许正因为这是一家写代码的公司，它才更早看见：工程方法不只可以用来设计软件，也可以用来设计人和 Agent 怎样一起工作。

博客最后，Replit 留下了下一题： 能不能把这种工作方式开放给所有用户？ 尤其是那些正在用 Replit 搭建业务的创业者和企业客户。

要做到这一点，权限、安全和成本控制必须撑得住更大的使用规模。这些能力还需要继续补齐。

三、复制路径：从这周开始

“组织云原生化”不是口号。落地要两条线并行：管理线决定场景、指标和边界；工程线把权限、审核和反馈做实。少一条，试点都走不远。

下面是本文给普通团队的行动建议，不是 Replit 官方发布的实施手册或时间表。

组织策略：管理者这周该做的决定

选一个可验证的试点，而不是一次性铺开。 找一个有明确对错标准的场景——代码审查、客服工单、销售线索初筛都可以。先定“使用前 vs 使用后”的指标，再按任务频率设观察窗口。本文建议先看 6—8 周，别用几次演示替代真实数据。

把定义权提前想清楚该下放给谁。 谁有权决定 AI 介入哪个环节？谁负责提供业务知识？结果出了问题，谁来负责？Replit 的做法给了一个提示：skills 和 integrations 来自不同部门，最懂业务的人必须参与定义。

入口放进现成工作流。 换到普通团队，可以优先接进企业微信、飞书或钉钉，而不是再造一个等着大家主动登录的新系统。

把“必须转人工”的边界写进制度，而不是靠个人判断。 涉及资金、对外承诺、高风险变更，哪些能由 AI 处理，哪些必须升级给人，要提前写清楚。

给买建决策设一个复审周期。 普通团队可以设一个固定节奏，比如每季度重算一次自建和外购的完整成本，别把一次采购判断当成永久答案。

工程地基：技术团队这周该做什么

先建沙盒环境，再谈生产权限。 Replit 先搭了 Agent 运行框架（harness）、microVM 和远程文件系统。普通团队可以先让 Agent 在副本、脱敏数据或测试环境里跑通任务，再考虑生产写权限。

权限体系走“最小必要”路线。 访问策略、令牌代理（token proxy）、审计日志和零信任网络，要先于核心系统开放。每个 Agent 能碰什么、用哪个身份碰、操作是否留痕，都要说得清楚。

给关键系统开放有限接口，而不是整体打通。 普通团队可以先开放“读取上下文＋提交建议”，比如生成 PR 或工单草稿；接着开放可撤销动作。直接改生产这类高风险操作，放在审批链末端。

设计风险分级的审核流水线。 Replit 公开的做法是：Agent 先评估风险，必要时再交给第二位人工审核者。普通团队借鉴时，可以按影响范围设计不同审核级别。别把所有变更都塞进同一条审批队列，也别把高风险动作直接交给 Agent。

搭建“管理者 Agent”的编排能力。 让一个 Agent 派生多个子 Agent，并行完成可以分别验收的子任务，而不是让每个人维护一堆互不相干的对话窗口。

打通业务语义层，而不是只开数据库权限。 告诉 Agent 哪些表是权威数据源、字段怎么关联、核心指标怎么算。没有这层业务坐标，即使能写 SQL，也更难稳定给出可信分析。

留一个持续学习的反馈闭环。 把用户和员工反馈、生产失败与重复问题汇总起来，再用基准测试和 A/B 实验验证候选改动。Agent 可以找问题、提修改、跑评测； 正式发布仍由工程师决定。

写在最后

原文里最值得反复读的一段话是：

“A self-driving company is not one without people. People still choose the destination.”

“自动驾驶公司不是没有人的公司。人仍然选择目的地。”

本文译。

Replit 接着写，人仍要决定哪些问题值得解决，做艰难取舍，运用品味，并为结果负责；只是越来越多时候，人不再亲自完成抵达终点所需的每一步。

这就是“超级组织”真正值得讨论的地方：不是公司里多了几个很会用 AI 的“超级个体”，而是权限体系、协作流程、部门分工和买建决策，都跟着 AI 重新走了一遍。

Replit 的技术栈不能直接复制，但这些原则可以缩小到一个场景里验证：先装护栏，再拿结果；先让人看得见，再逐步放权。

你所在的团队，组织策略和工程地基各自走到哪一步了？你们试过、但没跑起来的 AI 场景是什么，又卡在哪一条线上？

子非AI，焉知AI之乐 🤖

分享 AI 的有趣应用和创新案例。