为什么优秀的知识库仍然无人问津
问题和答案存在于不同的应用程序中
这就是问题的全部，而且非常平淡无奇。提问是在聊天客户端中进行的一种社交行为。而查阅文档是在浏览器标签页中进行的独自行为。向同事请教只需要发一条消息；而查看 Wiki 则需要切换上下文、进行搜索，并承担一无所获的风险。
团队通过链接来缩小这一差距——置顶消息、频道书签、每周发布员工手册 URL 的机器人。但每一次最终都落脚于“现在去读这个吧”。上下文切换依然存在。
文档回答的是一个页面，而不是一个问题
即使是维护良好的知识库，返回的也是文档。读者需要自己进行提取：浏览页面、定位段落、判断其是否仍然适用，并将其转化为针对眼前具体情况的答案。
这一步在规划时是隐形的，但在实践中却非常繁重，这就是为什么“我们有相关文档”与每月都会收到相同问题这两个现象能如此和谐地共存。信息是存在的，但答案没有被组装起来。检索和记忆并不是同一种操作，为什么 RAG 不是记忆中阐明了这一区别。
您的聊天平台的搜索范围仅限于该聊天平台
Slack 在这方面投入了资金，并且在有文档记录的边界内运行良好。用 Slack 的话来说，其 AI 功能“由您工作区中的知识提供支持”。答案“基于 Slack 中的相关信息，而不是筛选搜索结果”，并且它们“包含指向提供信息的源消息或文件的引用”。
当您的知识存在于其他地方时，有两个有文档记录的限制非常重要。可用性取决于订阅计划——自动搜索过滤器列在 Pro 及以上版本中，而“搜索答案”则出现在 Business+ 和 Enterprise+ 中。此外，语料库是您自己可以访问的内容：“AI 生成的回复仅包含您可用的信息（例如来自公共频道的群聊消息和其他内容，以及您所属的任何私有频道和私信）。”
向外延伸是一项独立的能力：“如果您使用的是 Enterprise+ 计划，组织所有者或管理员可以启用企业搜索，以在搜索结果中包含来自其他来源（如 Google Drive、GitHub 等）的内容和信息。”这是一个合理的设计，它也解释了为什么您聊天应用中的助手无法引用存在于您文档系统中的运行手册。
聊天中分享的材料最具有上下文相关性，但也最不持久
在大多数工作区中，最实用的产物往往会被粘贴到聊天中：错误截图、已签署的 PDF、某人在半夜重建的电子表格。Slack 将这些内容计入相同的历史记录窗口——“文件包括剪辑、PDF、文档、图像、屏幕截图以及音频和视频文件”——在免费版本中，“您可以查看和搜索过去 90 天内的消息和文件”，而“超过一年”的数据将被删除。
因此，您团队中最丰富的知识层却保存在最不永久的地方，而且没有任何 Wiki 更新能捕捉到它，因为没有人会把粘贴的截图当成文档。
每个人的私人助手都拥有私有的上下文
人们采用的折中办法是使用自己的 AI 订阅：在后台粘贴，获取答案。这只对一个人起作用一次。上下文保留在个人账户中，因此没有任何东西积累到共享的地方——这种分裂在知识工作者的跨工具记忆中有所描述，在组织规模上则在企业 AI 遗忘中有所描述。
团队尝试过的方法
在每个频道中置顶员工手册链接。 成本低，但最终仍以切换上下文告终。置顶内容也变成了一个没人维护的精选列表。
设立 #handbook 或公告频道。 将知识库变成了信息流，而信息流只会被当时在线的人在发布当天阅读一次。
针对聊天历史记录的搜索机器人。 有用，但局限于聊天：它无法根据从未发布过的文档进行回答。
为每个人购买个人 AI 订阅。 解决了个人效率问题，但团队知识仍留在原处。支持团队对此感受尤为深刻——这种模式在当助手忘记您的支持工单时中有所描述。
指定一名知识负责人。 有时是正确的，但这只是将失败集中在一个人的日程表上，而不是消除它。
解决办法：让知识库在提问的地方进行回答
重新构想：停止尝试将人们引向知识库，而是将知识库移到群聊中。具体来说，这意味着在频道中引入一个机器人，它根据指定的记忆体进行回答——而不是根据通用模型的通用知识——并将每次交流写回同一个地方。
后半部分是将其与带有聊天界面的搜索框区分开来的关键。在 MemoryLake 的 IM 连接中，交流会转化为记忆，因此语料库会随着团队实际提出的问题而增长，而不是来自于某人必须安排的文档编写冲刺。设置分为三个步骤，平台差异全部在第二步中。
步骤 1：添加 IM 连接
在控制台中，打开 MemoryLake → Workspaces，打开您想要公开其记忆的工作区，切换到 IM 选项卡，然后选择您的平台。在开始之前有两个先决条件：您需要拥有团队的所有者或管理员角色，因为成员“既不能查看也不能更改集成”，并且工作区至少需要一个项目以及一个与其关联的智能体（agent）。
步骤 2：输入应用凭据
每个平台都会颁发不同的一对凭据，并且每个平台都有不同的审批实际情况。这是值得提前规划的部分。
| 平台 | 您粘贴的内容 | 您的管理成本 |
|---|---|---|
| Slack | 机器人用户 OAuth 令牌 (xoxb-) + 应用级令牌 (xapp-) | 无需审核。文档直接指出：“Slack 侧不需要任何审核周期——一个人可以在大约十分钟内完成设置。” |
| 飞书 | App ID (cli_) + App Secret | 管理员权限，并且“发布版本需要管理员审核”。在此之前，权限范围是无效的：“权限只有在版本发布并获得批准后才会生效。” |
| 钉钉 | Client ID + Client Secret | 钉钉管理员权限，因为您需要创建应用、申请权限并发布它。 |
两个可以节省实际时间的注意事项。在 Slack 上，通过清单（manifest）创建应用可以一次性配置权限范围、事件订阅、私信入口和套接字模式（Socket Mode）——并且以后对权限范围或事件的任何更改都需要重新安装到工作区才能生效。在钉钉上，有一个可选的第三个字段，即 AI 卡片模板 ID：将其留空意味着每个回答发送一条消息，而设置它则可以实现逐字流式传输。
在您申请任何内容之前，有一个值得注意的命名陷阱：“飞书和 Lark 是两个独立的平台。”飞书是国内版，Lark 是国际版；账号和应用不互通，而特定部署与哪一个平台通信是部署级别的设置，而不是每个集成的选择。在错误的控制台中创建应用之前，请先与您的管理员确认这一点。
步骤 3：创建并连接
选择从聊天端回答消息的智能体，然后设置记忆范围：一个必选的读写项目（机器人从中检索并写入），以及任意数量的只读项目（它只能搜索但绝不能写入）。
请将其视为一项安全决策。文档中明确指出——“读写项目是一项授权决策”——因为每个能够接触到机器人的人既可以写入该项目，也可以读取其中已有的内容。将其指向您打算与团队共享的项目，而不是保存敏感材料的项目。然后创建集成并确认卡片显示为 Connected（已连接）。
三个真实的限制。机器人不会读取您的聊天历史记录：在每个平台上，它只接收提及它的消息，因此它无法看到频道或群组中的其他对话。它根据您连接的项目进行回答，这意味着第一周的质量取决于您加载的内容质量。而且它是上下文而不是强制执行——对于任何必须为真的事物，政策或检查才是保证，而不是记忆层。
运行后各平台的差异
其运行机制的分歧方式可能会让团队在第一天感到惊讶。
引起机器人的注意。 在群聊中，这三个平台都需要 @ 提及——未被提及的消息绝不会送达。私信（DM）有所不同：在 Slack 上，成员在侧边栏的 Apps 下找到该应用，无需 @ 即可提问；飞书私信受应用的可用范围控制；钉钉的集成则是围绕群组使用进行记录的。
答案出现的位置。 Slack 会在您的问题下方以回复串（thread）的形式进行回复，从而保持繁忙频道的易读性。飞书会引用您的消息并 @ 提及您进行回复，这可以防止答案在快速滚动的群组中丢失。
答案如何流式传输。 飞书逐字流式传输。Slack 通过分段编辑同一条消息来进行流式传输——出现 (edited) 标记是正常现象，并且在大约前 12 秒后刷新率会变慢。除非您提供了 AI 卡片模板 ID，否则钉钉每个回答发送一条消息。
发送文件或截图。 Slack 需要将文件和提及放在同一条消息中：“单独发布到频道的文件（没有提及）永远不会到达机器人——Slack 不会发送它。”飞书针对群组文档的有文档记录的路径是发布文件，然后回复该消息并 @ 提及机器人。钉钉将 @机器人 加上文本和图像作为单条富文本消息接收。
上下文持续多长时间。 Slack 频道是按回复串（thread）划分的，没有过期时间——一天后返回同一个回复串仍然有效。飞书和钉钉群组是按话题（topic）划分范围的：在 8 分钟无活动后，下一个问题将开始一个新话题，并且在发送文件或截图后，该窗口会延长至 30 分钟，以便针对同一张图片的后续提问能够继续生效。
重新开始。 在飞书和钉钉上，发送 /new。在 Slack 上，重置词没有斜杠——客户端会将任何以 / 开头的内容拦截为斜杠命令，因此在私信中它是单独的 new，或者在回复串中是 @bot new。
谁被允许加入。 访问权限由聊天平台侧决定，而不是通过第二个白名单。来自外部组织的 Slack Connect 用户会被默默忽略——不占用额度，不写入记忆。钉钉仅处理来自您自己组织成员的消息。在飞书上，私信遵循应用的可用范围，群组遵循群组成员身份。
群组内的隐私。 在这三个平台上，对话上下文都是针对个人的：在同一个群组或回复串中，一个人的交流绝不会出现在另一个人的交流中。项目记忆是共享的，这正是连接它的意义所在。
打造能回答问题的知识库的最佳实践
连接一个项目，而不是您拥有的所有内容。 从一个范围限定在团队应该共同了解的内容的项目开始，并为机器人可以引用但绝不能修改的材料添加只读项目。
用您已经在回答的问题来填充它，而不是您的文档库。 20 个带有答案和原因的常见问题胜过 200 页文档，因为当具体细节发生变化时，原因才是保留下来的东西。
每条记录只写一个主张。 简短、自包含的记录检索起来很干净。长文档会被完整返回，并将提取工作重新推给读者——这正是 Wiki 曾面临的失败。
选择您实际使用的平台。 如果问题出现在其他地方，那么集成将毫无价值。在一家使用钉钉运行的公司中，完美的 Slack 设置只是累赘。
在发布当天告诉大家这两条规则。 每次都要提及机器人（包括回复串回复），并在提及机器人的同一条消息中附加文件。几乎所有“它忽略了我”的报告都可以追溯到这两个原因之一。
在飞书或钉钉上，先询问管理员。 两者都需要发布和权限审核，因此周一提交的申请并不意味着周一就能运行机器人。Slack 是您可以在一个下午自己完成的那个。
将判断权留给人类。 机器人返回的是团队已经确立的内容；对于没人记录的情况该怎么办，仍然需要人类来决定。这一边界在AI 记忆究竟是什么中有所界定。
结论
知识库是在使用时失败的，而不是在编写时。问题之所以在群聊中提出，是因为同事们都在那里，而文档则要求人们离开该窗口、进行搜索并自己组装答案。聊天平台已经缩小了部分差距——在包含这些功能的计划中，Slack 的 AI 回答在 Slack 内容上运行良好，且仅限于每个人可以访问的内容——但存在于文档中而不是消息中的知识则超出了该范围，除非您使用的是可以访问外部来源的级别。
将知识库放在 @ 提及之后，可以同时消除上下文切换和组装步骤，并且将每次交流写回意味着语料库是从真实问题中增长的，而不是来自文档编写冲刺。设置很简短；需要规划的部分是管理方面的。决定谁可以在飞书或钉钉上批准应用，以及您愿意让每个能够接触到机器人的人读取哪个项目。做好这两点，Wiki 就不再是人们被要求去阅读的东西了。