制造软件的软件:主流软件工程的盲区

软件首先是制造活动的产物。

把软件理解为编码的结果，是对软件的结构性误判。

这不是修辞，而是活动性质判断。软件不是一次性的表达结果，不是写完即止的文本，也不是临场发挥的产物。它是一种需要被持续构造、交付、运行、维护和演化的制品。既然如此，软件行业就不只是一个写代码的行业，而是一个围绕软件制造活动组织起来的行业。

本文所说的“主流软件工程”，是指过去几十年软件行业中占主导地位的那套对软件制造活动的理解、拆解与组织方式。它把原本连续一体的制造活动拆开，分成若干可识别、可分工、可管理、可优化的部分，再围绕这些部分形成角色、流程、工具、平台和规范。过去几十年软件行业的主体进步，基本都发生在这套理解之内。

但也正因为它太成功，一个更深的问题被长期压回了背景：主流软件工程一直在研究如何更好地制造软件，却没有真正把“软件能否承接软件制造”前移为研究对象。

一、主流：研究制造之内

有的聚焦制造环节。编码如何更高效，测试如何更可靠，构建如何更稳定，调试如何更可控，性能如何更可测。于是有了编辑器、编译器、测试框架、构建系统和各种分析工具。

有的聚焦制造流程。需求如何进入设计，设计如何进入开发，开发如何进入测试，测试如何进入发布，发布后的反馈如何进入下一轮迭代。于是有了敏捷、持续集成、持续交付、DevOps，以及整套围绕交付流和反馈流建立起来的工程实践。

有的聚焦局部机制替代。不只优化既有工序，也尝试替换其中某些关键做法。于是有了低代码、模型驱动、模板生成、AIcoding。它们路径不同，但方向一致：减少某些环节对手工实现和个体经验的依赖。

还有一类工作，聚焦系统如何承接现实。客户、订单、库存、合同、审批、财务、权限、流程、组织，这些现实内容如何进入数字空间，如何被稳定组织，如何持续运行。于是有了ERP、CRM、OA、财务系统以及各类企业平台。

再进一步，还有一类工作，聚焦能力如何持续派生。应用、规则、流程、分析、模型、视图、指标，能否从较稳定的统一基础上持续长出来，而不是每次都从头再造。于是有了各种基础平台、数据平台和统一对象体系。

这些方向共同构成了现代软件工业的主体成就。但它们大多共享同一个默认前提：软件制造这件事本身，是已成立的背景。

二、盲区：制造本身尚未被软件化

真正较少被研究的，不是某个局部技术，而是软件制造活动本身。

软件制造的基本构成单位与组合语法是什么？
这些单位如何形成可组合、可校验、可继承的生成结构？
设计、实现与运行为何长期未能形成连续体？
制造所依赖的关键知识，如何摆脱个体依附而转化为公共结构？
一个系统能否同时承接其结果、变化及其自身的生成机制？

这些问题共同指向同一件事：软件制造活动本身，尚未被充分软件化。它仍高度依赖个体经验、项目制协调与人肉缝合来维持连续性。

三、分水岭：谁在承担制造的连续性

这里有一道真正的分水岭。

在主流软件工程的默认前提中，人始终是制造软件的中心承担者。人理解需求，人判断结构，人拆解任务，人写代码，人吸收变化，人维持一致性，也为系统失配兜底。工具、流程、平台和规范，都服务于同一个基本格局：让人更好、更快地制造软件。

“制造软件的软件”之所以构成分水岭，就在于它不再接受这个前提。

它不再把软件只看作被制造出来的结果物，而开始追问：软件能否同时承担制造活动本身的一部分结构责任。这里所说的“制造”，不只指产出软件制品，也包括使这种产出得以连续成立的生成机制本身。问题不再只是“人怎样更好地制造软件”，而是“软件能否成为制造软件的主要承接体”。

只要软件制造的连续性仍主要靠个体经验、项目组织和临时协调来维持，制造活动的主要承担者就仍然是人。反过来，只有当软件开始承接制造本身的关键结构责任，人作为制造连续性兜底者的地位才会被真正改写。

所以，真正的分水岭不是“有没有人”，而是：制造软件的连续性，究竟主要由人来维持，还是开始由软件化的公共生成与约束机制来维持。

四、大模型：不是原因，是显影

大模型不能忽略。但它在这里不是起因，而是显影。

“制造软件的软件”不是因为大模型出现才成立的问题。这个问题在大模型之前就已经存在：主流软件工程长期默认，人是制造软件的中心承担者，软件主要是被制造出来的结果物。

大模型改变的，不是这个问题的存在，而是这个问题的可见性。

当软件开始明显参与软件制造过程时，那个长期被默认的人机分工前提就被推到了台前。代码补全、测试生成、缺陷修复、仓库分析、代理执行，这些现象共同说明：软件已经不再只是制造的结果，也开始介入制造过程本身。于是，一个原本可以被遮蔽的问题被照亮了：我们究竟只是在制造更强的辅助工具，还是在推动软件开始承接软件制造的某些结构责任？

大模型没有自动跨过那道分水岭。它只是第一次让这道分水岭无法继续停留在背景里。

五、主流为何停在这里

这不是因为主流软件工程无能，而是因为它有自己的历史合理性。

它必须可教。一个行业若要形成规模，就必须把复杂活动拆成可识别、可训练、可管理的部分。阶段、角色、工序、交付物、规范和流程，正是这种可教学、可复制、可组织的产物。

它必须可用。行业从来不是等理论完备后才开始运行，而是在一套足够可用的制造理解上逐步积累。哪怕这套理解并不彻底，只要它能持续交付结果，就足以支撑大规模实践，并固化为主流。

它还必须可积累。环节优化、流程改进、局部机制替代、承载增强、能力派生，这些方向更容易形成清晰成果，更容易产品化、平台化、岗位化和标准化，因此天然更容易成为长期研究重心。

反过来，对“制造软件的软件”的研究之所以长期稀少，也很简单。它难以切分，难以岗位化，难以迅速产品化，也难以在现有分工结构中找到明确归属。一旦研究对象推进到这里，原有的角色边界、工具边界、项目边界和系统边界都会被触动。这不是局部优化，而是对主流软件工程默认前提的再审。

六、结论：从优化制造，到前移制造

主流软件工程研究了很多，而且成绩巨大。它研究环节、流程、局部机制、承载结构与能力派生，现代软件工业的主体进步，基本都来自这些方向。

但它没有真正研究软件制造本身。它没有把制造活动前移为首要对象，没有真正追问制造的基本构成单位、生成结构与连续性机制，也没有真正让系统承接其自身的生成机制。

这不意味着主流软件工程失效了；它意味着，主流软件工程可能已经把自己最重要的前提，当成了无需再研究的背景。

因此，软件行业下一步真正重要的问题，不再只是如何更好地制造软件，而是：能否把“软件制造”推进为一种具备公共语法、可内在连续、可自我承接的机制性活动。

“制造软件的软件”所标识的，正是这一转向：从在既定制造理解内持续优化，转向把制造本身前移为研究对象。