如果你最近一年在用 Cursor、Claude Code 或者任何 AI 编程工具，你大概率经历过这样一个时刻：AI 在一个小文件里写得又快又好，但当你让它改一个涉及三四个模块交互的功能时，它开始胡说八道——生成的代码语法完美，却完全搞错了模块之间的依赖关系，甚至创造出原本不存在的循环引用。
这不是 AI 不够聪明。这是它看不到全貌。
2025 年 2 月，Andrej Karpathy 发了一条获得 450 万浏览的帖子，发明了"Vibe Coding"这个词——不看 diff，不读代码，完全信任 AI 的输出，用感觉来编程。一年后，他本人宣布 Vibe Coding "已经过时了"，转而提出"agentic engineering"（智能体工程）。
从"信任氛围"到"回归工程"，这个转向背后的原因其实很朴素：大家逐渐意识到，AI 写代码的速度从来不是瓶颈，真正的瓶颈是 AI 能"看到"多少上下文。 你给它一个函数的范围，它写得比大多数人好；你给它一个系统的范围，它就开始迷路了。
这让我重新审视了一个老朋友——C4 Model。这套诞生于 2006 年的架构可视化方法，在过去近二十年里一直被理解为"一种画架构图的方式"。但如果换一个角度看，它的四层逐级分解机制，本质上就是一套上下文管理协议——而这恰好是当前 AI 编程最缺、也最需要的东西。
AI 写代码的真正瓶颈不是能力，是视野
为什么 AI 在小范围内表现优秀，在大范围内就容易出错？
原因在于一个硬性限制：上下文窗口。目前前沿模型的上下文窗口大约是 100 到 200 万 token，听起来很大，但一个中等规模的企业代码库轻松就能超过这个上限。你不可能把整个系统一股脑塞进去。
但问题不只是"装不下"。即使装得下，信息量太大也会导致注意力稀释——模型在海量代码中找到关键约束的能力会急剧下降。在企业环境中，一个常见的现象是：AI 补全的代码在本地能编译通过，但违反了代码库其他地方的约定和模式。代码"对"了，但放在系统里是"错"的。
卡内基梅隆大学对 800 多个 GitHub 仓库的追踪研究量化了这个问题：采用 AI 辅助编程后，新增代码行数暴涨了 281%，但代码复杂度和静态分析警告也在持续攀升，而且没有随时间改善。AI 很擅长生成"局部最优解"，但局部最优的叠加往往是全局的混乱。
Google 的 DORA 报告对此有一个精准的总结：AI 是现有工程条件的放大器。 架构清晰的团队用 AI 如虎添翼，架构混乱的团队用 AI 越跑越偏。区别不在于 AI 工具本身，而在于团队能否给 AI 提供正确的上下文边界。
那么问题就变成了：怎样才能系统性地给 AI 提供"刚好够用"的上下文？
"改一次没问题，连续改就崩了"
上面说的还只是"单次任务"的表现。真实的软件开发不是一次性的——你要持续迭代、持续维护。那 AI 在长期维护场景下表现如何？
2026 年 3 月，阿里巴巴联合中山大学发布了 SWE-CI——全球首个评估 AI 在"长期代码维护"中表现的基准。和之前的 SWE-bench 不同，SWE-bench 评估的是"给一个 Issue，能不能一次性修好"，本质上是快照式的。而 SWE-CI 评估的是：让 AI 从一个起始版本出发，经过数十轮迭代，逐步演进到目标版本——在这个过程中，它能不能持续维护好代码质量？
这 100 个任务中，每个平均跨越 233 天、71 个连续 commit 的真实演进历史。这不是"修一个 bug"的难度，这是"维护一个活着的项目半年以上"的难度。
结果相当残酷。SWE-CI 引入了"零回归率"这个指标——在整个维护过程中，之前通过的测试一个都没被搞挂的比例。大多数模型的零回归率低于 0.25。 也就是说，在四分之三以上的任务里，AI 在迭代过程中至少搞坏了一个之前好好的功能。只有 Claude Opus 系列超过了 0.5——也仅仅是刚过半。
这个数据指向一个核心矛盾：AI 可以写对当前这一步的代码，但它不知道这一步的决策会怎样影响下一步。 如果第三轮迭代为了快速通过测试而走了一条捷径，到第八轮的时候这个捷径可能已经变成了无法绕过的技术债。AI 缺乏的不是编码能力，而是"当前决策对未来影响"的全局视角。
但 SWE-CI 里有一个设计细节特别值得注意：它的评估框架采用了**"架构师-程序员"双智能体协议**。架构师智能体负责审视全局，分析当前代码和目标之间的差距，产出高层需求文档；程序员智能体负责根据需求文档修改代码。架构师看的是"系统还差什么"，程序员看的是"这段代码怎么改"。
这个设计本身就在暗示一个答案：要让 AI 做好长期维护，你需要把"看全局"和"写局部"分开——而这恰好就是 C4 Model 的层级分解在做的事。
C4 Model 的四层分解：一种天然的上下文分片策略
C4 Model 由 Simon Brown 在 2006–2011 年间创建，将软件架构分为四个层级：
Level 1 — System Context（系统上下文）： 你的系统和外部世界的关系。哪些用户在用它？它依赖哪些外部系统？一张图上通常只有 5–10 个元素。
Level 2 — Container（容器）： 你的系统内部由哪些可独立部署的单元组成？Web 应用、API 服务、数据库、消息队列……回答"大的积木块有哪些"。
Level 3 — Component（组件）： 某个容器内部由哪些主要组件构成？Controller、Service、Repository……回答"这块积木里的齿轮是什么"。
Level 4 — Code（代码）： 某个组件的具体实现。
Simon Brown 把这个比喻为"代码的 Google 地图"——从卫星视角看城市布局，一路放大到某条街道的门牌号。每次放大，你的视野在缩小，但清晰度在提高。
现在，请从大模型的视角重新理解这四层：
每下钻一层，需要放入上下文窗口的信息量就大幅减少。
在 Level 1，AI 只需要理解"这个系统和外部世界怎么交互"——几百 token 就够了。到 Level 2，它关注的是"这个系统内部有哪些运行单元、它们怎么通信"——几千 token。到 Level 3，上下文收窄到某个容器内部的组件划分。到 Level 4，就是一个组件内部的代码——这个粒度几乎在任何模型的上下文窗口内都能舒适容纳。
这意味着 C4 Model 的层级结构天然就是一套上下文分片策略。你不需要把整个百万行代码库塞进上下文窗口——你只需要根据当前任务所在的层级，给 AI 那一层的上下文就好。Level 2 的任务就给 Level 2 的信息，Level 3 的任务就给 Level 3 的信息。每一层的信息量都是可控的。
回到 SWE-CI 的"架构师-程序员"双智能体模式——你会发现它本质上就是 C4 Model 分层的一个运行时实例。架构师在 Level 1–2 工作：它看的是整个代码库的结构性差距，产出的是高层需求。程序员在 Level 3–4 工作：它看的是某个具体模块怎么改。两者之间传递的需求文档，就是不同层级之间的"上下文桥梁"。
SWE-CI 论文里有一个刻意的设计约束也值得玩味：它要求架构师每轮最多只产出五条最紧急的需求，避免一次性把所有问题都抛给程序员。这不就是 C4 Model 的哲学吗？每一层只展示那一层该关心的东西，不多也不少。
从理论到实践：这个机制已经在被验证了
如果你用过 Claude Code 的 subagent 机制，你可能已经在"体感"上理解了这个概念，只是没有用 C4 Model 的语言来描述它。
Claude Code 在处理复杂任务时，会将主任务拆解为子任务，每个子任务交给一个 subagent 处理。主 agent 持有全局上下文（对应 Level 1–2 的视角），subagent 只接收完成其特定任务所需的局部上下文（对应 Level 3–4 的视角）。这本质上就是 C4 Model 式的层级分解在 AI 工作流中的运行时投影。
区别在于，目前这个分解大多是隐式的、由 AI 自行判断的，而不是基于一份显式的架构模型。但显式化正在发生：
Structurizr 的 MCP Server 已经让 Claude Desktop 可以读写 C4 架构模型，把架构约束作为上下文注入代码生成对话。LikeC4 通过 API 把架构上下文暴露给 AI agent。今年 2 月发布的 Claude Code C4 Skill 能扫描任意代码库自动生成 C4 Model——开发者用它来理解一个 Vibe Coding 产出的项目，几分钟就获得了原本需要数小时代码浏览才能拼凑的架构认知。
这些工具做的事情其实是同一件：把 C4 Model 变成 AI 和人类之间的"共享地图"。 AI 用它来获取上下文边界——我该关注什么、不该碰什么；人类用它来验证 AI 的输出——生成的代码是否落在了架构的正确位置上。
Ian Bull 有一句话把这个观点推到了极致："架构就是提示词。代码的结构是你给 AI 的最重要指令。"
架构文档的读者变了
这里有一个容易被忽视的范式转变。
"代码即文档"曾经是一种流行的理念——好的代码应该自解释，额外的文档是多余的。这在人类开发者之间大致成立：一个有经验的工程师读几个关键文件就能拼出系统的心智模型。
但 AI 做不到这一点。一个命名良好的函数能告诉 AI 它做什么，但无法告诉 AI 它为什么在这里、它和其他模块的边界在哪、以及它不应该做什么。AI 无法仅从实现推断架构意图。
这意味着显式的架构描述——C4 图、领域词汇表、接口契约——正在从"有了更好"变成"不可或缺"。而且它们的首要消费者可能不再是人类，而是 AI。人类读到它们反而成了附带的好处。
回想 SWE-CI 的发现：AI 在长期迭代中最大的问题不是"写不出新功能"，而是"写新功能的同时搞坏了旧功能"——也就是回归。回归的本质是什么？是 AI 在改某个局部的时候，不知道这个改动会影响到系统的哪些其他部分。如果它能在动手之前先"读"一份 C4 Model，知道当前组件和哪些组件有依赖关系、它们之间的契约是什么，回归的概率就会显著降低。
这不能杜绝所有回归，但把"是否会影响其他模块"从人脑中的隐性判断变成了可以被工具检查的显式约束。
写在最后
Martin Fowler 有一个比喻很到位：AI 的产出像一个非常高产但你完全不能盲目信赖的协作者提交的 PR。你不能不用它——速度确实惊人；你也不能不审查它——它不理解全局约束。
你需要一种机制，在利用 AI 速度的同时，把它约束在正确的上下文范围内。C4 Model 的四层分解恰好提供了这种机制。它不需要学习新的形式化语言，不需要数月的建模工程。它的核心理念简单到可以在一张餐巾纸上画清楚：任何复杂系统都可以从外到内、逐层分解为更小的上下文片段。
这个理念在 AI 时代之前是架构沟通的最佳实践。在 AI 时代，它变成了让 AI 正确工作的基础设施。
当越来越多的"写代码"工作被 AI 接管，工程师的核心价值正在从"我能写出这段代码"迁移到"我知道这段代码应该在哪里、为什么在那里、以及它的边界是什么"。这种能力——理解系统的层次结构、管理上下文的边界——就是架构能力。
C4 Model 可能是你现在最值得投入学习的架构工具。不是因为它新，恰恰相反，而是因为 AI 让我们第一次如此清晰地看到了它一直以来的价值所在。
在一个代码可以被 Vibe Coding 出来的时代，真正稀缺的不是代码，而是理解代码应该在哪里、为什么在那里的能力。
本文首发于公众号 [架构余绪]，转载请注明出处。
