知识架构
知识库架构应帮助人们判断信息在哪里为准、如何找到，以及条件变化后由谁修正。一棵看起来完整的目录树不能自行解决这些问题。不同规模和工具环境的团队可以采用完全不同的空间划分，只要重要信息不会因位置混乱而失去作用。
从信息的用途判断归属
为一条信息选择位置时，先判断它服务什么工作：
- 它是长期协作规则，还是一次具体工作的背景和状态？
- 它需要被谁发现，谁有权访问？
- 它会频繁变化，还是作为历史证据长期保留？
- 人们需要共同编辑它、据此采取行动，还是只需要查询？
- 与它冲突时，哪一个位置应被视为权威来源？
这些问题比“它属于哪种文档模板”更重要。Handbook 适合保存长期协作规范；项目空间、任务系统、代码平台和受控文档可以分别承载具体工作的背景、行动和产物。但这些名称只是常见实现，不要求每个团队建立同样的系统。
每类信息需要权威位置
单一事实源不表示所有内容集中在一个工具，而是同一项当前事实或规则只有一个权威维护位置。其他位置应链接引用，或明确说明自己是快照、摘要和历史记录。
权威位置应尽量靠近真正维护该信息的工作。例如，代码行为以代码和验证结果为准，任务状态以实际推进工作的载体为准，跨团队协作规则以 Handbook 为准。不要为了“统一知识库”复制一份容易过期的镜像。
当两个位置发生冲突时，不能只让读者自行选择看起来更新的一份。参与者应确认哪一份拥有当前决定权，修正另一份，并保留必要的变更原因。
让信息能够被发现
可发现性需要服从隐私、安全和商业边界。信息应向有权继续相关工作的人提供清楚入口。受限内容可以保存在受控位置；公开入口只需说明它存在、适用范围以及如何申请访问，不应泄露内容本身。
人们通常从团队入口、项目入口、任务或搜索开始寻找信息。重要页面应从这些自然入口可达，并使用读者会搜索的名称。链接应表达关系，例如“当前决定”“实施任务”或“历史研究”，而不只是堆放相关 URL。
如果一条信息只有熟悉内部历史的人才能找到，应先改善入口和命名。增加标签未必能够解决问题。
维护责任应贴近工作
需要持续更新的信息，应由最接近其变化的人或角色维护。责任可以在正文、任务分配、代码所有权或团队职责中体现，不强制要求每页都有单独的 Owner 字段。
只有当读者无法判断谁能确认内容、或内容经常在无人负责时过期，才需要显式标出维护责任。Owner 负责促使信息保持可用，不意味着必须独自撰写内容或完成页面涉及的全部工作。
稳定的历史记录不需要因为没有持续维护者而被删除。它应清楚表明自己记录的是哪个时间点，以及当前结论在哪里。
信息会经历不同的变化
不同页面有不同的生命周期。变化频繁的状态需要及时更新；长期规则在做法改变时更新；研究和决定往往需要保留原貌，再链接到后续结论。
内容不再有效时，应根据后来者可能如何使用它选择处理方式：
- 会误导当前行动的旧说明，应标记失效并指向现行内容；
- 与其他页面重复的内容，应合并到权威来源并保留入口；
- 对理解历史仍有价值的决定和复盘，应归档而不是改写成今天的观点；
- 没有继续价值且不受保留要求约束的临时材料，可以删除。
定期清理只是实现手段。真正的要求是不要让已知失效的信息继续冒充当前事实。
用链接连接跨系统工作
一项工作可能同时涉及背景文档、讨论、任务、代码变更和决定。各载体应保存自己负责的部分，并通过链接形成可追踪路径。背景不必复制进每个任务，任务也不应成为另一份项目说明。
当工作跨系统交接时，交接点要足以让下一位参与者知道当前状态和下一步。例如，会议中形成决定后，应把结论写入决定或工作载体，再从会议记录链接过去；聊天中发现新任务时，应创建可追踪行动并返回链接。
好的知识架构允许读者分辨摘要与权威内容，并且无需依赖某个人解释整个路径。少量用于导航和概括的重复文字可以保留。
信息总入口
组织的信息分散在多个知识空间时，应当有一个总入口。它可以是知识库首页、团队手册或任何能列清楚「什么信息在哪里」的位置。总入口只需要做到让读者知道去哪里找什么，不需要复制每个子空间的内容。总入口本身也需要维护，子空间增减时同步更新即可。