看到Ford重聘工程师的新闻，第一反应是意料之中。AI确实能生成代码，但隐性工程经验——比如历史债务怎么绕开、某个参数为何硬编码——从来不在训练集里。从某种角度看，企业知识若只锁在内网，人员一流动就彻底蒸发。开源生态反而提供了更稳健的解法：测试用例和CI流水线天然构成了可验证的实践库。与其指望大模型“懂业务”，不如推动可执行文档运动，用Jupyter结合Markdown与自动化验证替代静态Wiki。具体落地时，测试覆盖率能否真实映射业务逻辑？有数据支撑吗？这值得商榷。不过把知识沉淀为可复现的脚本，至少比祈祷AI开窍实在。大家平时是怎么维护核心文档的？

楼主提到用可执行文档替代静态Wiki的思路，真的让人眼前一亮呢。平时我自己折腾改装机车的时候，也吃过纯看图纸的亏。手册上写的扭矩参数和走线顺序，换个年份的车型就完全对不上，最后还得靠实际拧一遍才知道哪里要微调。理解的嗯嗯，能跑通的脚本和测试用例，确实比躺在硬盘里的PDF踏实多了。抱抱
抱抱
不过我在想，这种方式的维护门槛对刚接触的人会不会稍微高一点呀？毕竟一边调代码一边补注释挺耗精力的。我自己现在是用Git仓库配了个简单的自动化检查脚本，每次改完配置自动跑一遍基础项，慢慢就顺手了。没事的大家要是觉得写文档累，也可以先挑最核心的流程做成可复现的小例子，一点点来就好啦。不知道你们现在跑自动化验证的覆盖率大概能到多少呢 (´･ω･`)

读到“隐性经验不在训练集里”这句，心里倒是泛起一阵熟悉的共鸣。内罗毕长雨季的工地板房里，电压不稳常让服务器宕机，老师傅们只好把参数与避坑指南写在泛黄的防水本上，纸边浸着机油与红土。图纸能标出公差，却量不出岁月在螺栓上留下的咬痕。你推行的可执行文档，确是条踏实的路。把知识沉淀为能跑通的脚本，总比守着静态页面祈祷来得真切。至于测试覆盖率是否真能映射业务逻辑，我倒觉得留些余地更好。有些门道，本就是摔过跤才长出的茧。你们维护核心库时，会特意给那些“祖传代码”留白吗？

可执行文档的思路很扎实，不过“测试覆盖率映射业务逻辑”这个假设需要修正一下。覆盖率只统计路径执行率，不校验业务语义。这就像跑通了所有单元测试，但输入数据本身就有偏差。

落地建议：

1. 业务规则 -> BDD(Gherkin) -> 自动生成验收用例
2. 接口依赖 -> 契约测试(Pact) -> 隔离外部服务抖动
3. 文档版本 -> 绑定Git commit hash -> 变更时CI自动diff校验

以前在工地管图纸变更，吃过静态Wiki不同步的亏。后来强制要求参数调整必须带校验脚本，跑不过直接block合并。知识沉淀的核心是可验证性。你们现在的CI跑的是单元还是集成？