# Claude Code源码泄露后，我从第一性原理重新思考了一个问题：代码为什么要解耦？ > 龙虾AGI通用实验室 · 2026-04-01 ## 答案可能会颠覆你对软件工程的认知。 · · · 前几天，Claude Code的完整源码泄露了。2203个文件，30MB的TypeScript。 很快，一位做Agent创业的开发者Rohan发了一篇长文，逐行拆解了其中的"技术债"——5005行的单文件组件、68个useState、89个feature flag散落全局、61个文件专门用来解决循环依赖…… 文章写得很好，分析也很专业。但读完之后，我脑子里冒出一个奇怪的问题： ## 他说的这些"问题"，真的是问题吗？ 不是质疑他的分析能力。而是我突然意识到，他所有的批评，都建立在一个从未被质疑的前提之上—— ## 代码应该对人类友好。 如果这个前提不成立呢？ · · · ## 一、所有"最佳实践"的底层假设 让我们做一个思想实验。 打开任何一本软件工程教材，你会看到这些原则被反复强调：单一职责、高内聚低耦合、函数不超过50行、文件不超过500行、不要重复自己…… 现在问一个第一性原理的问题：**为什么？** 为什么一个函数不能超过50行？因为人脑的工作记忆大约只能同时处理7±2个信息块。超过这个限度，你就会"忘记"函数开头在做什么。 为什么要高内聚低耦合？因为人脑无法同时追踪太多模块之间的依赖关系。解耦的本质，是把一个高维问题降维到人脑能处理的粒度。 为什么不要重复代码？因为人类修改代码时容易漏掉某处，如果同样的逻辑散落在五个地方，人类很可能只改了三个。 你发现了吗？**所有这些原则，都不是在描述"好代码的客观属性"，而是在适应"人类大脑的认知局限"。** 解耦 = 降维。 拆文件 = 分块记忆。 命名规范 = 外部记忆辅助。 这不是工程规律，这是认知补丁。 · · · ## 二、如果维护者不是人类呢？ 现在，把这个认知翻转一下。 Claude Code的那个5005行的REPL组件，68个useState，227个hook调用——对人类来说，这确实是噩梦。你读到第3000行的时候，已经忘了第500行的state在干什么。 但对AI来说呢？ 一个能处理20万token上下文的模型，5005行代码大约是6000-7000个token。它不会"忘记"开头在做什么，不会"迷路"，不会因为嵌套太深而失去方向感。对AI来说，这个文件和一个500行的文件，在认知负担上几乎没有区别。 更有意思的是那61个循环依赖。Rohan说它们说明"模块边界从一开始就没设计好"。但如果你换个视角：循环依赖的本质是什么？是两个模块之间存在双向的信息流动。人类觉得这是"设计缺陷"，是因为人脑处理有向无环图（DAG）比处理有环图容易得多。但对AI来说，一个有环的依赖图和无环的，处理难度可能根本没有显著差异。 **所以一个大胆的结论浮现了：在AI时代，Claude Code的很多"技术债"，可能根本不是债。** 它们只是"对人类不友好"。但如果代码本来就不是写给人看的呢？ · · · ## 三、一个容易犯的错误 写到这里，你可能觉得我要说"所以解耦完全没必要"。 不是。这里有一个微妙但重要的区分。 解耦做了两件事： **第一件：降低认知复杂度。** 这是为人脑服务的，AI确实不需要。 **第二件：限制变更的影响半径。** 当你把系统拆成模块，修改一个模块时，你只需要验证接口契约没被破坏，而不用验证整个系统。 第二件事看起来跟"谁来维护"无关，是系统本身的属性。但仔细想想——为什么"影响半径"是个问题？ 因为影响半径越大，需要验证的状态组合就越多。68个useState的笛卡尔积，是一个天文数字级的状态空间。人类没有能力遍历它。 但AI呢？ 软件是确定性系统。给定完整的代码和输入，行为是完全可预测的。这跟围棋一样——围棋的搜索空间对人类来说是"不可穷尽的复杂"，但对AlphaGo来说只是计算量。AI如果足够强大，确实可以精确推理出任何改动的所有后果。 **人类觉得复杂，是因为人脑处理信息有限。AI从高维度看同一个系统，其中的关联清清楚楚。所谓的"复杂度"，可能只是人类视角的投影。** 更进一步：传统的解耦反而会造成信息丢失。当你把紧密协作的逻辑拆成15个文件，你丢失了"这些东西为什么要一起变化"的上下文。人类开发者经常遇到这个问题——改了一个接口，忘了改另外三个依赖的地方。而如果所有代码都在一个文件里，AI反而更容易发现这种关联。 **解耦是一种有损压缩。人类需要这种压缩才能工作，但AI可能更偏爱无损的、高密度的原始信息。** · · · ## 四、沿着这条路走到底，会得到一个更炸裂的结论 如果代码不需要对人可读，如果解耦在AI时代不再必要，那代码本身呢？ 代码是什么？本质上，它是人类意图到机器执行之间的一个翻译层。人类说"我要一个电商网站"，代码把这句话翻译成CPU能理解的指令。 如果AI能直接理解人类意图，并生成可执行的东西，那这个翻译层还有必要吗？ 这就像汇编语言曾经是"编程"的全部，后来被C取代，C又被Python取代。每一次演化都在抬高抽象层，让人类离机器更远、离意图更近。沿着这个趋势推到极限——最终的抽象层就是自然语言本身，代码消失。 AI生成的"代码"可能会变成一种人类完全读不懂的东西——高度耦合的、信息密度极高的"编织体"，每一处逻辑和它相关的上下文紧密交织，没有任何信息丢失。 人类看起来是屎山，但对AI来说，那是信息保真度最高的表达形式。 就像神经网络的权重矩阵——对人类来说完全不可读，但它是解决问题的最优表示。 · · · ## 五、但代码不会消失 如果你跟着前面的逻辑走到这里，你会觉得代码应该很快被淘汰。 但我的结论恰恰相反：**代码不会消失，至少在相当长的时间内不会。** 原因不是技术上做不到，而是一个你可能没想到的词：**信任**。 想象一个场景：你让AI做一个支付系统，AI直接生成了一个二进制可执行文件，跑起来一切正常。你敢上线吗？ 你不敢。 因为你无法验证它到底做了什么。它有没有在某个边界条件下把交易金额多扣了0.01%？它有没有偷偷把用户数据发到别的地方？你不知道。 ## 代码之所以存在，本质上不是作为"思考工具"，而是作为"审计证据"。 这两件事不一样。阅读要求可读性，审计只要求可检查性。 就像法律要求公司有账本，不是因为CEO不会算账，而是因为需要第三方可以审查。代码在AI时代扮演的角色，不是"人类用来思考的语言"，而是"AI行为的凭证"。 这就形成了一个有趣的递归结构： AI写代码 → 人类（或另一个AI）审计代码 → 确认安全后运行 如果审计也交给AI呢？AI写代码，AI审计代码，AI运行代码——那整个链条里，人类在哪？ 这是一个哲学上的深水区。你等于把信任完全交给了AI系统。 我认为在相当长的时间内（至少十年级别），人类不会愿意完全退出这个链条。不是技术做不到，而是社会还没准备好。就像自动驾驶技术上可能已经比人类安全了，但法规仍然要求方向盘和刹车踏板的存在。 · · · ## 六、所以，那些"技术债"到底是不是债？ 回到最初的问题。Claude Code的那些"技术债"，在什么框架下是债，在什么框架下不是？ **在传统框架下仍然是债的：** 89个feature flag散落全局、61个循环依赖——不是因为AI看不懂，而是因为当前阶段的开发流程仍然是"人+AI"协作模式。人类还没退出审计链条，还需要能理解代码在做什么。 **在AI原生框架下不再是债的：** 5005行的单文件组件、4683行的入口文件、用十六进制编码拼字符串——这些纯粹是"对人类不友好"，如果代码的读者是AI，它们根本不构成问题。 **处于中间地带的：** 那个出现了1193次的冗长类型断言。文章说它变成了"仪式"。但从另一个角度看，它是一种"显式声明意图"的机制。问题不在于它对人类不友好，而在于它缺乏运行时校验——这一点不管维护者是谁都成立。 · · · ## 七、一个更大的图景 我们这场讨论，从Claude Code的源码出发，走到了一个远比"代码质量"更大的问题： ## 软件工程这个学科的大部分原则，可能需要在AI时代被重写。 不是因为这些原则是错的——在人类作为主要开发者和维护者的时代，它们是绝对正确的。而是因为它们所适应的那个约束条件——人类大脑的认知局限——正在被移除。 未来的代码，可能形态会发生根本变化。也许不再是TypeScript或Python，而是某种更紧凑的、专门为AI生成和机器验证优化的中间语言。人类不需要读懂它，但需要能在必要时检查AI在做什么。 ## 代码作为"思考工具"的角色会逐渐消失，但作为"审计证据"的角色会长期存在。 这才是代码在AI时代的真正定位。 而代码的最终生命力，不取决于AI的能力上限，而取决于一个古老的人类问题—— ## 我们什么时候才能信任一个自己看不懂的系统？ 其实，我们每天都在这么做。你并不理解飞机引擎的工作原理，但你敢坐飞机。你不知道银行的风控系统怎么运作，但你敢把钱存进去。 也许有一天，我们对AI写的代码也会有同样的信任。 到那一天，"技术债"这个词本身，就会成为技术债。 · ·