AI 时代最大的设计转变不在于谁来写代码，而在于代码被期望存活多久。

在软件领域，churn 一直是个贬义词。微软的研究人员多年前就表明相对代码 churn 可以预测缺陷密度。Adam Tornhill 写了一整本书，名为《你的代码是犯罪现场》，其中频繁变更、复杂的文件是头号嫌疑对象。GitClear 的研究预测 AI 助手将使代码在写完后两周内被重写的比例翻倍，并将其定性为对质量的下行压力。这种本能根深蒂固：不断变化的代码就是曾经出错的代码。

但这种本能来自一个写代码很昂贵的世界。持久性是你让钱花得值的方式。当一个功能的成本是一个下午而不是一个冲刺时，这笔账就反过来了。重写某些东西往往比小心翼翼地保存它更便宜，而这只会变得越来越成立。

代码库如今是花园

我们一直用建筑的术语来描述软件：架构、地基、脚手架、承重墙。建筑本应静止不动。

我认为代码库正变得更像花园。具体来说，是种满一年生植物的花园。园丁每个季节都会重新种植一年生植物，没人会因为番茄植株在十月枯死就说它是技术债。园丁真正的投资放在那些不会更替的东西上：土壤、花坛、灌溉系统、角落里的那棵橡树。良好的结构恰恰是让重新种植变得便宜的原因。

频繁 churn 的代码本质上是可丢弃的，而可丢弃并不意味着草率。它仍然可以做得很好。只是它不是为持久而造的。一年生植物的质量意味着它完成自己的任务、在边界处经过测试，并且可以被移除而不破坏周围的一切。

问题在于，我们还没有一幅高质量 churn 长什么样的图景。我们对质量的心智模型与长寿纠缠在一起。我们会炫耀那些六年未被触碰、一直运行的代码。所以 churn 无论如何都会发生，但它是隐性的，并且落在最方便的地方。

churn 实际落在哪里

我查看了过去六个月的Forem：563 次提交。churn 最多的文件是app/models/article.rb，在其中 37 次提交中被触碰。

我们的垃圾邮件处理器也排在上面，第 13 位。这个我挺满意。垃圾邮件是一季一收的作物。垃圾邮件发送者不断改变策略，我们的代码也应该跟着一起翻新。

article.rb是橡树。当橡树每周都被挖出来一次，就意味着新功能正在核心模型里扎根，因为那是种下去最容易的地方。这就是结构性的妥协。翻新不是问题。承重部位的意外翻新才是。

为此而设计

几个让翻新变得明确而非意外的想法：

给各层命名。大声说出哪些是一年生、哪些是多年生。我们的AGENTS.md已经做了一个粗略版本，它会告诉 AI 助手在核心认证、信息流排序和缓存管道周围要小心行事。这不应该只是一张警告标签。它应该是代码库的形态。

把契约放在花圃的边缘。接口、schema、API 规范和测试，这些固定的是行为而非实现，它们就是多年生植物。它们背后的任何东西都可以自由重写，无论是人还是智能体。

让移除变得廉价。检验一株好的一年生植物的标准，是你能不能把它拔出来而不扰动花圃。如果某个东西注定要翻新，它就不该把卷须伸进所有地方。

按层衡量翻新。快速层的高翻新率是健康的标志。慢速层的翻新则是警报。

翻新是一种设计输入

翻新无论如何都会发生。AI 已经让它成为我们构建的大多数东西的默认变化速率。我们可以继续把它当作一种症状，也可以把它当作一种设计输入，并构建出让我们能自信地重新栽种的结构。

我承认，我一直更倾向于认为翻新比软件设计的传统智慧所暗示的更可接受。在我的实际经验中，我从未把避免翻新视为一件好事。我过去能看到争论的双方，现在我坚定地站在这个阵营：翻新与我们的代码库和系统的质量及刚性正相关。

我宁愿打理花园，也不愿假装它是一栋建筑。