llm-wiki-compiler审查策略实战：让人工审核AI生成的页面，防止幻觉污染知识库-开发者社区

llm-wiki-compiler审查策略实战：让人工审核AI生成的页面，防止幻觉污染知识库

【免费下载链接】llm-wiki-compilerThe knowledge compiler. Raw sources in, interlinked wiki out. Inspired by Karpathy's LLM Wiki pattern.项目地址: https://gitcode.com/gh_mirrors/ll/llm-wiki-compiler

llm-wiki-compiler是一款把原始资料"编译"成互链 Wiki 知识库的开源工具，而它的审查策略（Review Policy）正是为 AI 生成内容上的第一道安全阀：在页面写入wiki/之前，先由人工把关，从源头防止 LLM 幻觉混入你的知识库。本文带你快速上手--review全量审查、自动拦截策略、四大数据风险信号，以及审批队列的日常操作。

为什么 AI 生成的页面需要人工审查

llm-wiki-compiler 遵循 Karpathy 提出的 LLM Wiki 模式：先把论文、笔记、网页等原始素材一次性编译成带引用、带元数据的 Markdown 页面，而不是每次提问都临时拼凑。这个模式的最大优势是知识会不断积累复用——但同时也意味着，AI 写错的每一页都会被反复引用。

一次幻觉、一处编造的引用，如果被直接写进wiki/，就会成为后续所有查询和 Agent 上下文的一部分，像污染水源一样扩散。审查队列的价值就在于：在你点头之前，wiki 绝不改变。

两种审查入口：全量拦截与自动策略

llm-wiki-compiler 提供两层审查机制，可按团队信任程度自由选择（详见 review CLI 文档）：

一键全量审查：compile --review

给任意 compile 命令加上--review，所有新生成的页面都会先进入.llmwiki/candidates/候选目录，而不是直接落盘：

llmwiki compile --review

这是"全有或全无"模式——适合冷启动阶段、或对模型输出还不够放心的场景。

自动拦截策略：只拦风险页，放行安全页

更精细的做法是在.llmwiki/config.json中声明一份审查策略，让常规编译照常直写大多数页面，只自动拦截触发风险条件的少数页面（完整配置说明见 review-policy.mdx）：

{ "version": 1, "review": { "hold": ["low-confidence", "contradicted", "schema-violating", "provenance-violating"], "lowConfidenceThreshold": 0.5 } }

这样"高置信度页面秒写、风险页面排队"，在审查摩擦与编译效率之间取得平衡。

四大风险信号：哪些页面会被自动拦截

策略的判定逻辑是一段纯函数式的规则评估（源码：policy.ts）：页面触发任一启用的模式即被暂扣，原有线上页面保持不动。各模式含义一目了然：

风险代码	触发条件	拦截的理由
`low-confidence`	页面`confidence`低于阈值（默认 0.5），或干脆没写置信度	模型自己"不确定"，幻觉风险最高
`contradicted`	页面声明了`contradictedBy`，与其他页面内容冲突	知识自相矛盾，需人工裁决
`schema-violating`	未通过`.llmwiki/schema.json`的交叉链接规则	结构性不完整，可能是拼凑出的内容
`provenance-violating`	引用指向不存在的源文件、行号范围非法或引用标记损坏	证据链断裂——幻觉的典型信号
`all`	无条件拦截所有页面	等价于`compile --review`，但持久生效

每次编译结束后，llm-wiki-compiler 会报告拦截结果，例如Wrote 8 page(s), held 2 for review，让你对知识库的"进出账"心中有数。

审查队列日常操作：4 条命令走完审批流

被暂扣的页面会带着明确的拦截原因码存储在.llmwiki/candidates/中，用 review 子命令即可逐个处理：

llmwiki review list # 查看待审候选及拦截原因 llmwiki review show <id> # 预览全文、引用、置信度、冲突标记 llmwiki review approve <id> # 批准：写入 wiki/ 并刷新索引 llmwiki review reject <id> # 拒绝：归档留痕，不动 wiki/

几个值得注意的设计细节：

审批不重新调用大模型。批准的页面就是你审查过的那份字节，杜绝"审的是 A，上线的是 B"。
拒绝是有粘性的。被拒候选移入.llmwiki/candidates/archive/供审计；只要源文件不变，下次编译不会重新生成同页。
批量审批。review approve-batch --input <manifest.json>可用一次锁、一次共享刷新批准最多 100 个候选，适合周期性集中审查。
过期自动修复也走同一策略。llmwiki refresh --stale重编译过期页面时同样遵守审查策略，风险页依然先排队。

审批成功后，页面写入wiki/concepts/<slug>.md，索引、Map of Content、嵌入向量、Wikilink 修复一次性刷新，候选文件随后清理——整个过程在 wiki-model.mdx 中有完整目录结构说明。

批准后的知识库可以运行llmwiki view --open在本地浏览器中浏览：左侧"Reviews"一栏实时显示待审候选数量，页面右侧展示来源文件与新鲜度标记，审查闭环在视觉上同样透明。

失败即拦截：审查策略为何"fail-closed"

审查配置本身也做了防误用设计：如果hold数组中出现未知模式名，或config.json损坏无法解析，compile 会直接报错中止，而不是悄悄禁用策略、把所有页面放行直写。

这一点在安全模型里很关键——它保证了一条"配置错误 → 审查被绕过 → 幻觉直接入库"的静默通道不存在（配置解析逻辑见 config.ts）。

审查策略适用场景速查

场景	推荐配置
个人笔记库，信任模型输出	不开启审查（默认直写）
共享团队 Wiki / 对外权威知识库	全量拦截：`"hold": ["all"]`
生产级知识库，追求效率与安全的平衡	四种风险信号全开，调低置信阈值
引入外部 OKF 包或 Connector 抓取内容	默认自动进队列（外部内容一律视为不可信，批准时需用`--draft-content-hash`固定你审查过的正文）

配合llmwiki lint与llmwiki eval质量门（见 ci-quality-gates.mdx），你可以把"人工审查 + 自动质检"做成 CI 里的固定关卡，让知识库的每一次增长都可审计、可追溯。