工程团队的 AI 软件工厂实战手册 | Warp CEO Zach Lloyd

📌 One-Sentence Summary Warp CEO Zach Lloyd 演示 AI 软件工厂：公开 Slack 启动分拣、Linear 工单、GitHub PR 与计算机操控 QA，管理层则用代码定义的指标追踪吞吐、成本、每 PR 人工交互次数、LLM-as-judge 评分与自改进闭环。 📝 Summary Claire Vo 访谈 Warp CEO Zach Lloyd，探讨软件工厂如何超越本地编程智能体。从构建者视角，在公开 Slack 中标记 Wilson 会触发分拣、创建 Linear 工单、实现功能、提交 GitHub PR，并运行可产出验证视频的计算机操控 QA——工作全程可见，队友可随时加入讨论。Sentry 崩溃修复也能进入同一闭环。更大的转变是集中式管理层：团队看板展示自动化率、吞吐速度、智能体成本，以及每 PR 人工交互次数（重新提示、Linear 评论、评审修正）作为产线停顿频率的代理指标。Warp 仍人工审核每个 PR，但现在允许发起提示的同一人进行评审；Zach 将评审视为风险管理，并指出从启动到 PR 平均约 35 分钟，而 PR 到首次人工评审约 3.5 小时，团队每月有超过 2000 个 PR。工厂以代码定义（仓库、MCP 服务器、配置、智能体），用 LLM-as-judge 跨次运行评分（如冗余测试），并由观察智能体在大约 20–25 个失败样本后改写步骤来改进。可回放历史任务以比较模型的成本与质量权衡并用于路由。Zach 还演示了借助 Figma MCP、Granola 销售 FAQ 以及日历与邮件线索表的 CEO 工作流，并强调速度仍需要传统用户研究与设计共创，以免工厂交付混乱。 💡 Main Points 软件工厂将编程智能体扩展为完整的公开 SDLC 闭环 在 Slack 中标记 Wilson 会分拣输入、创建 Linear 工单、实现功能、提交 GitHub PR，再运行带验证视频的计算机操控 QA，让协作保持公开而非本地孤岛。 管理层价值来自集中指标与每 PR 人工交互次数 云端聚合呈现吞吐、自动化率、智能体成本以及所有干预触点，帮助负责人判断智能体驱动的产出是否真正在随时间提升。 以代码定义的工厂支持评分、自改进与任务回放 LLM-as-judge 为每次运行打分（如冗余测试）；观察智能体从 20–25 个失败样本改写工厂步骤；回放历史任务支持基于证据的模型路由。 速度仍需人工产品判断与有选择的评审信任 目前所有 PR 仍需人工评审；Warp 取消了跨人评审要求，同时保留用户访谈与设计共创，确保交付对准真实用户问题。 💬 Key Quotes 什么是软件工厂？至少对我们来说，它是一个真正的名词——一种产品概念，由一批仓库、一批 MCP 服务器、一批配置以及一批智能体组成：代码评审智能体、设计智能体、各类自动化。这一切都用代码定义。 普遍直觉是：你越是要反复提示、干预或哄劝智能体，吞吐就越受限。 代码评审变成了一场风险管理练习。 归根结底，软件建得再快也不重要：它仍必须解决某个用户问题，而且要用好的方式解决。 我在和某个东西对话，它正在做我过去 20 年一直做的工作，而且现在做得比我还好一些。 📊 Article Meta AI Screening： 90 Featured： Yes Source： How I AI Author： How I AI Category： 人工智能 Language： 英文 Read Time： 22 min Word Count： 5313 Tags： AI 与智能应用 , 模型路由 , AI Agent , 测试与质量 , 开源项目 Play Full Video