乐于分享
好东西不私藏

当代码的主要产出方不再是人,软件工厂还成立吗?

当代码的主要产出方不再是人,软件工厂还成立吗?
过去两年,AI 编码助手从"补全下一行"走到了"独立完成一个特性分支"。不少团队的真实数据是:仓库里新增代码的一半以上,第一作者已经不是人。这个趋势不会回头。于是一个问题开始变得无法回避——我们花了很长时间建起来的软件工厂,那套以 DevSecOps 为骨架的流水线、门禁、评审和度量体系,是为"人写代码"这个时代设计的。当代码的主要产出方不再是人,这座工厂本身还成立吗?
我的判断是:成立,但它的重心会被彻底翻转。软件工厂不会消失,它会从"生产代码的工厂"变成"生产信任的工厂"。这篇文章想把这个判断讲清楚——为什么翻转、翻在哪里、以及哪些组织会在翻转中最先失控。

01

软件工厂的隐含前提
先把"软件工厂"这套体系还原到它的出发点。
DevOps 也好,DevSecOps 也好,它们诞生时面对的核心矛盾是:代码是稀缺且昂贵的,人是产能瓶颈。一个组织一年能交付多少软件,取决于它有多少工程师、这些工程师的时间被浪费了多少。所以整套体系的设计目标非常一致——让人写的变更,更快、更安全地流过去。
持续集成,是为了让人提交的代码尽早合并、尽早暴露冲突;代码评审,是用另一个人的注意力为一个人的产出兜底;安全左移,是把安全检查从下游搬到上游,因为越晚发现人犯的错,修复成本越高;价值流分析,度量的是人产出的变更在流水线各环节的停留时间。你会发现,每一个实践的分母都是"人的产能",每一个优化的对象都是"人工产出的节奏"。
这没有错。在那个时代,这是对的抽象。

02

前提崩塌之后:瓶颈的迁移
现在这个前提正在崩塌。当 AI 成为主要产出方,代码从稀缺品变成近乎免费的大宗商品。生成一段实现不再需要一个下午,而是几十秒;重写一个模块的成本,可能低于读懂并修改它的成本。
稀缺资源换了位置,瓶颈必然迁移。新的瓶颈不再是"写",而是"判定"——判定这段代码该不该存在,是否符合真实意图,能不能被信任地放进生产系统。
这件事最先冲击的是代码评审。评审制度的经济学基础是:写代码慢、看代码快,所以一个资深工程师的注意力可以覆盖若干个人的产出。而当一天的变更从几十个 PR 变成几百上千个,这个算术就不成立了。人工评审要么沦为橡皮图章,要么成为把 AI 产能重新压回人类速度的堰塞湖——两种结局都意味着这道工序按原样保不住。
被冲击的还不只是评审的数量,还有评审的性质。"读代码比写代码难"是这个行业的老问题,而 AI 把它放大到了极致:评审者面对的不再是一个可以当面追问思路的同事,而是一段没有"作者"可供质询的产出。你不能问它"这里为什么这么写"然后从迟疑里听出风险——一切判断只能依据摆在眼前的制品和证据。这逼着我们把过去藏在人际信任里的判断,显式地搬到制品层面来。
再看测试。过去测试是"验证实现是否正确"的手段;当实现可以被无限次廉价重生成,测试的地位悄悄上移了——它成了"定义什么叫正确"的规格本身。你写下的验收测试是什么,AI 交付的系统就"是"什么。某种意义上,这是形式化方法社区喊了几十年的事,被产能革命从侧面推成了现实。

03

流水线不是更不重要,而是更重要了
有一种流行的推论是:既然 AI 这么强,流水线这套繁文缛节可以简化甚至拆掉了。我认为恰恰相反——流水线会变得空前重要,只是重要的理由变了。
原因很直接:人已经审不过来了。当人工注意力无法覆盖全部产出,自动化门禁——测试、静态分析、策略即代码、依赖审查、来源证明——就不再是"辅助人做判断的工具",而是事实上的正确性定义本身。门禁里写了什么,系统就守住什么;门禁里没写的,就等于放行。过去门禁松一点,还有人的经验兜底;现在门禁的边界,就是组织判断力的边界。
会有人问:判定环节难道不能也交给 AI 吗?让一个模型去评审另一个模型的产出。当然可以,而且一定会大规模发生——但这不消解问题,只是把信任的锚点向后推了一层:AI 评审员依据什么评审?它的判据谁来定、谁来验?递归到最后,这条链必须有一层锚定在确定性的、可审计的东西上——可执行的测试、可校验的证明、显式写下的策略。此外还有一条必须守住的原则:判定者与生成者要分离,评审模型不能与编码模型共享同一个"大脑"和同一套激励,否则整条链本质上是自己给自己签字。AI 可以承担判定的"劳动",但判据的"立法权"和判定体系的独立性,仍然是组织必须自己持有的东西。
当然,有一种更激进的设想值得认真对待:如果软件可以随用随生成,我们是否还需要管理"变更"这个概念?也许未来某类软件真的会走向"一次性"——不维护、不演进,需求变了就整体重造,验证的对象从代码差异变成系统行为。我不排除这条路线在某些场景成立,比如内部工具和原型。但对于要长期运行、承载责任、与物理世界和资金安全绑定的系统,"整体重造"并不能豁免验证义务——你重造得越频繁,越需要一套能快速、自动、可信地回答"这一版还对吗"的体系。换句话说,激进路线不是流水线的替代,而是对流水线验证能力的极限压力测试。
打个比方:软件工厂正在从加工车间变成计量认证机构。车间时代,工厂的核心资产是产线和工人;认证时代,核心资产是标准、量具和证据。产出物从"二进制包"变成"二进制包,以及证明它可信的那一整套证据"。
这也意味着一个残酷的筛选:那些今天把流水线当"自动打包工具"、门禁形同虚设、测试覆盖靠报表美化的组织,会在 AI 产能到来时最先失控。不是因为 AI 不好用,而是因为它们从来没有真正把判断力编码进体系里——过去靠老师傅的经验在流程外兜底,而 AI 的产能会直接冲垮这种非正式的兜底机制。

04

三处必须重写的地方
说软件工厂"成立",不等于说它可以原样运转。至少有三块需要重写。
第一,安全模型:防御对象从"代码缺陷"扩展到"生产者本身"
传统 DevSecOps 防的是人的疏忽——漏打的补丁、硬编码的密钥、没校验的输入。这些依然要防,但新增的威胁面是生产者:一个 agent 的权限边界在哪里,它会不会被藏在 issue、注释或依赖文档里的提示注入操纵,它引入的第三方包是不是幻觉出来的仿冒品,它有没有在数千次提交中夹带一个人眼永远不会去看的后门。"最小权限"这个老原则要重新落一遍——这次的主语不是运维人员,而是编码 agent:它能读哪些仓库、能动哪些分支、能触达哪些密钥,都需要像管理生产环境访问一样被显式治理。供应链安全的问题清单上,"谁写的这段代码、依据什么写的"从考古题变成了必答题。
第二,资产定义:真正需要管理的资产上移为意图
当代码可以廉价重生成,代码本身的资产属性在贬值,升值的是它的上游——规格、约束、架构决策、验收标准。这些过去散落在文档、会议纪要和某个人脑子里的东西,现在必须成为一等公民:有版本、有评审、有变更追溯。提示词和任务描述会进入配置管理的范围,架构约束会从"设计文档里的一段话"变成"流水线里可执行的检查"。变更管理的对象,从"这段代码改了什么"上移为"我们对系统的意图改了什么"。
第三,证据链:合规体系的答案会更严,而不是更松
在强合规领域——航空、医疗、金融,以及我更熟悉的装备软件研制——"谁写的、依据什么、如何验证"的追溯要求不会因为 AI 而放松,只会更严。软件工厂的核心交付物,会从软件本身扩展为"软件加上它的保证论证(assurance case)":需求可追到设计,设计可追到实现,实现可追到测试,每一环都有机器沉淀的证据,而非事后补写的表格。这条路线在通用行业已有先声——SBOM 与制品来源证明的快速普及;在军标体系下则有更深的制度渊源,后文详谈。

05

美军软件工厂的三段剧情
以上还是推理。把视线投向实践最激进的地方——"软件工厂"这个词在全球最大的践行者,是美国国防部。它近十年的轨迹,恰好为前面的论证提供了一组现成的注脚。
第一段剧情是证明可行
2017 年,空军的 Kessel Run 以"第一家军队软件工厂"的姿态出现,用一款空中加油规划软件在几个月内省下了传统采办体系几年都省不下的燃油成本,证明了一件事:哪怕是全世界最官僚的组织,也可以运行敏捷的软件产线。此后软件工厂在美军内部快速繁殖,Platform One、Black Pearl、陆军软件工厂等三十余家相继成立,形成了一个至今活跃的软件工厂联盟。
第二段剧情是暴露短板
Kessel Run 后来的路并不平坦——成本与交付争议、与传统采办体制的摩擦、组织架构的反复调整,直到并入建制内的项目办公室,再到 2026 年初以"下一代空中作战中心"项目的形式重新出发。首任国防部首席软件官 Chaillan 在 2021 年愤而辞职时的公开抱怨,把问题说得很直白:工具和文化的先进,抵不过组织与流程的滞后。用四要素的语言说,美军用十年验证了"工具单兵突进"的天花板在哪里。
第三段剧情最值得注意:AI 来了之后,美军的第一反应不是放松管控,而是重建信任链
2025 年国防部推出 SWFT(软件快速通道),改造的对象正是最官僚的环节——运行授权(ATO):用 SBOM、第三方验证和 AI 辅助的风险评定,把一次性的审批换成持续的、证据驱动的信任判定;同期的软件现代化实施计划,明确要为 AI 制定专门的 DevSecOps 参考设计、扩大持续授权(cATO)的覆盖面。cATO 这个机制本身就值得多看一眼——它把"审批时刻"消解为"证据流",是"生产信任的工厂"迄今最完整的制度化样本。换句话说,在代码产能即将爆炸的前夜,这个体系选择把宝押在"判定的工业化"上。这与本文的判断,是同一个方向。

06

国内的镜像:同一场考试的另一张考卷
国内的软件工厂建设,尤其在装备行业,这几年同样铺开得很快。但路径与美军几乎相反:美军是文化先行、体制追认,国内多是平台先行、自上而下。这条路径的典型困境,很多从业者不会陌生——平台建起来了,运行体系没长出来。流水线成了汇报材料里的截图,门禁为了赶节点可以一键放行,度量数据主要服务于对上而不是对内。这正是"工具堆叠"的典型形态:四要素里买齐了工具,组织的权责、流程的判定环节、视图的真实透明,都还停在原地。
但国内装备行业也握着一个常被低估的结构性优势:军标体系本质上就是一套"证据驱动"的制度设计。GJB 438C 规定的文档体系、GJB 2786 规定的研制过程、定型审查、第三方独立测评——这套制度的内核假设从来不是"信任工程师的自觉",而是"只认可归档的证据"。过去我们抱怨它形式大于实质,是因为证据靠人工事后补写,补写的证据当然只剩形式。而 AI 时代恰恰需要的就是显式的、制度化的、不依赖个人自觉的判定体系——这与军标的设计哲学高度同构。差的只是一步转换:让证据从"人工事后补写"变成"机器过程中自动沉淀"。如果这一步走对了,国内装备行业不是追赶者,反而可能在"生产信任的工厂"这条新赛道上占住先手——因为它从未指望过硅谷式的工程师文化兜底,它一直想要的就是可审计的制度化判断。
具体到装备软件,AI 产码还会撞上几道行业特有的考题。
其一,定型与审查的对象问题
传统军标隐含着一条信任链:"合格的人 + 受控的过程 ⇒ 可信的产物",所以审查既看产物也看过程,而过程的核心是人的资质与活动记录。AI 产码打断的正是"合格的人"这一环。出路不在假装这一环还在,而在把信任的重心移向产物侧证据:更完备的测试判据、需求追溯矩阵的自动生成与自动核查、关键部件的形式化验证。民航 DO-178C 对开发工具做"工具鉴定"的思路值得借鉴——未来对编码 agent 本身做资格认定与等级划分,可能会成为安全关键领域的标配。
其二,独立性原则的新生命
军工传统里的独立测评(IV&V)常被看作合规成本,但在 AI 时代它突然获得了普适的技术含义:生成者与判定者必须分离。这一条前文已经论证过——独立测评机构几十年积累的"不信任生成方"的方法论,恰好是整个行业此刻最需要的东西。
其三,密级与隔离的约束
涉密环境意味着模型要私有化部署、语料不能出网,短期内"用不上最强的模型"会成为现实落差,甚至成为新的能力分层线。但换个角度看,封闭环境里的私有化模型加上高质量的军标语料与领域判据,也可能养出通用模型不具备的领域判定能力。约束从来都是双刃的——关键看组织把力气花在抱怨约束上,还是花在约束内的最优解上。

07

人的位置:从工人到质检总师
那么人去哪里了?
不是离开工厂,而是换了岗位。人从流水线上的操作工,变成三个新角色:定义验收标准的人——把组织对"什么是对的、什么是好的、什么是可接受的风险"翻译成机器可执行的判据;处理例外的人——门禁拦下的边界情况、判据之间的冲突、前所未见的场景,这些依然需要人的判断;以及维护体系本身的人——判据也会过时、失配、被绕过,需要有人持续审视这套"判断力的编码"是否还对准着真实世界。
这三个角色有一个共同点:它们消耗的都是判断力,而不是产能。这对工程师的成长路径是一个不小的冲击——过去一个人可以靠大量地写来积累手感,未来"写"的机会被机器拿走了大半,判断力要从哪里长出来?我没有完整答案,但可以肯定的是,组织需要有意识地保留让人建立手感的空间,否则十年后将无人有能力为机器的产出把关。这可能是这场转型中最少被讨论、却最伤筋动骨的一环。
用一个我常用的框架来看:组织、流程、工具、视图四个要素里,过去二十年行业的注意力严重偏向工具——买平台、堆链路、上大屏。AI 恰好把工具这一层的门槛降到了最低,于是真正的差距暴露在另外三层:组织有没有把判断的权责界定清楚,流程有没有把判定环节显式建模,视图能不能让人在海量机器产出中看见该看的东西。工具堆叠掩盖不了运行体系的缺失——这个判断在 AI 时代不是被削弱了,而是被加倍放大了。

08

结语:问题问反了
回到标题的问题。"当代码的主要产出方不再是人,软件工厂还成立吗?"——写到这里可以说,这个问题其实问反了。
软件工厂从来不该被理解为"组织人写代码的方式",它的本质是"组织把自己的判断力沉淀为可运行体系的方式"。人写代码的时代,这个本质被产能瓶颈遮住了,大家忙着优化流速;AI 写代码的时代,产能不再稀缺,本质水落石出。
所以真正的问题是:你的软件工厂里,除了工具和流速,到底沉淀了多少判断力?如果答案是很多——那么恭喜,AI 是你的杠杆,每一条被编码的判据都会被成千上万次地复用。如果答案是很少——那么危险的不是 AI,是你的工厂本来就只是一堆工具的合影,而现在,遮羞的幕布正在被撤走。
工厂还在。只是它生产的东西,从来就不该是代码,而是信任。

09

作者简介
Daniel,关注软件工程如何在复杂约束环境中真正"运行起来"。长期聚焦 DevOps / DevSecOps 与软件工厂在装备与 JG 领域的实践与反思,围绕组织、流程、工具与视图等关键要素,探索软件研制从"工具堆叠"走向"运行体系"的路。