上篇：为什么现在干不了
一、先分清两件事
过去两年，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 是行业常见经验值，此处按此估算）：
| 文档类型 | 量级（token） |
|---|---|
| 业务代码 | 1000 万 |
| 测试代码与用例 | 1000 万 |
| 设计文档、接口定义 | 150 万 |
| 测试日志与报告 | 150 万 |
| bug、评审、变更记录 | 100 万 |
| 过程文档总量 | 约 2400 万 |
代码只占四成。而日志、评审、bug 记录这三类，恰恰是过程里增长最快的部分。
这里必须回答一个问题：同样面对 2400 万 token，为什么 AI 致命而人不是？
因为人不需要把所有东西放进同一个上下文。人有语义索引------他知道那个关键决策在第 7 轮的评审记录里，能直接调出来。而 AI 要么全量读入（受制于上下文与注意力），要么压缩（受制于漂移）。
**人有索引，AI 只有窗口。** 这是同一堆文档对两者成本不同的根本原因。
每一轮迭代，AI 都要带着此前全部的过程文档再跑一遍。第 i 轮读入约等于 i 乘以每轮新增文档，总读取量约为总量乘以 N 的一半。
| 迭代轮数 N | 每轮产出 | 峰值上下文 | 累计 Prefill |
|---|---|---|---|
| 20 | 120 万 | 2400 万 | 2.4 亿 token |
| 50 | 48 万 | 2400 万 | 6 亿 token |
| 100 | 24 万 | 2400 万 | 12 亿 token |
峰值上下文恒为 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）
| 方案 | 规模 | 费用 |
|---|---|---|
| 自购 | 18-20 卡 | 340-375 万元 |
| 云租（按月） | 20 卡 | 31-38 万元/月 |
| 云租（按小时） | 20 卡 | 约 960 元/小时 |
十一、时间账
超长上下文下，Prefill 跑不到标称速度。标称 5000 token/s 是短上下文的数字；2400 万 token 上下文、权重跨 20 张卡、batch size 被迫为 1，实际吞吐掉到 500-1500 token/s。取 1000。
Prefill：
| N | 累计读取 | @1000 t/s | @500 t/s |
|---|---|---|---|
| 20 | 2.4 亿 | 2.8 天 | 5.6 天 |
| 50 | 6 亿 | 6.9 天 | 13.9 天 |
| 100 | 12 亿 | 13.9 天 | 27.8 天 |
Decode（总产出 2400 万 token，与 N 无关）：
| 速度 | 时间 |
|---|---|
| 20 t/s | 13.9 天 |
| 10 t/s | 27.8 天 |
纯计算合计（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 方案 |
|---|---|---|
| 架构与决策 | 全额 | **全额（省不掉）** |
| 编码实现 | 全额 | 接近零 |
| 审查 | 抽检，约 60 万 | 全量，约 150 万 |
| 算力 | 0 | 89-179 万 |
| 集成与调试 | 常规 | 更高（陌生代码，+40 万） |
| 合计 | 约 216 万 | 约 240-330 万 |
结论不是"AI 贵到离谱"。结论是：
AI 省下的编码人力，被算力、全量审查、更高的集成成本吃掉了。
同等量级的钱和时间，换来的是一个不保证能交付的东西。
人的时间可预测、可管理、有终点。AI 的时间是概率性的------每一次生成依赖前一次，而前一次可能是漂移的。它可能三个月收敛，也可能永远收敛不了。
这个结论比"AI 贵一倍"保守得多，但它更难反驳------因为它不依赖任何一个会被技术进步推翻的数字。
下篇：为什么原理上不行
十四、不会质疑约束
上一节的所有论证，都建立在当下的技术条件上。硬件会更便宜，注意力会更高效，RAG 会更聪明。那部分会变。
而下面这一节不会。
架构不是"读完全部代码之后的最优解"。架构是在相互冲突的约束之间，切一刀。
性能与开发效率。稳定与灵活。现在能上线与三年后还能改。完美方案与明天老板要 demo。
有人会说：把"只有 3 个人月、老板明天要上线"写进 prompt，AI 就有约束了。
但那不是约束，那是输入。
架构师的价值从来不只是"在给定约束下优化"。它更在于判断哪些约束是假的。
老板说必须明天上线，架构师会说：那我们先上这个子集，剩下的分两期。产品说要支持任意组合查询，架构师会说：前三个场景覆盖九成，剩下的走离线。
这是重新定义边界，不是求解。
而 AI 不做这件事。因为约束对它是给定输入，不是可质疑的对象。它可以在约束下做到最优，它不会问"这个约束能不能拿掉"。
更关键的是：**质疑约束是有风险的。** 你说"这个约束是假的"，如果错了，责任是你的。而 AI 不承担这个------它说了不算，所以它说什么都不要紧。
一个不会质疑约束的东西，可以给出方案，不能定边界。
十五、还有最后一样：签字
架构设计的最后一件事不是技术判断。是承担风险。
出了事要有人扛。这个"扛"不是比喻------它意味着有一个人，他的名字挂在这个决定上，而这个决定不可撤回地塑造了此后所有的路径。那个改动留下的疤，就是锚点。
而 AI 的输出，无论多复杂，都建立在"可预判、可回滚"的基础上。它的权重可被重置，没有不可逆的历史。它执行了收束，但净值恒为零。
它付账单，它不付代价。
所以它能给出方案，但那道疤长不到它身上。不长疤的东西无法抵押，无法抵押的东西无法负责，无法负责的东西不能签字。
而不签字的东西，不能定架构。
十六、AI 在工程里的正确位置
说这么多不是要否定 AI。它在工程里非常有用，但角色是副驾驶 ，不是主驾驶。
- 全局架构规划：交给人类架构师，AI 做辅助检索和方案模拟
- 本地执行层：代码生成、重构、单模块设计、单元测试、文档摘要，上下文控制在 32K 以内，可靠且高效
- RAG + 精准检索 ：把大代码库切块，按需检索相关片段------对局部编码有效，对跨模块耦合无效，所以架构决策不能依赖它
- 确定性工具兜底：编译、测试、静态分析这些确定性环节，必须由传统工具完成------但要记住它们兜不住架构性错误
- 人类把关：关键决策、架构方案、上线判断，必须由人负责
结语
这篇文章给了两组理由，必须分开看。
第一组会随时间缓解：
上下文有物理上限，压缩损失精度，长上下文注意力偏移，概率生成不可靠，多 Agent 放大随机性，测试反馈在污染状态下加速漂移，过程文档随迭代累积而分支率同步上升，算力成本是百万元级。
这些是当前的实现限制。它们会被改进------有些可能改进得很快。如果你用它们论证 AI 永远不行，两年后你会被打脸。
第二组不会：
不会质疑约束，所以不能定边界。
没有净值，所以不能签字。
这两条不依赖任何技术参数。算力翻一百倍、上下文翻一千倍，它们一条都不会变 。因为问题不在能力，在于------它付账单，它不付代价。
工程需要确定性、可追溯、可负责。这三样里，前两样 AI 在未来也许能补齐一部分。
第三样永远不能。
它能读完所有的代码。它读不到那些代码为什么是那样。