为什么大多数团队 wiki 撑不过一年
我从 2018 年开始远程工作，大半时间在帮初创公司和企业团队搭 Notion 知识体系。同样的剧情反复上演：大家往工作区倒了一个季度的页面，然后新同事问入职清单在哪，答案永远是 Slack 里那句「我去找下链接」。
代价很容易被低估。Buffer 2024 年远程工作状态报告显示，98% 的受访者希望至少部分时间远程工作，分布式团队不是一阵风。哈佛商业评论的研究指出远程员工生产力高 13%，但只要有人花四十分钟翻找一条埋在九个同名 Notes 页面下的决策，这点优势就归零。
失败模式几乎从不是工具问题，而是结构问题：页面没有负责人、数据库没有结构、搜索返回一墙长得很像的结果。一套好的 notion 模板先把结构立起来，再让内容往上积累。下面这套方案靠的是起步小、早定责任人、把 wiki 当产品运营。
我给每个团队都装的七段式骨架
我搭的每个 wiki 都从同样七个段落开始，顺序对应成员真实的工作动线：先看变化，再查决策，然后照流程操作，最后找到对的人。
| 段落 | 放什么 | 为什么重要 |
|---|---|---|
| 首页 | 公告、每周摘要、常用链接 | 给入职一个单一入口 |
| 决策日志 | 带日期、背景和负责人的决策 | 结束翻找决策历史的日子 |
| 操作手册 | 一步一步的操作规程 | 把口头经验变成可复现步骤 |
| 流程指南 | 发布等重复性工作的指南 | 让跨时区产出质量一致 |
| 项目中心 | 进行中项目的状态和链接 | 取代每周例会的状态轰炸 |
| ADR 日志 | 架构决策记录 | 让工程推理经得起人员流动 |
| 人员目录 | 角色、时区、擅长领域 | 让跨时区协作变得可规划 |
两条规则让骨架保持生命力：每段指定唯一负责人负责修剪；所有页面从模板创建，绝不开空白页。落地时就是带日期、决策人与背景字段的决策日志模板，和带编号步骤、最近演练日期的操作手册模板。每季度再做一次模板复盘：同一个问题在 Slack 里被回答了两遍，答案就沉淀进手册或指南。这个习惯比任何功能都更能让页面堆变成被信任的知识库。
值得直接照抄的三套数据库结构
数据库设计是大多数 Notion wiki 悄悄出问题的地方。我接手过的工作区里，每个团队都自建项目追踪器，跨库搜索又慢又乱。工程团队的数据库结构不需要聪明，只需三个数据库、各十来个字段、彼此关联。
Projects 数据库
项目是骨架。每个进行中的事项在这里有一页，其他一切都链到它。
| 字段 | 类型 | 说明 |
|---|---|---|
| 项目名称 | 标题 | 保持简短，细节写在页面里 |
| 状态 | 单选 | 起草中、进行中、受阻、已完成、已归档 |
| 负责人 | 人员 | 唯一问责人，不设委员会 |
| 目标日期 | 日期 | 驱动日历与时间线视图 |
| 文档 | 关联 | 链接需求文档、简报和复盘页 |
| 最近复习 | 日期 | 一个季度没动的自动进待清理视图 |
最近复习字段干的活最重：它给你一个「九十天没人碰过」的保存视图，正是季度末最该看的清单。
ADR 日志
架构决策记录是工程团队停止反复争论同一问题的办法。每条记录只讲一个决策：考虑过的选项、接受的后果。
| 字段 | 类型 | 说明 |
|---|---|---|
| 编号与标题 | 标题 | 格式如 ADR-014：搜索迁移到托管服务 |
| 状态 | 单选 | 已提议、已接受、已取代、已否决 |
| 决策日期 | 日期 | 拍板的日子，不是写文档的日子 |
| 决策人 | 人员 | 写名字而不是团队，历史才有温度 |
| 背景摘要 | 文本 | 两句话说清问题与约束 |
| 后果 | 文本 | 什么变容易了，什么变难了 |
当一条 ADR 被取代时，把状态改为已取代并关联新记录。这条被取代记录组成的链条，会成为最值钱的入职材料之一。
人员目录
只讲工作不讲人的 wiki 会安静地失灵，跨时区时尤其明显。人员目录虽小，用处却不成比例。
| 字段 | 类型 | 说明 |
|---|---|---|
| 姓名 | 标题 | 每位成员一页 |
| 角色 | 单选 | 角色族加级别，方便筛选 |
| 时区 | 单选 | 存时区名而非偏移量，避免夏令时翻车 |
| 工作时间 | 文本 | 与直属负责人共同在岗时间，用 UTC |
| 擅长领域 | 多选 | 哪类问题的第一求助对象 |
| 入职伙伴 | 关联 | 链接到负责带新的同事 |
每个数据库控制在十个字段以内。关联和筛选视图能回答大多数组合问题；二十个字段的怪物没人维护，一个都答不了。这种克制也是检索保持快速的原因。
远程团队的 Notion AI 搜索工作流
结构化数据库解决「知道要找什么」的检索；更多时候大家输入的是一整句话：企业客户怎么退款、周五部署冻结定了没有。这是我为远程团队配置的 AI 搜索工作流，后两步更决定成败。
- 限定问答来源。AI 问答只覆盖上面几个 wiki 段落而非整个工作区，避免零散笔记冒充公司政策。
- 接入次级来源。把 Slack 与 Google Drive 作为连接器加上，让答案能引用决策讨论的会话，再链回决策日志。
- 写好页面描述。每个顶层页面配一句描述，AI 靠它决定引用什么，人靠它扫描结果。
- 固定入职常见问题。把新员工必问的十个问题——从报销到发布流程——保存并固定在首页段落。
- 每周复盘未答好的问题。每周花十五分钟，修掉失败背后的页面。
- 每月跟踪引用。AI 最常引用的页面才是文档主力，值得安排维护时间。
一个月后未答清单会明显变短，这就是生效的信号：新员工不再问东西在哪，而是问出更好的问题。
权限与让 wiki 活下去的维护节奏
权限是热情撞上现实的地方。默认切分很简单：全员可阅读评论所有内容；手册、指南与决策日志的编辑权给段落负责人及其代理人；人员目录与项目状态对全员开放编辑。外部协作者按具体项目邀请。
节奏和规则同样重要。段落负责人每月花三十分钟修剪与归档；每季度全团队用一小时过一遍过期项目视图和未答问题清单。两个仪式都不性感，但它们决定 wiki 第二年是否还被信任。
模板稳定后我会锁住它们。想加新字段，先找段落负责人，讨论记进决策日志再上线——否则一年后没人说得清结构。
团队 wiki 选 Notion 还是 Obsidian
notion 与 obsidian 的 wiki 方案之争几乎每个项目都会出现，诚实的答案是：它们优化的方向不同。
| 维度 | Notion | Obsidian |
|---|---|---|
| 上手成本 | 低，结构化模板开箱即用 | 中等，插件与约定需要时间 |
| AI 搜索 | 内置的全工作区问答 | 仅社区插件 |
| 结构化数据库 | 原生数据库，带视图与关联 | 非原生，依赖插件 |
| 文件归属 | 云端优先，可导出 | 本地纯 Markdown 文件 |
| 适用场景 | 带权限的共享团队 wiki | 个人知识库 |
共享团队 wiki 我默认推荐 Notion：权限、数据库与 AI 搜索都是标配，非技术同事无需培训。Obsidian 更适合个人思考与长文写作。不少团队两者并用：Obsidian 放个人笔记，Notion 放团队 wiki，每周同步变成公共知识的部分。
从哪里开始
这篇指南最有价值的是三件事：先装七段式骨架再写内容；三个数据库各控制在十个字段以内并相互关联；AI 搜索先跑满一个月每周复盘再下判断。
若你在配套建设更完整的文档习惯，我们的文档工作流指南覆盖写作侧，异步优先工作手册覆盖会议到文档的迁移，AI 原生工作流指南展示模块串联。这周先把骨架立起来，第一轮入职来临时，决策日志会替你说话。