页面类型：一个能用的知识库为什么需要 6 种页面

知识库结构笔记

你打开任何一页，3 秒之内能不能判断它是来干什么的——这往往比内容写得多漂亮，更能决定知识库能不能用。

上一篇我写过怎么决定一份材料该留还是该扔。判定做完，材料就只剩下能继续支撑工作的那一部分。但留下来，不代表知识库就能用——只是从一堆乱目录，变成了一堆体面的乱目录。真正的挑战在后面：这些材料该组织成什么样的页面。

我自己被这件事坑过很多次。同一个 wiki 里，有的页面是抽象原则，有的是项目当下状态，有的是上周一次核查，有的干脆就是一段命令清单。单看都成立，混在一起就开始打架——读者点进去前不知道会看见什么，写的人下次更新也不知道该按什么规则改。

现在我给每一页都先回答一个问题：它是什么类型。回答不出来，就先别写；回答得含糊，就拆开。

从材料到页面：上一篇没讲完的那一层

上一篇讲的是材料层——什么能进入知识库、什么应该留在工作目录里。那一层判定做完，手里大概剩几十份「值得变成页面」的材料：一段已经稳定下来的判断、一次改变了系统行为的选择、一个还在跑的项目的现状、一份验过证据的核查记录、一段被压缩过的演化史、一张被反复查的命令清单。

材料分类看「它是什么内容」，页面分类看「它要承担什么角色」——两件事不一样。一份审计报告作为原始证据可能被排除，结论却得改写成「Audit 页面」留下；一段聊天记录里的决策片段不进知识库，决策本身却要变成「Decision 页面」。从材料到页面，中间有一次重新分类。

这次分类做不好，整个知识库就会塌成「文档大杂烩」——什么都有，什么都不像。后来我强迫自己只用 6 种页面类型，多一种都不许加。

6 种页面类型，每一种都长什么样

顺序不是从最重要排到最不重要，是从「最稳定」排到「最易变」。越稳定的页面越接近知识，越易变的页面越接近工具。

Concept 概念页：一个稳定下来的想法或规则

Concept 页讲的是「这件事我是怎么看的」。它不带具体项目，不带具体时间，最好也不带具体人。一个 Concept 页应该可以在两年以后被新接手的人原样读，仍然成立。

例子：Canonical（真相源 / 权威）选择规则、Knowledge Model 本身、Page Types（页面类型，也就是本文背后的那一页）。这类页面写出来以后基本不动，动了就要写一篇 Decision 页解释为什么改。

Decision 决策页：一次改变了系统行为的选择

Decision 页只回答四件事：当时面对什么问题、有哪些备选、为什么选这个、后来证明对不对。它不是会议纪要，也不是设计文档——它是一份「我以后想知道当年为什么这么做」的备忘。

例子：后来为什么给所有上线动作加了 dry-run-first（先空跑一次）、为什么把主控写入责任人迁到独立的 sidecar 通道、为什么放弃某个看起来更通用的方案。Decision 页写完不再改，最多在末尾追加一段「后续观察」。

Project 项目页：一个有边界的工作流加当前状态

Project 页是 6 种里唯一允许频繁动的。它存在的目的，就是让任何一个新窗口、新 AI、新一天打开它，都能马上知道「这个项目当下在哪一步」。但光靠这个还不够——它必须有 owner、有当前阶段、有下一步动作、有最近一次更新时间，少一项都不算合格。

例子：OpenClaw Studio 某个 RC（候选发布）的当前状态、纪嫣然语音工作台某版本的开关状态、苏晚审美样本库的进度。Project 页是 wiki 里最危险的一类——最容易过期，也最容易被人误当成 Concept 页引用。后面会单独讲怎么把这一类和新鲜度标记绑死。

Audit 审计页：一次带证据链的核查

Audit 页讲的是「在 X 时间，我用 Y 方法核查了 Z，结论是这样，证据在那里」。它和 Decision 不一样——Decision 是要选什么，Audit 是已经做了什么、看到了什么。Audit 页天然带时间戳，带 evidence trail（证据链），带可复现的方法。

例子：某个 Stage（阶段）链路的端到端审计、一次内置磁盘资产盘点、一次跨账号配置一致性核查。Audit 页有意思的地方在于过期了也不能删——它就是历史，价值就在「当时确实做过这件事」。但它不该被新人读了以后误以为「现在还是这样」，新鲜度标记几乎默认 stale（已过期）。

Timeline 时间线页：一段被压缩的编年

Timeline 页是给「我想理解这玩意儿是怎么变成今天这样的」那一类问题准备的。它不写细节，只写转折点——某月某日做了某个关键选择、某周整个架构从 A 切到了 B、某个版本之后某个组件被弃用。

例子：某个项目某个季度的演进时间线、某个生态从单机到多账号的转换史、个人 AI 工作站从去年到今年的硬件演化。Timeline 页写出来以后不密集更新，只在「系统级变化」发生时追加一行——这跟我对 CHANGE 时间轴的处理方式是一回事。

Reference 参考页：一份命令、路径、边界的紧凑查表

Reference 页是工具，不是知识。它存在的意义不是被读，而是被查。它应该尽可能短、尽可能扁平、尽可能可复制粘贴——表格优先于段落，列表优先于句子。

例子：Gate 矩阵（哪一类操作走哪一条审批通道）、端口分配表、各账号的 Feishu 路由表、常用调试命令清单。Reference 页有个特殊属性：经常没有作者立场，纯粹是事实的快照。过期方式也因此很纯粹——事实变了就过期，事实没变就一直对。

三条写作规则：80% 的腐烂从破坏这三条开始

6 种类型分清楚以后，写每一页的时候只需要遵守三条规则。这三条规则我看着很笨，但每一条背后都是真实的翻车经历。

规则一：一页混了「概念 + 状态 + 操作」就拆

这是我见过的最大杀手。一个 README 页面，前三段讲项目设计哲学（Concept），中间五段讲当前进度（Project），最后又贴了一段启动命令（Reference）。当下看着「信息很全」，三个月以后没人愿意打开。

不是写得不好，是压根没法维护。设计哲学半年不动一次，当前进度可能每周改一次，启动命令可能下次重装就变。三种节奏完全不同的内容硬塞在一页里，结果只能是——更新的人只敢动最易变的那一段，剩下的越来越假。

拆开以后情况立刻不一样：Concept 页基本不动，Project 页只动状态那一行，Reference 页只在事实变化时刷新一次。每页都有自己的更新节奏，也不再骗人。

规则二：一页能被「链接到更好的真相源」替代就替代

我以前喜欢写「总结页」——把好几页内容糅成一份摘要，自以为对新读者友好。后来才发现，总结页是知识库里最危险的产物。它不更新，原始页一更新，总结页就开始撒谎；新读者偏偏更倾向于读总结页。

现在我的规则很简单：如果一页能被一句话改成「请看 X 页」，就不要写这一页，直接放一个链接。链接不会过期得比目标页更快，总结页会。

例外只有一种——这一页确实在做组合判断，把几个分散的 Concept 串成一个新结论。这时候它本身就是一个新 Concept 页，不是总结页。区别在于它有自己的判断，不只是把别人的话换个说法。

规则三：一页只是「执行日志」就只留摘要

AI 项目里特别容易冒出「执行日志型页面」——某次实验的命令逐条贴、某次 debug 的过程一路记、某次部署的输出原样保留。当时觉得「记录完整最安全」，半年以后再看，页面长得让人绝望，根本没人会读。

我现在的做法是：执行日志原文留在 evidence（证据）目录里，知识库里只保留摘要——这次跑了什么、得到了什么结论、有哪些反常被记录在了哪份原始日志里。摘要可能只有 200 字，但它能被读、能被引用、能被维护。原始日志能被搜索、能被回溯，但不需要长在知识库里假装自己是一页知识。

页面类型和新鲜度标记怎么联动

类型分清楚以后，最大的好处不是检索更快——是过期检查的节奏可以按类型差异化。上一篇我写过三态新鲜度标记：verified（已验证）、stale（已过期）、needs review（待复核）。但三态不能一刀切——每一类页面过期得不一样快。

我现在大致按这套 cadence（节奏 / 周期）来设：

• Concept 页：半年到一年复核一次。它本来就稳，查得太勤反而浪费。
• Decision 页：原则上不复核，只在出现「这个决策好像不对了」的信号时挑出来重看。历史事实，不是当下状态。
• Project 页：每两周到一个月复核一次，超过周期没人动就自动滑到 stale。
• Audit 页：默认 stale。一次性的核查证据，不打算永远 verified。
• Timeline 页：每次有「系统级变化」发生时追加一行，没有专门复核周期。
• Reference 页：每次依赖的事实变了就同步刷新一次。事实没变就保持 verified。

这样分以后，「复核知识库」不再是让人头大的总动员，而是几个不同节奏的小循环——半年扫一遍 Concept，每个月扫一遍 Project，Reference 跟着事实走。压力被分散到不同的时间点。

更关键的是：读者打开一页的时候，能根据「类型 + 新鲜度」两个信号判断这一页可信到什么程度。一个 verified 的 Concept 页和一个 verified 的 Project 页，可信度的含义不一样——前者是「这事我想清楚了」，后者是「这事到上周还成立」。两个信号联起来读，比单独看任何一个都准。

三种最常见的页面腐烂模式

讲完正面规则，反过来列一下我自己踩过的、也在别人 wiki 里看到的三种典型腐烂模式。一个知识库变烂，多半走这三条路。

模式一：混类型页面，谁都不愿意动

最常见的形态是 README——既要讲设计、又要讲当前状态、又要贴启动命令。一开始图省事，到后面所有人都不敢碰：动设计部分怕影响状态描述，动状态部分怕和设计对不上，动命令部分又怕贴错。最后这一页变成「最权威也最不准」的页面。

解法不是改它，是拆它——拆成 Concept、Project、Reference 三页，每一页交给不同节奏维护。原 README 只留一行链接索引。

模式二：过期不标，所有页面看着一样可信

没有新鲜度标记的 wiki，所有页面看起来权重相同——一份 18 个月没动过的 Project 页和一份昨天刚 verified 的 Concept 页，在搜索结果里长得一模一样。读者无法区分，AI 助手在做 RAG 检索时也无法区分，结果就是「老的会胜过新的」——老页面通常更长、更结构化，反而更容易被命中。

解法是把新鲜度标记当成强制字段，而不是可选字段——一页没有 freshness signal（新鲜度信号），它就不能进入正式的检索结果。哪怕标 needs review 都好，至少读者知道这一页要警惕。

模式三：重复总结，真相源被稀释

一个项目同时存在「设计文档」「项目说明」「FAQ」「Wiki 概要」「Onboarding 指南」，里面 70% 内容互相重复，只是侧重点和写作风格不同。每次原始事实变了，五份文档里只有一两份被同步——剩下三份继续按旧事实讲故事。

解法是认一份真相源，剩下的全部改成「请看 X 页」加一段窄窄的本页特有补充。这一条最难，因为「写一份新的」永远比「指向一份旧的」更有成就感——但知识库腐烂得最快的部分，恰恰是那些反复总结出来的「漂亮的新版本」。