在探讨 ”AI 是如何让架构腐烂“ 之前，我们先回到最根本的问题，架构是什么？
架构（Software Architecture）本质上是关于系统的重大决定，是软件系统的“骨架”和“交通规则”。
如果把开发软件比作建造一座城市，那么写代码是砌砖，而架构就是城市规划。
我们可以从以下三个核心维度来理解：
1. 它是“难以改变的决定”（The Hard Decisions）
Martin Fowler 曾给出一个精辟的定义：“架构是那些你在项目初期就渴望做对、且后续更改成本极其高昂的事情。”
- 在人类开发中： 选定关系型数据库还是图数据库、采用微服务还是单体架构。一旦选错，后期重构可能要伤筋动骨。
- 在AI视角下： AI 最擅长的是“砌砖”（写具体函数），但它很少会有“这些决定以后改不动”的概念。
2. 它是系统的“骨架”与“边界”（Structure & Boundaries）
架构规定了代码应该躺在什么地方，组件之间如何说话。它把一个复杂的、无法塞进人脑的大系统，切分成一个个高内聚、低耦合的小方块。
- 高内聚： 各司其职。算账的代码只管算账，渲染界面的代码只管界面。
- 低耦合： 接口隔离。哪怕算账的逻辑全改了，负责渲染界面的代码连一个标点符号都不用动。
3. 它是非功能性需求（Non-Functional Requirements）的保障
用户看到的只是“功能”（点击按钮能下单），但架构承载的是用户看不见的“能力”：
- 扩展性（Scalability）： 用户从 100 人变成 100 万人时，系统会不会崩？
- 可维护性（Maintainability）： 下个月要加个新功能，需要改动 1 个文件还是 100 个文件？
- 健壮性（Resilience）： 某一个第三方接口挂了，整个系统是直接瘫痪，还是降级运行？
在人类的世界里，我们通常凭借经验和对未来的预测，去小心翼翼地平衡这些“难以改变的决定”。
但当我们将这个任务完全交给 AI 时，奇妙（甚至灾难）的事情就发生了——因为 AI 是一种“没有明天、没有全局感、只有当下”的生物。它在理解“架构”这两个字时，天然带着致命的缺陷。
腐败的架构
我们将完全由 AI 进行的项目开发，拉伸到整个项目的生命周期（从初期到中后期）来看，就会发现“架构腐烂”并不是突然发生的，而是一场包装在“高效”外表下的慢性自杀。
更残酷的是，为什么人类很难驾驭这个情况？因为 AI 的开发节奏和人类的认知带宽之间，存在着天然的“降维打击”。
我们可以把全 AI 项目的生命周期，拆解为四个阶段来看这场“灾难”是如何演进的：
阶段一：项目初期（蜜月期）——“伪造的完美”
在项目刚开始的头几天，就好像是在做梦。
- AI 的表现： 你给它一个点子，它能在 10 分钟内帮你搭好框架、建好数据库结构，甚至连前端 UI 都画得有模有样。这一阶段代码量少，完全在 AI 的上下文窗口内，架构看起来极其标准（MVC、DDD 有模有样）。
- 人类的错觉： 人类在这个阶段会产生严重的自满，误以为自己成了“超级架构师”。人类开始疯狂下指令加功能，完全放松了对底层代码的审查（Code Review）。
- 腐烂的种子： AI 此时做出的所有架构决定，都是基于它训练集里的“大众模板”。它并没有**“为这个项目的未来三年做规划”**的能力。它不知道你未来是要做高并发，还是要做多租户隔离，它只是选了阻力最小的、能跑通 Demo 的那条路。
阶段二：迭代中期（异化期）——“勤奋的瞎子在砌墙”
随着功能不断堆叠，项目规模扩大，真正的架构腐烂正式开始。
- AI 的表现： AI 开始面临上下文窗口限制（Context Window Limit）。由于代码库太大，AI 无法同时读取所有文件。当它要加一个新功能时，它就像一个瞎子，只能摸到系统的一根手指。为了完成任务，它不再遵守初期的架构规范，开始在不同的地方复制粘贴相似的逻辑（Duplication 暴增 81%）。
为什么人类很难驾驭？
- 审查速度跟不上生成速度： 人类写一个功能要半天，AI 只需要 5 秒。AI 啪的一下生成了 500 行代码，里面夹杂了 3 个轻微破坏架构的“小改动”。人类要看懂这 500 行代码需要 20 分钟。人类偷懒了，直接点击了“合并”。
- 温水煮青蛙： 架构的崩塌不是断崖式的。今天这里多一个冗余函数，明天那里多一条直接读数据库的越权指令。系统依然能跑通，人类根本察觉不到承重墙正在被一点点掏空。
阶段三：项目后期（失控期）——“屎山之上的巴别塔”
- AI 的表现：此时的代码库已经变成了由 AI 自己编织的“赛博迷宫”。由于前期的逻辑漂移和重复代码太多，AI 自己也开始迷糊了。你让它修复 Bug A，它生成的代码会诡异地触发 Bug B、C、D。它开始陷入“补丁套补丁”的死循环。
这个时候，理解成本超过了重新开发的成本：由于代码不是人类自己写的，且缺乏统一的、人类可读的架构逻辑，此时的代码库对人类来说就是一本“外星天书”。人类已经完全失去了对项目的全局心智模型（Mental Model）。
“AI 恐惧症”：人类甚至不敢自己去改一行代码，因为不知道这行代码在几百个由 AI 复制粘贴的文件里有哪些隐式依赖。人类只能继续依赖 AI 去修，而 AI 只能堆更多、更脏的补丁。
阶段四：维护期（死亡期）——“赛博废墟与技术破产”
- 最终结局：当我们说“要把系统的核心底座升级”，或者“要接入一个全新的大型业务”时，整个全 AI 项目彻底暴毙。因为无论是 AI 还是人类，都无法在不让整个系统雪崩的前提下，动它一根毫毛了。这个项目变成了一个“只能看、能勉强跑、但绝对不能改”的赛博废墟。
- 讽刺的真相：人类本想用 AI 节约成本，结果因为架构腐烂，最后不得不把所有代码全盘推翻，彻底重写。
综合 Gartner、MIT (NANDA 项目)、RAND Corporation 以及 S&P Global 针对软件工程和 GenAI 开发项目的跟踪数据，全 AI 开发项目的死亡率呈现出极其残酷的“倒三角沉没曲线”：
- 放弃率陡增（S&P Global / Gartner 数据）
- S&P Global Market Intelligence 的数据显示：放弃绝大部分 AI 代码/工程项目的公司比例，从前一年的 17% 飙升至现在的 42%。
- IDC 的专项调研指出：在全 AI 驱动的自主智能体（AI Agent）项目中，高达 88% 的 Agent Pilot（试点项目）永远无法进入实际生产环境（Never reach production）。
- “95% 无经济回报”现象（MIT 2025/2026 研究）
- MIT NANDA 项目在深入分析企业级 GenAI 代码落地时发现：95% 的 GenAI 独立试点或完全无人类把关的项目，在利润表（P&L）上带来了 0 甚至负向的回报。
- 绝大多数项目在生成了数万行代码后，由于缺乏底层数据治理和模块抽象，陷入了“修改 Bug 引入更多新 Bug”的卡死状态，最终被迫全盘推翻。
我们该怎么利用 AI？
SonarSource 2026 年的报告显示，38% 的开发者表示审查 AI 代码比审查人类同伴的代码更费劲。当 AI 的代码产出占比超过 80%–90% 时，人类审查的速度会彻底跟不上 AI 吐出代码的速度，出现认知超载（Cognitive Overload），导致审查流程形同虚设。
而在理想的团队协作模型中，人类与 AI 的工作量分配应当是深度不对称的：
┌─────────────────────────────────────────────────────────┐
│ 人类 (Human Architect) │
│ [30% 认知工作量] │
│ - 业务域模型设计 (Domain Modeling) │
│ - 边界与契约定义 (API/Schema Contracts) │
│ - 破坏性/跨模块重构 (Legacy Refactoring) │
│ - 对抗性代码审查 (Adversarial Code Review) │
└────────────────────────────┬────────────────────────────┘
│ (约束与 prompt 上下文)
▼
┌─────────────────────────────────────────────────────────┐
│ AI (AI Coding Agent) │
│ [70% 执行工作量] │
│ - 样板代码生成 (Boilerplate & CRUD) │
│ - 单元测试与边缘用例补全 (Unit Test Generation) │
│ - 局部函数与叶子节点实现 (Leaf-node implementation) │
│ - 静态文档与注释撰写 (Documentation) │
└─────────────────────────────────────────────────────────┘
一、建立 AI 对抗性 Pipeline（角色分离）
不要使用同一个 AI 上下文同时处理业务实现与代码审查。必须在生产管线中建立双 Agent 隔离机制：
- 执行者（Executor Agent）： 专注于叶子节点逻辑与业务接口，快速高效产出。
- 审查者（Reviewer Agent）： 绝对不参与代码编写，专门寻找违反架构规范的代码，检查跨层调用、隐式
try-catch吞报错、死代码与硬编码。 - 人类终审 Merge： 结合 CI/CD 自动化静态检测（ESLint / ArchUnit），对重复率或依赖图谱超标的提交一键拒收。
二、 动态演进的“架构契约”（Dynamic Architecture-as-Code）
CLAUDE.md 或 .cursorrules 等规则配置文件绝不是一开始写好就一成不变的石碑，而是随着项目迭代动态演进的活文档。
- 初期： 保持轻量（30 行以内），只划定目录职责与禁止
any等全局底线。 - 中期（事件驱动）： 采用“踩坑 - 提炼 - 固化”闭环。每次 Code Review 发现 AI 破坏架构（如在组件层写了 50 行数据清洗 logic），立即追加一条具体规则（如：“所有数据清洗必须提至
utils/”）。 - 后期（规则下沉与瘦身）： 稳定下来的自然语言规则应转化为硬性 CI/Linter 脚本；规则文件按子目录模块化加载（Modular Rules），防止上下文过长导致 AI 产生注意力漂移。
三、 关键节点的“Human-in-the-Loop”控制阀
人类必须死守三个绝对不可让渡给 AI 的“生死门”：
| 关键节点 | AI 负责什么 | 人类必须把控什么 |
|---|---|---|
| 1. 领域建模与数据表设计 | 根据需求草拟 DDL / Type 定义 | 审核实体关系、主外键索引与数据边界 |
| 2. 模块 API 与契约 | 生成 Swagger 规范与样板 Response | 划定模块调用边界，杜绝循环依赖 |
| 3. PR 代码合并 | 自动生成 ChangeLog 与 PR 摘要 | 进行对抗性审查，严防隐式逻辑风险 |
最后
AI 技术的爆发，并没有让“软件架构”这一经典学科走向衰亡，反而将其推向了前所未有的重要高度。
- 代码生成越低成本，架构设计就越显昂贵。 AI 赋予了我们以前所未有的速度“砌砖”的能力，但如何规划城市的道路与承重结构，依然取决于人类架构师的远见与洞察。
- 摆脱“全自动”幻觉，走向“高精尖”协同。 试图完全脱离人类监管去构建复杂系统，无异于在沙滩上建造摩天大楼。AI 应当是极其高效的“超级执行者”，而人类则必须牢牢守住“架构掌控者”与“质量守门人”的核心角色。
在 AI 编码时代，衡量一个软件团队终极竞争力的，不再是写了多少行代码，而是在面对 AI 极其庞大的代码吞吐量时，能否保持系统的简洁性、边界的清晰度以及架构的长期可演进性。
