NanoClaw 创始人 Gavriel Cohen 最近提出了三条 AI 时代的编程理念，乍看有些道理，但仔细一想，每条都在软件工程的雷区上蹦迪。
NanoClaw 创始人 Gavriel Cohen 最近提出了三条 AI 时代的编程理念（原文链接）：
第一点，DRY 也就是不重复造轮子的原则过时了。 以前我们极度追求代码复用。但在 AI 时代，AI 在修改共享函数时往往不会考虑下游连锁反应。适度的代码重复，反而成了最简单有效的物理隔离，让系统更安全。
第二点，严格的文件行数限制过时了。 过去我们喜欢把代码拆成无数个小文件。现在，与其让 AI 在多个文件之间反复横跳去理解逻辑，不如让它在一个稍长一点的文件里把整件事情干完。
第三点，代码不需要经得起时间的考验。 不要再为了所谓的未来扩展性去过度设计了。只要满足当下的需求即可。因为六个月后，更聪明更强大的下一代模型，会直接帮你把整个系统重写一遍。
说实话，这三条观点乍看有些道理，但经不起推敲，每一点都在软件工程的雷区上蹦迪……
DRY “过时”？恰恰搞反了
DRY 的本质从来不是"减少打字量"，而是确保同一业务逻辑只有唯一的变更点（Single Source of Truth）。
用代码重复来做"物理隔离"，其实是在系统中埋下了 N 个语义相同但各自漂移的定时炸弹。今天你复制了一段权限校验逻辑到十个服务里，明天安全策略变更时，AI 真的能找齐这十个副本并保持它们语义一致吗？
AI 改共享函数时不考虑下游连锁反应，这不是 DRY 的锅，是 AI 能力的缺陷。工具不够好就放弃经过半个世纪验证的工程原则，这叫因噎废食。该做的是改进 AI 对变更影响范围的理解，而不是把系统退化成一堆语义孤岛。
现实中的 AI 编程早已不是"一个 AI 管一切"的童话。当团队中多个 AI Agent 并行工作——一个在改支付模块，另一个在改订单模块——如果它们各自持有一份重复的业务逻辑副本，谁来保证这些副本的一致性？没有 DRY 约束的系统在多 Agent 并发修改下只会加速语义漂移。
真正的隔离靠的是接口契约、明确边界和版本化 API，不是散落在各处的复制粘贴。
文件可以变长？这不是进步，是走回头路
模块化和关注点分离不是为了讨好人类的阅读习惯，而是为了控制复杂度的增长速率。
一个几千行的大文件往往意味着高耦合：函数之间隐式依赖、状态共享不透明、改任何一处都可能触发意想不到的副作用。觉得"让 AI 在一个长文件里干完整件事"更高效，其实是在假设 AI 永远能完美理解全部上下文——但即便是最新的大模型，超长上下文中的注意力衰减（attention dilution）也是公认的问题。
在多 Agent 协作的场景下，这个问题更加致命。两个 AI Agent 同时修改同一个大文件的不同部分，合并冲突的概率和解决成本远高于各自维护边界清晰的小模块。文件越大，并行协作的摩擦系数越高。
这和人类团队协作面临的问题本质相同——Conway 定律不会因为参与者从人类变成 AI 就失效。模块化的文件边界本质上就是协作的接口契约，无论协作者是人还是 Agent，这个道理不变。
软件不是写一次就完事的产物，它需要被多方协作维护、被 review、被测试、被局部替换。把文件拆短不是强迫症，是对系统长期熵增速度的约束。
“代码不需要经得起时间考验”？最高级形式的技术债合理化
“六个月后更强的模型会帮你重写一遍”——这个愿景很美好，但有三个致命漏洞。
第一，业务知识不在代码表面，在设计决策里。
为什么这里用最终一致性而不是强一致？为什么超时设成 3 秒？为什么降级逻辑是这样而不是那样？这些藏在设计背后的 trade-off，过度设计的代码可能还记录了它们，但"只满足当下需求"的代码一定不会。
新模型来重写时，它从哪里恢复这些上下文？更别说当多个 AI Agent 分头重写不同模块时，如果没有统一的设计规范和架构约束，重写出来的系统大概率是一个风格混杂、假设冲突的弗兰肯斯坦怪物。
第二，重写成本从来不只是代码本身。
还有数据迁移、集成测试、上下游适配、灰度发布、回滚预案。每六个月全量重写一次，系统在任何时间点都处于不稳定态。
第三，技术进步不会消灭对良好设计的需求。
软件工程 50 年的历史反复证明——没有银弹。新工具带来新效率，但永远不会消灭对良好设计的需求。
用"反正会被重写"来合理化不做设计，和用"反正会死"来合理化不锻炼身体一样荒谬。
AI 改变的是编码效率，不是软件工程的基本定律。
复用、模块化、面向变化设计，这些原则存在了几十年，不是因为人类打字慢，而是因为软件系统的复杂性有其内在的增长规律——无论操刀的是人类程序员还是 AI Agent，也无论是一个 Agent 还是一百个。
把 AI 当前的能力局限当作范式转移的信号，是一种危险的短视。