首页
/
新闻
/
AI软件工厂:将工单转化为拉取请求的智能体,以及为何没有供应商会公布首次合并成功率
AI软件工厂:将工单转化为拉取请求的智能体,以及为何没有供应商会公布首次合并成功率
摘要
本文探讨了AI软件工厂的兴起——这类系统中编码智能体自主将工单转化为拉取请求——并指出供应商大肆宣传与缺乏公开验证其主张的基准之间的差距。
暂无内容
查看缓存全文
缓存时间:
2026/07/27 13:48
# AI软件工厂:炒作与现实,2026年真正落地的产品
来源:https://hashnode.com/blog/ai-software-factory
摘要:AI软件工厂是2026年最响亮的赛道:一套系统,编码代理从工单直接生成经过验证的拉取请求,中间无需人工介入。炒作是真实且可引用的,从Cursor大会演讲到以该术语命名的厂商,都是明证。但其下的差距同样真实:没有任何公开基准能够衡量这些工厂是否真的交付了成果。
## 此刻
一个五十年前的术语正迎来它的第三次高光时刻,而这次所有人都同时登场了。
Cursor在舞台上讲授它:Eric Zakariasson的演讲"构建你自己的软件工厂"(https://www.youtube.com/watch?v=rnDm57Py54A)将这一转变描述为开发者从编写代码转向定义意图、约束和验证,然后管理执行其余工作的生产系统。Morning Brew的联合创始人正在向从未打开过终端的人解释它:Alex Lieberman的《什么鬼是软件工厂?》(https://www.linkedin.com/pulse/what-hell-software-factory-alex-lieberman-g13ce)(2026年6月1日)告诉商业受众"人类向上移动一层,从做事转为指挥"。一家国防承包商正在即兴发挥"无灯制造"的概念:BrainGu的《进入黑暗软件工厂》(https://www.braingu.com/news/enter-the-dark-software-factory/)(2026年5月6日)描述了"一条由AI处理从需求到拉取请求的管道",然后花了大部分篇幅讨论为什么没有治理就不应该运行它。
厂商们已经超越了仅仅撰写这个类别。现在有获得融资的公司将这个词置于其名称和标语中,并且每个季度都有更多公司出现。当公司开始以类别名词为自己品牌命名时,这个词就已经成为了市场。
以下尚未出现的是:证据。没有公开基准来衡量从工单到合并PR的可靠性,没有跨厂商对比,没有标准方法来检验一家工厂相对于另一家的说法。命名已经超越了衡量,这正是炒作周期的定义。这并不意味着这个类别是虚假的,只是它尚未被定价。
## 为什么是这个术语,为什么是现在
"软件工厂"此前已经历过两次重生,每一次都将前一次无法触及的层面实现了工业化。
第一个时代将人标准化。日立从1969年开始按工厂流水线组织程序员(https://en.wikipedia.org/wiki/Software_factory),Michael Cusumano的《日本的软件工厂》(1991)记录了日立、东芝和NEC将标准化流程和复用推到了何种程度。微软在2004年重新使用了这个短语,用于模型驱动的产品线。自动化的单元是方法;人们仍然编写一切。
第二个时代自动化了通往生产的路径。2010年代的软件工厂(https://www.vmware.com/topics/software-factory)是一个DevOps平台:黄金流水线、CI/CD、安全扫描。美国国防部至今仍在运行经过认证的软件工厂,如Kessel Run和Platform One,这就是为什么该术语的很多搜索流量带有政府意图。交付变得可重复。实现仍然需要人工,按工程师工时计费。
第三个时代自动化了实现本身,这正是当前被炒作的。代理编写代码。前两个时代都没有试图做到这一点,这就是为什么一个1969年的术语突然出现在会议舞台上。
抛开品牌包装,该类别中每个已发货的产品都运行着相同的五阶段循环。下面每个阶段都是由厂商自己记录的,而非推测。
- **输入。** 工作以工单、规格说明或记录的错误形式从Linear、Jira、Slack或支持队列到达,而不是作为输入到编辑器中的提示。
- **隔离。** 启动一个沙箱,克隆仓库,并在运行结束时销毁。
- **实现。** 一个编码代理在该沙箱内进行工作。一些工厂运行专有代理;有些则根据任务路由到你选择的代理。
- **验证。** 运行执行仓库自身的检查,失败时重试,审查自身的差异,对于UI工作则驱动真实浏览器并记录会话。这个阶段是整个工厂与一个被单独放置过夜的代理之间的全部区别。
- **拉取请求。** 每个变更的仓库一个PR,附带着差异、检查结果和记录。由人类审查并合并。
AI软件工厂循环流程图:从Linear、Jira或Slack输入,一个隔离的沙箱,一个编码代理实现变更,通过仓库检查和记录的浏览器QA进行验证,最后人类审查一个附带证据的拉取请求(每个仓库一个)
与你已经使用的工具之间的边界归结为人何时需要介入。编码助手需要你打字。编码代理需要你在会话中引导,这正是我们关于Codex与Claude Code对比(https://hashnode.com/blog/codex-vs-claude-code-2026)的全部主题。一个工厂希望人在恰好一个点介入:审查。这种模式现在有了一个名称,即后台编码代理(https://factorykit.ai/blog/background-coding-agent),而有用的定义取决于循环在哪里运行以及由谁关闭,而不是基于底层是哪个模型。
## 谁实际发货了产品
截至2026年7月27日,有四款产品定义了这个类别。下面的每项声明都来自该日期各厂商自己的网站,全部是厂商自行报告的。没有对任何一行进行独立测量。
| 产品 | 公司 | 他们的宣传语,他们自己的话 | 从哪里开始到哪里结束 | 部署方式 |
|------|------|--------------------------|----------------------|----------|
| Devin (https://cognition.com/) | Cognition | "第一个自主软件工程师" | 在你的代码库和工具中计划、编写、测试和交付生产代码 | 企业版;已知客户包括高盛和梅赛德斯-奔驰 |
| Factory (https://factory.ai/) | Factory | "一个自我改进的SDLC系统" | 信号摄取、分类、代码生成、验证、发布和监控 | SaaS、混合、本地部署、气隙环境 |
| 8090 (https://8090.ai/) | 8090 | "面向受监管企业的AI原生软件工厂" | 从自然语言业务意图到生产代码,附带完整审计追踪 | 自助服务平台加自定义企业构建 |
| FactoryKit (https://factorykit.ai/) | Hashnode | "为你的团队提供后台编码代理" | 规格、工单和错误到每个仓库一个经过验证的PR,附带浏览器QA记录 | 按使用量计费,无按席位许可;云或你自有的基础设施 |
披露:FactoryKit是我们的产品。它诞生于Bug0(https://bug0.com/),其开源引擎Passmark已成长为增长最快的Playwright AI库之一,被200多个团队使用,创始人们构建了FactoryKit作为这项工作的下一步:同样的验证优先方法,面向无人值守的编码代理。
## 炒作忽略了什么
在这个类别的噪音之下存在四个缺口。它们也是FactoryKit围绕其构建的四个问题,这并非巧合:创始人们在Bug0和Passmark交付了验证工具,然后将其指向编码代理。
**没人能证明可靠性,所以每次运行都必须证明自己。** 这个类别中没有厂商发布首次尝试合并率,包括我们。FactoryKit的应对方案是让每次运行携带自己的证据,而不是要求信任:它执行仓库自身的检查并附有修复尝试,审查自身的差异,对于UI工作则驱动真实浏览器并记录会话。你不需要相信一个并不存在的基准。你直接观看附在PR上的记录。
**并行是卖点,也是账单。** 十个沙箱在一夜之间清理工单是演示。十个沙箱以全价代币重试失败的检查是发票,因为底层的模型(https://hashnode.com/blog/llm-api-pricing)对每次尝试都收费,无论成功与否。这是团队从Passmark带来的纪律,Passmark是一个基于"缓存已验证内容而非付费让模型重新发现"前提构建的引擎。将验证置于运行内部既是成本策略也是质量策略,因为在检查阶段捕获失败比三天后由人工捕获更便宜。
**审查是瓶颈,解决方案是带着预先论证的结果到达。** Lieberman关于人类向上移动一层的说法有一个他未深入探讨的尖锐边缘:一家工厂生成拉取请求的速度快于高级工程师能够负责任地审查它们。FactoryKit的浏览器QA阶段运行在Passmark上,因此UI变更带着会话记录和断言结果一起到达,审查者从证据开始而非从零开始。BrainGu的"黑暗工厂"文章从国防角度提出了相同观点:实现可以熄灯,但责任永远不能。
**安全边界移动了。** 一个拥有仓库访问权限的无人值守代理引发了一个高于其他一切的问题:它能泄露什么?沙箱隔离是入场券。FactoryKit的立场是代理永远不应该持有任何机密,因此GitHub令牌和模型密钥留在沙箱之外,防火墙将其注入出站流量,并按仓库限定范围。一个被攻破或行为不当的代理没有任何东西可交出。无论你评估哪家工厂,先问这个问题;它比任何演示都能更快地区分出产品。
## 购买前应检查什么
三个问题,按它们结束销售电话的速度排序。
1. **对于像我这样的仓库,你的首次尝试合并率是多少?** 不是演示仓库。如果答案是一个不存在的基准,你就了解了这个类别的真实成熟度。
2. **一次失败的运行花费我多少?** 重试是全价计费。获取重试策略和每次运行的经济学书面说明。
3. **运行时我的机密存放在哪里?** 如果答案涉及凭据与代理一起放在沙箱内,继续追问。
## 常见问题
### AI软件工厂只是炒作吗?
这个类别是真实的,围绕它的市场领先于其证据。产品存在,企业正在部署它们,并且架构在厂商之间保持一致,这通常是持久事物的标志。不存在的是任何独立测量它们是否交付的指标。这两个事实同时成立,这正是身处炒作周期中期的样子。
### 我的团队应该构建还是购买软件工厂?
构建意味着走Zakariasson路线:让你的代码库对代理可读,定义护栏和验证,从你已经付费的编码代理中连接你自己的管道。它适合拥有强大平台工程和不寻常约束的团队。购买能让你在第一天就获得沙箱、凭证和验证管道,当构建需要花费一个季度时,购买就变得合理。无论如何,审查瓶颈是你需要解决的问题;没有厂商能帮你摆脱它。
### 运行一个AI软件工厂的成本是多少?
两个计量表。平台方面,按使用量计费且无按席位许可是新兴模式。底层代币方面,代币成本随并行度和重试次数增长,因此每完成任务的成本是需要跟踪的数字,而不是每次运行的成本。一个需要三次尝试才能完成每个工单的工厂,其成本是其演示的三倍,并且驱动该计算的费率卡变化频繁,以至于我们在一个实时页面上维护它们。
相似文章
Reddit r/AI_Agents
一篇评论文章,质疑 AI 代理生成的拉取请求和 token 消耗指标激增是否真的能转化为有意义的业务价值,并警告不要优化虚荣指标而忽视实际影响。
Ars Technica
## Ars Technica 报道:研究显示 AI 编码代理提升代码产出,但拖慢整体交付速度
Ars Technica 报道了一项研究结果,该研究显示,AI 编码代理(AI coding agents)虽然能够提升代码产出量,却拖慢了整体交付速度。具体表现为:
- 代码审查(pull request review)时间增加 **49%**
- 要求修改(changes requested)的比例几乎翻倍
- 目前尚未发现可归因于 AI 的显著就业变化
研究发现,AI 代理虽然让开发者更快地产出代码,但由于生成的代码量大幅增加,审查人员面临的审查负担也随之加重,导致整体交付周期反而被拉长。与此同时,尽管业界对 AI 取代开发者岗位的讨论甚嚣尘上,但截至目前,并没有显著的就业数据变化能够直接归因于 AI 技术的应用。
Reddit r/AI_Agents
关于当前AI编程代理输出验证实践的一点反思,指出开发者通常只是粗略查看差异就合并,而没有全面审计代理的会话活动,引发了对AI时代代码审查文化的担忧。
Reddit r/AI_Agents
文章探讨了关于AI编程代理是否应拥有自主合并Pull Request权限的争论,重点区分了软件工作流中的代码生成与部署决策。
X AI KOLs Following
GitHub COO Kyle Daigle 讨论了 AI 智能体创建的拉取请求激增(3 月份达到 1700 万),以及预计今年将有 140 亿次提交。他强调开源维护者的控制权、基于使用量的定价模式取代按席位许可,以及随着 AI 工具使非开发者也能构建应用,开发者与非开发者之间的界限正在模糊。