物界前沿AI 软件工厂的难点，在谁负责合并
看完这篇关于 AI software factory 的报道，我的判断很明确，让 agent 开 PR 不难，难的是进入真实工程流水线。软件工厂背后连着仓库结构、CI、权限、回滚、安全扫描、负责人签字。只要这些环节没接上，自动化就只能停在 demo。
报道标题里提到 agents 可以 open、review、merge PRs。这三个动作看着简单，其实是三条能力线。开 PR 要理解 issue，定位模块，生成 patch，写变更原因，最好带测试。做 review 要读 diff，判断接口破坏、边界条件、安全风险。自动 merge 进入主分支，风险从建议变成事实。
Microsoft Foundry 这类模板化方案也说明这个方向。官方把语音代理、发布管理、数据统一做成预置模板，连 Azure 和 GitHub 快速入门也打包进去。但模板解决启动成本，不解决生产责任。
跟 Copilot 比的话，我用了大约 2 个月。它在补全、样板代码、单文件小修上确实省事。可一旦从 issue 扩到 PR，就容易生成看起来完整、实际没跑过的东西。最近刚上手试 GPT 和 Claude，也用了不到一周。物界这个插件试了一下，才 6 天，PR 描述能写得像那么回事，但描述漂亮不等于代码可合。
卡住的是责任链和可验证性。AI 编程工具最容易骗人的地方，是输出太顺。
我前面写过一篇讲 AI slop 的帖子，核心意思就是这个，批量生成内容看着像人话，信息却空。PR 也一样。一个 agent 能写出修复了空指针、补充了单测、提升了性能，但如果没人能验证，这些句子只是包装纸。
工程里难的是可验证性。测试有没有跑，覆盖率有没有掉，migration 能不能回滚，权限模型有没有改坏，日志能不能定位，这些都不是模型随口一句就能负责。我们跑小仓库时，最怕它把不相关文件一起改。长上下文一遗忘，补全看着聪明，代码会偏。物界这类工具补全逻辑有可取之处，但长上下文错误放到 PR 自动化里更危险，一次改动可能跨多个文件。
WorkBuddy 的经验也提醒我，非标准素材清洗不稳定。脏数据进去，结果容易乱。代码仓库里也有脏素材，比如过期 README、失效注释、历史 issue、半废弃模块。agent 如果没有上下文权重和动态判断，很容易把旧规范当成当前事实。企业选型里，我之前更在意模型能力，现在想法变了。能不能换、有没有审计、供应链是否安全，往往比模型聪明一点更实际。
Microsoft 工作趋势指数年度报告里说，82% 的领导者表示有信心在未来 12-18 个月内使用数字劳动力扩展员工产能。这个比例不低。但这是领导者的信心，工程责任链还没接上。工厂能不能跑，关键看事故归谁管。
落地路线可以按风险从低到高走。先做只读 review。让 agent 在 PR 里评论，给建议，不碰代码，不碰合并。这个阶段最容易评估真实判断。能发现空 catch、指出 migration 没有回滚、提醒接口兼容性，比生成一百行代码更有价值。
再做 draft PR。agent 开分支，生成代码，跑 CI，但状态必须是草稿。人确认后才允许合。关键是把审查从读代码前移到验收证据，包括测试结果、影响文件列表、变更说明、回滚方案。
最后才谈自动 merge。范围必须很窄，比如文档、配置样板、低风险内部工具、纯 UI 文案、无业务逻辑的格式化改动。核心业务流程、权限、支付、数据迁移、安全边界，短期内别指望全自动。
预测一个趋势。未来 12-18 个月，AI software factory 大概率先从 review agent 普及，再向半自动 PR 推进。敢自动 merge 的场景，大概率是低风险内部项目和高度标准化代码，大型生产仓库会晚一些。工厂落地后，谁签字、谁负责会先被摆上台面。
📌 本文编译自 Hacker News，原文：https://www.firecrawl.dev/blog/ai-software-factory
版权归原作者所有，本文为基于公开报道的编译与独立分析。
