12G 本地推理生产线 ⑧ 四问知识库方法论：让 AI 系统不再重复踩坑

四问变更日志、三要素经验条目、快照证据链、git 版本化——让任何新会话五分钟还原全部状态

2026-10-21 约 1531 字预计阅读 4 分钟

前六篇记录了这条推理生产线怎么搭起来的。这一篇回答最后一问：怎么让这套东西的知识不随会话蒸发？

自托管系统的状态散落在配置文件、启动日志、显存/内存快照、事故记录里。一次典型事故（第 3 篇的"专家缓存从 955 掉到 146"）如果不落盘，下次再出就是重新假设、重新排除、重新跑日志——小时级。而 Agent 会话没有"记得上次"，每个新会话都从零开始猜。

解法不是"写更多文档"，是一套固定格式的知识库 + 强制执行协议。

外加 git 版本化整个知识库——文档本身也有版本，回滚有据。

“如何验证"必须写验收线，不写"跑了一下没问题”。 本系列的 1728 验收写了 6 条硬线（955 experts / 1.84G、3 条 7–9K 大生成、无 #2065 警告行、42 t/s 档、无 exit -9……）——“没问题"是下结论，不是证据。

“如何恢复"是排障时最先看的一问。 改崩了 30 秒内知道怎么回（cp 哪个快照回来 + 重启），不需要回忆。多数变更日志缺这两问，缺的恰恰是排障最要命的部分。

快照目录存四样：改前/改后配置（带 sha256）、引擎日志全文、环境快照（nvidia-smi 逐进程分解表）、终端验收贴件。每条变更记录登记快照路径 + 校验和。

收益实测：几个月后翻"当时 reserve 到底是多少”，sha256sum 一对比就知道用的是哪份；换硬盘重建，按快照目录逐项拷回即可。

规则一（L14）：expert cache 数量偏离预期，第一假设是环境脏，不是配置错。 第 3 篇那 146 experts 就是脏启动。标准动作 = nvidia-smi 零检查（空闲 ≥ 11G = 干净；桌面基线 2.3–2.4G 逐进程有账），清环境重测，不动配置。

规则二（L16）：不要在脏环境假设上提配置回滚。 当时基于脏启动的 1.03G free 建议过回滚 512；干净环境重测 1728 本身健康，回滚建议纯属白扔保护。参数改动的门槛 = 干净环境下的实测数据，永远不是事故现场的脏数据。

这两条的共性：先分"环境因素"与"配置因素”，环境因素先清环境，干净环境仍不达标才改参数。 这条规则比任何单篇参数教程都耐用。

不依赖 Strata：ComfyUI、vLLM、OpenClaw、CI 环境全适用。固定成本 ≈ 半小时搭目录 + 一条纪律；变动成本 = 每次改动多写 4 行。换来的：

排障时间从小时级降到分钟级，且知识不再随会话蒸发。

一句话：知识库不是写给自己看的文档，是给"下一个五分钟后已经失忆的会话"看的交接协议。

系列完结。八篇：总览 → 三维 OOM → 显存调优 → 窗口/KV → 量化选型 → 长文 SOP → 接入 Hermes → 知识库方法论。下一篇（非本系列）：这条零成本生产线怎么变成现金流。