钟摆厌倦了摆动

两派、一个WhatsApp，没有明显的赢家

不需要编造一个轶事：任何在2026年领导工程团队的人都经历过这种情景。一个团体发誓打破单体架构是他们职业生涯中最好的决定。同一个聊天群中的另一个团体发送了Kubernetes账单的截图，显示每月的费用不低于五位数。没有人在撒谎。这恰恰是问题所在：软件架构不再是一场技术讨论，而是一场部落认同的讨论，双方都有真实的数据来支持他们相互对立的立场。

在我加入任何一派之前，我决定做我在Slack上参与这场辩论一年半以来从未做过的事情：追溯每个数据到其起源。我的发现并不是一个赢家，而是一个关于谁在做什么、为什么做以及——这才是有趣的部分——公共话语与内部实际行为之间的差异的地图。

每个人都引用的数据，但没有人能指出其来源

我从这项调查中最令人不舒服的发现开始，因为它最好地解释了软件行业如何形成共识。

我在2025年和2026年的数十篇文章中搜索了“42%的组织采用微服务正在将服务整合回更大的单元”的数据。所有这些文章都将其归因于“2025年CNCF的一项调查”。其中一篇文章——它引用了这个数据——在其生产说明中承认，它是由一个使用人工智能的自动化管道“验证对CNCF x SlashData 2026报告”（ManoIT / DEV Community, 2026）编写的。我直接访问了cncf.io，审查了2024年年度调查报告（CNCF, 2025）、2025年11月关于与SlashData合作的研究的公告（CNCF, 2025）以及基金会发布的最新调查报告，在我能够打开的所有文件中，这个确切的42%数据都没有出现。然而，一个数据始终如一地出现：46%的后端开发人员使用微服务，容器和Kubernetes的使用仍在增长（CNCF/SlashData, 2025）——我直接核实了这个具体数据，与基金会的原始声明相符。

这是否意味着 42% 的数据是虚假的？不一定是这样 —— 这正是基金会在网络研讨会或侧边面板中报告的那种数字，而这种数字不总是像主要 PDF 文件一样被索引，而且它几乎被至少八个独立来源以一致的详细程度引用（包括服务网格的采用率从 18% 下降到 8%） (SoftwareSeni, 2026；ThirdEyeData, 2026；ByteIota, 2026)。但是，对于一篇吹嘘自己验证每个数据的文章来说，诚实地讲：42% 是 2026 年整个架构辩论中最常被引用的数字，我却无法将其与一个可读的原始文档进行核实。因此，我们应该将其视为“被广泛重复，但未经独立验证”，而不是一个既成事实。这是一个很好的例子，说明技术领域中的“共识”有时只是人工智能生成的内容在圈子里自我引用。

有一点是有坚实基础的，并且有原始资料支持 —— 而且在这篇文章的原始草稿中，我缺乏对这个问题的深入探讨，所以我去寻找了真正的资料：亚马逊 Prime Video 的迁移。他们的工程团队在自己的博客中记录了如何将一个分布式架构的视频质量监控服务整合到一个单体架构中，实现了 90% 的基础设施成本减少 (Amazon Prime Video Engineering, 2023)。

反对微服务的最常引用的案例

Amazon Prime Video 在将视频监控服务整合到单体架构后，基础设施成本的降低。

90%

基础设施成本降低（2023）

Ver los datos

反对微服务的最常引用的案例

Indicador	Valor
基础设施成本降低（2023）	90%

这个案例 —— 已经三年了 —— 仍然是所有反对微服务的人必引用的例子，这是有道理的：它来自同一个教会世界微服务的公司。

Shopify：证明“单体”并不等同于“小”

如果支持微服务的论点一直是“没有微服务你就不能扩展”，Shopify 用具体的、可验证的数字在自己的工程博客中驳斥了这一说法。他们的平台运行着他们自己称之为“壮丽单体”的东西：一个单一的 Ruby on Rails 应用程序，内部组织成具有严格边界的组件，这些边界是由他们为此目的开发的 Packwerk 工具强制执行的。在黑色星期五的流量峰值期间，他们的基础设施每分钟支持数十个 terabyte 的数据，数据层是根据商店 ID（shop_id）进行分区的，而不是将应用程序代码分成独立的服务 (Shopify Engineering, s.f.)。

这种区分很重要：Shopify 并没有避免模块化，而是避免了分布式。他们的组件是由代码边界（在领域驱动设计的语言中称为有界上下文）分隔的，但它们运行在同一个进程中，彼此之间没有网络调用。这正是 2025-2026 年的大多数文献所确定的“模块化单体”的定义 —— 这是一种在传统单体和微服务之间的真正的第三种选择 (Al-Qora'n & Al-Said Ahmad, 2025)。第一个关于这个主题的学术系统文献综述发表在《未来互联网》杂志上，仅发现 2020 年至 2025 年 5 月之间有 15 项同行评议的初步研究，这说明了一个重要的问题：行业实践远远领先于支持它的正式研究。

雷达 1 —— 软件大公司真正做了什么

雷达 1 — 软件巨头的真正做法

基于正文中关于每家公司的陈述，编辑评分从 0 到 10 分，不是正式调查。每个轴都朝着更高的值是“更好”的方向。

遗留系统的独立性部署速度操作的简单性原生集成的 AI/代理每个功能的成本效率边界治理的成熟度

• SAP（遗留 ERP 正在过渡）
• Shopify（原生模块化单体）
• Oracle（混合 SOA）
• Anthropic / OpenAI（原生 AI）

Ver los datos

雷达 1 — 软件巨头的真正做法

Eje	SAP（遗留 ERP 正在过渡）	Shopify（原生模块化单体）	Oracle（混合 SOA）	Anthropic / OpenAI（原生 AI）
遗留系统的独立性	2	8	4	9
部署速度	3	7	4	9
操作的简单性	4	7	3	8
原生集成的 AI/代理	3	5	3	10
每个功能的成本效率	3	8	4	7
边界治理的成熟度	6	9	5	8

有了这些信息，让我们来看看提出这个问题的六家公司 —— SAP、Oracle、Microsoft、Apple、Anthropic 和 OpenAI —— 以及十几家在 2025-2026 年技术文献中经常被引用的公司。

<strong>SAP</strong> 可能是这个群体中最诚实的案例：他们自己的技术社区将 S/4HANA 的核心描述为“一个巨大的模块化单体”，它正在逐渐分解为本地云架构，没有承诺完成日期 (SAP Community, 2025)。这不是数字化转型的营销语言：这是一家 50 年历史的公司承认，打破一个 ERP 单体需要超过十年。

<strong>Oracle</strong> 同时推行着两个相互平行的论点。Fusion Applications 于 2011 年基于经典的面向服务架构（SOA）诞生 (Oracle, Wikipedia, s.f.)，从那时起，“Spectra 项目”将功能转移到 Kubernetes 管理的容器中的微服务上，使用 Helidon 框架 (Oracle Cloud Blog, 2023) —— 但 Oracle 自己的博客将这个过程描述为“幕后发生”的事情，客户不会感知到它，正是因为对运行成千上万家企业工资和资产负债表的软件进行完全重写是不现实的。

<strong>Microsoft</strong> 没有关于这个话题的统一声明，但其行为可以从第三方的技术文献中看出：2025-2026 年对于企业级 .NET 来说，主导模式与整个行业相同 —— 从模块化单体开始，只有在有实际需求的证据时才提取微服务 (Murmu Software, 2026)。其内部的 AI 实践（下面描述的“带有隔离子代理的编排器”）也证实了相同的哲学。

<strong>Apple</strong> 没有发布后端架构，但在其开发者生态系统中，对于大型 iOS 应用来说，主导模式是通过 Swift Package Manager 实现的模块化单体，而不是微服务：将其分成内部框架，而不分割编译和部署过程 (Tariq, 2025)。这与 Shopify 在后端使用的模式相同，但应用于客户端。

<strong>Anthropic 和 OpenAI</strong> 是这个雷达中最有趣的案例，因为它们不在 ERP 或电子商务中竞争：它们在如何编排 AI 代理方面竞争，而它们的架构就是产品。Anthropic 在其工程博客中记录了其代理作为单个循环运行，具有工具和子代理，受中央编排器控制，而不是作为对等的微服务网格 (Anthropic Engineering)。OpenAI 放弃了其实验框架 Swarm（2024 年），转而使用代理 SDK（2025 年），但保持了相同的极简设计原则：一个代理决定何时将控制权转移给另一个代理，而无需复杂的中央协调器或网格通信 (OpenAI Swarm repo; Tao An, 2026)。我将在 AI 部分再次讨论这一点，因为这是我认为整个研究中最有启发性的发现。

对于这个雷达，我选择了六个轴，这些轴是通过自己的研究确定为最具启发性的：<strong>架构上的遗产独立性</strong>、<strong>部署速度</strong>、<strong>操作复杂性</strong>、<strong>对 AI/代理的原生集成</strong>、<strong>每个功能的维护成本</strong> 和 <strong>边界治理的成熟度</strong>（他们如何认真对待 Conway 法则）。我比较了四个代表性的配置文件 —— SAP（过渡中的遗产 ERP）、Shopify（原生模块化单体）、Oracle（混合 SOA）和 Anthropic/OpenAI（原生 AI，编排器 + 子代理）—— 因为试图在单个雷达图中绘制 24 家公司将是无法读懂的；其余的企业格局 —— Microsoft、Apple、Amazon、Google、Meta、Netflix、IBM、Salesforce、Stripe 和其他出现在 2025-2026 年文献中的公司 —— 在正文和方法论中讨论，而不是在图表的轴上。

雷达 2 —— 另一边：谁维护开源

雷达 2 — 另一方面：谁维护开源

基于关于每个项目的陈述，编辑评分从 0 到 10 分，不是正式调查。

声明的单体哲学减少的维护团队无网络的内部模块化采用规模独立于基金会

• Linux（内核）
• PostgreSQL
• Kubernetes
• Proxmox

Ver los datos

雷达 2 — 另一方面：谁维护开源

Eje	Linux（内核）	PostgreSQL	Kubernetes	Proxmox
声明的单体哲学	10	8	1	9
减少的维护团队	3	5	1	9
无网络的内部模块化	8	7	2	7
采用规模	10	8	9	5
独立于基金会	6	7	2	9

这里用户提出的问题是精确的：维护 Linux Foundation、MySQL、MariaDB、PostgreSQL、Proxmox 等 30 个高影响力项目的组织做了什么？简短的答案是：开源世界已经进行了几十年的讨论，远早于“微服务”成为企业流行词。

基础案例是 <strong>Linux 内核</strong>。1992 年，Andrew Tanenbaum 公开地写信给 Linus Torvalds，说在那个时候编写单体内核是“向 70 年代巨大倒退”的一步，并且微内核已经赢得了学术辩论 (Tanenbaum-Torvalds debate, Wikipedia, 1992)。Torvalds 回应道，微内核“将问题推到了通信空间，这是一个比他们声称解决的问题更大的问题” (Torvalds, sobre el debate micro vs. monolítico)。34 年后，Linux —— 单体 —— 运行在绝大多数服务器上，GNU Hurd —— 微内核 —— 仍然是一个学术项目。讽刺的是：使得微服务能够运行的基础设施（容器、Kubernetes、整个云）是建立在一个通过成为单体赢得了自己战争的内核之上。

<strong>PostgreSQL、MySQL 和 MariaDB</strong> 在数据层面上遵循相同的逻辑：它们是由设计而成的单体过程，自身社区积极讨论是否“分解”数据库到数据微服务中是否有意义，或者这只是重新引入了之前通过函数调用就能解决的网络复杂性 (Reintech, 2026)。2025-2026 年的主导答案是：保持数据库的单体，并在其周围放置应用微服务，而不是在内部。

<strong>Proxmox</strong> 是最典型的“另一种开源方式”的例子：一家小型的奥地利公司，没有像 CNCF 这样的基金会或多供应商政府的支持，它维护着一个故意保持简单的全能平台（虚拟机 + LXC 容器 + 存储 + 网络），与 Kubernetes 的原生替代品 KubeVirt (Kubermatic, 2026) 相比。它是基础设施软件中同样的模式，André Staltz 多年前描述为开源的“整体主义学校”：像 WordPress、Django 或 Linux 这样的项目以一个整体的形式解决一个大问题，而“模块化学校”则以包为单位发布单个实用程序 (Staltz, 2018)。十多年后，它仍然是我发现的最有用的思维框架，用于解释为什么 Gogs（单个二进制文件，单个维护者）和 Kubernetes（数百个协调的部分）代表了同一开源运动的对立哲学 (Laoutaris, 2025)。

对于这个雷达图，我使用了五个轴：<strong>宣称的整体主义哲学</strong>、<strong>维护团队的大小</strong>、<strong>无网络的内部模块化</strong>、<strong>采用规模</strong> 和 <strong>对基金会治理的依赖</strong>。我比较了 Linux（内核）、PostgreSQL、Kubernetes 和 Proxmox —— 我回顾的技术文献中最常被引用的四个参考点，在 20 多个项目（包括 MySQL、MariaDB、Caddy、SigNoz、Gogs、Nginx、Envoy、Terraform、Ansible、Jenkins、Prometheus、Grafana、Elasticsearch、Redis、Kafka、Django、WordPress、GitLab、Nextcloud 和 Home Assistant 等）的更广泛的范围内，这些项目都记录在方法论中。

雷达 3 —— 政府：四种哲学，同一个扩展问题

雷达 3 — 政府：四种哲学，同一个扩展问题

基于关于每个政府块的陈述，编辑评分从 0 到 10 分，不是正式调查。

云基础设施的成熟度声明的模块化/互操作性已验证的事务规模对私营供应商的主权内部系统的成熟度

• 美国
• 欧盟
• 中国
• 印度

Ver los datos

雷达 3 — 政府：四种哲学，同一个扩展问题

Eje	美国	欧盟	中国	印度
云基础设施的成熟度	5	7	8	7
声明的模块化/互操作性	3	10	4	8
已验证的事务规模	6	5	7	10
对私营供应商的主权	4	8	10	6
内部系统的成熟度	3	6	7	8

这里是原始问题变得更有趣的地方，因为政府不争夺市场速度：它们争夺主权、互操作性和不在自己的规模下崩溃。

<strong>美国</strong> 正在经历最坏的情况：根据政府问责局（GAO）的数据，联邦政府每年在技术上花费超过 1000 亿美元，其中大约 80% 的资金用于维护遗留系统的运行，而不是用于建设新系统 (GAO, 2025)。这是任何 CTO 都会面临的十年老的单体应用问题的国家版：技术债务以预算而不是架构优雅来支付。

<strong>欧盟</strong> 采取了相反的立场，并且是明确记录的：由 ITU、爱沙尼亚、德国和 DIAL 发起的 GovStack 倡议，得到了欧盟全球门户的资金支持，其官方培训课程的标题就是《避免单体应用：集成微服务以实现无缝数字转型》 (ITU Academy / GovStack, 2025)。其技术规范将“构建块”（数字身份、数据交换、流程编排）定义为可由领域微服务组成的互操作模块 (GovStack Specification, s.f.)。这是对微服务辩论中微服务一方的机构明确承诺，欧洲数字主权（EuroStack）论点也推动了这一方向 (Bertelsmann Stiftung, 2026)。

<strong>印度</strong> 建立了世界上最大的分层架构示例，却从未在其公共话语中使用过“微服务”这个词：印度堆栈。Aadhaar（生物识别身份，14 亿人注册）、UPI（即时支付，2026 年 4 月单月 223.5 亿笔交易——超过 Visa 全球每天处理的交易量）和 DigiLocker 作为通过开放 API 相互连接的独立层运行，而不是作为单一的政府系统 (Policy Circle, 2026；由 comunicado del gobierno de India 独立证实）。有关数字公共基础设施的学术研究证实，这些架构使用微服务和标准化 API 作为主导的技术模式 (arXiv 2503.08725, 2025)。这是世界上最大的、经过验证的微服务辩论案例——带有一个细微差别，即印度最高法院在 2018 年出于隐私原因限制了 Aadhaar 的私人使用，这表明模块化架构部分是对法律问题而非仅技术问题的回应。

<strong>中国</strong> 正在推行一个名为“政务云”的集中式云计算基础设施，目标是实现县级以上行政单位100%的覆盖，这是“中国数字化”战略的一部分 (National Data Administration / Digital China Wins the Future, 2026)。与欧洲的互操作性模块化建设不同，中国的目标是明确的集中化——预计到2026年，中国数字政府市场将超过2000亿元人民币，其中73%将用于政府云基础设施 (IDC, vía Huawei Cloud, 2026)。从架构上讲，这与欧洲模式相反，尽管两者都使用微服务作为内部技术实现的模式。

技术预算中用于维护现有系统的比例

用于维护现有系统/基础设施而不是构建新系统的技术支出百分比。

美国 — 维护遗留系统的年度百分比（1000 亿美元+）

80%

中国 — 预计用于政府云基础设施的 2000 亿人民币的百分比

73%

Ver los datos

技术预算中用于维护现有系统的比例

Concepto	Valor (%)
美国 — 维护遗留系统的年度百分比（1000 亿美元+）	80%
中国 — 预计用于政府云基础设施的 2000 亿人民币的百分比	73%

四个政府，四种架构立场

每个政府块的立场和关键指标的摘要。

政府	架构立场	关键指标
美国	分散/遗留	~80% 的 1000 亿美元+ 年度预算用于维护遗留系统
欧盟	微服务/明确的构建块	GovStack + EuroStack，数字主权
印度	分层架构（印度堆栈）	2026 年 4 月，UPI 交易 2.235 亿笔
中国	集中式政府云	100% 的县级覆盖，~2000 亿预计

Ver los datos

四个政府，四种架构立场

政府	架构立场	关键指标
美国	分散/遗留	~80% 的 1000 亿美元+ 年度预算用于维护遗留系统
欧盟	微服务/明确的构建块	GovStack + EuroStack，数字主权
印度	分层架构（印度堆栈）	2026 年 4 月，UPI 交易 2.235 亿笔
中国	集中式政府云	100% 的县级覆盖，~2000 亿预计

在我查看的文献中，日本和韩国并没有像这四个国家一样明确的建筑立场——他们通常遵循OCDE其他发达经济体中占主导地位的逐步现代化到云计算的模式，没有像GovStack或India Stack一样的明确宣言。

这个雷达有五个轴：<strong>云基础设施的成熟度</strong>、<strong>模块化/互操作性声明</strong>、<strong>已证明的交易规模</strong>、<strong>国家对私营供应商的主权和控制</strong>以及<strong>内部系统的复杂性和成熟度</strong>(你特别要求优先考虑的轴)。我用相同的权重比较了美国、欧盟、中国和印度，就像我们在范围中定义的那样。

大学所说的话（以及它们尚未知道的事情）

我在美国、欧盟、中国、印度、日本和韩国的大学中寻找了最近的学术研究，发现最诚实的结论是：学术界落后于行业，而不是领先。2025年10月在《未来互联网》杂志上发表的第一个关于云中模块化单体的正式系统性文献综述——发现2020年至2025年5月之间只有15个经过同行评审的初级研究，其主要结论是甚至连对该术语的明确定义都没有达成一致 (Al-Qora'n & Al-Said Ahmad, 2025)。2026年的一项研究，使用2022年至2026年间的67个来源的多声文学综述，得出了类似的结论，即缺乏坚实的实证基础来支持行业已经做出的价值数百万美元的决定 (ResearchGate, 2026)。

2026年，《清华科学与技术》杂志发表了一项关于具有实时要求的工业自动化微服务架构的研究 (Martínez et al., 2026)——这是一个特定的技术角度（工业4.0），而不是中国关于一般辩论的机构立场。在印度、欧洲和美国机构的文献中，模式是重复的：有数十篇关于如何从单体迁移到微服务的论文（使用人工智能自动识别边界、依赖图、机器学习），但很少有研究回答何时应该这样做，并且几乎没有关于企业规模的实际成本的严格可复制的比较。2025年的一篇arXiv论文直接题为“微服务正在死亡”，提议放弃“微服务”这个单位，转而使用通用模块接口——这是一个信号，表明即使在最热衷于分布式的技术社区中，术语本身也开始感到不足 (arXiv 2511.04548, 2025)。

没有人预见到的转折：编排AI的AI选择了模块化单体

这是我认为整个研究中最有趣的发现，它直接回答了我一开始提出的问题：生成式AI是否推动了更多的分布式或更多的集成？

2025年，AI代理行业有自己的二元辩论：网格架构（多个代理之间没有中央协调器的对话）与单个代理工具。Cognition——Devin背后的公司——在2025年6月发表了一份强有力的声明：“不要构建多代理系统” (Cognition, 2025, vía FlowHunt, 2026)。到2026年，这个两极分化的辩论已经在Anthropic、OpenAI和Cognition本身独立采用的单一模式中崩溃：一个拥有完整上下文的编排代理，分派用于隔离任务的短暂子代理，每个子代理都有其自己的新鲜上下文窗口，并且在它们之间没有点对点通道，也没有共享的可变状态 (FlowHunt, 2026)。

再次阅读：<strong>它们之间没有点对点的通道</strong>。这不是微服务网格架构，而是几乎字面意义上的模块化单体的定义：一个具有完全权威的中心进程，按需调用模块，清晰的边界，以及永远不会超出编排器控制的通信。Anthropic 自身记录了其代码代理以相同方式运行：一个具有广泛工具目录的单一代理循环，而不是独立服务的网格 (Anthropic Engineering)。OpenAI 也从 Swarm（已停用）走到了其当前的显式 <em>handoffs</em> SDK，没有网格协调器。

2025 年 12 月，Agent2Agent（A2A）协议加入了 Linux Foundation 的新基金会（专注于人工智能和代理（AAIF）） (Linux Foundation, dic. 2025) 下的 MCP —— 协调基础设施正在标准化，但正在标准化的模式是层次结构，而不是平面网格。如果问题是“人工智能是否推动向单体架构还是微服务？”，那些构建人工智能的人的实际行为（而不是他们的营销话语）给出的答案是：向具有可丢弃子代理的模块化单体架构，而不是向自治微服务的分布式网格。

如何实现带有子代理的模块化单体

关于 AI 代理架构的里程碑时间线。

1. 1992Tanenbaum 告诉 Torvalds，单体内核是一个倒退；Torvalds 回应说，微内核只是将问题转移到了通信上。
2. 2023Amazon Prime Video 将监控服务整合到单体架构，基础设施成本降低 90%。
3. 2025Cognition（Devin）发布“不要构建多代理系统”。
4. 2025在 Linux 基金会下成立 AAIF，MCP 和 Agent2Agent 是锚点项目。
5. 2026CNCF 和 SlashData 报告称，46% 的后端开发人员使用微服务，在整合辩论中。

Ver los datos

如何实现带有子代理的模块化单体

Año	Hecho
1992	Tanenbaum 告诉 Torvalds，单体内核是一个倒退；Torvalds 回应说，微内核只是将问题转移到了通信上。
2023	Amazon Prime Video 将监控服务整合到单体架构，基础设施成本降低 90%。
2025	Cognition（Devin）发布“不要构建多代理系统”。
2025	在 Linux 基金会下成立 AAIF，MCP 和 Agent2Agent 是锚点项目。
2026	CNCF 和 SlashData 报告称，46% 的后端开发人员使用微服务，在整合辩论中。

如果你要在 2026 年启动一个项目，这就是我会做的

没有一个通用答案，但在我审阅的每个严肃来源中，都有一个一致的模式，从 Amazon Prime Video 的案例到学术界的 <em>系统文献综述</em>：

1. <strong>从模块化单体开始，而不是从平面单体或微服务开始。</strong> 从第一条提交开始定义明确的领域边界（领域驱动设计），尽管一切都在一个进程中运行。稍后将一个定义良好的模块提取到一个独立的服务中是廉价的；拆解一个定义不良的微服务网格是非常昂贵的。

2. <strong>仅当你有真正的证据时才提取服务</strong>，而不是依靠直觉：真正独立的扩展需求，物理隔离的监管要求（如支付中的 PCI），或真正不兼容的技术栈（用于机器学习的 Python，用于核心的 Go）。

3. <strong>团队规模比产品规模更重要。</strong> 2025-2026 年文献中反复出现的阈值 —— 50 名或以上工程师的团队，具有清晰的组织边界 —— 是微服务开始证明其协调成本合理的点（逆向应用康威定律）。

4. <strong>如果你要将人工智能代理集成到你的架构中</strong>，Anthropic 和 OpenAI 在生产环境中验证的模式 —— 中央编排器与短暂的隔离子代理 —— 是今天具有最多实证证据的选择，而不是 2024 年讨论的点对点代理网格。

本研究的最终信号灯

正文中 39 个具体引用的信任分布。

39 个引用

• 绿色 — 原始或确认 — 56%
• 黄色 — 单一次要来源 — 41%
• 红色 — 无法核实，透明显示 — 3%

Ver los datos

本研究的最终信号灯

Segmento	Valor
绿色 — 原始或确认	22
黄色 — 单一次要来源	16
红色 — 无法核实，透明显示	1

如果决定不再由人类做出，会改变答案吗？

这是我的真正问题，促使我进行了这项完整的研究：在两三年内，当一个人工智能代理提议你的下一个项目的初始架构时 —— 而且它已经在这样做了，使用建议文件夹结构和模块边界的工具 —— 它是否仍然会推荐“从简单开始，只有在有证据时才分布”？或者人工智能生成和维护分布式代码的便捷性（更多服务，更多 YAML，更大的配置）会因为不再是疲惫的人类来维护它而倾向于复杂性？

你们看到了什么：你们的代码副驾驶是否将你们推向更简单或更多的活动部件？

Esteban Rey
X: @Kilowatto
LinkedIn: https://www.linkedin.com/in/kilowatto
Wikidata: https://www.wikidata.org/wiki/Q140672978