软件工厂落地：每PR成本从71美元降到20美元，吞吐量增四成

本文将给出一些具体策略，讲如何在组织内推广软件工厂。我说的“软件工厂”指的是云端可度量、可随时间改进的智能体闭环。这里我会聚焦人员和组织变革，而不是工厂赋能的技术方面。对于技术底座，我假设你使用的是类似工厂技术栈（factory stack）的基础设施。

太长不看（tl;dr）

- 目标不是实现完全自动化。目标是尽可能快速、高效地交付质量最高、对客户影响最大的软件。
- 从简单、低风险的工厂自动化开始：也就是工程师视为杂务的任务。
- 让通过工厂直接发起提示（prompt）像在工程师已经使用的工具中标记一个智能体（agent）一样简单。
- 把工厂定位为基础设施平台，而不是“产品”，让每个人都做“工厂工程”（factory engineering）。
- 鼓励但不强制，庆祝已交付的工作，而不是 token 消耗。
- 先跟踪采用率（通过工厂合并的 PR（Pull Request，合并请求）百分比），然后跟踪吞吐量、周期时间和每个 PR 成本。

从目标开始

先明确目标。目标不是实现完全自动化。目标是在你的组织里把编码智能体用到极致，从而尽可能快速、高效地交付质量最高、对客户影响最大的软件。你需要通过仔细度量和调优工厂来证明你正在做到这一点。我们称之为“工厂工程”。

一个重要前提：除非团队先至少把一部分产品工程工作通过工厂完成，而不是只靠本地编码智能体，否则你没法做工厂工程。这意味着要把智能体集中到一份共享配置中，让团队可以一起优化。一旦工作开始流经工厂基础设施，你就有基准可以度量和改进。

两种启动策略

我们在 Warp 内部以及和客户一起落地时，一直用两种策略来启动。

策略一：从简单的工厂自动化开始

第一种是落地简单的工厂自动化。例如，Warp 自己的工厂会自动化修复 Sentry 上报的服务器崩溃，自动分类我们在内部试用（dogfooding）时遇到的新问题，生成每周更新日志并更新公开文档。对客户，我们也设置了类似自动化，用于调查生产问题、分类用户反馈等。

这些都是低风险任务，你可以让智能体自行完成。如果智能体做对了，很好。如果没做对，你可以忽略输出，也可以让人来修复（如果你修复了，这会成为工厂工程学习循环的重要输入，后面会讲到）。关键在于从简单开始，先让一些任务跑起来，帮助工程师习惯工厂基础设施以及与工厂智能体交互。选择工程师眼中的杂务任务，是立刻展示价值的好策略。

从自动化开始，你不需要让工程师大幅改变日常习惯；一个人可以为所有人配置自动化，整个团队都能获得一些收益。不过理想情况下，整个团队会响应这些自动化的输出，承担审查其 PR 或生成 issue 的责任。关键是确保自动化有良好的信噪比，并且自动化的任何结果都有明确负责人。

因此，我不建议一开始就让智能体组成完整闭环去修复你的待办列表（backlog）或自动修复新 issue。智能体很可能生成永远没人审查的 PR，让工程团队对工厂方法反感（“这东西就是个垃圾内容喷射器（slop cannon）”）。从小处开始，专注于那些一开始输出就可能正确的任务。让一组工厂 champion 负责配置这些自动化，并且在那个团队把自动化调优到能可靠生成高质量工作之前，不要大范围推广工厂。

策略二：让通过工厂直接发起提示变得容易

第二种策略是让通过工厂直接发起提示尽可能容易，而不是在本地做。在 Warp，我们已经完成了这个转变——我们大多数直接提示从 Slack 开始，然后在我们依赖的其他云工具（如 Linear 和 GitHub）中继续。我们的工厂基础设施允许这样做：你可以在一个工具里开始工作，然后在另一个工具里带着相同上下文继续。

从与客户的合作中我们知道，这是很大的行为改变，需要在方法上多思考。重要原则是在工程师已经工作的地方与他们相遇。为输入工厂工作引入新的产品界面或工作流，会比允许工程师在他们已经在用的工具里标记智能体带来更高摩擦。我们不建议构建一个新的“工厂网页门户”作为与工厂协作的主要场所。

相反，让工厂可以从你的通讯平台（如 Slack 和 Teams）、issue 跟踪器（如 Jira 和 Linear）、代码托管平台（如 GitHub 和 Gitlab）访问。让通过工厂工作就像在这些工具里标记一个智能体一样简单。确保它可靠、快速，并且智能体完成工作所需的所有权限和上下文都已配置好。再说一次，如果开发者尝试这些流程但没成功，会迅速侵蚀对整个工厂方法的信心，让大家转向本地工具。

说到本地工具，你还希望工厂直接与本地编码智能体集成。如果工程团队混用 Claude Code、Codex、Pi 等，他们应该能直接通过这些工具把工作提交到工厂；这意味着本地提示不是发送给本地智能体，而是发送到工厂 MCP（Model Context Protocol，模型上下文协议），由它把工作提交到云端闭环。

你的工厂应该支持工作在软件生命周期任意阶段进入：一开始的新 ticket（工单）或想法，有了 spec（规格文档）之后，甚至工程师已经起草了本地 PR 之后。目标仍然是让提交工作尽可能容易，从而让更多工作流经云基础设施，并开始建立一套在工厂中工作的肌肉记忆，以及一份工厂工程可以改进的数据集。

把工厂定位为基础设施，而不是产品

在设置早期自动化和直接提示时，你应该确保团队在工厂出故障时不会走进死胡同。开发者喜欢掌控自己的工具；他们希望能够理解和调试问题，不用阻塞在等别人帮忙上。如果你把工厂当作整个团队拥有的基础设施，这比把它当作只有管理员能配置的 SaaS（软件即服务）产品，更可能吸引大多数开发者。

所以，不要把工厂定位为“产品”，而要定位为一个基础设施平台，每个人都应在上面做“工厂工程”。工厂工程是让内部工厂变得更好的工作。它意味着改进驱动工程吞吐量的技能、模型和上下文；意味着鼓励工程师为他们的杂务构建自动化；意味着给他们提供对工厂工作流打分和做基准测试的工具，并赋能他们用智能体构建自我改进循环；还意味着每个人都负责降低工厂成本、提高工厂 ROI（投资回报率）。如果你使用 Warp Factories 这样的平台，所有这些工具都是内置的，但除了工具之外，“工厂工程”实际上是一种思维模式。

鼓励，但不强制

假设你已经有了合适的基础设施，你需要激励团队开始使用它。我们在 Warp 实现这一点的方式是：领导层鼓励但不强制，并通过公开表扬、工厂排行榜（不是 token 排行榜），或一个展示优秀工厂工作的共享 Slack 频道，来庆祝大家在工厂中完成工作。工厂排行榜应该把成本考虑进去，庆祝已交付的工作，而不是 token 消耗。

对我们团队来说，一旦工程师开始在公开场合工作，他们通常会有一个顿悟时刻，明白这种方式为什么更好。例如，当你在 Slack 中开始工作，你可以轻松标记一位队友来征求他们的意见，而所有上下文都已经在那里。你可以从任何地方用手机继续这项工作。你可以搜索团队历史，并用这些工作来指导下一次提示。产品工程师会开始感受到这种新工作方式带来的许多不那么显而易见的收益，这让他们愿意坚持下去。

跟踪工厂采用率

为了确保工厂方法有效，你需要跟踪工厂采用率，并围绕它设定目标。最简单的起步指标是通过工厂合并的 PR 百分比。你要看总量，但也应该找出那些喜欢新工作流的早期工厂用户，并庆祝他们把工厂使用比例尽可能提高。

工程化工厂

一旦有一些工作流经工厂，你就可以开始专注于工程化工厂，确保它随时间不断改进。这里的关键指标是工厂吞吐量（已交付 PR）、周期时间和每个 PR 成本。但你也应该看工厂评分指标，也就是让智能体从代码质量、冗长度以及你可能关心的其他维度来评估工厂交付得如何。

推动这些指标可以变得像游戏一样。在 Warp，我们正乐在其中地调整模型组合和工厂工作流，以降低每个 PR 成本。过去六周里，采用工厂方法后，它从 71 美元降到 20 美元，回滚率更低，PR 吞吐量比上个月高 40%。团队里还有人提出实验来进一步改进。作为一个深切关心效率和资金消耗（burn）的创业公司创始人，看到我们在提高速度和质量的同时降低成本，实在不可思议。

最终目标

我最后的想法是：当你在推广工厂过程中遇到坎坷时，始终提醒团队最终目标：更快交付，为客户创造更多价值。工厂只是工程团队可以用来达成这个结果的新工具。

在 Warp，我们的使命是赋能开发者更快、更高效地交付更好的软件，转向工厂模式是朝这个方向迈出的重要一步。