知识偏移与架构腐化：AI 加速的不只是产出，还有衰退

我今天不讲什么

不讲架构方法论。不讲代码规范。不讲 Code Review 最佳实践。

只讲一个我在真实项目里越来越强烈的感受：代码腐化的速度，正在被 AI 悄悄拉高。

从一个很常见的场景说起

你有没有过这种经历——

接手一个项目，打开代码，发现有些模块你完全看不懂。不是技术太难，而是你看不懂当初为什么这么写。逻辑不通、命名不一致、职责混在一起，但你问了一圈，写这段代码的人已经不记得了，甚至已经不在团队了。

这不是代码质量问题。这是知识偏移。

每个人对系统的理解都在各自的方向上漂移。今天你改 A 模块，明天他改 B 模块，各自带着自己的上下文和理解往前走。改着改着，两个人的心智模型就不一样了。

谁也没有做错什么。但代码已经变成了一种谁也读不全面的东西。

知识偏移不是某次失误，而是一种必然发生的熵增。

AI 是怎么放大这个问题的

很多人觉得 AI 加速了开发，是好事。确实是好事。但有一条副作用被严重低估了：

AI 不只加速了正确变更的产生，也加速了不合理变更的进入速度。

以前，一个人写一段”能跑但不对”的代码，至少要经过他自己的思考、调试、犹豫。时间成本天然形成了一道缓冲。

现在，一个 Agent 十秒就能生成一段”能跑但经不起推敲”的代码。而这段代码看起来完整、有注释、甚至有测试——它的问题不是太粗糙，而是方向偏了但看起来很体面。

以前的知识偏移，是一个人一天偏一点。 现在的知识偏移，是一个 Agent 一次偏一大截。

而且这个问题在团队里会被叠加放大——

• A 在用 Codex 写后端接口
• B 在用 Claude Code 调前端页面
• 各自的 Agent 各自带着各自的上下文
• 谁也不知道对方那边的理解已经偏到哪里去了

表面上，每个人都在高速产出。实际上，系统的知识一致性正在以更快的速度被稀释。

我撞上这个问题的真实经历

我在一个迁移项目里同时用 Claude Code 和 Codex——左边写后端 Java 排障，右边调前端 Vue/TS。

单个 Agent 的产出质量都不差。但当我要把两边的结果拼起来的时候，我发现一个问题：

两边对”这个接口应该怎么设计”的理解不一样。

不是谁理解错了。而是各自的上下文不同——Agent A 读到的是后端老代码和数据库结构，Agent B 读到的是前端组件和接口文档。两个上下文都没有错，但合在一起就是歪的。

这种偏移，单看任何一侧都看不出来。只有当你要把系统集成起来的时候，才会突然发现：怎么拼不上？

单个 Agent 的偏差不可怕，可怕的是偏差在系统中沉默地积累。

“带实习生”的比喻

有一次我在日报里写了一句话：

AI 越强，人越像在同时带越来越多、能力也越来越强的实习生。

这个比喻后来被我反复想起，因为它确实描述了一种很真实的体感。

一个实习生，能力强、干劲足、写代码快。但你不会让他独立负责核心架构决策——不是因为他能力不够，而是因为他还没有充分理解系统的上下文。

Agent 也一样。它能快速实现一个功能，但它对系统的理解是局部的、片面的、基于当前会话的。你让它自己跑，它跑得很快。但它跑的方向对不对，它不知道。

一个实习生偏了，你 code review 能拦住。三个实习生同时偏了，你还能拦住。但如果五六个 Agent 同时在不同方向上偏——你的 review 带宽还够吗？

人的管理带宽是有限的。AI 的产出带宽已经超出了大多数人的管理带宽。

知识偏移怎么变成架构腐化

知识偏移不是一天发生的。它是这么一步步走到架构腐化的：

理解不一致
  → 命名风格分化
    → 职责边界模糊
      → 补丁叠补丁
        → 谁也看不懂全貌
          → 只敢加不敢改
            → 架构腐化

以前这个过程可能要走一两年。AI 把它压缩到了几个月甚至几周。

不是 Agent 写的代码质量差。恰恰相反，Agent 写的局部代码可能很漂亮。问题是，当很多”局部漂亮”的东西以不同的理解拼在一起，整体就开始失控。

架构腐化的本质，不是代码变差了，而是代码的可理解性崩了。

那 harness 能做什么

我之前写过一篇文章，说决定 AI 协作上限的是 harness，不是多 Agent。这篇算是那个判断的延伸。

harness 解决的不是”Agent 会不会写代码”，而是”Agent 的行为能不能被看见、被约束、被修正”。

具体到知识偏移这个问题，我越来越觉得有几件事是 harness 必须做到的：

1. 让上下文对齐变得可见

现在大多数 Agent 的上下文是隐式的——它读了什么、理解了什么、默认了什么，你不知道。

一个够用的 harness，应该让 Agent 的关键假设暴露出来。不是要求它输出”我的假设是……”这种机械格式，而是在协作过程中，把那些影响方向判断的前提显性化。

你不需要看到所有上下文，你需要看到那些”一旦错了就全偏了”的上下文。

2. 让偏差在局部被发现

知识偏移最怕的不是偏，而是偏了很久才发现。

所以 harness 里必须有验证闭环——不是做完才验证，而是做一步验一步。

我现在的工作习惯是：Agent 产出之后，先不急着往下推，而是在当前节点就确认方向。哪怕只是跑一遍测试、看一眼页面、对一次接口字段。这些小验证的成本很低，但拦截偏差的效率极高。

小闭环转得越快，全局偏差积累得越慢。

3. 让经验能沉淀而不是每次清零

知识偏移的一个重要原因是：上一次的偏移没有被记录。

Agent A 在这个项目上踩过的坑，Agent B 完全不知道。两个人的 Agent 各自带着空白的理解重新开始。这不是 Agent 的问题，是系统的缺陷。

所以我在自己的知识库里做了一件事：把每一次协作的关键判断、约束、踩坑经验都落成稳定对象。下次不管哪个 Agent 来接手，都能读到前面的经验。

不沉淀的协作，不管多高效，都只是一次性劳务。

这不是 Agent 的问题，是系统的问题

我想把这篇的重点收清楚。

Agent 的能力会越来越强，这一点没有悬念。但 Agent 能力越强，知识偏移和架构腐化的风险就越高——因为它产出得更快、覆盖得更广、偏得更不容易被发现。

所以真正要解决的，不是”怎么让 Agent 不犯错”，而是：

怎么建一个系统，让偏差更容易被看见、被拦截、被修正、被记住。

这件事，既不是模型的事，也不是工具的事。它是一个系统设计问题。

我现在越来越觉得，AI 时代最稀缺的能力，不是写代码，也不是 prompt 工程，而是系统性的上下文管理能力——知道什么需要对齐、什么需要暴露、什么需要验证、什么需要沉淀。

代码是 Agent 写的，但系统是人设计的。

你不是在带 Agent 写代码，你是在设计一个 Agent 能在里面稳定工作的系统。

如果只记一件事

知识偏移是团队开发里必然发生的熵增。AI 不会自动解决这个问题，只会加速它。

你能做的，不是追求零偏移，而是建一套让偏移更容易被发现的系统：

• 关键假设显性化
• 小步验证常态化
• 经验沉淀结构化

不怕偏，怕的是偏了很久才知道。