跨国深谈← 返回←Tesla 的暗工厂：65% 的 PR 由智能体自动产出，95% 的代码没人看过

Tesla 的暗工厂：65% 的 PR 由智能体自动产出，95% 的代码没人看过

关联

人物 Rob Willoughby · Guy Pajani · Simon Maple

公司 暗工厂 · TESL

概念 智能体 · 验证器 · 编排器 · 沙箱 · 软件工厂 · 形式化验证

这一集是 Tesla 的 AI 工程负责人 Rob Willoughby，聊他们在公司内部建的“暗工厂”(dark factory，指无人盯守、智能体自主写代码并合并的软件工厂)。最反直觉的一点是：这个代码库里只有约 5% 的 PR 曾被人类审过——剩下 95% 的代码，没有任何人看过 。而这正是设计出来的。

什么叫“暗工厂”：从 Linear 工单到 PR 的全自动流水线

先看数字：Tesla 现在每周 60-70% 的 PR 由暗工厂产出，其中生产代码部分(注册表、Web UI、CLI 等)约占 40%，这些仍强制人工审查；而暗工厂自身和内部研究的代码库，执行“全部自动合并”策略——Rob 的理由很直接：如果不能自动合并，说明你没有足够的验证手段来信任写代码的过程 。

最夸张的一次：两个周末前的忙碌周五，他和同事下班去伦敦街头享受热浪，暗工厂在周末两天里为他们两个人交付了 150 个 PR，全部自动合并，全程零人工干预 。

节目的开场做了个现场演示：把一张 Linear 工单(修复一个安全审计发现的字符串转义问题，因为涉及网站展示，需要人审)翻成“待办”，暗工厂检测到交接后自动启动容器接管实现 。另一张针对暗工厂自身的工单则贴上 auto-merge 标签，CI 全绿加审查智能体批准后直接进仓库 。

【背景】Linear 是一款项目管理/工单工具；CI 指持续集成，即每次提交自动跑的构建与测试流水线。

暗工厂之前：单玩家智能体工程，瓶颈换了位置

在暗工厂出现前，团队的状态是“单玩家智能体工程”：每个工程师用自己的本地智能体或云端智能体(Claude Code、Cursor agent 之类)干活，但人始终坐在驾驶座上——定范围、实现、本地验证、推 PR 。工作流没变，只是代码生成变便宜了。

结果瓶颈转移：一是验证和测试——他们跑单体仓库(monorepo,多个项目的代码放在一个仓库里，构建相互依赖)，任何改动都要本地构建全量测试，还得手动点 UI、打端点确认行为，实现免费了但验证负担照付 。二是代码审查——工程师从写代码变成整天审代码：一个人一天能出 20 个 PR,如果每个都要人审，团队就陷入互相审 PR 的循环，PR 放 stale 了还产生合并冲突 。

心态也随之反转：以前周五是回看这一周干完了多少；现在“不为周末做准备的周五才是糟糕的周五”——你要向前看，计划、堆叠、排队足够多的工作喂给暗工厂 。

组件拆解：编排器很简单，真正的杠杆在上下文和验证

整套系统分两大块。编排器(orchestrator):轮询 Linear 拿新工单，按项目、优先级、阻塞关系排优先级，分发给隔离沙箱里的编码智能体，然后全程“ babysit”这个 PR 。Rob 的第一个大教训是：这部分简单得惊人——“从工单到产出代码的机制”是最容易建的，真正难的是周围的一切；不投资那些层，你会退回到被审查淹没的老工作流 。

几个具体设计决策：

• Linear 是唯一事实来源：所有会产生持久工件(PR、Notion 文档)的工作必须流经 Linear,换来审计链路和可调试性，还能白用 Linear 已建好的阻塞关系、子任务、标签体系 。
• 起点寒酸到好笑：最初就是一个连着 Linear 和 GitHub 的 Python 队列，智能体跑在某台笔记本的 Docker 沙箱里——以至于有位工程师一周不许合上笔记本 。现在智能体跑在内部 Daytona 沙箱的强力容器里，能拉起整个单体仓库的测试栈、跑集成测试、在 UI 上点击验证，还把操作录屏和截图贴回 PR——人类不用 SSH 上去点按钮，看视频就能确认智能体做对了 。
• PR 上的循环：智能体推 PR 后，CodeRabbit 和内部审查智能体(基于“技能”，现有安全、可读性、功能正确性三个)发评论，CI 失败(包括变异测试、基于属性的测试)也变成信号贴回 PR;编排器看到信号就重新唤醒智能体去修，智能体逐条推理、内联回复、解决评论，搞不定就暂停并把问题发回 Linear 工单通知人类 。

核心机制：验证器——把“品味”写成一句自然语言

这是全集最有原创性的部分。关于代码品味和架构，他们的方案是**验证器(verifier)**:一条自然语言的单句陈述，针对特定代码路径，能被 LLM 判定“是/否”。比如“这些文件只允许从 library 导入”——用正则写死很痛苦，用自然语言表达原则，LLM 当法官，每次只评估这一条，不用在满脑子冲突优先级里权衡 。

验证体系是一条阶梯 :

1. 能写成完全确定性规则的就写成确定性规则——现在没有人类工程师被 lint 规则折磨了，智能体不在乎规则多绕，写多复杂的正则都行，还省掉 LLM 调用费 。
2. LLM 当法官的验证器，只看 diff,便宜、快、人类可读。
3. 智能体代码审查做兜底，捕捉前两层漏掉的。

还有自动晋升：每晚分析 PR 上智能体和人类的评审评论，把反复出现的问题提炼成新验证器——持续“左移”，更快更便宜也更可读 。

任务拆解目前仍刻意留在人类手里：不是把 Q1 计划扔给暗工厂，而是像给初级工程师那样给一张范围明确的工单；工程师的新工作是做白板讨论、把讨论沉淀成一组工单 。而且实现既然近乎免费，有不确定的设计就同时起六七个 PR 探索方案，把分析落在真实代码上而非理论空谈 。

【背景】转写稿中的 TESL/Tesla 指公司 Tesl(做智能体上下文管理的公司)，与电动车公司 Tesla 无关，系同音转写所致。

翻车与教训：竞态、重复计数，和一次失败的语言重写实验

早期最痛的 bug:PR 评论被重复计数，同一任务进队列两次，两个沙箱里的智能体竞态抢活；修好一天又退化，两三天里冒出 60 个 PR 都在修这个问题 。解法是给队列行为建形式化验证模型(数学方法证明系统性质)——Rob 坦言前智能体时代他根本不会做，这次和 Claude 用了约一天，之后零复发 。重要洞察：智能体没有人类那种“这是敏感代码”的上下文直觉，又不想花 token 喂给它，所以验证必须比以前更硬 。

第二个实验更雄心：他们相信只要验证层够强、只围绕“组织关心的行为”(不在乎实现，只在乎点了按钮结果会出现)，就该能仅凭验证层用新语言从零重建整个系统。他们在团建时试了：只带验证层(端到端测试、集成测试、形式化模型)，让智能体把 Python 实现重写成 Elixir(一种并发友好的语言)。

队列部分完美，但暴露了大盲点：Linear 标签路由、PR 堆叠、CI 批处理等核心功能只覆盖在单元测试里，端到端测试只测了快乐路径，重写版上线即坏，搞坏了别人的 PR,实验宣告失败 。但他认为这比 Anthropic 的 Rust 重写更激进也更可行，重写出的 Elixir“显然是地道的”——而且只有继续做这类实验，才能找到验证层的缺口 。

关于 95% 无人看过的代码：团队比公司其他团队小，但 Slack 消息量是别人的 10-15 倍，靠过度沟通共享上下文；出了问题不回滚 PR,而是“向前修”——问验证端漏了什么，补成验证器或测试 。Rob 承认现在还会偶尔早上醒来想“这怎么合并进去了”，信任建设是永无止境的曲线 。主持人总结得好：自主性是赢得的，不是开启的 。

怎么落地：分层采用，先上下文再验证

对想学的组织，Rob 给的路径不是“一键开启”，而是渐进 :

• 先做好仓库里的上下文——这本身就能改善本地开发。他的判断：你给的上下文对模型结果的影响，比换一个模型更大 。
• 然后死磕测试：测试便宜到不值钱，为一切写端到端测试、集成测试、行为测试，锁住你真正关心的那层——不是代码怎么写，而是产品表现出的行为 。
• 再上验证器这类人类可读的离散单元，最后才是全自动工厂。

文化上最关键的一条：让工程师感觉品味和质量还在自己手里——资深工程师过去靠人肉审 PR、写风格指南来守护质量，现在把经验编码成一组验证器，全公司所有智能体跑他的代码时都会执行，个人影响力瞬间放大到所有人 。

对新人的门槛也没那么高：有新员工入职第二天就在给暗工厂加验证器。但需要接受一个心态转变——智能体不是“同样的活干得更快”，而是软件工程的新原语；工程师不会消失，但角色更像机械师：不造车，而是搭好工厂运行的环境、坏了去修 。

节目最后回看了开场那两张工单：metrics 工单全程无人类介入，CodeRabbit 批准、Kikimura 合并，Rob 也不打算去看代码——“测试过了，至少没坏；真坏了就向前修” 。安全修复那张，从开工单到 PR 只用了十几分钟，唯一的人类触点是团队工程师 Sahil 点了批准和合并 。

本集带走

• 自动合并是信任的试纸：Rob 的原则是“不能自动合并，说明验证不够”——把压力从人审转移到验证体系建设上。
• 验证器 = 一句自然语言的品味规则：确定性规则优先，写不了就用 LLM 当法官的单条验证，智能体审查只做兜底；每晚自动把重复出现的问题晋升成验证器。
• 编排层不值钱：工单到代码的管道简单，别在那儿卷；差异化在验证层和你能组合的原语。
• 为周末排队，而不是回看一周：周五的价值变成给暗工厂堆够工作，周一回来收获一个“相对不同的架构”。
• 出问题向前修，不回滚：每次翻车都问“验证端漏了什么”，补成验证器或测试——信任就是这样一条永无尽头的曲线。
• 顺序别乱：先仓库上下文，再测试，再验证器，最后才谈全自动；上下文对结果的影响大于换模型。
• 让工程师保住品味：把资深工程师的经验编码成验证器，全公司的智能体都会执行，个人影响力规模化到所有人。

我上次看的时候，Dark Factory 代码库中只有大约 5% 曾经由人类查看过 PR 并批准它。
Last time I looked, I think about only 5% of the Dark Factory code base had ever had a human look at the PR and approve it.
—— Rob Willoughby · [00:11]

我认为人们实际上不再去查看代码了，因为他们都在使用智能体。
I don’t think people actually go look at code anymore because they’re all just using agents.
—— Rob Willoughby · [00:18]

因为我可以使用本地智能体一天产出 20 个 PR,但如果政策说每个 PR 都需要人工审查，那我的团队就得去审 20 个 PR。
Because I can churn out 20 PRs in a day using a local agent, but if we have a policy where every PR needs a human review on it, well then my team needs to go review 20 PRs.
—— Rob Willoughby · [11:06]

我喜欢认为自主性是赢得的，不是启用的。
I like to think autonomy is earned, not enabled.
—— Simon Maple · [30:41]

智能体不介意烦人的刁钻规则，它们可以很开心地去撞墙让事情跑起来。
Agents are fine with annoying Infiniki, they can very happy to go bang their heads against the wall in order to make something work.
—— Rob Willoughby · [27:31]

而且我不认为人们还会去查看代码了，因为他们都只是在用智能体。
And I’m not, I don’t think people actually go look at code anymore because they’re all just using agents.
—— Rob Willoughby · [32:01]

我认为需要的是这样的人：他们认识到智能体不只是把同样的事做得更快，而是我们做软件工程的一个根本性的新工作流原语。
Um I think it needs to be folks who are recognizing the fact that agents are not just doing the same thing but faster, but are fundamentally new workflow primitive in how we do software engineering.
—— Rob Willoughby · [40:47]

我特意强调是“与你”，而不是“为你”，因为那个验证环节，重申一下，我认为正是人类杠杆的来源。
Um and I’m being key there to say with you, not for you, um, because that verification bit, just to reiterate, is something that I think where it’s the human leverage comes from.
—— Rob Willoughby · [49:02]