WorkBuddy + 腾讯乐享，原来知识库还能这么用

大家好，我是苍何。

我在上个月的时候，分享了我是如何用 WorkBuddy + Codex 搭建个人知识库的文章。

图片展示的是苍何在2026年8月9日发布的一篇名为《用 WorkBuddy / Codex + Obsidian 搭建自生长的个人知识库实战》的原创文章。文章开头介绍苍何，提到如果没有AI，他最想做的是知识管理博主，但分享方法论也没那么有意思。图片中还显示了该文章的点赞数954、评论数6090、收藏数634、分享数80等数据，以及21人关注此文章和片段的信息。该图片与上下文紧密相关，是对苍何分享个人知识库搭建经验文章的直观呈现。

收获到了很多朋友的喜欢，不少朋友更是在评论区分享自己的搭建实践以及自己的困惑。

这张图片是用户在评论区的提问内容，显示为在北京8月9日发布的评论，提问内容为“这种能小团队使用吗？或者局域网共享？”，该评论是针对WorkBuddy搭建个人知识库的内容提出的，对应前文内容中提及的读者针对知识库搭建方式的相关困惑，体现了有用户关心该知识库搭建方式在团队、局域网场景下的适用性。

其中有人问到，说我的那种知识库搭建方式是否支持团队使用。

个人知识库可以围绕自己的习惯来搭。到了团队场景或者企业场景，还得考虑：资料散在不同地方怎么汇总，版本不一致该信哪份，哪些内容能让谁、让哪个 Agent 读取。

于是我去找了找适合团队使用的知识库，发现腾讯乐享也能接入我正在用的 WorkBuddy。手头正好有个项目要整理资料，就拿它试了试。

刚开始做项目时，我只想着先把功能做出来，文档就想着回头再写，结果一直拖着。

程序员拖延写文档的双格漫画：写代码时说文档回头补，几周后看不懂代码，git blame 一查发现作者是自己

最近维护 WeSight，我就有这个感受。功能越做越多，改个页面、排查一个问题，都得先翻代码、找资料。让 AI 来做，它也得从头检索一遍。

WeSight 是我在做的开源桌面 AI Agent 项目，把 Claude Code、Codex 等编码 Agent 放进同一个可视化工作台。

图片展示了开源桌面AI Agent控制台WeSight的官网页面。页面上方有导航栏，包含Product、Studio、Workflows等选项。中间部分以大字突出“Run your CLI agents from one desktop app”，并说明其功能，即把Claude Code、Codex等编码Agent放进可视化工作台，统一本地运行时、模型提供者、权限事件、技能、定时任务和内存。页面底部有“Download”下载按钮。该图片与上下文介绍的WeSight是作者在做的开源桌面AI Agent控制台相呼应，直观呈现了其功能特点。

我这个项目，已经同时包含产品定义、技术架构、设计素材和用户反馈。放到企业里，这些资料会分散在产品、研发、客服、销售等多个部门。

如果没有统一知识来源，不同 Agent 很容易各自拿到一部分信息，甚至继续引用已经过期的版本。

这段时间，我试着用腾讯乐享整理它的项目资料。乐享是一套给 Agent 用的企业 AI 知识库，我把技术文档、设计素材和用户反馈放进去，再让 Agent 带着这些资料继续做事。

这次，我想验证乐享能否把一套项目知识接进来，加工成 Agent 能理解的结构，持续管理其来源和状态，再按权限应用到 WorkBuddy 的真实任务中。

我先从 WorkBuddy 里接上乐享知识库，让它梳理本地项目。

要求很直接，乐享的 Agent 会自主建库和进行分类整理。

整理完，一共分了五个库：产品与业务、技术与工程、设计与规范、运营与增长，以及团队规范与新人手册。

WeSight 项目的五个知识库

按业务用途分类后，各类项目资料有了明确的归属。即使主要由我一个人维护，也能按统一的结构查找、补充和更新文档。

比如技术库里的这篇开发指南，把架构说明和常用命令整理到了一起，还注明内容来自仓库中的哪份文件。要核对时，可以回去看原文。

技术与工程库中的架构说明和开发指南

我更喜欢的是，之前反复调整的那些界面截图，也一起收进来了。右侧还有对图片内容的描述。

下次讨论页面怎么改，就可以直接引用这些资料。否则，光是找到“之前看过的那一版”，有时候就得翻一会儿。

设计与规范库中的界面截图及知识概览

到这里，项目里的文字和图片有了共同的入口，也补上了分类、来源和说明。Agent 再来查，至少有地方下手了。

项目资料整理完，还有一类内容每天都在增加：用户反馈。

大家在群里聊问题，有人报 Bug，有人提建议。同一件事可能隔几天又被提起。等到要安排开发时，再翻聊天记录就挺费劲。

所以我在 WorkBuddy 里配了一个自动化任务：每天收集产品群的反馈，写进乐享的运营与增长库，晚上 8 点向我汇报。加

在这套流程里，WorkBuddy负责定时执行、跨工具取数和生成结果；乐享负责保存团队知识、维持资料之间的关系与权限，并为下一次任务提供可信上下文。

这里是 WorkBuddy 负责定时执行，乐享存放整理后的资料。任务里要把知识库接上，企业**的访问也要提前配好，能读取哪些记录取决于账号权限。

下面这些，就是已经按日期留下来的记录。

团队和企业一起使用时，还要注意资料的访问边界。Agent调用乐享知识时，会受到当前用户知识权限的约束；不同成员发起同一个任务，能够调用的资料范围也可能不同。这个就解决了我一直以来的痛点和担忧。

反馈收进来以后，我又往前试了一步。

用户说“用不了”，到底是已知问题，还是一个没遇到过的新问题？如果开发文档里已经分析过，再从头查一遍就很可惜。

于是我让 Agent 同时查两个地方：运营库里的用户反馈，以及技术库里的架构说明和已知问题。

提示词里，我特别强调要留下用户原话，找到对应的技术文档并写出文档名；没找到记录的，就标成待核实。

完整提示词放在文末。先看这份结果。

用户反馈与技术文档交叉核实的分析报表，AI 辅助生成

比如这两条反馈，一条有记录可查，另一条还得复现。

一条是“IM 手动停止后，新消息不显示或延迟较高”。报表找到了《07 IM 渠道停止对话后消息状态异常分析》，标注为开发库已有记录支持的问题。接下来就能沿着这份文档，看之前分析到了哪一步。

另一条是 Apple Silicon 设备上，0.9.3 版本首次启动出现白屏。这条被标成了“开发库无记载，需复现”。

两条用户反馈的跟进方式：已有记录则查阅历史分析，未收录则尝试复现并补充记录；AI 辅助生成示意图

看到这里，至少知道接下来该分别做什么：一条先查已有分析，另一条先想办法复现。它还单独分出了噪音信息，方便我继续筛选。

这比只列出一长串问题更方便我往下处理。真正的原因是否找对、修复能不能生效，后面还得验证。

我理解的知识治理，大概就落实在这些细节上：哪句话有出处，哪条结论还没确认，哪些资料需要继续补。把这些分清楚，后续的 Agent 才有比较明确的依据。

知识治理的三个检查维度：资料出处、核实状态与待补内容，为 Agent 后续处理提供依据；AI 辅助生成示意图

前面那条 IM 消息异常，就连着用户反馈和一份历史分析。要是这种联系能留下来，下次遇到类似问题，就能顺着找到相关资料。

乐享的知识图谱也是这个思路：先由机器梳理资料之间的关联，再让熟悉业务的人确认。

项目一直在改，文档也得跟着更新。比如 Bug 已经修了，库里还写着“待解决”，下次查到就容易误判。

我发现乐享正在探索通过 LLM Wiki，把分散的原始资料重新组织成更适合 AI 理解和调用的 Wiki；当项目内容发生变化时，还可以进一步识别新旧知识之间的差异，提出更新建议，让知识持续跟上项目进展。

LLM wiki 持续维护的探索思路：项目变化后由 AI 提出更新建议，经人工核对再更新知识库；AI 辅助生成概念示意图

我选中 WeSight 项目的相关资料，交给乐享的 LLM Wiki 去构建。它会从已有文档中抽取主题和关系，再重新整理成一组互相关联的 Wiki 页面。过了一段时间，我看到的结果是这样的

图片展示的是LLM Wiki的Wiki概览页面。页面上方有“LLM-wiki - Wiki概览”标题，下方是关于LLM Wiki的介绍，包括其设计目标、模型检索基础、桌面原型实现等。页面左侧有导航栏，可访问主页、Wiki、Agent引擎、Electron桌面、模型检索、Provider配置等板块。右侧有“知识最核心主题”板块，列出Agent引擎、Electron桌面、Windows平台、其他、数据存储、模型Provider等主题，每个主题后有数字序号标识。该图与上下文介绍的LLM Wiki相关，展示了其内容概览。

我体验过很多LLM wiki。乐享和workbuddy结合，能解决“文档半衰期”问题，拥有闭环的知识反哺与维护机制，项目永远在迭代，知识库最大的痛点永远是“写出来即过时”。好用的系统必须有像我们前面提到的巡检机制——能够感知代码与业务变化，提示人工核对，或者由 Agent 验证后再把最新结果反写回库中。能自我更新的知识库，才有长期的生命力。刚好乐享在这方面很有巧思。

前面的报表可以用来辅助安排开发。再往后，可以让接入知识库的编码 Agent 查资料、尝试复现问题，把验证过的结果写回来。这个流程还有继续往下做的空间。

这里我们以一个真实的开发来举例。

团队收到**反馈：“Windows 客户端在特定系统环境下偶发白屏/闪退”。以往开发需要到处翻历史 PR、**群聊记录或架构文档定位原因，极其费时。

图片展示的是WorkBuddy+腾讯乐享知识库的对话界面。上方提示在Windows平台遇到偶发闪退问题，需结合当前乐享知识库中沉淀的Electron架构、Windows平台适配文档及历史Issue记录排查。下方是WorkBuddy的回复，显示预计耗时8.25 - 11.7天，已深思熟虑，先从乐享知识库查找相关文档再做排查，还列出了搜索关键词如“Electron”“Windows”等。该图片与文档中尝试用知识库资料做路演PPT的上下文相关，展示了知识库的使用场景。

Agent 输出排查思路与复现代码

图片展示了WorkBuddy+腾讯乐享在排查Windows平台Electron闪退问题时，Agent利用知识库辅助排查的场景。Agent先在乐享知识库检索相关文档，再进行排查，找到关键的历史Issue来源，如block fetch page等，继续读取相关内容。图片中还标注了“可以看到前期Agent规划的知识库在此刻的作用”，表明知识库在此问题排查中发挥了重要作用。

完整的排查报告(讲的大概意思是解释为什么会闪退，以及闪退的原因是什么。)

这张图片展示的是软件闪退问题排查的完整流程，以时序图形式呈现。第一例程序会自动启动，先后执行启动+whenReady、initStore()（注册同步打开SQLite）、createWindow()，此时窗口处于ready-to-show状态但不显示；当用户双击图标触发第二例操作时，会拉起新进程，主实例appquit()无日志，出现进程抢锁失败，最终导致任务栏一闪即退，且此时主实例的second-instance状态下mainWindow仍为空，窗口始终无法正常显示。图片对应文档中“完整的排查报告”相关内容，以可视化方式呈现了程序闪退的原因及排查过程。

问题复现和修复结果验证后，Agent 可以把结论整理成知识更新建议；经确认后再回写乐享，为下一次排查提供依据。

这张图片是一份记录Windows平台Electron闪退问题的排查文档截图，文档内容围绕闪退问题展开，包含具体的排查条目与内容。其中明确列出了4处更新记录，分别是关于旧版Windows调试的参考变更、已知崩溃属性的优化修正、对Windows版本兼容性的调整，以及团队成员的补充说明，还标注了对应操作的对应编号。文档下方还附带了相关命令行操作的内容记录，整体呈现出问题排查与复盘的完整过程，契合上下文里Agent完成闪退排查后生成排查报告的相关内容。

接着，我又试着用库里的资料做一份路演 PPT。

产品介绍、技术资料和界面截图都在库里，就想着让它用这些内容做一份初稿：

从执行过程能看到，它先找了产品定位、技术架构和功能特性等资料。

乐享检索项目知识，准备生成路演 PPT

下面是其中两页。封面用了 WeSight 的产品定位，功能页把对话界面和实时工作区放在了一起。

WeSight 路演 PPT 封面，AI 辅助生成

WeSight 路演 PPT 功能页，AI 辅助生成

说实话，通过乐享 LLM Wiki 这种方式做的路演 PPT，发现 Agent 查的更准了，效果比我之前做的好多了。

图片展示的是WeSight产品路演PPT封面。左侧上方有WeSight标志及“OPEN SOURCE · MIT”字样，中间是“产品路演 · PRODUCT ROADSHOW”标题，下方是“开源桌面AI Agent控制台”及“把Claude Code、Codex等编码Agent统一装进同一个可视化桌面工作台”等文字。右侧是一个卡通机器人形象，背景为深蓝色渐变。该图片位于文档开头部分，是对WeSight产品定位及功能的介绍，与文档中对产品功能的描述相呼应。

这次折腾下来，最有用的还是反馈核实那一步。已有分析的，可以顺着文档继续查；还没记过的，先留着排查。

项目知识库中的资料按任务复用：项目介绍和界面素材用于路演 PPT 初稿，用户反馈和技术文档用于反馈核实；AI 辅助生成示意图

资料整理也有前期成本，生成的结果还得自己看。但对我这种会反复修改项目、处理用户反馈的人来说，先把这些记录留下来，后面确实方便些。

如果你和团队也经常在聊天记录、技术文档之间来回找东西，可以参考这个流程。先拿一小段时间的反馈和对应文档试一次，看看它找的依据对不对，再决定要不要用到更多工作里。

完整提示词留在下面，按自己的项目改就行。

下面是这次用的完整反馈分析提示词。复用时，把项目名、知识库名和文档名换成自己的实际内容，并检查 Agent 是否具备相应的访问权限。