如果你让一个 AI Agent 管理你的知识库你最怕什么怕它乱建页面——一个传感器参数就开一页三个月后 200 个僵尸页。怕它乱打标签——今天用 “性能优化”、明天用 “优化-性能”标签体系两个月就烂了。怕它瞎更新——新来的资料跟旧结论矛盾它直接覆盖旧知识永远丢了。怕它不更新——三个月前的配置参数早过期了页面还标着最新。这些问题根因不在 AI——在你没给它一部宪法。LLM Wiki 的核心设计里SCHEMA.md 就是这部宪法。它定义了 Agent 能做什么、不能做什么、做到什么程度算合格。一个好的 SCHEMA.md 让 Agent 的行为从凭感觉变成守规则一个差的或者根本没有的会让 Wiki 从 14 页稳步增长到 27 页变成 14 页爆炸成 140 页垃圾。这篇文章不讲怎么用 LLM Wiki讲怎么设计它——用我实际维护的嵌入式 Linux Wiki27 页、6 实体 20 概念 1 对比、89 份原始文档作为案例拆解 SCHEMA.md 的 5 个关键设计决策。老规矩先看效果这是我 Wiki 的 SCHEMA.md 开篇领域定义嵌入式 Linux 知识体系——从 Bootloader 到应用层的完整技术栈覆盖海思 Hi35xx、全志、瑞芯微、NXP 等平台。约定清单文件名用中文、每页至少 2 个出站链接、更新必刷新日期、所有操作写 log。标签分类体系15 个技术标签boot/kernel/driver/dtb… 5 个硬件标签soc/peripheral/power… 5 个平台标签hisi/rockchip/nxp…。页面阈值一个概念出现 2 次以上来源才建页超过 200 行考虑拆分。就这四条规则让 Agent 在 89 份 PDF 的批量摄入中做出了 12% 建页 17% 更新 71% 跳过 的精准决策。没有 SCHEMA.md 会怎么样Agent 会为 PDF 里出现的 37 个芯片名各建一页为 200 多个技术术语各建一页——然后你的 Wiki 就废了。决策一领域是什么——不给 Agent 画圈它就会上天SCHEMA.md 第一段必须定义领域边界。这不是走形式——Agent 的所有判断都以此为锚。我的领域定义嵌入式 Linux 知识体系 —— 覆盖从 Bootloader 到应用层的完整技术栈 - 引导与启动U-Boot、设备树、启动流程 - Linux 内核配置、模块、内存管理、调度 - 设备驱动字符/块/网络驱动、平台驱动模型 - 文件系统rootfs 构建、initramfs、Flash 文件系统 - 构建系统Buildroot、Yocto、交叉编译、工具链 - 调试与性能gdb/kgdb、tracing、oops/panic 分析 - 芯片平台海思 Hi35xx、全志、瑞芯微、NXP i.MX 等为什么这么写三个设计原则原则一正枚举优于负枚举。不要写不包括 Web 前端、不包括数据库——写了也没用AI 不会因为不包括就避开反而会混淆。直接列出领域覆盖哪些方向不在列表里的自然不处理。原则二子领域细分到 Agent 能识别。如果只写嵌入式 LinuxAgent 不知道边界。但写了 12 个子领域后Agent 看到一篇关于 eBPF 的文章就能判断在调试与性能子领域内→处理。看到一篇 React 教程→不在任何子领域→跳过。原则三留一个工程实践兜底。我的最后一条是工程实践最佳实践、踩坑经验、性能优化。这不是技术分类但它是最高频的摄入类型——90% 的文章不是讲原理而是讲我怎么踩了这个坑。没有这个兜底分类这些内容都会被 Agent 判定为不匹配领域而丢弃。一个反面案例早期我让 Agent 处理一份海思 SDK Release Notes里面提到建议使用 Ubuntu 18.04。Agent 判断Ubuntu 版本不属于嵌入式 Linux 领域——跳过了。但这条信息是环境配置的关键。加了构建系统交叉编译、工具链这条子领域后Agent 就知道Ubuntu 版本 → 影响工具链兼容性 → 属于构建系统 → 收录。领域定义不是写一次就不改的。每次发现 Agent 漏掉了应该收的内容就在子领域列表里补一条——让宪法随实践演化。决策二页面阈值——什么时候建新页什么时候更新旧页这是最让 Agent 纠结的决策也是最容易出问题的。我的阈值规则条件动作一个实体/概念出现在 2 个来源中建新页是某个来源的核心主题建新页只是顺便提了一嘴不建页信息是对已有页面的补充更新已有页页面超过 ~200 行考虑拆分成子页面内容被完整替代移到 _archive真实案例89 份 PDF → 决策矩阵2026 年 6 月 19 日我把 Hi3519DV500 原厂 SDK 的 89 份 PDF 丢给 Agent 处理。最终结果建页12%11 页新建的 11 页包括 Hi3516DV500 芯片Hi3519 vs Hi3516 对比中频繁出现满足 2 来源条件、ToolPlatform 烧录工具多份手册核心主题、SVP NPU 工具链AI 推理核心工具集、裸烧升级独立 19 页手册、U-Boot 移植独立开发指南等。更新17%20 个已有页面获得了内容补充——电源管理加了 SVB 调压细节、RTSP 推流加了多路参数、启动配置加了完整启动流程时序。跳过71%大量 PDF 是寄存器手册的章节索引、版本更新日志、法律声明页面——这些 Agent 判断不满足建页阈值直接跳过。如果阈值写的是每个新概念都建页——那会是灾难。PDF 里提到的术语超过 200 个。如果阈值写的是只有用户明确要求的才建——那 89 份 PDF 只会更新 3 个已有页面大量有价值的内容沉淀在 raw/ 里永远不被发现。阈值设计的核心洞察2 来源规则是一个自然的噪声过滤器——出现一次可能是偶然出现两次说明值得一个独立页面。核心主题规则防止漏网——有些内容只在一份文档出现但它是那 19 页手册的唯一主题。200 行拆分规则防止页面变成长文——读者打开一个 500 行的页面会直接放弃50 个 100 行的页面会被忽略。200 行是一个在可读和太多之间的平衡点。决策三标签分类体系——不设计就会失控标签是 Wiki 的第二维索引。第一维是目录结构entities/concepts/comparisons第二维就是标签——它可以跨目录聚合。我的标签体系25 个标签分三类。技术领域标签15 个boot、kernel、driver、dtb、filesystem、build、debug、rt、memory、networking、security、isp、ai、video、tools硬件标签5 个soc、peripheral、memory-hw、power、interrupt平台标签5 个hisi、rockchip、nxp、allwinner、ti设计原则互不重叠。每个标签有明确的语义边界。dtb 只用于设备树相关内容boot 只用于引导流程。如果一篇文章同时涉及 boot 和 dtb它打两个标签而不是发明一个boot-dtb混合标签。数量克制。25 个标签对我 27 页的 Wiki 来说看起来多但它覆盖了从 boot 到应用层的完整技术栈。标签数量应该和领域宽度成正比不是和页面数量成正比。如果 Wiki 增长到 200 页这 25 个标签仍然够用——只需要在标签下做子分类不需要加新标签。先定义再用。SCHEMA.md 有一句硬性规则“Each tag on a page must appear in this taxonomy. If a new tag is needed, add it here first, then use it.” 这防止了 Agent 自由发挥——它不能因为觉得这篇文章好像跟信号完整性有关就创建一个 signal-integrity 标签。必须先加到 SCHEMA.md 的分类体系里。一个反面教训早期没有标签分类体系时Agent 给 DDR4 接口设计页打了 tag: ddr给 DDR 参数配置页打了 tag: ddr4给 DDR 初始化页打了 tag: memory。三个页面讲同一件事三个不同标签永远聚合不到一起。标签体系的设计方法第一步列出你领域的 5-10 个最核心概念第二步每个核心概念扩展出 2-3 个相关标签第三步加上平台/工具标签你用的芯片、你用的软件第四步用 3 个月然后删掉没用过的标签我的经验是新标签体系里约 40% 的标签从来不会被用到该删就删。决策四Agent 行为约束——告诉它怎么做而不是做什么SCHEMA.md 里最有价值的部分不是数据规则阈值、标签而是行为约束——告诉 Agent 在特定场景下的操作流程。我的核心行为约束1. 交叉引用规则“每页至少 2 个出站链接。更新已存在页面时检查是否需要增加反向链接。”这条规则的效果是什么27 页 Wiki 没有一页是孤岛——每页都能通过 wikilinks 导航到至少 2 个其他页面。Graph View 里是一张连通图而不是一堆孤立节点。2. 更新政策“当新信息与已有内容冲突时查日期——新来源通常优于旧来源。若确实存在矛盾同时标注两种观点及日期和来源。在 frontmatter 标记 contested: true。”这解决了知识冲突的核心问题不是谁对谁错的二元判断而是何时何据的时间线标注。读者可以看到2024 年的文档说 A2026 年的实践发现 B——然后自己判断。3. 出处标记“合成 3 来源的页面在段落末尾加让每条结论可追溯。”这个细节很重要——Wiki 不是凭空生成的每一段知识都有来源。三个月后回看一个页面你能知道NPU 推理延迟是 12ms这个数据是来自官方手册还是某次自测——追溯链条完整。4. 日志驱动“所有操作追加到 log.md。每天结束前检查 log 长度超过 500 条则轮转。”log.md 是 Agent 的记忆文件。它记录了每一批摄入、每一次更新、每一次 lint 的结果。当你问Wiki 上周加了多少页时答案不在 Agent 的对话记忆里——在 log.md 里。Agent 读 3 行就能回答不需要翻 3 天前的聊天记录。行为约束的设计心法不是告诉 Agent “要做什么”它会做而是告诉它做到什么程度算完成用量化指标2 个链接、200 行上限、500 条轮转替代模糊描述每条规则后面跟一个为什么——不是给 Agent 看的是给你自己看的。3 个月后你回看 SCHEMA.md需要立刻回忆起当初为什么定这条规则决策五质量信号——让 Agent 告诉你这页可能有问题传统笔记的问题不是内容错误——而是你不知道哪些内容可能错误。SCHEMA.md 里设计了三个质量信号字段confidence置信度high | medium | lowcontested有争议true | falsecontradictions冲突页面列表[页面名]实际使用场景当 Wiki lint 检查时Agent 会自动标出confidence: low 的页面 → “这页只有单一来源建议找交叉验证”contested: true 的页面 → “这页有未解决的矛盾需要人工判断”contradictions 列表 → “以下 3 个页面跟此页描述矛盾”举个例子BSP 编译系统页面有 9 条踩坑记录全部来自实际调试经验confidence: high。而 DDR4 接口设计的信号完整性部分只参考了一份原厂 Design Guide标记为 confidence: medium——因为 DDR4 走线规则跟具体 PCB 层叠结构强相关一份参考不够。质量信号不是给读者看的——是给未来的你和你将来的 Agent 看的。三个月后你回头看一个低置信度页面不会把它当权威结论。六个月后 Agent 读到一个有争议标记会主动停下来问你是否需要调查而不是盲目更新。给 SCHEMA.md 加版本意识这是我在维护中领悟到的最重要的一课SCHEMA.md 本身也需要迭代。我的 SCHEMA.md 从第一版到现在改了 4 次v12026-06-16只有基本约定和 frontmatter 格式。页面超过 200 行考虑拆分这条当时还没有——结果 BSP 编译系统页面第一次写出来就是 400 行。v22026-06-18加了标签分类体系和页面阈值。之前 Agent 没有任何建页规则batch ingest 时要么全部建页要么全部跳过。v32026-06-20加了 confidence/contested 质量信号。起因是一个 DDR 时序参数被新资料覆盖但旧数据没被标记——后来花了一个小时排查为什么两页说的不一样。v42026-06-23加了 raw/ frontmatter 的 sha256 漂移检测。起因是一份在线文档被作者悄悄更新了Wiki 引用的还是旧版本。每一次迭代都来自真实踩坑——不是我觉得应该加这个而是上次出了问题必须用规则堵住。SCHEMA.md 设计得好不好一个检验标准就够了把你 Wiki 的 SCHEMA.md 删掉换一个全新的 Agent 从零开始维护同一个 Wiki。如果新 Agent 三个月后的 Wiki 质量和你的差不多说明宪法写好了。如果新 Agent 三个月后 Wiki 炸了——tag 体系混乱、页面重复、交叉引用断裂——那问题不在 Agent在你没给它一部好宪法。