关注Warp这家公司已经有几年时间了，它从命令行界面工具迅速演变为软件工厂平台，这个过程确实引人注目。Warp成立于2021年中期，ChatGPT尚未诞生，最初是一款基于Rust的终端产品。后来AI浪潮来袭，它顺势转型为集成编码袋里的终端。 但近几年来，CLI工具的竞争格局急剧变化——Claude Code、Codex CLI、Gemini CLI等产品背后都有科技巨头撑腰。这很可能促使Warp在2025年4月将其核心CLI工具开源。 作为Warp的日常用户，能明显感受到它比Mac自带的CLI要强大得多。不过更值得关注的是这家公司适应时代的能力——这种特质在2023年首次采访CEO Zach Lloyd时就已经显露端倪。所以在2025年的AI Engineer World's Fair上，Lloyd发表关于“软件工厂”的主题演讲后，自然要找他深入聊聊。 Warp推出了名为Oz的袋里编排平台，这代表了Lloyd所预言的行业转型方向：从工程师与袋里交互式协作，转向能持续执行分类、实现、审查、验证和监控软件变更的自动化系统。Oz旨在连接多个模型和编码框架，跨越本地环境和隔离的云沙箱，同时融入开发者已有的工具链。 在Lloyd的演讲结束后（完整视频可在YouTube观看，是了解软件工厂概念的绝佳入门材料），我们进行了一场深度对话，话题涵盖Warp为何转向软件工厂、Lloyd如何独立构思这个术语（巧合的是，另一家名为Factory的公司也在用类似概念），以及他为何预测未来一年内大多数重要软件项目都将采用某种形式的自动化工厂模式。

从单打独斗的袋里到自动化开发循环

**问：** 你第一次接触到“软件工厂”这个概念是什么时候？是什么吸引了你？ **Zach Lloyd：** 具体什么时候开始用这个词已经记不清了，但也就是最近半年的事，随着软件自动化能力越来越完备，这个想法自然就浮现了。 我们最初做的是单次自动化：在云端运行一个袋里。很多平台都是这么起步的。然后发展到定时运行云端袋里。 下一个问题是：最有价值的自动化循环是什么？答案其实就是软件工程的完整循环：分类、规范制定、实现、审查、验证、发布和监控。 大约一年前，我们就开始朝着云端自动化的方向构建，那还是在开始开发Oz之前。过去几个月，整个行业也在逐渐向“工厂”这个词汇靠拢——这次会议上甚至专门设置了软件工厂专题。 我们现在的产品就是围绕这个理念来设计的。在下一个版本的Oz中，用户将可以设置自己的工厂，查看工厂状态，管理工厂车间。 不过“工厂”这个词能火多久，我倒不是特别在意。关键在于从交互式开发向自动化开发的转变。“工厂”只是一个有用的比喻。

在现有工作流上搭建工厂

**问：** 你的演讲展示了一个软件工厂架构，里面包含你们自己的好几个产品。Warp的计划是提供架构中的全套工具吗？ **Lloyd：** 没错。进入我们的云端袋里平台Oz后，系统会引导你完成工厂设置。 你可以选择要接入的仓库、要自动化哪些软件生命周期环节、以及在什么节点需要人工介入。不同组织和代码库会有不同偏好：是全面自动化代码审查，还是对高风险变更保留人工审核？ 设置完成后，系统就开始创建循环。它可以从Jira或Linear拉取issue，允许通过Slack或Teams提交需求，也支持开发者在GitHub上直接指派给袋里。 从产品角度看，有意思的地方在于：工厂的多数环节并不需要重新设计界面，而是融入现有工作流。至少我们是这么设想的。

Warp为何要走出终端

**问：** 我第一次报道Warp时，它还在打造现代终端。代码当然依然重要，但越来越多代码是由袋里生成的。Warp的产品愿景也随之拓宽了吧？ **Lloyd：** 完全正确。换个角度来看，公司的使命自创立以来从未变过：始终是帮助开发者和公司更快地交付更高质量的软件。 产品本身经历了巨大的演变。从AI浪潮前的一款现代化终端起步，下一步是内置袋里的终端——这个方向我们仍在投入，并且已经开源。 但世界在持续变化。底层AI的进步速度太快了，我对未来的判断就是演讲里提到的：交互式的重要性会越来越低。 作为公司，你需要一个集中的地方来构建软件，并衡量这一过程的效率。我从不害怕调整产品的方向。底层技术越来越好，不适应的公司只会被抛在后面。

工厂工程：一门新学科

**问：** “工厂”这个词可能会让一些开发者反感，毕竟它暗示着机械化和重复性劳动。你的AI工程师同事们对这个转向反馈如何？ **Lloyd：** 这个概念在经济决策者——也就是工程团队的负责人——那里引起了强烈共鸣。 但个体工程师可能会觉得太机械、缺乏创造力。他们会想：“我喜欢写代码，为什么要去工厂上班？” 我在演讲中试图传达一个观点：这将演变为一门新的工程学科。如果把这份工作看作元工程——构建构建产品的系统——那么它可能非常有意思。 它用到很多相同的解决问题的技能。你会思考：为什么袋里做这个任务很出色，做另一个任务却不行？该如何调整它的反馈？它需要什么上下文？工作流应该怎么改？ 不管怎么说，这些系统加速软件开发的威力太大了，纯粹靠手写代码的做法很快就会变得不合时宜。

前线部署工程师的角色

**问：** 会议上还有另一个趋势——前线部署工程，它通常融合了产品管理、咨询和传统工程。这和软件工厂模型是什么关系？ **Lloyd：** 搭建一个软件工厂可能需要对接大量现有系统，具体取决于公司规模。 工厂不仅要理解这些系统中的上下文，还要整合到整个组织的工作流中才能发挥最大效能。这方面大量的前线部署工作本质上就是一个转型项目。 它需要真正懂工程的人来配置和部署这类系统。我们自己也做一部分，一些竞争对手也在做。 最终形态会是什么样，现在还不好说。Warp更倾向于平台型业务而非服务型业务。但派能力强的工程师进入企业，用这些产品改造其工作流——这本身就是一个现成的生意。

Warp作为Oz的试验场

**问：** 我本人就用Warp作为终端，也会用它做一些编码工作。在软件工厂时代，原有的Warp CLI产品会变成什么样？ **Lloyd：** 开源Warp时，我们把仓库的治理权交给了Oz。我们围绕这个开源项目搭建了一个软件工厂，用的就是自己的工厂平台。 我们仍在全力以赴地改进Warp。这一次是与社区一起，而且大量工作由袋里来完成。在这个意义上，Warp就是工厂概念的试验场。 但它同时也是一个有近百万开发者使用的产品，其中很多人把它当作主要开发环境。我们自己每天都在用，内部也有专门的工程师负责改进它。只是我们开始用工厂思维来推动这一切。

渐进式自动化，而非一夜取代

**问：** 你预计未来一年软件工厂的采用情况会怎样？ **Lloyd：** 这事不会一蹴而就。工程师不会某天早上醒来，发现软件工厂已经取代了他们的工作。 公司会从特定用例开始——某种类型的issue、或者风险较低的仓库。这些地方他们可能接受没有人逐行审查每条代码。 然后观察效果。接下来工程挑战就变成了：如果现在能自动合并20%的PR，能不能提高到30%、40%、50%乃至60%？ 当然，总会有一部分工作需要人类来完成，因为太复杂、太模糊，或者需要原创性思考。 但我认为这一转变会在未来一年内发生。我的预测是：每个重要的软件项目都会有一个持续驱动它的代码引擎——某种类似工厂的东西。 这会变得像GitHub、像CI/CD一样——成为严肃软件项目运作的标准组成部分。如果不发生，那才叫奇怪。

从自动化最烦人的部分开始

**问：** 会场上有成千上万的AI工程师。他们应该做哪些准备来迎接这个变化？ **Lloyd：** 先别急着只盯着直接开发产品，试着搭建一些针对工厂的自动化，感受一下这个过程。 比如，你希望一个袋里自动实现用户的issue。要让这件事跑起来，需要什么？是什么阻碍了你采用它？ 也许代码审查是瓶颈。也许袋里确实改了代码，但你根本看不清楚它改了什么。只有真正去构建这个循环，你才会发现这些问题。 跳出“凡事亲自动手”的思维定式。找出工作中最烦人的一环，试着用工厂的方法创建一个循环去自动处理它。