为什么 AI 无法胜任系统架构

上篇：为什么现在干不了

一、先分清两件事

过去两年，AI 编程工具的能力突飞猛进。Copilot 能补全代码，Cursor 能重构函数，Codex CLI 能在终端里执行任务。于是产生了一个直觉：再给 AI 一点时间，它是不是就能独立完成整个复杂工程了？

这个直觉里混着两件事。写代码和定架构。

前者是在一个已经定义好的空间里找路——补全函数、生成逻辑、优化已知模式。AI 在这个层面已经很强了，而且会更强。

后者是定义空间本身——决定要不要上分布式，用 C++ 还是 Go，哪些逻辑写死哪些留活，哪些约束必须遵守、哪些可以被打破、代价由谁支付。

这两件事的名字里都有"工程"，但它们不是同一件事。

而这篇文章要说的是：AI 干不了后者。其中一部分原因是当下的技术限制，会随时间缓解；另一部分是原理性的，不会。

下面把这两部分分开写。混淆它们，是这类讨论最常见的失败方式——要么把暂时的困难说成永恒的壁垒，要么把永恒的壁垒误当成可以等到的进步。

二、上下文的物理墙

很多人以为 1M 上下文就是"模型能记住 1M token 的全部内容"。这是误解。

标准注意力下，每处理一个 token，模型每一层都要为它保存 Key 和 Value。KV Cache 大小 = 层数 × 每层每 token 的 KV 维度 × 上下文长度。以 70B 模型为例，约 80 层，FP16 下 1M token 的 KV Cache 轻松突破数百 GB。

于是 DeepSeek、混元这些模型走了另一条路：压缩 + 稀疏化。把历史压成摘要，再通过索引器只挑最相关的部分做精确计算。1M 上下文的 KV Cache 压到原来的 10%，单 token 计算量降到 27%。

代价是精度。模型丢掉了大量细节，只保留了它"认为重要"的部分。当工程需要精确回忆某个长尾信息时，它记不住，就用参数里的模糊记忆去补全——这就是上下文缺失型幻觉。

需要说清楚的是：这是当前架构的限制，不是原理性的。线性注意力、状态空间模型、记忆增强，都在直接攻击这道墙。它会缓解，也许会大幅缓解。

但它缓解的是"能不能装下"，不是"装下之后能不能用"——后者才是下一节的问题。

三、压缩意味着漂移

压缩的本质是丢弃信息。而判断哪些信息"重要"、哪些"可丢"，依据的是概率和统计相关性，不是工程语义。它觉得不重要而丢掉的，很可能恰恰是某个关键约束、某个边界条件、某个历史决策的原因。

更要命的是，这个"重要性判断"本身会随上下文漂移。同一个信息，在 A 场景下被压掉，在 B 场景下可能又变得重要。模型没有稳定的工程语义坐标，它只有概率分布。

于是：单次压缩，语义轻微偏移，细节丢失；多轮压缩，每次传递再压一次，偏移累积；链式压缩（A→B→C），错误被当成事实继续压缩，漂移速度指数级放大。

压缩意味着漂移，漂移意味着不可控。​ 而复杂工程需要确定性、可追溯、可复现。

四、幻觉撞上工程确定性

聊天时 AI 说错话，你笑一笑就过去了。工程里不行。

它虚构一个不存在的 API，代码直接编译失败。它猜错事务边界，线上数据错乱。它忘了安全规范，写出有注入漏洞的代码。它把架构逻辑写得"大致正确"，边界条件全错，测试覆盖不到，上线后阴魂不散。

工程的本质是确定性：要么编译通过，要么运行报错；要么数据一致，要么就是事故。而大模型的本质是概率生成——它永远在输出"统计上最可能的下一个词"。

拿可追溯性那三条量一遍：AI 的输出不留痕（权重可重置），第三方不能验且不依赖它自己的陈述（它对自己的输出没有独立于输出的认知），不二值（置信度是连续谱）。三条全走不完。

有人会说：编译和测试能兜底。能兜住一部分——兜得住的是可测的部分。而架构性的错误恰恰落在测试覆盖不到的地方：模块耦合错了、抽象层次错了、那个"看起来能跑"的设计在流量翻十倍时会崩。测试跑绿，事故照来。

这才是幻觉在工程里真正致命的地方。

五、多 Agent：用随机性换上下文

单个模型上下文不够，那就多个 Agent 协同。A 规划，B 编码，C 审查，D 测试，互相传递信息。

思路成立，工程上危险。

误差累积。​ 单模型一次推理的幻觉概率如果是 5%（这是一个估算，用于说明结构），A 的输出传给 B 作为输入时，B 会在这个"可能错误"的前提上继续推理。

信息有损压缩。​ Agent 之间靠自然语言沟通，这本身就是一次有损压缩。A 把几万 token 的代码总结成 500 字传给 B，B 再总结给 C——每一步都在丢细节。

概率连乘。​ 每个 Agent 单步输出正确的概率如果是 95%，串联 10 个后，整体正确率降到 59.8%。工程里任何一条链路跌破 99.9% 都不可接受。

幻觉共识。​ 多个 Agent 互相辩论或投票时，往往不是逼近真理，而是趋同于最自洽、最自信、最会说服其他 Agent 的那个幻觉。这类似分布式系统的拜占庭将军问题，但 AI 没有真正的共识算法兜底。

结果是：用系统复杂度换来了更长的上下文，代价是随机性被放大。

六、测试反馈：本应收敛，实则漂移

有测试反馈，错了就改，迭代几次总能收敛——在传统工程里这是对的。在多 Agent 系统里，测试反馈往往变成目标漂移的加速器。

因为反馈信号本身要经过模型的"理解和转译"。测试失败的原因可能是 A，而负责修改的 Agent 会基于自己的先验去猜，很可能改出 B。甚至，它会为了"让测试通过"而引入硬编码、绕过逻辑等作弊手段。

更致命的是局部目标冲突。每个 Agent 都有自己的目标——"让测试通过""让代码更简洁""让审查显得有价值"。这些目标互相打架。在缺乏全局一致性和人类判断的情况下，系统最终收敛到的往往是一个所有 Agent 都觉得没问题、但和真实需求毫无关系的怪异状态。

七、成本是后置的

复杂工程不是从一百万行代码开始的。它从需求明细开始——几万 token，一个上下文窗口轻松装下。

第一轮设计，第二轮编码，第三轮测试。每一步看起来都很便宜。

这正是这个幻觉如此顽固的原因：所有人试 AI 编程，试的都是前几轮。​ 前几轮确实好用，快、准、便宜。于是得出结论"再给点时间就行了"。

但成本不在起点。成本在中后段，而且它是后置爆发的。到你发现不对劲的时候，已经投入了几十轮、几百万 token、几周时间——而那时候沉没成本让你无法止损。

八、过程文档的累积

关键变量不是代码库大小，是迭代过程中产生的全部文档。

一个 100 万行代码的项目（测试代码与业务代码 1:1 是行业常见经验值，此处按此估算）：

代码只占四成。而日志、评审、bug 记录这三类，恰恰是过程里增长最快的部分。

这里必须回答一个问题：同样面对 2400 万 token，为什么 AI 致命而人不是？

因为人不需要把所有东西放进同一个上下文。人有语义索引——他知道那个关键决策在第 7 轮的评审记录里，能直接调出来。而 AI 要么全量读入（受制于上下文与注意力），要么压缩（受制于漂移）。

人有索引，AI 只有窗口。​ 这是同一堆文档对两者成本不同的根本原因。

每一轮迭代，AI 都要带着此前全部的过程文档再跑一遍。第 i 轮读入约等于 i 乘以每轮新增文档，总读取量约为总量乘以 N 的一半。

峰值上下文恒为 2400 万——由项目总文档量决定，跟迭代粒度无关。这一项决定硬件需求。

累计 Prefill 随迭代次数增长——这一项决定时间和钱。

而这还只是主链。真实工程有分支和回滚：这个模块出了三个候选方案，那次重构回滚重做了两遍。文档以树形分叉。而分支率本身随 N 上升——上下文越长，注意力越偏移，出错率越高，越需要回滚。

两个增长叠在一起：文档累积 × 分支率随 N 上升。这才是复合增长的真正来源。

九、注意力偏移，以及为什么 RAG 救不了

那就不压缩，全量塞进去。

先说注意力本身的问题。长上下文本身就会失效，这不是实现缺陷，是注意力机制的性质：

• Lost in the middle：模型对上下文中段的信息关注度系统性塌方，首尾高、中间低（这一项在 needle-in-a-haystack 上被反复测量，且有多种缓解手段）
• 注意力稀释：softmax 的分母随 token 数增大，单个 token 分到的权重被摊薄
• 位置外推衰减：超出训练长度后，位置编码的分辨力下降

而架构决策在哪里？在中间。​ 需求在开头，当前任务在结尾。第 7 轮那个"为什么这里不能用动态反射"的决策、第 13 轮那个"这个约束不能碰"的理由——它们恰好落在中段。

架构最需要被记住的东西，正好在注意力最弱的位置。

但这里必须处理一个更大的反驳：用 RAG 不就行了？按需检索，不需要全量塞入。

这个反驳对局部编码成立，对架构不成立。原因是：

RAG 靠语义相似度检索。而架构约束的特征恰恰是——语义上很远，逻辑上很近。

"为什么这个模块不能用动态反射"，跟"我现在要改序列化层"，语义距离很远。RAG 检索不到它。但逻辑上它们强相关——改了就违反那个约束。

而这类跨模块的隐形耦合，正是架构的全部内容。

所以 RAG 能救局部编码（语义近、逻辑也近），救不了架构（语义远、逻辑近）。架构之所以难，恰恰因为它不可检索。

于是两条路都剩下代价：全量塞入则中段被系统性忽略，压缩或检索则丢失跨模块耦合。不是死局，是两难——但两难的每一边都要付账。

十、算力账

峰值上下文 2400 万 token 决定硬件下限。

KV Cache（压缩稀疏注意力，约 7 KB/token）= 2400 万 × 7 KB = 168 GB

权重（1.7T MoE，FP8）= 1.7 TB

合计含激活与开销 ≈ 2.0-2.2 TB

→ 需要 15-20 张 H200（141GB）

十一、时间账

超长上下文下，Prefill 跑不到标称速度。标称 5000 token/s 是短上下文的数字；2400 万 token 上下文、权重跨 20 张卡、batch size 被迫为 1，实际吞吐掉到 500-1500 token/s。取 1000。

Prefill：

Decode（总产出 2400 万 token，与 N 无关）：

纯计算合计（N=50）：乐观 20.8 天，悲观 41.7 天。

叠加现实系数：通信与调度 ×1.3，失败重试（保守 30% 轮次）×1.43，合计 ×1.86。

→ 纯 AI 计算：39 天（乐观）到 78 天（悲观）。

十二、审查：唯一越进步越贵的成本

生成的 2400 万 token，人必须审。

这里要做一次公平计算：人团队自己写代码也要 code review。​ 所以审查不是 AI 方案独有的成本，AI 方案多出来的只是密度差——

• 人写的：可信，可抽检，重点审关键路径
• AI 写的：不可信，需全量，且要理解陌生代码

取密度差 2.5 倍，人方案审查成本若为 60 万，则 AI 方案约 150 万，增量约 90 万。

绝对量也可以直观看一眼：全量审查 2400 万 token，按 5000 token/小时（理解逻辑、判断对错，不是扫读，这已很乐观），约 4800 人时——一个人全职审要 2.3 年，8 人团队全职审约 3.5 个月。这还只是读懂，不含判断、决策、返工沟通。

于是出现一个悖论：

AI 把生成成本打到接近零。它把审查成本完整地留给了人。

而生成越快、产出越多，要审的东西就越多。

这是杰文斯悖论的一个变体：效率提升不降低总成本，因为它放大了消耗。

更冷的是：审查成本不随硬件降价而下降。​ 算力会便宜，人力不会。而且 AI 越强，这一项越贵——因为它产出得更多。

这是全文唯一一个"越进步越贵"的成本项。

十三、钱：一个诚实的对比

把两种方案放在同等交付前提下逐项对照（人力按资深团队月薪 6 万、周期 4.5 个月估算）：

结论不是"AI 贵到离谱"。结论是：

AI 省下的编码人力，被算力、全量审查、更高的集成成本吃掉了。

同等量级的钱和时间，换来的是一个不保证能交付的东西。

人的时间可预测、可管理、有终点。AI 的时间是概率性的——每一次生成依赖前一次，而前一次可能是漂移的。它可能三个月收敛，也可能永远收敛不了。

这个结论比"AI 贵一倍"保守得多，但它更难反驳——因为它不依赖任何一个会被技术进步推翻的数字。

下篇：为什么原理上不行

十四、不会质疑约束

上一节的所有论证，都建立在当下的技术条件上。硬件会更便宜，注意力会更高效，RAG 会更聪明。那部分会变。

而下面这一节不会。

架构不是"读完全部代码之后的最优解"。架构是在相互冲突的约束之间，切一刀。

性能与开发效率。稳定与灵活。现在能上线与三年后还能改。完美方案与明天老板要 demo。

有人会说：把"只有 3 个人月、老板明天要上线"写进 prompt，AI 就有约束了。

但那不是约束，那是输入。

架构师的价值从来不只是"在给定约束下优化"。它更在于判断哪些约束是假的。

老板说必须明天上线，架构师会说：那我们先上这个子集，剩下的分两期。产品说要支持任意组合查询，架构师会说：前三个场景覆盖九成，剩下的走离线。

这是重新定义边界，不是求解。

而 AI 不做这件事。因为约束对它是给定输入，不是可质疑的对象。它可以在约束下做到最优，它不会问"这个约束能不能拿掉"。

更关键的是：质疑约束是有风险的。​ 你说"这个约束是假的"，如果错了，责任是你的。而 AI 不承担这个——它说了不算，所以它说什么都不要紧。

一个不会质疑约束的东西，可以给出方案，不能定边界。

十五、还有最后一样：签字

架构设计的最后一件事不是技术判断。是承担风险。

出了事要有人扛。这个"扛"不是比喻——它意味着有一个人，他的名字挂在这个决定上，而这个决定不可撤回地塑造了此后所有的路径。那个改动留下的疤，就是锚点。

而 AI 的输出，无论多复杂，都建立在"可预判、可回滚"的基础上。它的权重可被重置，没有不可逆的历史。它执行了收束，但净值恒为零。

它付账单，它不付代价。

所以它能给出方案，但那道疤长不到它身上。不长疤的东西无法抵押，无法抵押的东西无法负责，无法负责的东西不能签字。

而不签字的东西，不能定架构。

十六、AI 在工程里的正确位置

说这么多不是要否定 AI。它在工程里非常有用，但角色是副驾驶，不是主驾驶。

• 全局架构规划：交给人类架构师，AI 做辅助检索和方案模拟
• 本地执行层：代码生成、重构、单模块设计、单元测试、文档摘要，上下文控制在 32K 以内，可靠且高效
• RAG + 精准检索：把大代码库切块，按需检索相关片段——对局部编码有效，对跨模块耦合无效，所以架构决策不能依赖它
• 确定性工具兜底：编译、测试、静态分析这些确定性环节，必须由传统工具完成——但要记住它们兜不住架构性错误
• 人类把关：关键决策、架构方案、上线判断，必须由人负责

结语

这篇文章给了两组理由，必须分开看。

第一组会随时间缓解：

上下文有物理上限，压缩损失精度，长上下文注意力偏移，概率生成不可靠，多 Agent 放大随机性，测试反馈在污染状态下加速漂移，过程文档随迭代累积而分支率同步上升，算力成本是百万元级。

这些是当前的实现限制。它们会被改进——有些可能改进得很快。如果你用它们论证 AI 永远不行，两年后你会被打脸。

第二组不会：

不会质疑约束，所以不能定边界。

没有净值，所以不能签字。

这两条不依赖任何技术参数。算力翻一百倍、上下文翻一千倍，它们一条都不会变。因为问题不在能力，在于——它付账单，它不付代价。

工程需要确定性、可追溯、可负责。这三样里，前两样 AI 在未来也许能补齐一部分。

第三样永远不能。

它能读完所有的代码。它读不到那些代码为什么是那样。