你有没有想过，为什么有些代码库越改越顺，有些却越改越乱？

一位开发者最近提出了一个有趣的视角：把代码库看作一个"引力场"，而每一次提交（PR）就是施加在这个场上的力。好的结构会让好的修改自然发生，坏的结构则会反复诱导糟糕的捷径。在AI能快速生成代码的今天，这种"引力效应"变得更强了。

打开网易新闻 查看精彩图片

他把这个设计思路称为"吸引子工程"（Attractor Engineering）。

打开网易新闻 查看精彩图片

核心直觉很简单。现有的命名规范、类型定义、职责边界、测试覆盖、目录结构、过往实现范例，乃至代码审查文化，都在塑造"下一个修改哪里感觉最自然"。当结构良好时，后续变更倾向于找到合适的位置；当结构糟糕时，看似合理的局部修改往往会重复走同样的弯路。

更关键的是，PR改变代码库，而被改变的代码库又反过来影响下一个PR的形态。这不是静态设计，而是动态演化。

那么，谁塑造了这个场？不只是工程师。产品经理、技术文档、CI/CD流水线、测试套件、审查流程，都在共同作用。作者把这些理解为"耗散系统"——它们移除不想要的力，塑造变更的轨迹。

打开网易新闻 查看精彩图片

为了观察这条轨迹，他开发了一个叫ArchSig（架构签名）的工具，从多个维度追踪代码库的演化方向。

文章后半部分走得更远，把这套直觉与AAT（代数架构理论）、Lean形式化验证和有限反例联系起来。但对实践者来说，前半部分的启发已经足够：与其纠结单点设计，不如关注结构如何引导未来的修改流向。

当AI能批量生产PR时，设计"修改会往哪里去"可能比审查单个修改更紧迫。