嵌入式老项目的经验,80%藏在文档外面

你手里有文档对吧？功能说明、接口定义、参数表，该有的都有。

但如果你仔细想想，一个维护了三五年的老项目，真正值钱的那些知识，到底在文档里还是在别的地方？

答案是：大部分不在文档里。

文档只覆盖了冰山一角

大部分老项目的文档，写于项目初期。

那时候什么状态？需求刚确定，功能还没做完，文档写的是“这个东西应该是什么样的”——功能清单、接口定义、通信协议、基本参数。

然后项目进入开发阶段，需求改了，代码跟着改。文档呢？改了一部分，剩下的没顾上。

再往后量产了，进入维护期。修bug、加功能、适配新硬件版本。每一次改动都在代码里，有多少人同步更新了文档？

到了今天，你手里的文档，覆盖的可能只有这个项目20%的知识。

剩下80%呢？

那80%都藏在哪

先说一个常识：嵌入式项目的经验密度，比大多数行业都高。

一个跑了三五年的产品，中间经历了多少事情？

硬件改了几个版本。每个版本的跳线不一样，某些引脚的功能有变化，电源方案从LDO换成了DC-DC。这些在文档里有吗？大概率没有。

固件也迭代了很多版。某个中断优先级为什么不能调，调了会在特定工况下偶发死机。某个通信超时为什么设了200ms而不是100ms，因为总线负载率高的时候100ms不够用。这些在文档里有吗？工程师自己都记不全。

客户现场出了各种问题。有些是使用不当，有些是环境干扰，有些是固件bug。怎么排查的、怎么解决的、下次怎么避免——这些经验，在谁的脑子里？在当时的售后和研发脑子里。

还有更隐蔽的：新人的踩坑记录。刚接手这个项目的时候，哪些地方容易搞混、哪些配置容易忘、哪些操作有坑——这些知识更不可能写在文档里，因为经历过的人觉得“这不是常识吗”，但新人不知道。

把这些加起来，你会发现：

项目真正核心的知识，不在文档里，而在人的脑子里、聊天记录里、提交记录的注释里、某个被遗忘的Excel表格里。

为什么以前搞不定这些知识

不是没人想过要整理。

很多团队试过。让工程师写技术文档，推不动。建知识库，建了几天就没人维护了。搞FAQ，写了几十条就停了。

为什么推不动？

因为这些知识是非结构化的。

它不是“功能A的参数是B”这种整齐的信息。它是“为什么A的参数是B而不是C，因为C在温度高的时候会漂移，2019年夏天出过一批客诉，后来改成了B”。

这种知识，传统文档格式很难承载。

你让工程师把这个写进文档，他得组织语言、理清逻辑、找到合适的位置放进去。这个工作量比写代码还大，写完了也没人看，因为后来的人不知道这条知识在哪篇文档的哪个角落。

所以大家自然就不写了。写了也白写，不如直接记在脑子里。

换个思路：不是整理文档，是整理知识

AI来了之后，这件事的解决思路变了。

以前是：找到知识 → 写成文档 → 分门别类 → 维护更新。四步都很重。

现在是：把资料喂进去 → AI自己理解 → 你问它答。

不需要你把知识“整理”成文档格式。源码、注释、提交记录、硬件版本说明、聊天记录、Excel表格——原始素材丢进去就行。

AI做的是从这些素材里提取出“知识”，然后以问答的方式呈现出来。

你问“这个GPIO为什么配成推挽输出”，它不是去找文档，而是结合源码上下文和注释，给你一个解释。

你问“固件v2.3和v2.4有什么区别”，它不是去翻变更日志，而是从提交记录和代码差异里告诉你。

你问“客户反馈通信超时怎么排查”，它从历史问题记录里提取排查步骤。

这些事情以前做不到，是因为没有工具能同时理解代码、文本、表格和聊天记录。

现在有了。

最关键的转变

说实话，AI能做到的程度，取决于你喂了多少素材进去。

但这里有个好消息：你不需要把那80%全部整理好再喂。

先从最容易获取的20%开始——源码和注释。这是现成的，不需要额外整理。AI从源码里能提取出来的知识量，比你想象的多。

然后逐步补充。项目交接记录、硬件版本差异、历史问题清单，找到什么就补什么。不用一次到位。

最难整理的那些——藏在人脑子里的经验，可以通过问答的方式来提取。老工程师在用系统的过程中，发现AI回答不到的地方，他自己补充进去。这比让他从零写文档轻松得多。

关键不是你现在有多少，是你开始往里积累了。

知识的价值不在于存了多少，在于需要的时候能不能找到。

那80%以前找不到，是因为它们散落在不同的地方，没有一个统一的方式去检索。