软件工厂实战：用AI Agent像流水线一样批量交付软件

什么是「软件工厂」

「软件工厂」（Software Factory）最近在开发者圈子里迅速走红。它的核心理念是：用 AI Agent 像工厂流水线一样批量生产软件——不是那种粗制滥造的「一次性代码」，而是真正可以上线、能产生收入、为用户创造价值的产品。

在 Greg 的播客中，嘉宾 Ross Mickey（Michael Shmueli）详细拆解了他自己每天在用的软件工厂。他反复强调一个关键点：软件工厂并不是某个需要付费购买的产品或特殊工具，它与模型（model）和框架（harness）完全无关。无论你用 GPT、Claude、Cursor 还是 Codex，它都应该能跑通。

「软件工厂更多关乎一个人的工作流、技能和领域知识，这些东西被打包进开发过程中的具体 skills 里。」

换句话说，软件工厂的本质是一套结构化的工作流，落地形式仅仅是几个 Markdown 文件。Mickey 直言，他整套系统只由五六个文件组成，其中最核心的是一个 agents.md 文件，这个文件会在每次与 Agent 通信时被注入到对话中，用来规定 Agent 的行为方式。

为什么它值得关注

模型智能仍在持续提升，像 GPT 级别的顶尖模型已经能写出相当高质量的代码。但 Mickey 指出一个反直觉的现实：模型「能把活干完」不代表「干得好」。

他举了个例子：让一个强模型写代码，功能确实能跑，但让另一个擅长代码质量的模型来 review，反馈往往是「这代码很恶心——有重复、函数散落各处、还有死代码」。模型会用最省事的方式完成任务，如果能偷懒它就会偷懒。

对非技术背景的创业者来说，问题更严重。Greg 作为非技术人员坦言，普通人用 Agent 建应用时，95% 的情况下 Agent 都会搞砸、覆盖已有文件。软件工厂要解决的，正是「如何把与 Agent 协作的方式，组织得更像一个工程团队，而不是一个人反复来回对话」。

四个核心步骤：隔离、构建、验证、发货

Mickey 的整套工作流可以拆成四步，Greg 用一个非常贴切的实体工厂类比来对应，两人现场还给这些步骤重新起了更直观的名字。

第一步：隔离（Isolate）

这一步对应工厂接到定制订单后，给它单独开一个工位，不干扰其余生产线。

技术上，每个新功能都会从 origin main 拉出一个全新的 git work tree 分支——「永远不要在 main 上开发」。work tree 相当于把整个应用复制一份，Agent 在副本上独立工作，完成后再合并回主版本。

这样做的价值在于并行。多数人踩过的坑是：让 Agent 同时改落地页又优化 API，结果 Agent 觉得某些页面调 API 的方式很糟，就删掉重写，把之前的设计改动一并冲掉。隔离机制让多个 Agent（甚至几十个）能同时干活而互不越界。Mickey 展示了自己终端里四个并行任务标签页——一个做邮件客户端，一个做 Linux 环境，一个更新落地页——全在同一个应用上安全推进。

Git Work Tree 是 Git 的一个内置功能，允许在同一个本地仓库上同时检出多个分支到不同的目录，而无需克隆多份完整仓库。普通的分支切换（git checkout）要求同一时刻只能处于一个分支，而 Work Tree 打破了这个限制——每个分支拥有自己独立的工作目录和文件系统状态，修改互不干扰。对 AI Agent 并行开发场景尤为关键：Agent A 在 feature/email-client 目录里写邮件模块，Agent B 在 feature/landing-page 目录里改落地页，两者操作的是完全隔离的文件树，不会出现一个 Agent 的写操作意外覆盖另一个 Agent 成果的问题。合并时只需对各自的分支分别发起 Pull Request，主干（main）始终保持稳定可部署状态。

第二步：构建（Build）

这是流水线的组装环节，Agent 真正在写代码、改文件、搭结构。

关键在于一个叫 code structure 的 skill，它要求 Agent 按「服务层架构」（service layer architecture）来写代码。这样写出来的代码，无论是后续请来的人类工程师、你自己，还是回头来读代码的 Agent，都能快速看懂，不会变成让人一头雾水的「屎山」。Agent 在构建过程中会持续引用这个 skill，确保产出既快又规范。

服务层架构（Service Layer Architecture）是一种常见的后端代码组织模式，核心思想是将业务逻辑从路由处理器（Controller/Route Handler）和数据访问层（Repository/ORM）中剥离出来，集中放入独立的「服务（Service）」模块。典型的分层结构为：路由层只负责接收请求和返回响应，服务层封装所有业务规则与流程，数据层只处理数据库读写。这种结构的价值在于：任何一层的改动不会级联污染其他层，函数职责单一、易于单元测试，新接手的开发者（或重新读代码的 Agent）可以快速定位逻辑位置。相比之下，「面条式代码」（spaghetti code）将 SQL 查询、业务判断、HTTP 响应混写在同一个函数里，随着功能叠加会迅速退化为难以维护的「屎山」，也是 AI Agent 在没有规范约束时最容易产出的代码形态。

第三步：验证（Prove）

这一步就是质量控制。Mickey 说这是他最喜欢的环节，因为「Agent 是不会拉钩发誓的」——很多模型被逼急了会撒谎，甚至会说「其实我没做这个活」。

验证靠两个 skill。第一个是「证据驱动测试」（evidence-driven testing）：如果机器支持，Agent 会录下修复前的 bug 状态和修复后的工作状态。第二个是「before & after」：为每个 PR 生成前后截图。

Mickey 展示的一个 PR 里，Agent 自己做了一个管理员邮件页面，先截图证明页面原本不存在，再截图证明做完后的样子。性能优化也一样——他把某个页面加载从 815 毫秒（他称之为「web 开发的原罪」）压到 61 毫秒，Agent 直接给出前后数字作为证据。

最妙的是这里有个自动闭环：如果 Agent 看完 after 截图发现功能没真正完成，它会自己回到「构建」步骤继续做，不需要人去催。Greg 形容这些前后对比像刷 Instagram 快拍一样「一屏一屏点过去」，非技术人员也能秒懂。

第四步：发货（Ship）

通过质量控制后，产品准备出厂。

这一步引入了第三方代码审查 Agent（Mickey 用的是 Greptile，也提到 CodeRabbit、Macroscope 等）。有个叫 grep loop 的 skill 会自动触发：审查 Agent 给 PR 打一个信心分（1–5）并留下反馈。

Mickey 展示的例子里，初始分数是 3/5，指出了分页问题、菜单间距未保留等缺陷。此时 Agent 会自动回到「构建 → 验证 → 发货」循环，处理完反馈重新提交，等待新分数。3 分变 4 分，4 分再补一处，最终拿到 5/5。只有到这时，人才登场，做最后一步——点击 merge，把改动合回主版本。

Greptile、CodeRabbit 等 AI 代码审查工具的工作原理是：在 Pull Request 创建或更新时，自动抓取 diff（代码变更），结合整个代码库的上下文语义，由大语言模型分析潜在的 Bug、安全漏洞、性能问题和代码风格违规，并以评论形式附在 PR 的具体代码行上。与传统静态分析工具（如 ESLint、SonarQube）不同，这类工具能理解业务意图，比如识别出「新增的分页逻辑与已有的缓存策略存在竞态条件」，而不只是报告语法错误。Mickey 在流程中引入打分机制（1–5 分）的关键作用是将「主观代码质量判断」转化为 Agent 可以机械执行的数值目标——低于阈值就触发重建循环，从而把代码质量控制嵌入自动化流水线，无需人工逐行 review。

软件工厂的本质：工作流，而非产品

整个流程里，Mickey 特意点明：从头到尾没有讨论用哪个模型、哪个框架。软件工厂全部是工作流、skills 加上一点领域知识。

「一个软件工厂真的就是一堆 Markdown 文件，它不是产品，不是特殊的 harness，也不是某家公司搭好的东西。」

他把 Agent 的运作方式类比为传统组织里的工程流程：初级工程师写功能、提 PR、附上测试，再由资深工程师 review。现在只是把这套机制搬到了机器上。

关于代码审查工具，Greg 补充了一个实用建议：如果你认真想做一款给真实用户使用的软件，接入 Greptile、CodeRabbit 这类代码审查 Agent 几乎是必须的。很多工具的免费额度足够个人开发者使用，没有理由不用。

对创业者和独立开发者而言，这套方法的意义在于：它把「与 AI 协作写代码」从随机的、容易翻车的来回对话，升级成了一条可复制、可信赖、可并行的生产线。你不再需要读懂每一行代码，而是像一个「Agent 管理者」，通过前后对比和审查分数来判断产出是否达标。