AI 时代重读《编写可读代码的艺术》:它关心的从来不是代码好不好看

让 AI 生成一个模块，已经不算什么难事。

真正麻烦的是三个月以后。

需求变了，测试还是绿的，可没人敢动那段代码。写代码的人忘了当初为什么这么写，AI 也只记得现在的文件，不知道哪些绕路是业务要求，哪些只是历史遗留。

这时重新看《编写可读代码的艺术》，会发现它真正关心的从来不是“代码好不好看”。

它真正追问的是：

AI 改变的，正好是这件事的另一半：

所以 AI 时代最容易积累的，不只是技术债，还有一种更隐蔽的东西：理解债。

代码今天能跑，不代表三个月后还有人知道它为什么这样跑。

看这段很短很漂亮的 Python 代码代码：

业务规则其实是：

换一种写法：

代码变长了，但“已付款”和“超过 100 元”这两个条件被明确写了出来。以后需求改成“超过 200 元”，也更容易找到该改哪里。

可读性不是让代码更短，而是让读者更快回答：

AI 很擅长把一小段代码整理得漂亮：

每个函数可能只有十几行，命名也很规范。

但原来一眼能看懂的流程，可能变成：

单个函数都很清楚，整个数据流却要在十个文件之间来回跳。

这就是 AI 时代一个容易被忽略的风险：

函数该不该拆，不能只看行数。真正要问的是：它们是不是两个不同的业务概念，未来是不是应该一起变化。

AI 看到两段代码长得像，往往会建议把它们合成一个 PriceCalculator；但订单价格、运费和退款金额，也许只是今天碰巧用了相似公式，明天却会分别变化。

这正是 DRY（Don't Repeat Yourself）最容易被读错的地方。

DRY 要消灭的不是所有长得相似的代码，而是同一条业务知识被写在多个地方。比如“订单满 100 元免运费”这条规则，如果同时散落在下单、结算和退款逻辑里，改一次就得找三遍，这才是真正危险的重复。

但订单价格、运费和退款金额只是恰好用了相似公式，就不一定应该强行共用一个抽象。它们未来可能分别变化，过早合并反而会让本来独立的规则绑在一起。

真正该消灭的不是重复代码，而是重复的知识。 错误的抽象，会让三个本来可以独立修改的地方绑在一起。

过去是：

现在多了一层：

Agent 会搜索代码、定位文件、修改实现、运行测试，再回来继续修改。它能不能安全行动，取决于代码库是否把边界表达清楚。

如果支付、订单和库存各自有明确边界，你可以告诉 AI：

如果所有逻辑都塞进一个 processEverything()，你连“只改哪里”都很难说清楚。

所以，人不是为了 AI 才写得更规整。清晰的结构首先是给人看的，同时让 AI 更容易判断：

以前代码很贵，程序员会自然控制数量：

现在 AI 可以很快增加工具函数、兼容分支和抽象层。工程师真正要控制的，就不再只是写了多少行代码，而是系统增加了多少无法被人快速理解的复杂性。

Code Review 也会随之改变重点。格式、命名和简单静态检查可以交给工具，人更该追问：

这才是重新理解《编写可读代码的艺术》后，最值得带进 AI 时代的地方。

可读性不是装饰，也不只是让同事少皱几次眉。它是在给未来的修改者留下足够清楚的因果：

过去，这个“未来的修改者”主要是另一个程序员。

现在，它也可能是下一次接手任务的 Agent。

所以今天写代码，实际上是在同时维护两种可读性：

这也是为什么《编写可读代码的艺术》在 AI 时代没有过时。它真正留下的不是一张命名和格式清单，而是一种工程要求：

这可能是最值得带进 AI 时代的一句话：