跨国深谈← 返回←Warp CEO 的软件工厂：2000 个 PR 一个月，人成了瓶颈

Warp CEO 的软件工厂：2000 个 PR 一个月，人成了瓶颈

关联

人物 Zach Lloyd · Claire Vo

公司 Warp

概念 软件工厂 · 智能体 · 编码智能体 · 代码审查 · 计算机使用 · LLM 当裁判 · 自我改进 · MCP · 模型

「软件工厂」是 2026 年最热的概念之一——输入想法，输出代码甚至产品。这期节目里，Warp 的 CEO Zach Lloyd（他做的 Warp 是一款智能体终端产品）向主持人 Claire Vo 现场演示了这个概念在 Warp 内部真实运转的样子。

结果有点反直觉：工厂的自动化部分运转飞快——从任务启动到提交 PR 只要 35 分钟；真正拖慢整条产线的，是等着人工审查代码的那三个半小时。剧透警告，他原话是：「人类才是问题所在」。

工厂是什么：不止是编码智能体

很多人用的还是「本地编码智能体」：打开 Claude Code 或 Codex，改代码、本地测试、推上 GitHub。Zach 说工厂和它的区别在于两点。第一，它管的是整个软件开发生命周期，不只是「想法到代码」这一步；第二，一切都发生在公开场合和云端。

具体流程是这样：Warp 把自己的工厂命名为 Wilson，员工在公开的 Slack 频道里 @ Wilson，说「帮我做个东西」。Wilson 接到后会走完整条流水线——先把它当「工厂输入」而非直接构建指令处理：开一个 Linear issue（用于追踪）、实际实现代码、创建 GitHub PR、然后做 QA。

QA 是关键一步：工厂智能体用 computer use（让 AI 直接操作电脑界面来验证）给完成的功能录一段视频，展示所有按键操作。你拿到的不只是一段代码，而是工单、PR、审查、验证视频打包在一起的完整交付。

还有一个容易被忽略的变化：工作在公开环境中发生。Slack 线程里有多个人围观、可以随时插进来贡献，构建者不再是在本地孤岛里干活。有些任务甚至不需要人发起——比如 Sentry（一个崩溃报告系统）报出崩溃时，信号会自动触发工厂去修。

管理者视角：把整个团队的构建集中到云端

Zach 强调，工厂方法真正不同的部分不是个体构建者怎么干活，而是一切集中到云端之后，管理者第一次能看清全局。他自己作为 CEO 关心的是：我们进展多快？

构建方式有没有随时间变好？钱有没有浪费？在每个工程师各有一套本地环境的世界里，这些问题根本没法回答。

于是有了几个他反复强调的度量：

• 每次 PR 的人工交互次数：你在 Slack 里重新提示了几次、在 Linear 上评论了几次、代码审查里纠正了几次。背后的直觉是：你必须引导、哄劝智能体的次数越多，吞吐量就越受限——就像运营特斯拉工厂要问「你需要多少次停下产线」。
• 智能体成本视图：可以看到团队几周前成本飙升，后来调整了模型配置降了下来。他说最大的成本杠杆就是**模型选择**，上下文管理是次要因素。

用评分和自我改进让工厂自己变好

这是整集最「工厂化」的部分。因为工厂是闭环系统——每次智能体执行任务都被记录——你可以回溯检查任务完成质量。

比如他们发现智能体爱写冗余测试：它写测试不完全是为了防回归，只是「顺路」验证行为，结果堆出一堆没必要的测试。做法是写一个评分器，用 LLM 作为裁判（选一个中等智能水平、不太贵的模型，否则打分本身就烧钱），按采样率检查所有运行记录里有多少次被判定存在冗余测试。

再往上一层就是**自我改进**：让一个观察者智能体去看所有失败的运行（Zach 强调要有真实样本量，比如 20-25 个失败案例，否则会基于单个案例过度纠正），然后让它直接给出工厂定义的修改建议——比如调整工厂智能体工作流程中第 10 步的定义。

这一切能成立的前提是：工厂本身是用代码定义的——一堆仓库、一堆 MCP 服务器、一堆配置、一堆智能体，全部代码化。好处有两个：一是你能冻结某个时点的工厂状态、修改定义后把历史任务全部重跑来对比效果；二是既然全是代码，编码智能体就能自己动手改进工厂。

还可以更进一步：拿自己的真实历史任务，用不同模型配置重放，衡量成本和质量的差异。就像 TerminalBench 这类公开基准，只不过是在你自己的数据上重建。比如拿一批前端任务测试换便宜模型行不行——不行的话质量会打折扣——然后把实验结果反馈进模型路由策略，让「哪个任务用什么模型」有真实证据支撑。

主持人 Claire Vo 补充了一个对所有团队都适用的提醒：如果你对每个编码会话都没有会话级、工具调用级、测试失败级的可观测性，就在浪费大量优化效率、成本和模型选择的机会。有的团队是把每个本地会话都传到 S3 上自己做评估，而工厂的优势是这一切天然集中。

技术型 CEO 的非技术用法：Figma、销售会议和冷线索

Zach 还展示了 CEO 日常的用法。他自嘲完全用不明白 Figma（设计工具），「像长了三根大拇指」，所以他改幻灯片的方式是：通过 Figma MCP 加编码智能体，语音口述「复制这张幻灯片、让 host 框包含 sandbox 框、给 launch pad 加点火箭主题」——对着一个不会画画的大脑，这成了超能力。

第二个任务是让智能体用 Granola MCP（一款会议记录工具的接口）回顾他过去四周的销售会议，整理出关于 Warp Factories 最常被问到的十大问题，并要求匿名化。结果显示「买还是自建」是头号问题，其次是安全、工作流、成本管理——他拿这些去反过来修正销售演示文稿和网站的话术。

第三个任务是翻过去六个月的邮件和日历，找出值得再次触达的冷线索，汇总成 Google Sheet。他的工作方式就是：想到什么，开个标签页就把任务启动了。

2000 个 PR 一个月，怎么不乱

Claire 的尖锐问题：上个月超过 2000 个 PR，人审查不过来，怎么防止「混乱当道」？Zach 给的答案一半很朴素：老办法依然管用——大量 dogfooding（自己重度使用自己的产品）、用户访谈、设计工作坊。

「说到底，不管你构建软件有多快，它仍然必须解决某个用户问题。」另一半是工厂带来的意外红利：工具使用存在幂律，少数人是超级用户；因为一切在公开的 Slack 里发生，其他人能直接看到专家怎么用，整个团队被拉高。

关于人类的角色还有一个具体变化：以前要求 A 用智能体构建、B 来审查代码，现在不再要求——提示智能体的人可以自己审查。但所有 PR 目前仍经人工审查，这是组织选择；他预计等信心足够，一定比例的任务会跳过这步。

Claire 建议的路线是按风险给 PR 打分，低风险自动盖章通过，把人力留给真正需要高质量审查的地方。Zach 完全同意：「代码审查正在变成一种风险管理练习。」

被问到 AI 不听话时的提示词策略，他说自己不吼，会「被动攻击式地翻白眼」——「你造了这个没人要你造的东西？」但他提醒大家保持惊奇：他在和做着自己干了 20 年的工作、而且干得有点比他好的东西对话。

他引用了 Louis C.K. 那个段子——飞机上第一次有 Wi-Fi，旁边的哥们因为视频卡顿暴怒，「我们在飞机上啊，给它一点时间。」

本集带走

• 工厂 = 生命周期 + 公开 + 云端：从 Slack 里 @ 工厂开始，自动走完开 issue、实现、PR、computer use 录视频验证的全程，人人可见、可介入。
• 盯「每次 PR 的人工交互数」：你重新提示、引导、纠正智能体的次数，就是产线停机次数——这是吞吐量的瓶颈指标。
• 工厂要用代码定义：这样才能冻结状态、改配置后重放历史任务对比效果，智能体也才能自己去改进工厂。
• 自我改进要有样本量：让观察者智能体分析 20-25 个失败案例再改定义，单案例会造成过度纠正。
• 用 LLM 做裁判打分时选中等智能水平的模型，否则打分本身就把省下的钱烧回去了。
• 成本最大的杠杆是模型选择，上下文管理其次；最科学的做法是在自己的真实任务上重放对比，别只看公开基准。
• 再快也得解决真问题：用户访谈、设计工作坊这些「传统」环节照样要做，丢掉人类输入的关键部分，快没有意义。

剧透警告，人类才是问题所在。
Spoiler alert, the humans are the problem.
—— Zach Lloyd · [01:11]

我认为代码审查变成了一种风险管理练习。
I think code review becomes an exercise in risk management.
—— Zach Lloyd · [17:04]