LLM 最危险的不是答错，而是把错写进 wiki：我用 lint + git 把“知识污染”治住了（附清单/模板）

我做这套“编译式知识库”（raw → wiki → 交付）的第一周，体验非常爽：
一篇新资料扔进去，LLM 能更新索引、补概念页、做对比表、加交叉链接——甚至一次触碰十几页。后来我才意识到：这既是优势，也是最致命的风险。

因为当 LLM 写错时，它不是“错一次”，而是把错误沉淀成长期资产，然后在后续 ingest/query 里不断引用、不断扩散——你得到的不是一次性幻觉，而是会增殖的“知识污染”。

这篇文章我只讲一件事：我如何用 lint（体检）+ git（回滚）+ schema（规约）把知识污染从“不可控”变成“可控”。思路来自 Karpathy 在 2026-04-04 发布的 LLM Wiki 模式：raw/wiki/schema 三层 + ingest/query/lint 三操作 + “wiki 就是一个 git 版控的 Markdown repo”。 

1）我怎么第一次踩到“知识污染”（一个可复用的事故模板）

你可以把这个案例替换成你真实经历：产品口径、法务合规、竞品参数、旅行政策、医学营养……任何“看似小错但会反复被引用”的信息都行。

事故场景：团队口径 / 方案结论被写进 wiki

• 我做了一份主题 wiki：把会议纪要、竞品文档、报价邮件、法规条款等都放进 raw。raw 只存证据，不让 LLM 改（source of truth）。 
• 某次 query，我问：“我们为什么选方案 A，不选 B？”
• LLM 给了一段非常顺滑、结构很漂亮的回答，并“顺手”把这段写进了 wiki/decisions/xxx.md（它会把好的回答回填进 wiki，这也是 LLM Wiki 的关键：探索会沉淀、会复利）。 
• 一周后 ingest 新资料时，LLM 又依据这段“决策理由”去更新了对比表、索引、概念页（跨页维护本来就是它的强项）。 

问题在这里爆炸：
那段“决策理由”里有一句关键事实是错的（比如：某竞品支持某功能 / 某条政策允许某做法 / 某项成本估算低了一个数量级）。错一次不可怕，可怕的是它被写进了“稳定页面”，随后被反复引用，变成“组织常识”。

我后来回看才明白：LLM Wiki 让知识能积累，也让错误能积累。你不做治理，系统越用越危险。

2）为什么这种污染在 LLM Wiki 里特别容易发生（机制讲透，才能治）

Karpathy 的核心设定有三点（也是污染高发点）：

1. wiki 是“持久、复利的中间层”
   ：LLM 不再每次从 raw 临时拼答案，而是维护一套结构化、互链的 Markdown wiki。
2. 一次 ingest 会触碰很多页面
   ：他明确写到“一个来源可能触碰 10–15 个 wiki 页面”。 
3. 好的 query 结果应该回填
   ：否则答案会消失在聊天历史里。

把这三点合在一起，你会得到一个现实：

LLM 在这个体系里不是“回答问题”，而是在“写代码”（写 wiki 文件）。
既然它在写文件，那就一定会出现：回归错误、连锁修改、依赖扩散、技术债——以及“知识污染”。

所以你要做的不是“让它永远不犯错”（做不到），而是建立一套工程化防线：可审计、可体检、可回滚。

3）我用的三道防线（结论先给）

第一道：raw 不可变（证据层锁死）
raw 是唯一真源，LLM 只读不写；任何结论必须能回指 raw。

第二道：lint 不是“偶尔检查”，而是固定产出的体检报告
lint 要找：矛盾、过时、孤岛、缺页面、缺交叉引用、缺口要补资料（Karpathy 把这些写得很具体）。

第三道：git 工作流（把 LLM 当会写文件的同事）
wiki 是 git repo：你要 diff、要分支、要回滚、要可追踪。 

下面我把每一道防线写成“你照抄就能跑”的实操。

4）第一道防线：raw 锁死 + 证据链强制化（最关键）

4.1 raw 目录的硬规则

• raw 里放：网页剪藏、PDF、截图、录音转写、数据表、邮件原文
• LLM 永远不允许改 raw
  （你要修 OCR/去水印，也要保留原始版本或记录变更）
  Karpathy 明确把 raw 定义为 immutable、source of truth。

4.2 任何“稳定结论”必须带来源

我对“稳定页面”（例如概念定义、决策结论、对外口径）强制加一段：

• Sources（证据）
  ：列 raw 文件名/链接
• Assumptions（前提）
  ：这条结论依赖哪些条件
• Expires/Review（复核时间）
  ：时间敏感内容必须有复核点

这样做的效果很直接：
你把“LLM 的顺滑叙事”拆回“可检查的证据+前提”。一旦有人质疑，能立刻回到 raw，而不是在 wiki 里互相引用转圈。

5）第二道防线：lint 体检（把污染变成“工单”）

Karpathy 的 lint 定义非常清晰：定期 health-check，找矛盾、过时、孤岛、缺页、缺交叉引用、数据缺口并建议补 web search。

我把 lint 具体化成一个固定输出：每次 lint 生成一份报告 + 一份待办。

5.1 lint 检查清单（你可以直接贴进 schema）

A. 证据链与可审计性

• 稳定页面（status=stable）是否都有 sources？
• 结论段落是否存在“无来源断言”（例如“显然”“业内都知道”“一般来说”）？
• 是否出现“引用了 wiki 但没有引用 raw”（自我循环引用）？

B. 一致性（Contradictions）

• 同一概念是否出现两套定义？
• 同一指标口径是否前后冲突？
• 同一决策的理由是否在不同页面被改写成不同版本？

C. 时效性（Stale claims）

• 是否存在“当时成立、现在可能过时”的结论（政策/价格/版本/功能）？
• 超过复核日期仍未复核的页面列表

D. 结构健康（Orphans / Missing links）

• 孤岛页：没有任何入链（Karpathy 明确点名 orphan pages）。
• 关键枢纽页是否过载（所有东西都往同一页塞，导致“神页”不可维护）

E. 知识缺口（Data gaps）

• 哪些关键问题缺 raw 证据？
• 建议补哪 3 个来源（并写清“补它是为了验证什么”）

5.2 lint 报告模板（固定格式 = 复利）

Markdown

# LINT REPORT — YYYY-MM-DD
## 1. Executive Summary
- contradictions: X
- stale pages: Y
- orphan pages: Z
- missing sources: N
## 2. Critical Issues (must-fix)
1) [CONTRADICTION] [[concepts/XXX]] vs [[decisions/YYY]]
   - conflict: ...
   - suspected cause: ...
   - proposed fix: ...
   - required raw evidence: raw/...
## 3. Warnings (should-fix)
- [STALE] [[...]] review_by passed
- [NO-SOURCES] [[...]] contains claims without sources
## 4. Suggested Next Sources
- source idea 1: ...
- source idea 2: ...
## 5. Change Plan (if applying)
- files to edit:
  - ...
- files to create:
  - ...

关键点：lint 不只是“指出问题”，而是把问题变成可执行的变更计划。否则你会永远停在“发现很多问题”的焦虑里。

5.3 为什么我建议加 YAML frontmatter（让 lint 变“可计算”）

你不需要复杂数据库，但你需要最少的结构化元数据，让查询/体检更可靠。

我给每页加一个最小 frontmatter：

YAML

---
type: concept|decision|summary|comparison
status: draft|stable|stale
confidence: 0.0-1.0
sources:
  - raw/2026-04-01_xxx.md
updated: 2026-04-14
review_by: 2026-05-14
---

如果你用 Obsidian，Dataview 能直接把 YAML frontmatter 当字段查询，生成表格（例如列出 status=stale 的页面）。

6）第三道防线：git（把 LLM 当“会写文件的同事”，而不是神谕）

Karpathy 说得很直白：wiki 就是一套 Markdown 文件的 git repo，你天然拥有版本历史、分支与协作。

我的做法也很简单：所有大改动一律走分支。

6.1 我最常用的 4 个动作（够用了）

1. 每次 lint-fix 开新分支

Bash

git checkout -b lint/2026-04-14

1. 让 LLM 先生成“变更计划”，再落盘
   
   两段式写入（Plan → Apply），能极大降低“它一口气改 20 个文件但你不知道改了啥”。
2. 只看 3 类 diff

• 改了“结论句”的（最危险）
• 改了“定义/口径”的（会扩散）
• 删除了 sources / assumptions 的（直接拒绝）

1. 必要时一键回滚

Bash

git revert <commit>
# 或
git reset --hard <good_commit>

6.2 一个我强烈推荐的纪律：稳定页面需要“保护模式”

• status: stable
   的页面，LLM 不允许直接改正文结论
• 只能：
1. 新增“补充段落”并标注来源
2. 或把它降级为 status: stale，等待你复核后再恢复 stable

这条纪律的价值是：
你把“自由写作”变成“受控变更”，知识库就不会像野草一样到处窜。

7）我最真诚的提醒：这套体系的坑，不在工具，在人性

最后说 3 个我认为最容易把人坑死的点——也最值得你写出来建立可信度：

1. “写得像真的”比“写错”更危险
   
   LLM 的强项是顺滑叙事；你必须用 raw 锁死证据链，否则它会把不确定写成确定。
2. “回填答案”是复利点，也是污染入口
   
   Karpathy 强调好答案要回填进 wiki。 
   所以你必须先有 lint + git，否则回填越多，污染越快。
3. 不做 lint 的 wiki，会在 20–50 个来源后开始腐烂
   
   不是因为你笨，是因为“维护成本”在指数增长；Karpathy 这套思路的本质就是把维护劳动交给 LLM，但你仍需治理框架（schema）来约束它。

附：你可以直接抄走的“反污染最小套装”（一页总结）

• raw：immutable，source of truth（LLM 只读不写）
• schema：写清 ingest/query/lint，写清页面类型、命名、证据链、稳定页保护规则
• lint：固定输出 LINT REPORT + change plan；检查矛盾/过时/孤岛/缺证据链
• git：分支 + diff 审阅 + 可回滚（把 LLM 当同事）
• （可选）frontmatter + Dataview：把“体检”变成可计算清单

松花酿酒，春水煎茶。

眉上风止，见字如晤。

一只阿木木