AI 软件工厂实战：让智能体自动打开、审查并合并 PR

截至 2026 年 9 月，AI 编程工具的竞争重点已经从“能不能生成一段代码”转向“能不能把一次软件变更完整交付出去”。真正有价值的 AI 软件工厂，不是让模型在编辑器里补全函数，而是让智能体从需求、分支、PR、测试、预发布验证一路工作到合并。

**AI 软件工厂是由多个智能体和自动化流程组成的软件交付系统，它能够把自然语言需求转化为代码变更，并通过审查、测试和治理规则决定是否进入主分支。**这类系统的关键不在于某个模型的单次回答，而在于上下文是否完整、动作是否可回滚、证据是否足够，以及合并权限是否被严格限制。

Firecrawl 发布的 《How to Build an AI Software Factory》 给出的思路很有代表性：让智能体不只阅读 diff，还要真正打开浏览器，在预发布环境里验证被修改的用户流程。这个方向比传统“AI 给 PR 留几条评论”更接近软件工程，也更值得团队投入。

先把目标说清楚：自动化的是闭环，不是替代责任人

**自动化 PR 闭环是指智能体完成创建分支、提交变更、发起 PR、运行检查、生成审查意见和执行合并等连续动作。**它解决的是等待、搬运和重复验证，而不是替产品负责人决定需求是否正确，也不是让模型在没有边界的情况下直接改生产系统。

一个成熟的闭环通常包含五类角色：

1. 需求智能体：读取 Issue、产品说明或工单，将任务拆成可执行的验收标准。
2. 编码智能体：在隔离分支中修改代码，补充测试并提交 PR。
3. 审查智能体：分析 diff、调用静态检查工具，寻找逻辑、安全和兼容性问题。
4. 行为验证智能体：启动预发布环境，使用浏览器操作真实页面和关键流程。
5. 治理控制器：检查权限、测试结果、风险等级和人工批准状态，决定是否允许合并。

这套分工比“一个万能 Agent 负责所有事情”更稳。编码者和审查者最好采用非对称配置，至少使用不同的提示词、检查清单或批评流程，否则同一个模型很容易重复自己的盲点。

一次 PR 到底应该怎样被智能体处理

**高质量的 AI 代码审查必须同时覆盖代码级证据和运行时证据。**只读 diff 可以发现一部分空指针、类型错误和明显的权限判断缺失，但无法证明一个真实用户流程是否可用。

可以把完整流程拆成以下八步：

1. 读取任务并创建隔离分支

智能体先读取 Issue、相关讨论、历史 PR 和仓库贡献指南，再创建独立工作分支。任务不能只靠一句“修复登录问题”驱动，至少要明确影响范围、验收条件、禁止修改的目录以及需要执行的测试。

隔离分支是第一道安全边界。智能体只能在临时工作区写入文件，不能直接向主分支推送；工作区还应限制网络访问、凭据读取和可执行命令范围。

2. 编码并提交 PR

编码智能体完成修改后，必须先运行格式化、类型检查、单元测试和构建任务，再创建 PR。PR 描述不应只是模型生成的长篇总结，而应该结构化列出：改了什么、为什么改、验证了什么、没有验证什么、剩余风险是什么。

一个重要原则是控制 PR 大小。500 行以上的合并请求更容易被快速批准而不是实质审查；如果一个任务必须修改多个模块，应拆成可以独立验证的多个 PR。

3. 分析 diff 和收集上下文

**上下文收集是 AI 审查能否有效的分水岭，它包括被修改文件、调用链、相关 Issue、历史讨论、部署日志和数据库或接口契约。**脱离上下文的模型只能做局部模式匹配，无法判断“这次看似多余的校验是否其实是业务规则”。

智能体应先建立变更地图：哪些函数被改动，哪些入口会调用它们，哪些页面或接口受影响，哪些测试覆盖了这些路径。对数据库迁移、鉴权、支付、缓存失效和异步任务等高风险区域，需要自动提高审查等级。

4. 运行代码审查

代码审查阶段可以让编程智能体执行专门的 review 流程，也可以接入独立的审查模型。输出应该按严重程度分类，而不是把所有建议混成一串：

• 阻断级：安全漏洞、数据损坏、权限绕过、确定性的生产事故。
• 高风险：核心业务逻辑错误、兼容性破坏、事务边界错误。
• 一般问题：异常处理、边界条件、测试覆盖不足。
• 建议项：命名、可读性、文档和重构方向。

审查智能体必须给出文件位置、触发条件、影响范围和修复建议。只说“这里可能有问题”的评论不应阻塞 PR。

5. 在预发布环境中打开浏览器

**行为验证是智能体通过浏览器或计算机操作能力，在可控环境中模拟用户完成真实流程的测试。**它解决的是“代码看起来正确，但产品实际上不能用”的问题。

例如，一个结账流程的验收不应止于检查价格计算函数。智能体需要打开预发布站点，添加商品、应用优惠券、确认总金额、提交订单，并记录每一步的页面状态。登录功能则要覆盖登录、密码重置、会话过期和权限跳转。

与传统端到端测试相比，浏览器智能体的优势是可以根据页面变化调整操作，并解释异常；缺点是成本更高、结果更不稳定，也可能因为视觉误判或环境噪声产生假阳性。因此它适合验证关键路径，不适合替代全部确定性测试。

6. 收集可复核证据

**可复核证据是带有截图、URL、操作步骤、控制台日志和测试时间的验证记录，目的是让人能够重现智能体的结论。**一条“我测试过了，没有问题”的评论没有审查价值。

对于失败流程，报告至少要包含：复现步骤、预期结果、实际结果、截图、浏览器控制台错误、网络请求状态以及对应的提交版本。对于通过流程，也应记录关键断言，而不是只留下绿色状态。

7. 将报告发布到 PR

PR 评论应当先生成草稿，再按照风险规则决定是否自动发布。低风险的格式和文档建议可以直接评论；涉及权限、支付、个人数据、删除操作和生产配置的发现，必须要求人工确认。

评论最好采用固定结构：结论摘要、阻断问题、非阻断问题、行为测试结果、证据链接、未覆盖范围和建议动作。这样开发者可以快速定位真正需要处理的内容。

8. 根据策略决定合并

**自动合并是治理规则的最终执行动作，而不是模型“觉得没问题”后的按钮。**只有在必需检查通过、风险门槛满足、分支没有冲突、审查意见已处理并且权限策略允许时，系统才应合并。

建议采用分级策略：

| PR 类型 | 智能体权限 | 是否需要人工批准 | 合并条件 | |---|---|---|---| | 文档、格式、依赖补丁 | 可创建 PR，可自动修复 | 低风险时可免批准 | CI 通过、变更范围受限 | | 普通业务逻辑 | 可修改和评论 | 必须一名维护者批准 | 单元测试、集成测试、审查通过 | | 鉴权、支付、数据库迁移 | 可分析，不可直接合并 | 至少两名人工批准 | 安全扫描、回滚方案、预发布验证 | | 生产配置和数据删除 | 默认只读 | 必须人工执行 | 变更评审、发布窗口和审计记录齐全 |

这套系统与传统 AI 代码审查有什么不同

**传统 AI 代码审查主要判断 diff 是否存在代码模式问题，AI 软件工厂则判断一次变更是否满足交付条件。**前者擅长局部发现，后者试图覆盖从任务意图到用户行为的完整链路。

| 能力 | 传统 AI 代码审查 | 带浏览器的交付智能体 | |---|---|---| | 读取 PR diff | 支持 | 支持 | | 静态模式分析 | 支持 | 支持 | | 读取 Issue 和历史讨论 | 部分支持 | 支持 | | 启动预发布环境 | 通常不支持 | 支持 | | 操作真实页面流程 | 不支持 | 支持 | | 截图和控制台证据 | 通常不支持 | 支持 | | 创建或修改 PR | 部分支持 | 支持 | | 自动合并 | 依赖仓库规则 | 可由治理控制器执行 |

Simular AI 在其 AI 代码审查实践 中将流程分成渐进的三层：Linter 处理格式，AI 审查工具处理样板模式，具备计算机访问权限的 AI 代理处理行为验证。这个分层很合理，因为不同问题需要不同证据，不能把浏览器操作硬塞进每一次小型代码审查。

最大风险不是模型写错，而是团队停止认真审查

**AI 审查最危险的失败模式是橡皮图章效应：评论数量增加了，人工审查质量却下降了。**公开案例显示，超过 500 行的合并请求有 73% 的时间没有经过实质性审查；另有团队在部署 AI 审查后将 PR 周期缩短 59%，但合并后缺陷率反而上升 23%。这些数字未必适用于所有组织，却清楚说明了一个问题：速度指标不能代替质量指标。

AI 工具产生的误报会进一步训练人类忽略评论。部分评测中，代码审查工具的误报率达到 29%—45%；当开发者每天处理大量低价值建议时，他们会形成快速关闭评论的习惯，最终连正确的安全信号也可能被跳过。

因此，系统不能用“评论越多越智能”衡量效果。更有意义的指标包括：

• 首条有效反馈的中位延迟；
• 阻断级问题的精确率和召回率；
• 合并后缺陷率与回滚率；
• 自动评论被人工采纳、驳回和误报的比例；
• 浏览器验证覆盖的关键用户流程数量；
• 智能体动作的人工接管次数；
• 从 PR 创建到可发布状态的总周期。

已有资料显示，CodeRabbit 在一组基准测试中的总体召回率为 52.5%、精确率为 50.5%，GitHub Copilot 审查模式的召回率为 36.7%、精确率为 56.5%。这类数字只能作为方向参考，不能直接当成团队上线后的真实准确率，因为仓库语言、测试质量、PR 大小和问题分布都会显著影响结果。

一套更稳妥的落地路线

**AI 软件工厂应该从只读审查开始，再逐步开放修改、发布和合并权限。**不要第一天就让智能体接管主分支。

第一阶段只做观测：智能体读取 PR 并生成不影响合并的报告，团队收集误报、漏报和无效评论。第二阶段允许它修复格式、补充测试和更新文档，但所有变更仍由人工创建 PR。第三阶段接入预发布环境，对登录、结账、核心仪表盘等关键流程做行为验证。第四阶段才为低风险 PR 开放受限自动合并。

权限设计应遵循最小授权原则：

• 使用短期凭据，禁止读取不相关仓库和生产密钥；
• 将代码修改、评论、批准和合并拆成不同权限；
• 对可修改目录、命令、网络域名和资源消耗设置白名单；
• 所有动作记录提交版本、执行者、工具版本和时间；
• 支持一键停止、回滚和撤销智能体权限；
• 将预发布数据脱敏，禁止智能体接触真实个人数据；
• 对自动合并设置变更行数、文件路径和风险等级上限。

在工程实现上，可以用 GitHub Actions 编排 CI、测试和策略检查，用仓库保护规则控制主分支，再把浏览器验证作为独立的可选检查。GitHub 官方的 Actions 文档 和 GitHub Skills 提供了工作流自动化与实践训练入口。关键是把模型输出视为“候选证据”，而不是天然可信的状态。

结论：真正的工厂是证据系统

AI 软件工厂最值得借鉴的地方，不是让模型写更多代码，而是把 PR 变成一条可观测、可验证、可回滚的交付流水线。代码审查智能体可以快速发现局部错误，浏览器智能体可以补上运行时验证，治理控制器则负责把“模型建议”转换成“是否允许合并”的明确规则。

但它不会自动消除软件工程中的责任。智能体可能漏掉语义错误，也可能被噪声环境误导；模型生成的代码还会让审查者产生“看起来没问题”的心理锚点。更现实的目标是让 AI 处理重复劳动、提前暴露风险，把人类时间留给架构、产品取舍和高风险决策。

如果一个团队现在就要开始，建议先选一个低风险、测试覆盖较好的仓库，连续运行四周，只比较有效问题率、合并后缺陷率和人工接管次数。能证明质量没有下降，再逐步扩大智能体的行动范围。自动合并不是终点；能够用清晰证据解释“为什么这次变更可以合并”，才是 AI 软件工厂真正成熟的标志。

参考来源

1. GitHub Actions：GitHub 官方工作流自动化能力介绍，可用于编排构建、测试和部署检查。
2. GitHub Skills：GitHub 提供的交互式实践项目，覆盖 Actions、仓库管理等开发流程。
3. Simular AI：AI 代码审查：介绍从 Linter、AI 审查到计算机操作型智能体的渐进式分工。
4. 知乎：高级 AI 智能体系统架构与实战：讨论 AI-DevOps 与软件工厂的系统化架构。
5. Firecrawl：How to Build an AI Software Factory：本文“PR 审查 + 浏览器行为验证”闭环的主要参考案例。