如何设计一份属于自己的个人技术文档,让经验不会失传

经验不等于资产，被记录复用的才算

PROLOGUE · 引子

我以前有一个很大的误区。总觉得自己工作了十几年，经验应该已经很多了。做过很多项目。踩过很多坑。解决过很多问题。也经历过一些别人没有经历过的事情。这些东西，应该已经成为了我的能力。

但有一天，我突然发现：很多经验其实并没有真正留下来。它们只是存在我的脑子里，存在聊天记录里，存在某个已经结束的项目里，甚至存在某个我已经记不清名字的会议里。如果有一天我离开现在的工作环境，这些东西可能就跟着一起消失了。

那一刻我开始意识到：经验不等于资产。只有被记录、被整理、被复用的经验，才真正开始成为自己的资产。

做程序员久了，很容易产生一种错觉。工作时间越长，处理过的问题越多，自然就越有经验。但后来我发现：真正拉开差距的，不是经历过多少事情，而是：你有没有把经历转化成自己的知识系统。

比如我曾经解决过一个很复杂的线上问题。当时花了两天时间排查，日志看了很多，代码改了很多，最后终于定位到原因。问题解决之后，我松了一口气，然后就结束了。

几个月以后，类似的问题再次出现，我又重新排查了一遍。后来我才发现：我并不是解决过这个问题，我只是经历过一次这个问题。两者完全不同。经历，如果没有沉淀，很容易失传。

公司有技术文档。项目有架构文档。接口有 API 文档。系统有运维手册。为什么？因为我们知道：不能把系统运行所需要的知识全部放在某一个人的脑子里。否则这个人一离开，系统就会出现知识孤岛。

我突然觉得：一个人的职业生涯，其实也是一个复杂系统。那么，我是不是也应该给自己建立一份文档？不是写给公司看的，不是写给领导看的，也不是为了绩效考核，而是写给未来的自己。

我把它叫做：个人技术文档。它记录的不是“我做过什么”，而是：我从这些事情里，真正学到了什么。

最开始其实很简单。每当遇到一个值得记录的问题，我就留下一个条目。比如以下这些问题：

为什么这个项目最后延期了？为什么这个需求反复修改？为什么一个看起来很简单的系统，最后变得越来越复杂？为什么一个团队明明技术能力不错、项目却推进得很慢？为什么某些方案在技术上很好、最后却没有被采用？

这些问题表面上是项目问题。但如果认真分析，会发现里面往往隐藏着很多规律。技术只是其中一部分。还有组织、沟通、利益、资源、决策、人的行为。这些东西，才是工作十几年以后越来越重要的经验。

仅仅记录问题还不够。还要记录自己的解决过程。当时有哪些判断？排除了哪些可能性？用了什么方法？为什么最后选择这个方案？哪些尝试失败了？哪些东西其实是走了弯路？

以前我特别容易只记录最终答案。现在我越来越重视过程。因为未来真正需要复用的，往往不是答案，而是：当我再次遇到类似问题时，我应该如何思考。这其实就是经验真正有价值的地方。

这一层开始变得有意思。我会把某个问题进一步抽象。比如：

一次项目延期，可能最终不是因为“开发效率低”，而是需求没有稳定输入。一次团队冲突，可能不是某个人“不配合”，而是双方的目标函数不一致。一次技术方案被否决，可能不是方案不好，而是方案没有解决决策者真正关心的问题。

当我开始这样整理的时候，我发现：经验开始从案例变成模型。案例只能告诉我“那一次发生了什么。”模型则可以告诉我“下一次可能还会发生什么。”这两者的价值完全不同。

再往下，我开始记录一些更抽象的东西。比如：什么情况下我不会再继续堆技术方案？什么情况下我会选择先做小实验？什么情况下我会接受一个不完美的方案？什么情况下我会拒绝一个需求？什么情况下我会选择离开一个项目？

这些东西以前都是凭感觉。现在我开始尝试把它们写下来。因为我越来越发现：真正决定一个人长期表现的，往往不是知识，而是判断。知识告诉你有哪些选择，判断告诉你什么时候应该选哪一个。而判断，本身也是可以沉淀的。

一开始建立个人文档，很容易走向另一个极端。什么都记：看到一篇文章记下来，看到一个工具记下来，看到一句话记下来，收藏一个网页，保存一个视频，最后整个系统变成一个巨大的资料仓库。看起来知识很多，实际上越来越难用。

后来我给自己定了一个原则：只记录那些改变过我判断的东西。一个知识，如果只是“知道了”，不一定值得长期保存。但如果它让我改变了一次决策、解决了一个问题、避免了一次错误、形成了一个新的方法，那么它就值得留下来。

这时候，个人文档就不再是“收藏夹”，而开始变成：个人经验数据库。

以前写文档，我习惯记录成功方案：最后用了什么技术，最后采用什么架构，最后怎么解决问题。但现在，我反而越来越重视失败。因为成功往往有偶然性，而失败通常会暴露系统里的真实问题。

为什么这个项目没有做成？为什么我当时判断错了？为什么我明明知道问题、却没有行动？为什么一个看起来正确的决定、最后结果并不好？这些东西如果不记录，很容易被时间抹掉。几年之后，我只记得“当时挺难的。”，但已经想不起：我到底在哪里判断错了。

所以现在，我会给自己留下一个简单的“事故复盘”。不是为了责备自己，而是为了让未来的自己少交一次学费。

个人技术文档最有价值的时刻，不是写完的时候，而是下一次遇到类似问题的时候。比如：遇到一个新的项目，搜索一下过去的经验；遇到一个新的职业选择，看看过去类似的判断；准备做一个副业，看看以前做项目时踩过的坑；准备学习一个新领域，看看过去自己的学习方式为什么有效或者无效。

这时候，文档开始产生复利。过去的一次经历，经过记录、经过抽象、经过复盘，最终变成下一次决策的输入。经验开始被重复使用。这才是真正的知识资产。

我以前想过很多次：如果十年以后，我离开程序员这个职业，我还能留下些什么？代码可能没了，项目可能没了，公司可能没了，甚至曾经使用过的技术，也可能已经过时。

但我希望留下来的，是另外一些东西：我解决复杂问题的方法，我判断事情的方式，我踩过的坑，我对人的理解，我对工作的理解，我对自己的理解。这些东西不依赖某家公司，也不依赖某一种技术，它们才是真正属于我的东西。

所以我现在越来越觉得：一个程序员真正应该维护的，不只是代码仓库。还应该有一个属于自己的：人生知识仓库。

“积累”这两个字。以前我以为：积累就是工作年限越来越长。后来发现不是。如果十年的经验只是重复了一年十次，那也未必是真正的积累。

真正的积累应该是：经历一次，记录下来，复盘一次，抽象一次，下一次遇到类似问题时，能够更快地做出判断，然后再把新的经验写回系统。

我现在也在尝试给自己建立这样一份个人技术文档。它可能不漂亮，甚至一开始很凌乱。但我希望几十年以后回头看，它不是一堆笔记，而是一本真正属于自己的：人生运行手册。

记录我怎么工作，怎么思考，怎么做决定，怎么犯错，怎么重新开始。也记录一个40岁程序员，是怎样一点一点，把过去的经验，重新编译成未来可以使用的能力。

因为我越来越相信：人生最可惜的事情，不是犯过错。而是：同一个错误，人生重复运行了很多次。

所以，从现在开始。把经验留下来。让它不要只活在记忆里，让它成为下一次人生迭代时，可以调用的代码。

我是 语霖，执笔为语，心落成霖。

如果这篇对你有启发，欢迎点赞、在看、转发，我们下篇见

THANKS FOR READING