有回我打开一个老工程的目录，看见几个体积不太对劲的文件。其中一个 4 MB 出头，点开一看，十三万行，全是同一种形状的类，字段、属性、序列化标记一个接一个，注释也是一个模子印出来的。
当时我给自己定的规矩很简单，生成的东西不用读。它不是我写的，也不是同事写的，是外部那套标准模板照着吐出来的，既然不归我写，就不归我读。
后来我数了一次，才发现「稳赚」站不住。
先看那个 4 MB 的文件头上压着的那句话，原文是英文：
//This code was generated using the Energistics Generator tool. Direct changes to this code will be lost
//during regeneration.
翻译过来就是，这份代码是生成器吐的，你直接改它，下次重新生成全丢。这些行在体制上是只读的，长得跟旁边的代码一样，编译也一起过，可你碰它的那一刻就等于没改。
然后我把行数加起来，这一加让我沉默。
| 行数 | |
|---|---|
整个仓库的 .cs |
197,802 |
| 挂着那句只读声明的那个文件 | 135,258 |
| 同目录里另一个机器吐的枚举文件 | 20,787 |
| 剩下人手写的 | 41,757 |
光挂着声明的那一个，就占了仓库的六成八。加上同目录那个机器吐的枚举文件，两个合计 156,045 行，接近八成。
这里的麻烦有三层。第一层是改不了，那 156,045 行跟手写的 41,757 行混在同一份提交里，可其中十几万行是只读的，谁手改了一行，下次重新生成就没了，还不会有人报错。第二层是没人看，文件大、内容重复、没有讨论价值，于是它自动从所有人的视野里退出。第三层是提交记录被淹，真正有人动过的那几行一重新生成，就埋进了几万行机器变更里。
生成代码省下的是「对齐」的工夫，欠下的是「治理」的工夫。对齐确实省了，让机器照着标准吐一遍，比人手一个个字段写过去可靠得多，这一点我不改口。但生成物一旦进了仓库，它就跟手写的代码一样成了团队的资产，治理的账一样要还，谁有权重新生成、多久生成一次、生成完那几万行 diff 谁看，一件都躲不掉。如果再来一次，我会在第一次生成完就把规矩定死，生成物一律当只读的，要在它之上做扩展就另开一层，别贴着生成物改；重新生成后不看逐行 diff，只看生成器的输入有没有变。机器吐得快，不等于你可以甩手。