构建软件的口头传统可能无法在人工智能时代幸存

直到32岁成为一名软件工程师之前，我的整个职业生涯都是围着文字转的。我曾是一名历史学家，深深扎根于书籍、档案和文章之中。我转行的原因在这里并不重要，我在其他地方写过；说白了，历史学家这行找工作太难了，以至于我想做点别的事情。我成为软件工程师是因为我喜欢它那种解决问题的感觉和设计上的门道。我在Hagerty保险公司担任后端工程师。不知怎的，我竟然适应了这份工作，甚至可能做得不错。但这份工作最让我摸不着头脑的是，很少有东西被写下来。

现实是这样的：软件开发靠的是口口相传。尤其是当你刚开始当工程师时，你并不是在编写全新的代码；你可能是在一个遗留代码库中工作。你会发现，关于这代码是干嘛的、为啥这么写，问题比答案多得多，而当你去寻找答案时，不会有太多书面记录。也许有一份早期的设计文档，但结果发现，在开始工作之前，所有内容都经过了大幅修改。也许有几页维基页面解释了已知问题，有些早就解决了，有些就扔在代码里没人管，慢慢烂掉。也许有人在代码本身中留下了注释，但通常那是一个警告，不要更改某些内容，否则其他东西会崩溃。

在这个层面上，当历史学家这经历，居然成了我意想不到的优势。历史学家习惯于从碎片中重建故事，而不是在档案中找到现成的解释。因此，当需要在陌生的代码库中进行更改时，你最后多半得找另一个开发来问问。他们在那里待得足够久，了解底层发生了什么，他们也许能解释为什么改变一个看似无害的东西可能会变成一个非常糟糕的主意。

软件工程这行，跟文档的关系挺矛盾的。每个人都同意文档在理论上很重要，但在实践中，它要么不一致，要么过时，要么完全缺失。一部分原因就是懒。编写文档通常不如编写代码本身有趣。但这也是意识形态上的。敏捷运动的兴起部分是为了反对文档繁重的瀑布式方法论，而敏捷的核心价值观之一明确优先考虑“可工作的软件胜过全面的文档”。结果呢，躲开了官僚式的过度文档，行业又把文档不足当成了常态。

这种比较可能会让一些还在学校深造的朋友感到不悦。软件工程师并不“展示”他们的代码；我们不会把它当故事讲出来，如果有人问我为什么编写了一个存储过程而不是别的办法，我也不会用顺口溜来回答。但口头传统确实有教人的成分，这点上，工程师之间也存在着类似的做法。某些软件开发模式或实现方式会被优先考虑，而另一些则会被冷落（工程师们往往会把代码库的某些部分当成“反面教材”，提醒别人别学样）。这是培训新工程师的主要方式之一。

这并不是说口头知识是坏事，或者文档天生就是好东西。依赖口头传统传承文化和信息的社会，很多时候都稳稳当当传了数千年。他们琢磨出了特别靠谱的信息传递方式。但在一个方面，软件工程很不一样：软件工程师的跳槽率。依赖口头传统的社会不会每五到七年就换掉他们的说书人，但即使是知名科技公司的雇主，也可以心里有数地预期工程师每隔几年就会走人。我惊讶地发现，干了没几年，有些项目我可能是唯一一个从头跟过的人。而最要命的，不仅仅是“这段代码是做什么的？”，更是“为什么当初要这样写，我改了会不会出事？”

结果是行内经验的不断流失。这不仅使带新人更加困难；也使得解决老毛病技术债变得更加困难。如果新接触代码库的人一头扎进去就开始修改，你就面临着搞出一堆乱子的风险。每一次试图修复技术债（这本身就是一个拖了几十年、越来越严重的问题）的尝试，都变得更难搞、更冒险，这使得技术债更没人愿意碰。这也让带新人更加困难和耗时，同时增加了出大错的风险。

所以，大家很容易觉得生成式AI能出手帮我们搞定这事儿。毕竟，就算你不想把大型语言模型（LLM）直接扔到老代码库里——而且不该这么干的原因多了去了——让它自己根据代码库生成文档，听着好像能补上没别的书面资料的短板。LLM确实能帮你把代码总结出来。

但先别急着这么想。除了瞎编乱造，还有个更深的问题：写文档本身就是思考过程的一部分。不管我是在写历史还是写软件，在花几个小时写代码之前，先把思路用话说清楚，能帮我把方案打磨得更好。文档还能记下你当初的意图。LLM可能能总结代码库是干嘛的，但它没法靠谱地解释开发者为啥选这个方法不选那个，或者当时是咋权衡的。

再说，文档也是让别人明白你为啥这么干的机会。如果他们打算改我写的东西（特别是几年后），他们就能懂我为啥非得那么写，以及删了可能会丢啥。LLM能读我写的代码，甚至能扫一遍整个大代码库，准确说出它在干啥。但它没法判断作者的心思。

解决方案不是把动脑子的事儿甩给别人，至少你要是想少欠技术债、让新人上手更轻松的话。反过来，得重新捡起写东西这回事，至少是那些对我们管用的部分。就像科技圈儿里有口头沟通的文化，也有写东西的文化，这俩能和平共处。最好的例子之一就是ARPANET开发那会儿，工程师们搞出了一种围绕RFC（也就是“征求意见稿”）的文化：这玩意儿就是非正式的小纸条，用来聊标准、问题、方案和最佳做法。有的写得一本正经，有的带点幽默，但全都是写给同行工程师看的。想象一下用同样的心态来写文档：别把它当成给经理交差的官样文章，而是当成跟将来接手你代码的人交流。

咱们不把文档当回事儿，最后倒霉的是自己。过去这方面做得并不好：瀑布模型之所以栽跟头，很大原因就是逼着工程师给项目经理和领导写报告、写材料。他们可以自己写文档，也确实该写。至于咱们，也得把自己的那份写出来。