软件工程正在变成工厂工程——Zach Lloyd(Warp)

• Zach Lloyd 是前 Google principal engineer（首席工程师，Google 工程师职级里很高的一档），带过 Google Docs 套件的工程团队，当工程师 20 多年；如今「依然在频繁地交付」，但过去六个月一行代码都没写过。今天讲三件事：自我改进的软件工厂、新的开源模式、他眼中开发正在经历的变化。→ 详细
• 他创办的 Warp 是一个开源的 agentic 开发环境（让 AI agent 替你干活的开发工具）：公司从终端起家，「基本上就是一个内置了 agent 的终端」；几个月前开源，GitHub star 超过 6 万、几百人贡献过代码、活跃开发者 80 多万；重心正从终端与交互式开发，转向「怎么把开发自动化」。→ 详细

▲ 图注：幻灯片「The evolution of agentic development」——时间轴依次是 Chat → AI Autocomplete → Interactive Agents → Automated Agents，Interactive Agents 被虚线圈住、标着「TODAY」：今天停在交互式 agent，下一站是自动化 agent。

• 全场论点一句话："the discipline of software engineering is going to become something more like factory engineering."（软件工程这门学科会变得更像工厂工程）→ 详细
• 三个阶段：过去两年从「聊天 + AI 自动补全」（Cursor、Copilot）走到现在的「交互式 agent」（你坐在电脑前，让 Claude Code、让 Warp 去做事）；接下来 6 个月到一年——「节奏很难预测」——会大步迈向自动化。→ 详细
• 现场举手：用 agent 做开发的 100%；同时开好几个 agent 的几乎所有人；此刻就有 agent 在后台跑的也不少（「我不介意，换我也这么干」）；在云端跑 agent 的「不到一半，但也相当可观」。→ 详细

▲ 图注：全片核心模型「A cloud software factory」——新的产品想法或 bug 从顶部进来，顺时针经过 Triage → Spec → Implement → Verify → Ship → Monitor 再回到入口；三个蓝色虚线框是人介入的点：Reviewing the spec、Reviewing the code、Reviewing the product。

• 最后一问：谁已经在内部搭了系统、把整个 SDLC（软件开发生命周期，从分诊、写 spec、实现到评审的整条流程）自动化了？「我看到有人举手」——"So this is what's going to happen." 他相信每个有相当规模的项目都会有这么一套东西，形状是一个大循环。「人人都在谈循环，其实循环没什么复杂的」：图上写的是「云端软件工厂」，直接写成「软件开发生命周期」也完全一样。→ 详细
• 逐环走一遍：想法从顶部进来 → agent 分诊 → 事情复杂就由 agent 写 spec → 人审 spec → agent 实现 → 人和 agent 一起审代码 → agent 验证 → 人审产品 → 发布 → 监控 → 回到开头再转一圈。分诊借的是医院的说法：活进来先判断轻重、归谁处理；spec 是规格文档，写清楚要做什么、做成什么样。→ 详细
• 图上的蓝色小框是人介入的点——数下来人只在审 spec、审代码、审产品三处出场，写 spec、实现、验证、分诊全由 agent 来。「不管是好是坏」，他认为软件开发最终就会长这样，于是论点落地："software engineers are going to be the ones who end up building and managing these factories."（最终负责搭建和管理这些工厂的，就是软件工程师）→ 详细

▲ 图注：两页相邻幻灯片拼在一起——左页「Cost to build」是一条一路下滑、趋近于零的成本曲线；右页「Time to clone」配的是 Same.dev 首页截图（大字「Make anything」加一个输入框）：造软件越来越便宜，抄软件越来越容易。

• 标题里答应要聊开源，因为 Warp 开源的主要原因之一就是建一座公开的工厂：他们做了个网站 build.warp.dev，公开展示系统里流转的所有 issue、各自卡在什么状态、哪些 agent 和哪些贡献者在处理——「一个规模化运转的工厂雏形」，"It's not working perfectly, but it is working."（运转得不完美，但确实转起来了）→ 详细
• 他放了一张自嘲「真的很蠢」的图：开发软件越来越便宜，推论是克隆软件变得轻而易举；当造软件几乎不要钱，软件生意就很难做——价值留不住，尤其是竞争对手能直接克隆你的时候。于是「给各位的第一条建议：先给你的代码申请专利」——台下笑，他马上改口「纯属玩笑，千万别这么干」。→ 详细
• 真正的建议：好产品当然要有，但 "a great product probably was never enough."（光有好产品可能从来都不够）——现在比任何时候都更是如此，以为只靠做出并发布一个好产品就能建成出色的软件生意，「你多半不会成功」。你需要产品之外的优势：分发渠道、生态、强品牌、数据护城河、资本；可创业公司这些一样都没有，还想突围，他建议的办法之一是公开建造（开源着做）。说清楚一点：Warp 是关起门做了五年才迈出这一步的。→ 详细

▲ 图注：build.warp.dev 的「Warp Contributions」页面——左栏按工厂阶段分组计数（Triaging、Ready to spec、Creating spec、Implementing 等，分诊下还分 Agent working、Awaiting agent、Needs info、Awaiting maintainer 等子状态），中间是带状态标签的 issue 列表，右下角写着「932,409 lines of code contributed」和贡献者榜。

• 公开建造的好处：帮你把生态长起来；"It can take you from being like hated on Hacker News to like tolerated."（能让你从在 Hacker News——程序员扎堆的科技新闻社区——上招人恨，变成被勉强容忍）；还能擦亮品牌、凝聚社区。→ 详细
• 那为什么拖了五年？开源的老痛点是：大量噪音 issue、粗制滥造的 PR（别人提交来的代码改动）、陷进「代码评审地狱」、花大把时间验证每个改动。最终让他们下定决心的，是先搭好了一整套自动化——其实就是一座专门管理这个开源项目的软件工厂；他自己说这是「绕了一大圈才说到这儿」的答案：痛点没消失，是有了工厂才管得住。→ 详细
• 做对了，开源世界里就是 agent 帮贡献者做贡献、帮维护者做维护。但他强调开源在这件事上没什么特别：每个有一定规模的项目都能从这种做法里受益。→ 详细

• 给想在自己项目里搭一套的人讲技术一点：起步阶段、或者从高层看，「其实没那么复杂」，一座有效的软件工厂先要三样——① 一套自动化；② 提供上下文和 skill 的方式（skill 可以理解为写给 agent 的一份份操作手册）；③ 在恰当时机把人拉进来的方式。→ 详细
• 第三条什么叫「恰当时机」？他的解释是「差不多就是工厂里有东西卡住的时候」。再加第四样、他特别强调「非常重要」的：④ 一套自我改进的能力，「可以把它理解成循环」——工厂不光要转，还要越转越好。→ 详细
• 他的预测：每家公司、每个开源项目的核心都会有一座软件工厂，就像 CI/CD（持续集成 / 持续部署：代码一提交就自动跑测试、自动上线的流水线）后来成了「那当然得有」——那是什么时候的事，「我也说不准，大概 10 年前吧」。→ 详细

▲ 图注：车间全流程图——分诊 agent 跑完分四路：可自动化的直通实现 agent；因范围或歧义需要 spec 的交给 spec agent、再由人审 spec（不通过退回重写）；需要人澄清的先由人补充输入、再回到分诊；暂不处理的先搁置。实现之后依次是代码评审 agent、验证 agent、人审代码与验证结果，通过后走 CI/CD 发布，监控 agent 发现问题就新建 issue、回到入口。讲者说这页不用细读，重点是它是一张流转的步骤图。

• 车间那页工作流图「信息量太大，你们不会细看的」，重点不是读懂流程，而是：车间本质上是一张由步骤组成的图，你在里面定义「我这个产品的软件到底是怎么造出来的」；而且每个产品的图都大同小异——东西进来、往下流、在某些环节卡住。→ 详细
• 输入就是想法，可能来自你的团队，也可能来自你的用户；它们从几类渠道进来，值得专门想一想：任务跟踪工具（最明显的一个）、Slack 和团队的各种沟通渠道、你的终端或 IDE（写代码的编辑器）、你的监控系统——总之有一组入口把活带进工厂。→ 详细
• 分诊，「非常重要的一步」。他把它简化成一件事：让一个 agent 盯着新进来的 issue 做判断——"if this is easy and this is unambiguous, just implement it"（简单、又没有歧义，就直接实现），「想让工厂真正转起来，就从这一步入手」；issue 难，才交给一个专门产出 spec 的 agent。也就是说，不是每个需求都走全套流程，先按难度分流。→ 详细
• 他问台下谁在用规格驱动开发（spec-driven development：先写清规格、再让 agent 照着写代码），有人举手；做法很多，但他认为「非常有效」。Warp 的做法、也是他推荐的：让 agent 写两份——product spec（产品规格）描述你要实现的产品不变量，也就是不管代码怎么写都必须成立的产品行为（字幕原词是 invariance，译者按上下文判为 invariants）；tech spec（技术规格）描述架构和代码的大致形态。一份管「做成什么样」，一份管「怎么搭」。→ 详细

• 实现：实现 agent 基本就是一个跑在云端某处的编码 agent，产出 diff（一份代码改动）；这一步各家编码 agent 都能用。→ 详细
• 评审「在很多方面是最痛苦的一环」："I expect that people are a little bit tired of reviewing agentic slop."（我估计大家都有点受够了评审 agent 写的垃圾代码）他的做法是先让一个 agent 做代码评审，之后随着时间推移，这变成一道风险管理题：什么时候该把人拉进来审代码——但流程里一定要留一个人能进来审的环节。（紧接着那句「对某些类型的应用，这一步非常重要」，指的是人工评审还是后面的验证，原话不好分。）→ 详细
• 验证靠 computer use（让 agent 直接操作电脑界面）：做 UI 的话，就让电脑真的去用一遍 agent 写出来的代码，并录视频、截图当证据；CI/CD 照样要用。→ 详细
• 监控：代码发布后 agent 不下班，要持续观察发出去的东西——有没有崩、有没有人在用。监控的输出再喂回工厂最上游，「就这样一圈又一圈地转下去」。→ 详细

▲ 图注：幻灯片「The factory primitives」的架构图——顶层是各种入口（Terminal，以及标着 Agent dashboard 的 Oz Web、Integrations、CLI/API/SDK、Mobile）；往下三层：Agent Control Plane（agent 配置如 Skills、Model / Harness、Memory，编排如智能路由与规则，管理如成本控制、治理、Evals）、Agent Execution（Warp 托管云或自托管，多 harness 即 Warp Agent / Claude Code / Codex，多 agent 分工）、Agent Data Plane（Artifacts、Skills、Memory、Knowledge Bases、Rules 等）。

• 他当天早些时候听了朋友 Adam 的演讲——Uber 在内部就搭了一版这样的工厂，「挺酷的」（那场演讲库里有，见 ep195）。但对多数组织来说「要看你处在什么阶段」：搭个简单版很容易，要搭一个真正能规模化的，你大概还是该专注自己的产品、别去造这套基础设施，因为「到头来你想要的东西实在太多了」。（片尾他提到 Warp 自己就有 agent 平台，这条「别自建」的建议出自卖方，参考时心里有数。）→ 详细
• 不管自建还是买，最后都会长成差不多的四层：① 入口——一堆把活送进工厂的途径；② 控制平面——决定活怎么在整个车间里分派；③ 真正干活的地方——云端沙箱（隔离的临时云端环境，agent 在里面怎么折腾都不影响别处），外加决定跑哪个 agent：用什么 harness（包在模型外面、管提示词 / 工具调用 / 循环的那层程序）、用什么模型。→ 详细
• ④ 他认为「非常重要」的最后一层：工厂底下的数据平面，让 agent 能记住自己做过什么、从中学习、随时间改进。→ 详细

▲ 图注：幻灯片「And you need loops for improving this system.」——左边内环（issue-triage 这份 skill）：新 issue 进来，分诊 agent 给 issue 分类；右边外环（improve-issue-triage 这份 skill）：skill 更新者读评论，由 agent 以 PR 的形式改进 skill；一条蓝色虚线把内环的分类动作和外环的读评论连在一起。

• "The factory is not just like a product, it's also a mindset."（工厂不只是一个产品，也是一种思维方式）回到开场论点：你需要度量，然后改进。既然叫工厂（「这个比喻你想延伸多远都行」），就该想效率：你发布了多少软件、在人的时间和 token 上各花了多少成本——把这两样量出来，并随时间持续改进。幻灯片上干脆写成一个公式：Factory efficiency = Software shipped / (token cost + human cost)（工厂效率 = 发出的软件 ÷ token 成本与人力成本之和）。→ 详细
• 改进的关键是循环，「听起来复杂，其实没那么复杂」：循环就是让 agent 观察自己在做什么、在哪里失败，从而不断变好。→ 详细
• 你会想放进工厂的一种常见循环是 skill 循环：工厂 agent 执行各种 skill，另有观察者 agent 专门看这些 skill 是怎么被用的、找出问题、设法改进 skill。他的例子：一个代码评审 agent 在 PR 上留评论，资深工程师或团队不断去纠正这些评论——观察者 agent 就看这些纠正，在下一次运行前把评审 agent 改好。人的每一次纠错，都变成了系统下一轮的输入。（同批 247 由 Warp 的 harness 负责人演示了这个 skill 循环的具体做法。）→ 详细

• 留给大家的最后一个思考：工程师得进入一种思维——"you're not just building the product, but you're building the thing that builds the product."（你不只是在造产品，而是在造那个造产品的东西）这更像流程工程、制造业一类的活；他坦白自己也在「非常努力地」让团队进入这种思维，「这并不总是容易」。→ 详细
• 这算不算扫兴？取决于你的乐趣在哪：乐趣在写代码的话，在座每一位工程师都会写得越来越少；乐趣在发布产品的话，「现在是前所未有的好时候」——他自己就属于后者，「我喜欢把东西做出来、发出去」。结论是一笔明账："everyone in here is going to code less, but they're going to ship more."（每个人代码都会写得更少，但发得更多）「这会是一种取舍。」→ 详细
• 用工厂工程师的心态看，仍有一整套很酷的工程挑战，几乎可以叫元工程（meta-engineering）：怎样设计你的 agent 系统，让它在「做工程」这件事上做到最好——他认为这是一组非常吸引人、值得去解决的难题。→ 详细

• 扫片尾二维码可以进他建的一个开源 GitHub 仓库，谁想试着搭自己的工厂 agent 都能拿去用；它有一部分用到了 Warp 的 agent 平台，但「说实话你不一定非得用它，我不是想借机推销我们的产品」。仓库的用处是讲清楚：想搭一个做分诊的 agent、或一个写 spec 的 agent，具体怎么做——怎么从「用工厂干活」的理论真正落到实践。随后他留了几分钟答问。→ 详细

• 提问本身是半截话，意思是：你一边说多数公司别自建工厂，一边又说工程师要去造工厂。他先认账：「我刚才说的确实有点自相矛盾」。→ 详细
• 他的化解：每个人都会部署某种工厂，但接下来要调校它——「这些 skill 适不适合我的领域？这座工厂是不是在以正确的方式构建我的产品？」这里仍有一堆有意思的工程挑战。有些场合确实可以自己搭，但大多数情况下你该专注打造公司的核心产品——部署一座工厂人人都会做，把它调校到适配你的产品才是要紧事。→ 详细

• 他认为这个新世界里最重要的能力是三样：适应力、批判性思维、学习的速度。→ 详细
• 如果是学计算机的，理解底层系统和架构、能对代码做推理、看得懂 agent 写出来的 spec，这些仍然「有巨大的价值」——呼应前面那条循环：人要审 spec、审代码，前提是读得懂。→ 详细
• 另一个事实：Warp 现在招的人比以往任何时候都多。外面很多「因为 AI 大家都找不到工作」的说法是在带偏方向，「至少到目前为止，我们的经历不是这样」。他在找的人是 "really adaptable product focused thinkers"（适应力很强、以产品为导向的思考者）——即便底层技术一直在变，也能出色地解决问题。→ 详细

• 他先承认工厂比喻的毛病：虽然自己一直往这个比喻上靠，「因为它确实说中了点什么」，但它听起来像在搞机械化、甚至去人性化。而这一切底下，"the only thing that matters is like are you building something useful?"（唯一重要的是：你做的东西到底有没有用）→ 详细
• 一座工厂要是一直批量产出没人在乎的东西，「那还有什么意义？」所以人的品味、人的输入、人的产品感，以及人在那些没法自动化的触点上把握方向，「绝对必不可少」。这也正是他自己每天在做的事：琢磨客户想要什么、大家想要什么、什么对他们真有价值。随后时间到，致谢下台。→ 详细
• 对照看：他的 Warp 同事 Safia Abdalla 在 ep191 直说挺讨厌「软件工厂」这个词——「人在哪儿呢？」；Zach 则拥抱这个比喻，只在这道题里承认它听起来去人化。→ 详细

演讲中没有给出讲者的个人联系方式；提到的两处公开资源如下。

• build.warp.dev：Warp 公开展示自家工厂的网站——系统里流转的所有 issue、各自处于什么状态、哪些 agent 和贡献者在处理。→ 详细
• 片尾二维码指向的开源 GitHub 仓库：https://github.com/warpdotdev-demos/cloud-factory-demo （演讲中没有念出地址，是从二维码解出的；仓库页自述是一套把工作从新进 issue 推进到「已验证改动」的 agent skill 与 GitHub Actions 工作流）。给想搭自己工厂 agent（如分诊 agent、写 spec 的 agent）的人照着做，部分用到 Warp 的 agent 平台但不强制。→ 详细