买零件,而不是造零件:CBSE如何预言了AI时代的软件开发
Site Owner
Published on 2026-05-21
CBSE核心理念是购买而不是重新构造,不是从零开发,而是把软件拆成标准零件组装成系统。构件有五大特征:可组装性、可部署性、文档化、独立性、标准化。三种组装方式决定了系统结构:顺序组装像流水线,层次组装像微服务分层,叠加组装像模块化中台。AI时代,云原生架构和AI Agent的Tool体系本质上是CBSE的落地实践。行业用了二十年,兜兜转转还是这几板斧。CBSE告诉我们:软件开发的核心能力不是写代码,而是做决策。

买零件,而不是造零件:CBSE如何预言了AI时代的软件开发
2016年,某个大厂技术团队接到了一个紧急需求:三周内上线一个推荐系统。项目经理做了一个疯狂的决定——不从头开发,直接去GitHub找开源项目拼装。结果呢?系统如期上线,三个月后平稳支撑了千万级流量。
这个故事后来被写进了内部培训手册,标题叫"买来的胜利"。听起来不光彩,但所有架构师都知道,这才是软件工程的正确姿势。
这背后的思想,就是今天要聊的——基于构件的软件工程(CBSE)。
01 你在写代码,还是在拼乐高?
CBSE的核心理念只有一句话:购买而不是重新构造。
这听起来像废话。但仔细想想,我们平时的开发模式是什么?产品经理提需求,程序员从零开始写代码,一行一行垒。三个月后上线,发现这个功能某某开源项目五分钟就能搞定。
CBSE就是来解决这个问题的。它的逻辑是:与其每次都从零开发,不如把软件拆成标准化的零件(构件),直接购买/复用这些零件组装成系统。
打个比方:传统开发是去菜市场买菜回来自己做,CBSE是直接点外卖。你不需要知道鱼是怎么养的、菜是怎么种的,你只需要确定你要什么、接口对不对。
这听起来是不是很像今天的AI编程?你不需要从零训练模型,直接调用API。CBSE在二十年前就把这个哲学讲清楚了。
02 构件的五个特征,缺一不可
既然是"买零件",那什么样的零件才值得买?CBSE给出了五个标准:
可组装性:零件的对外交互必须通过公开定义的接口进行。说人话就是——这个零件能不能插进我的系统?接口不标准,插不进去,白送也不要。
可部署性:构件必须是二进制形式的,能独立运行。不能是源代码级别的"参考实现",必须是个拿来就能部署的实体。
文档化:有完整的文档,用户能自己判断这个零件满不满足需求。没有文档的构件和黑箱没区别,买回来是个定时炸弹。
独立性:可以在无其他特殊构件的情况下独立组装和部署。不挑环境、不挑依赖,这样的零件才好管理。
标准化:符合某种公认的标准。EJB、COM/DCOM、CORBA、.NET——这些标准存在的意义就是让构件能互相"插拔"。
这五条标准,放在今天看,就是AI API的契约文档、版本兼容性要求、独立部署能力。行业绕了一圈,发现问题还是那几个问题。
03 三种组装方式,决定系统结构
买回来零件,怎么拼?
CBSE定义了三种组装方式,每种决定了不同的系统架构:
顺序组装:把两个构件按顺序串起来用。数据验证→数据处理→数据存储,线性流程,前一个的输出是后一个的输入。这种方式适合数据处理流水线,结构简单,问题定位容易。
层次组装:被调用构件的"提供"接口必须和调用构件的"请求"接口兼容。上层调用下层,分层清晰。表示层→业务层→数据层,这是最经典的分层架构。
叠加组装:多个构件合并成新构件,对外提供统一的新接口。基础认证+权限控制+日志记录=安全构件。功能叠加,对外收敛。这种方式适合构建领域能力模块。
这三种方式对应了现代架构的不同模式:顺序组装像管道式架构,层次组装像微服务分层,叠加组装像模块化中台。行业用了二十年,兜兜转转还是这几板斧。
04 为什么你公司的"复用"总是失败?
说到这里,必须泼一盆冷水。
CBSE听起来很美好,但现实是什么?大多数公司的"构件复用"就是一堆半死不活的工具类、一份没人更新的Wiki文档、一个谁都不敢删的legacy模块。
问题出在哪?
第一,接口标准不统一。 你有一套标准,我有一套标准,最后谁也不兼容谁。EJB、CORBA当年为什么没成?标准太多,谁也不服谁。
第二,文档和实现脱节。 构件更新了,文档没更新。或者文档写的是一套,实现是另一套。开发者不敢用,怕踩坑。
第三,缺乏激励机制。 写新代码有KPI,复用构件没有。谁愿意花时间把代码打磨成可复用构件?不如多写几个新功能。
第四,构件粒度不对。 太大了不好组合,太小了没有意义。找到一个合适的粒度,需要对业务领域有深刻理解,这不是一般团队能做到的。
这些问题的本质不是技术问题,是组织问题。CBSE失败的原因,从来不是技术实现不行,而是"购买"这套逻辑在组织内部推不动。
05 AI时代,CBSE终于等到了它的春天
有意思的是,CBSE这套理念,在云计算和AI时代反而焕发了新生。
云原生架构本质上就是CBSE的落地实践。AWS、阿里云提供的每一项服务——数据库、缓存、消息队列、人脸识别——都是一个构件。你调用API,我提供服务,不需要知道底层怎么实现。这不就是CBSE说的"购买而不是重新构造"吗?
AI Agent的Tool/Plugin体系更是CBSE的直接翻版。一个Agent调用多个工具,每个工具独立开发、独立部署、有标准化的接口定义。多工具协同工作,就是叠加组装。
微服务架构的原子化服务拆分,本质上是在把系统拆成可独立部署的"构件"。每个微服务有自己的接口、自己的数据、自己的生命周期,通过API通信。这就是层次组装的分布式实现。
所以你看,CBSE没有过时,它只是在等待合适的土壤。云原生、AI、全球化分工——这些趋势都在帮CBSE还债。
06 所以呢?
CBSE告诉我们一个反直觉的道理:软件开发的核心能力,不是写代码,而是做决策。
决定买什么零件、不买什么零件,决定用什么接口标准,决定构件的粒度应该多大——这些决策比写代码本身更重要。因为代码可以重写,架构决策失误的代价是整个系统的生命周期。
对于正在学架构设计的你,CBSE不是一道考题,而是一套思维方式:看到任何功能需求,先问能不能复用、再问怎么复用、最后才问怎么开发。这个顺序反了,写出来的就是"意大利面条"。
下次接需求的时候,问自己一句:这个零件,需要我自己造吗?
考点:基于构件的软件工程(CBSE)| 购买而不是重新构造