技术文档为什么总是过期的？

叙事型的笔记，可以靠连接和检索激活。但参数这类东西，不是找不找得到的问题，是改了一处、有多少个地方要跟着动的问题。

生产那边反馈说容量对不上，让我去核一下数据。

我打开共享盘，找到三个月前那次改版的规格书，看到电池额定容量已经改成了 50Ah——ECN 走完了，审批记录也在系统里。

但那次我只改了规格书。BOM、特殊特性清单、FMEA 有没有跟着同步，我当时没想到。

翻出来一看：XX 项目规格书、XX 项目 BOM、XX 项目特殊特性清单、XX 项目 FMEA——四份文档，四个地方写着这个参数，但对不上。有的改了，有的没改，有的是我自己也说不清楚改在哪一版。

文档过期，不是因为没人认真

我在工位上想过这个问题：这种混乱，到底是谁的错？

不是哪个人的错。是这套工作方式本身有个结构性缺陷——文档和数据是两件事，但我们把它们当一件事在管。

没有管理系统的公司，问题是显而易见的：文件散落在各人电脑里，同步靠发邮件，版本靠文件名区分，出了问题没法追溯。

但有意思的是，用了 PLM 系统的公司，这个问题大多数情况并没有消失，仍然需要人工处理。

ECN 走完了，系统里留着完整的审批链——谁提的、谁审的、什么时候批的，证据齐全，合规没问题。但系统记录的是”这次变更发生过”，不是”这个参数还出现在哪些文档里”。

当你把电池容量从 48Ah 改到 50Ah，系统不会告诉你：规格书、BOM、特殊特性清单、FMEA——这几份文档里也有这个数字，要同步。流程帮你留下了合规的证据，但没有帮你找到需要修改的地方。

一份 Word 规格书里，有排版，有表头，有公司 Logo，也有那个 48Ah 的参数值。这两种东西被打包在同一个文件里。当参数发生变更时，你得打开每一份文档，找到那个数字，手动改掉。只要有一个地方漏改，那份文档就”过期了”。

不是你不认真，是这件事本身的结构注定了它很难做对。就像你在四面墙上分别写了”禁止吸烟”，其中一面重新粉刷了墙，字没描回去，那面墙就”过期”了。因为”字”依附在”墙”上，墙一变，字就失效。而字一变，又需要修改四面墙。

参数住在文档里，就是住在危险里

我以前维护过一个产品家族，三个型号，共用一个基础铝型材端板。

某次设计变更，定制款的端板厚度从 2mm 改成了 2.5mm。这个参数改动本身很小，真正麻烦的是后续：

我当时是逐一打开，逐一修改，自以为改全了。

直到三个月后，客户拿着那份没改到的英文版规格书问我：这里的厚度是 2mm，是不是有错误？

那一刻，我才发现：英文版是单独维护的，当时忘了。

这就是”参数住在文档里”的代价——参数和文档的命运绑定在一起，文档一多，这根绳子就越来越乱。

分离是一种结构设计

后来我想明白了一件事：解决这个问题，不是靠更认真，而是靠改变结构。

让参数住在参数该住的地方——一个统一的数据源。

让文档变成这份数据的”视图”，而不是把数据手抄进去的副本。

当你需要输出一份规格书，就把参数注入模板，渲染出来。当你需要输出一份 DFMEA，就从同一个数据源取数据，再渲染。参数改了一次，所有文档在下次生成时自然跟着变——不需要你去每份文档里找那个数字。

这个思路，在软件开发里早就是常识：前端页面和后台数据库是分开的，页面不存数据，只是把数据展示出来。数据库里的数字更新，刷新页面就能看到最新值。

我们做工程文档，其实也是同样的问题，只是过去没有把它当成一个”分离”的问题来解决。

Markdown 分离内容和格式，是同一件事

前面几篇说过，我把工程笔记都改成了 Markdown 格式。

Markdown 做的事情，和”文档与数据分离”在逻辑上是一脉相承的。

Markdown 文件里只有内容，没有格式。字体是多少号、行距多宽、表格要不要底纹。这些不在文件里，由渲染器决定。你换一个渲染器，同样的 .md 文件可以输出成完全不同的样式。

这就是内容和格式的分离。

更进一步，如果文档里的某些数据也不是手写进去的，而是从一个参数库里拉取的，那就是内容和数据的分离。

两层分离叠在一起，就是：数据库维护参数 → 模板定义格式 → 渲染器负责输出。

任何一层单独变动，不会污染其他层。改数据，不影响模板；改模板，不影响数据；渲染引擎升级，两者都不动。

这套逻辑，是工程文档管理能走得更远的前提。

就像《规模》里讲的，当数量级提升，旧的管理方式会失效——不是因为旧方式不好，而是它本来就不是为这个量级设计的。

当你只有三份文档，手动维护也能过。当你有三十份文档，同一个参数出现在十几个地方，手动维护的漏改概率就不是靠认真能压住的了。

那时候，结构才是真正的答案。