内部 wiki：工具、结构，以及从频道历史中长出来的 wiki（2026）

内部 wiki 是一个组织只为自己撰写的页面集合：新经销商如何开通，最新价格表在哪里，6 月关于折扣做了什么决定，承运商延误时该找谁。它之所以是"内部"的，是因为读者是同事；它之所以是 wiki，是因为任何成员都可以写页面，任何页面都可以链接到另一个页面。对于 10–200 人的组织，从第二个人问出同一个问题那天起，就已经有了这样一份 wiki：唯一的选择，是让这些页面真实存在，还是让答案继续留在某位同事的脑子里和十几个聊天串中。

大多数关于内部 wiki 的指南都是软件清单。本文从更早的地方开始，因为工具是其中最小的决策：好用的 wiki 是一种人们能够顺利浏览的结构、一种始终准确的页面格式，以及一个团队每天本来就会打开的地方。先讲方法：结构、可直接复制的页面模板、来自一家诊所的实例；再讲机制：wiki 在您团队已经在用的工具中位于何处（依据各家自己的文档），以及各个工具如何处理真正定下规则的那场会议。因为检验 wiki 的不是上线那天，而是某个周一，新同事打开它，找到了一页他能读懂的语言写成的内容。

内部 wiki 是什么，不是什么

有四样东西都被叫作 wiki，它们之间的混淆正是许多 wiki 建了却很少有人打开的原因：

wiki 是第一行，也是其余三者所依赖的那一个。知识库是结构得到强制执行的 wiki：每个问题一条，每条都有负责人；30 天搭建知识库的方法在那篇指南中，本文讲的是 wiki 本身的形式。内网，是 wiki 在只有三个人有权写的时候变成的样子。共享盘是 wiki 所指向的文件存放之处，wiki 的职责是指向当前的那一份。wiki 也不是流程文档或 SOP：后者从头到尾描述一项工作；wiki 页面则说明去哪里找到它们，以及此后有什么变化。

让 wiki 成为"内部"的，不是密码，而是页面使用团队自己的词语来写，比如"卡萨布兰卡规则"、"周二配送"，并且可以说出外部页面永远说不出的东西：谁做的决定、为什么、取代了什么。

结构：七个板块，一个问题一页

人们会打开的 wiki 与不再被打开的 wiki，差别很少在于工具，而在于第一页写出之前做过或没做的三个决定。

按问题划分板块，而不是按部门。 一位同事问"我们怎么给瑞士的经销商开发票？"，他并不知道答案属于财务、销售还是物流；他只知道自己的问题。按部门组织的 wiki 会让他在三个板块中找一页内容。应当按人们提出的问题、用他们自己的话来组织，并把顶层控制在七个板块以内。超过七个，结构本身就需要搜索，而在一个还没人填充的 wiki 里搜索只会一无所获。小型组织常见的顶层板块有：客户与订单；资金与开票；人员与招聘；工具与权限；规则与决定；该找谁。

一个问题一页，不超过一屏。 回答一个问题的页面会被找到、被阅读；解释整个职能的页面只会被收藏、被扫一眼。"我们怎么给瑞士开发票？"是一页。"财务"是一个板块。如果一页需要目录，它就该是两页。

每页都有负责人和日期。 写明谁负责、何时最后核对的页面会被相信；同样的文字没有这两样，就是"可能已经过时"。负责人的工作很小：每季度回答一次"这还对吗？"，然后更新日期。这是让 wiki 活过第一年的唯一办法。一个指不出负责人的页面不是知识，而是猜测，应当撤下。

结构建立之后，有两个习惯可以保持它。团队频道里被问过两次的每个回答，都变成一个页面，由回答的人来写，并链接到它所属的板块。每个改变规则的决定，先在决策日志中记一行，再让陈述该规则的页面链接到它，这样六个月后，页面不仅能说明规则是什么，还能说明为什么。

如何在一周内建好内部 wiki

这个计划假定由一个人推动，也就是团队负责人，或被问得最多的那个人，其余成员只需花几分钟。

第 1 天：按团队已经在读的地方选址。 不是按软件对比来选。wiki 应当位于提问发生的地方：团队的频道，或文件已经所在的套件。放在第五个工具里、还要单独登录的 wiki，周一早上没有人会打开。后文的表格说明了各个位置保存什么、在哪里止步。

第 1–3 天：收集问题，而不是答案。 在频道里发一条消息："请回复你这周向同事问过的每一个问题，用你当时的原话。"到第三天会有四十到六十条，其中三分之一是重复的。数一数重复次数：被问了五次的问题就是第一页。

第 4 天：分成七个板块，指定负责人。 这些问题自然归成的几组，就是板块。为每个板块指定一位负责人，即回答了其中最多问题的人，再为前十五个页面各指定一位负责人。此时除了清单什么都不写：板块、问题、负责人。把它发回给团队，只问一句："还缺什么？"

第 5–7 天：用现有材料写出前十五页。 每位负责人用下面的模板写自己的页面，起点是聊天里的回复、定下规则的那场会议的纪要、三月份附上的那份文件。第一周的原则是"简短而真实，胜过冗长而完整"：两句话的回答加一个文件链接，注明日期并署名，就是一个页面。然后把板块索引置顶在团队阅读的地方，wiki 就存在了。

这一周里不会做的事：迁移共享盘、为每个流程都写一页、选择新工具。wiki 指向文件所在之处，指向流程所在之处。

内部 wiki 页面模板

一页，一个问题，不超过一屏。把它作为笔记复制下来填写；最常被跳过的是最后三行，而它们恰恰是让页面保持真实的部分。

[问题，用人们提问时的原话]
负责人： [姓名] · 板块： [七个之一] · 上次复审： [日期] · 下次复审： [日期]
简短回答： [两句话：该怎么做]
适用于： [团队、办公室、客户类型] · 不适用于： [人们容易混淆的情形]
步骤： [编号步骤，每一步写明涉及的系统、人员或文件]
背后的规则： [定下这条规则的决定，附日期和理由，并链接决策日志]
例外： [偏离常规路径的情形，以及各由谁决定]
文件在哪里： [链接到当前的模板、价格表、合同]
相关页面： [SOP、流程、本页的上一版本]

该模板是带粗体标签的纯文本，因此可以不加调整地粘贴到 Word 文件、Google Doc、wiki 页面、Slack canvas 或聊天笔记中。

实例：一家诊所一周后的 wiki

巴塞罗那的一家理疗诊所，24 人：前台四人，理疗师十四人，账务两人，其余是行政。一半理疗师来自阿根廷、哥伦比亚和乌克兰，近两年入职；三分之一的患者是用英语预约的英国和德国居民。三天的收集得到 52 个问题，去重后 37 个。形成的结构如下，括号内为第七天时各板块的页面数：

1. 患者与预约（5）：首次预约如何办理；爽约怎么处理；患者如何更换理疗师
2. 账务与保险（4）：哪些保险公司直接结算；如何为外国保险公司开具收据；何时给某次治疗退款
3. 治疗方案（3）：方案表放在哪里；谁来审批治疗计划；每次治疗后要记录什么
4. 工具与权限（2）：谁负责开通预约系统的权限；患者信函模板在哪里
5. 规则与决定（2）：提前 24 小时取消的规则；决策日志
6. 该找谁（1）：保险公司的联系人；设备维修热线

共十七页。被问得最多的问题"我们怎么开具德国保险公司能接受的收据？"，一年里前台已经由同一位账务负责人回答了九次；这一页只花了她十五分钟，因为第九次的回答已经写在频道里，只需要补上负责人一行和日期。

第 2 个板块中一份填好的页面：

我们怎么开具外国保险公司能接受的收据？
负责人： 账务负责人 · 板块： 账务与保险 · 上次复审： 2026 年 11 月 6 日 · 下次复审： 2027 年 2 月 6 日
简短回答： 使用"保险公司收据"模板，以患者的语言填写，每一行都附上诊断代码和理疗师的执业证号。
适用于： 自费就诊并向国外保险公司申请报销的患者 · 不适用于： 我们直接结算的保险公司，它们收到的是月度对账单。
步骤： 1. 在预约系统中打开该患者。2. 选择保险公司收据模板。3. 添加治疗计划中的诊断代码。4. 检查每一行都有执业证号。5. 以 PDF 发送，并将副本存入患者文件夹。
背后的规则： 2026 年 4 月德国保险公司拒付之后，增加了执业证号（决策日志条目 2026-04-22）。
例外： 需要按次逐项列明收据的患者，请联系账务负责人；其他人不开具此类收据。
文件在哪里： 保险公司收据模板；诊断代码清单；患者文件夹。
相关页面： 哪些保险公司直接结算；何时给某次治疗退款。

wiki 在您已经使用的工具中位于何处

一个 10–200 人的组织，会把 wiki 建在自己已经付费的套件中，每个套件都有放页面的地方、放文件的地方，以及承接会议所留内容的路径。它们各自止步于不同的地方，而且在每一个中，页面都是以输入时的语言保存的。以下仅为有文档记载的行为，取自各家厂商自己的页面，并注明了各页面的核对月份：

这四者有三点相同。页面是以输入时那一种语言写成的文档或消息，读另一种语言的成员，读的要么是它，要么是别人制作的副本。文件在第二个地方，要通过第二次搜索才能找到。而会议，也就是规则被争论、被定下的地方，只有在事后有人手动录入时才会进入 wiki：Teams 和 Meet 在哪些情况下才会保留转录和摘要，以及通话结束后如何保存它们，见Microsoft Teams 和 Google Meet 把您的转录、录制和摘要存放在哪里；许多团队出于同样的原因添加的 AI 会议记录工具，在 Otter.ai 替代方案中有对比，它们每一个写出的摘要都只用一种语言。

这些套件所记载的翻译，属于通话或读者的屏幕，而不属于页面：Microsoft 记载，当组织者拥有 Teams Premium 或 Microsoft 365 Copilot 许可时，Teams 会议提供实时翻译字幕；Google 记载，符合条件的 Workspace 方案中 Meet 提供翻译字幕（均为 2026 年 8 月核对）；WhatsApp 记载，可在读者的手机上翻译收到的消息（2026 年 8 月核对）。各自覆盖什么、止步于哪里，见 Microsoft Teams 实时翻译、Google Meet 实时翻译和 WhatsApp 翻译。说乌克兰语的理疗师周一打开的那页收据说明，与这些字幕是两个不同的对象，它是以输入时的语言来阅读的。

从频道历史中长出来的 wiki

InterMIND 是一个沟通空间，团队的工作都在频道中进行，因此 wiki 有一个显而易见的归处：使用它的那个团队的频道，比如诊所的前台、出口团队、代理机构的客户小组。这个频道同时也是提问发生的地方，是会议开始的地方。前面的三个决策可以直接对应到它上面。

页面及其负责人就是频道中的笔记。笔记是带标题和编号列表的富文本消息，之后可以从它自己的菜单中编辑，每位成员以各自的语言阅读，原文只需一键切换即可查看；置顶之后，板块索引就是新同事最先找到的东西。开启编辑历史后，规则被修改前的措辞，会以逐词差异（diff）的形式，连同时间戳显示在当前文本上方：这就是负责人"上次复审"那一行所指向的复审轨迹。页面所指向的文件，如收据模板、诊断代码清单、保险公司合同，会上传到同一个频道，在每个方案中都附带一份以读者语言撰写的 AI 摘要，每个要点都链接到它所来自的段落；在付费方案中，文件本身会以译成读者语言的版本打开（文档支持 30 种语言）。如果主文档仍保留在文档工具中，它的更新会通过电子邮件进入频道：频道的主持人会给它分配一个专属地址，发到该地址的邮件会作为一条普通消息出现，标明发件人，并保留附件。从 Slack 迁来的团队可以带上自己的频道：标准的 Slack 工作区导出文件会还原为每个 Slack 频道对应一个频道，消息按顺序排列并保留原始时间戳，置顶和表情回应也都保留，每条消息都由每位成员以各自的语言阅读。

每个页面背后的历史，正是频道完成上表中留给人工去做的那部分工作的地方。定下规则的那场会议从频道开始；通话期间，草稿页面会通过 Share to conference 显示在每个人的屏幕上，位于视频画面旁边，可以是一份笔记，也可以是聊天中链接的 Google Docs 或 OneDrive 文档；每位参会者独立滚动查看，并以各自的语言阅读，而分享者可以实时编辑。通话结束后，会议纪要根据会议本身生成：一份摘要，标明已达成一致、未决或有争议的要点，带负责人的 action items，每一行都保留其时间戳；会议期间共享的文档，其摘要也会与发言内容一并纳入。纪要通过电子邮件、频道中的一条消息以及日历事件中的一个链接送达，每位已登录的成员都以各自的语言阅读：记录是按读者翻译的，而不是只用会议室碰巧使用的那种语言写一次。任何成员都可以编辑它，每次编辑都会保留作者和修订历史，频道会保留过往每一场会议的纪要，所以定下执业证号规则的那场会议，距离陈述该规则的页面只有一次点击。这就是从频道历史中长出来的 wiki：前台的第九次回答、争论规则那次通话的纪要、四月附上的模板，全都在一处，页面位于它们之上。与上面的表格对照来看，差别只是一句平实的事实陈述：那些套件所记载的字幕，翻译的是正在进行的通话；而在这里，页面、产生它的会议、它的文件及其历史是同一份记录，由每位成员以各自的语言阅读。

提问频道也会从另一个方向得到同样的处理。成员自己的助手，无论是 Claude、ChatGPT、Copilot 还是 Gemini，通过 MCP 连接器接入，就能在一次提问中搜索会议纪要、转录、聊天和共享文件的文本，比如"我们怎么开具德国保险公司能接受的收据？"，并返回相应的段落，同时标明每段来自哪场会议、哪一天、哪个文件；这适用于开启了 AI 功能的组织，并且通过助手读取的范围仅限于该成员所在的会议和频道。聊天本身有搜索功能，而且整个 wiki 可以被完整取走：在每个方案中，都可以通过设置中的备份，把频道连同其消息、转录和文件导出为 ZIP，这是在组织层面而不是页面层面回答了所有权的问题。

掌握团队知识的人并不总是员工。保险公司的理赔联系人、设备技术员、懂得德国收据规则的自由职业会计：频道的外部成员通过电子邮件，以免费账号加入，和其他人一样阅读页面及其历史；而没有账号的人是某一场会议的访客，他们通过链接加入通话，用手机即可，无需付费，以自己的语言实时收听，会后没有记录。主持人提供空间，在付费方案中，只为过去 28 天内的活跃成员付费，即参加过会议、在聊天中发过言或向助手提过问题的成员；沉寂下来的成员可以免费保留访问权限，这正是 wiki 所需要的：两年前写下那一页的人，依然可以留在频道里。

• 查看完整的会议纪要：一份真实的记录，由写出您自己纪要的同一套代码渲染而成。
• 试用在线演示：无需注册；开口说话，听房间里的内容按每位听者的语言翻译。

作为一门手艺，内部 wiki 能够经受任何工具的更替：仍然需要有人收集问题，把结构控制在七个板块以内，给每个页面写上名字和日期，并在频道中回答而不是私信回答。不必继续存在的是第二份工作：把会议的决定重新键入 wiki，并为每个页面手工维护一份译文，一次一种语言，只为那些阅读另一种语言的同事。

FAQ

什么是内部 wiki？

内部 wiki 是一个组织为自己的成员撰写的一组页面，包括事情如何做、文件在哪里、决定了什么以及为什么，它们集中保存在一处，任何成员都可以写页面，任何页面都可以链接到另一个页面。它与公共 wiki 的区别在于读者是同事而不是客户；它与内网的区别在于，更新页面的是实际做事的人，而不是某个中央团队。真正被打开的页面，是按人们提出的问题来组织、并且每页都有负责人和复审日期的那些。

内部 wiki 和知识库有什么区别？

wiki 是任何人都可以按任意结构来写的一组页面；知识库则按人们提出的问题来组织，每个问题一条，每条都有指定的负责人和复审日期。wiki 通过加入结构和负责人变成知识库；没有这两样，它就会长成数百个没人能浏览、也没人核对过的页面。软件往往是同一个，而在 30 天内把前者变成后者的方法，见如何建立知识库。

如何创建内部 wiki？

按团队已经在读的地方选址，而不是按软件对比来选；用三天时间收集团队实际提出的问题，保留他们使用的原话；把它们归入不超过七个板块，并为每个板块和每个页面指定负责人；用现有的材料，如聊天回复、会议纪要、文件，写出前十五页，使用包含简短回答、步骤、例外和复审日期的一页模板；把板块索引置顶在团队阅读的地方。然后保持这个闭环：每个被回答过两次的问题都变成一个页面，每个页面的负责人在到期日复审它。

内部 wiki 应当包含什么？

每个问题一页，每页包含：用人们所用的话写的问题、负责人、上次复审日期和下次复审日期、简短回答、适用和不适用的情形、写明所涉及系统或人员的步骤、规则背后的决定及其日期、例外情形及各由谁决定、当前文件的链接，以及相关页面的链接。整个 wiki 需要一个不超过七个板块的结构，按所问的问题而不是按部门来组织，并在团队阅读的地方置顶一份板块索引。

哪个工具最适合做内部 wiki？

团队每天本来就会打开的那个，因为放在第五个工具里、还要单独登录的 wiki，周一没有人会去查看。在 Microsoft Teams 中，页面和文件位于频道及其 SharePoint 站点中，会议笔记是一个 Loop 组件；在 Slack 中是频道里的 canvas；在 Google Workspace 中是从日历链接的 Google Doc；在 WhatsApp 中就是群聊本身。每一种都有上表中记载的限制，并且每一种都让页面保持输入时的语言。InterMIND 把团队的笔记、文件、聊天和会议纪要保存在同一个频道中，由每位成员以各自的语言阅读，与这些工具并行，而不是取而代之。

可以在 Microsoft Teams 中搭建内部 wiki 吗？

根据 Microsoft 的文档，团队的文件存放在随团队创建的 SharePoint 站点中，所有标准频道共用该站点，每个频道一个文件夹，因此频道的 Files 标签页就是 wiki 文档所在之处；会议笔记是一个 Loop 组件，任何与会者或组织者都可以编辑，自动保存，并可从 Teams 日历和会议纪要中进入。有两个有文档记载的限制对 wiki 很重要：外部与会者无法访问或编辑会议笔记；聊天和频道消息可以由 Teams 保留策略在一段时间后删除，而文件遵循各自的 SharePoint 和 OneDrive 策略（页面核对于 2026 年 10 月和 11 月）。

如何让内部 wiki 保持最新？

靠每个页面上的负责人和复审日期，除此之外别无其他。负责人的工作，是每季度回答一次"这还对吗？"并更新日期；负责人已经离开的页面，要么换新负责人，要么撤下。有两个习惯为页面提供内容：团队频道里被回答过两次的每个回答都变成一个页面，由回答的人来写；每个改变规则的决定都先记入日志，这样页面就能链接到它为什么改变。以这种方式维护的 wiki，每回答一个问题就增长一页，没有人需要把它当作一个项目来重写。

来源：Microsoft Learn — Teams and SharePoint integration；Microsoft Learn — Learn about retention for Teams；Microsoft — Take meeting notes in Microsoft Teams；Microsoft — Translate a message in Microsoft Teams；Microsoft — Use live captions in Microsoft Teams meetings；Slack — Pricing；Slack — Customize data retention in Slack；Slack — Export your workspace data；Slack — Meeting agenda template (canvas)；Google Chat — Use Automatic Translation in Chat；Google Meet — "Take notes for me" in Google Meet；Google Meet — Use translated captions；WhatsApp — How to export your chat history；WhatsApp — Privacy policy；WhatsApp blog — Introducing message translations。Microsoft Learn 的 Teams–SharePoint 页面核对于 2026 年 11 月；Teams 保留策略和会议笔记页面、Slack canvas 模板页面以及 Google "Take notes for me" 页面核对于 2026 年 10 月；Teams 消息翻译和字幕页面、Slack 定价、保留和导出页面、Google Chat 翻译和 Meet 字幕页面以及 WhatsApp 页面核对于 2026 年 8 月。各厂商会随时间调整方案、功能和语言列表，请查看其页面以了解当前状态。