先说我读这篇文章的真实顺序：第一遍扫完，我觉得Ben就是个拿花园当比喻的文艺程序员，写代码的人突然跟你聊多年生、一年生、土壤、花床、灌溉系统，场面感越强，越像在掩盖一个他自己没讲透的判断。第二遍我才反应过来，这哥们儿是在算一笔很具体的账：写代码这件事，计价模型得换。他说“当前缺少高质量churn的图景，因为人们把质量心智模型与长期存活纠缠在一起”，这句才真正值钱。你信吗，一个写代码的人跑出来说“长期存活”是需要被拆开的执念？
我先算了一笔账。AI这波给所有人都发了一张降价券，一个功能从几周缩到一个下午。可降价只降了“写出来”，没降“留下来”。留下来的成本里有一块几乎没人爱提：你现在维护的代码里，有多少只是因为“当时写它很贵，舍不得重写”才活到今天？这问题早有人拿数据碰过——微软的研究员说过相对churn能预测缺陷密度，Tornhill在《Your Code as a Crime Scene》里把频繁修改的复杂文件列为头号嫌疑。可这套逻辑有个隐含前提：代码写得贵，所以改得频繁等于坏味道。如果代码自己快到一个下午就能写出来呢？那“改得频繁”可能根本不是坏味道，它只说明这活儿本来就该频繁改。你以为你在闻坏味，其实你闻到的，是旧定价逻辑还糊在这行的大脑皮层上，没退干净。
说句扫兴的。GitClear那个预测——AI助手会让代码两周内被重写的比例翻倍——很多人一看就拍大腿，说质量要完。Ben不当回事，他把这事当成一个需要被重新设计的现实。这两种读法差在哪？前一种还默认所有代码都是种下去要活二十年的橡树，churn一高就焦虑，加班加固，写一堆“以防万一”的抽象层；后一种问的是，凭什么所有代码都该活二十年？你见过几个功能真能撑过三个产品周期？那些高churn的部分，下个季度就拔了，你花在“让它活久一点”上的力气，全是冤枉钱。
Ben自己的账本挂在那：Forem六个月563次提交，article.rb被改37次，churn全场第一。他管它叫橡树。一个承重模型每周被改，说明新功能“因为方便”就往核心模型里扎根。这四个字才是真问题——不是有人故意偷懒，是压根没人明确说过“这里不许随便生根”。垃圾信息处理器改了13次，他觉得健康，因为垃圾信息策略本来就该随季节走，该换就换，一年生植物。article.rb被新功能频繁侵入，不是代码质量出问题，是边界没人管。这跟写得好坏关系不大，本质是结构性妥协。（插一句不相干的）我见过太多团队一听到churn高就搞质量专项，把一年生和多年生混在一起要求降低churn。结果一年生代码为了少改一次套上三层间接，表面churn降了，该死的时候死不掉，活生生把花床沤成沼泽。这不是质量，这是给每季的牵牛花修水泥花盆。
那怎么办？Ben给的路可以算成一笔账：把代码库分成两层。一层是多年生的土壤、花床、灌溉系统、角落那棵橡树——这些churn必须低，低不下来就是警报，每一次改动都是在承重墙上动土。另一层是一年生的花，该频繁换，它换得少反而说明你在用长期存活的成本去伺候短命的功能。判据不玄学，就一条：更换成本加上更换概率，值不值得为它买“活下去”的保险。一年生代码的更换成本已经被AI打到地板了，它们没资格享受多年生的加固待遇。article.rb那种地方，改一次的成本自己心里要有数，那是承重墙改电线的账，别算错。
这里有一笔我一开始算错的账。我原本以为这套分层是为了“让代码质量更好”，后来发现它的价值在别处：让公司的钱花对地方。维护预算从来不是均匀撒在每行代码上，是按焦虑分配的——哪个模块一改就出大事故，哪里的维护时间就堆过去。一年生和多年生不分清，焦虑就跟着均匀分布：article.rb每周被改大家无感，某个一年生功能模块改崩了反而惊动所有人开复盘会。分层不是在提升质量，是把焦虑和改动频率重新对齐到同一套坐标系里。这笔账，比质量观实在。
评论里那几条，最有意思的是Mahdi JabinPour那条：一年生功能频繁改动迫使核心模型编辑，是边界泄漏的早期信号。我认，跟Ben说的是同一件事。Shubhra Pokhariya提Next.js缓存边界模糊，那是另一个层面的账：工具本身没区分生命周期，宽泛的revalidateTag让无关功能共享缓存失效。不是开发者