# WorkBuddy 飞书文档读取踩坑实录：AI 越改越崩，一个被忽略的信任机制坑掉上千积分 #WorkBuddy#

前言

如果你在 WorkBuddy 中接入了飞书（Feishu），并且在一个独立任务窗口里能正常读取飞书文档，但在另一个空间（Workspace）下的任务窗口里怎么都读不了——别急着让 AI 帮你修，先看完这篇文章。

这不是一个技术教程，而是一个真实用户的踩坑记录。我花了大半天时间、消耗了大量积分，让 AI 反复排查"飞书文档读取失败"的问题，结果每次它都信誓旦旦说"找到根因了""修好了"，然后在另一个窗口依然不能用。最终我自己发现了问题所在——但发现的方式不是靠 AI 的诊断，而是靠放弃。

希望这篇文章能帮你少走弯路。

一、问题是什么样的

我的使用场景很典型：

• 在 WorkBuddy 中创建了多个任务窗口
• 有些是独立的任务窗口，有些归属于某个"空间"（比如"XX工作集"）
• 我已经接入了飞书连接器，能正常收发飞书消息
• 在某个独立任务窗口中，AI 能顺利读取飞书文档、甚至给出优化建议
• 但在空间下的任务窗口中，AI 始终无法读取飞书文档

具体表现是：我发一个飞书文档链接过去，那个窗口的 AI 会尝试用网页抓取工具去打开链接，然后被飞书的登录页挡住，最后告诉你"无法访问，请截图发给我"。

二、踩坑全过程

第一轮：AI 说"令牌过期了"

AI 的第一个诊断是：飞书 OAuth 令牌过期了。

它检查了令牌状态，发现 access token 确实过期了，于是做了刷新操作。刷新后在这个窗口里确实能读飞书文档了。

但另一个窗口还是不行。

📌 第一个教训：令牌过期只影响当前窗口的 CLI 调用，和另一个窗口读不了文档没有直接关系。AI 把"相关性"当成了"因果性"。

第二轮：AI 说"启动脚本有路径 Bug"

AI 发现飞书 CLI 工具（lark-cli）在 Git Bash 环境下有路径转换 Bug——cygpath 不可用时，Unix 风格路径 /c/Users/G/... 没有正确转换为 Windows 格式，导致 Node.js 解析路径错误。

AI 修复了这个 Bug，信心满满地说"现在所有新窗口都能用了"。

但另一个窗口还是不行。

📌 第二个教训：CLI 工具的 Bug 只影响走 CLI 路径的调用。如果另一个窗口根本不用 CLI，而是用网页抓取工具去打开飞书链接，修 CLI Bug 对它毫无帮助。

第三轮：AI 说"创建一个全局技能就行"

AI 创建了一个用户级技能（feishu-router），规则是"凡遇到飞书 URL，一律用 lark-cli，禁用 WebFetch"。这个技能对所有项目窗口生效。

AI 再次信心满满："这个技能是用户级的，所有窗口都会加载。"

但另一个窗口还是不行。

📌 第三个教训：技能只是告诉 AI "应该怎么做"，但如果那个窗口的工具集里压根没有 Bash 工具，它连 lark-cli 都调不了。技能是导航，不是引擎——没有引擎的车，导航再准也开不动。

第四轮：AI 说"配置 MCP 服务器就彻底解决了"

AI 发现了终极方案：把飞书能力做成 MCP 服务器（lark-mcp），MCP 工具是所有窗口共有的，不依赖 Bash。

于是 AI 折腾了很长时间：

• 安装 lark-mcp 包（遇到 npm 缓存权限问题）
• 修复 npm 的 .DELETE 文件 Bug（Windows 上 npm 把 .js 文件重命名了）
• 完成 OAuth 授权登录
• 扩展 MCP 工具到 32 个（含文档读取、编辑、创建）
• 更新 MCP 配置文件

AI 第四次信心满满："现在所有窗口都能读取、编辑、创建飞书文档了。"

但另一个窗口——你猜对了——还是不行。

📌 第四个教训：MCP 服务器配置好了不等于生效了。WorkBuddy 有一个安全机制：自定义 MCP 服务器默认不被信任，必须在 UI 中手动点击"信任"才能被所有窗口加载。光改配置文件，日志里会一直报 skipping untrusted server。

第五轮：我放弃了

在经历了四轮"修好了→还是不行"的循环后，我做了最正确的决定：放弃在空间任务窗口中读取飞书文档，改在独立任务窗口中完成工作。

然后我就能继续工作了。

三、真正的根因是什么

事后复盘，问题的根因其实是一个被所有人忽略的安全机制：

MCP 服务器的信任机制

WorkBuddy 的 MCP 安全策略是这样的：

关键点：直接编辑 mcp.json 或 .mcp.json 配置文件添加 MCP 服务器，不会自动获得信任状态。mcp-approvals.json 文件记录信任状态，默认是空的 {}。

也就是说，AI 改了半天配置文件、修了 Bug、装了包、做了授权——全都是无用功，因为 MCP 服务器从未被信任过，日志里一直在跳过它。

为什么独立窗口能读但空间窗口不能

这是最让人困惑的地方。实际情况是：

• 独立任务窗口的飞书能力走的是 CLI 模式（lark-cli），通过飞书连接器（feishu connector）调用，不依赖 MCP 信任机制
• 空间下的任务窗口可能走了不同的工具路径，或者工具集配置不同，导致没有正确加载飞书 CLI 工具

所以两个窗口表现不一致，不是因为"空间"本身有什么限制，而是底层工具加载机制和信任状态的差异。

四、避坑指南：你应该怎么做

坑 1：不要盲目信任 AI 的"我找到根因了"

AI 每次诊断后都会说"找到根因了""修好了"，但它的诊断往往只看到了一层原因，没有挖到最底层。

正确做法：让 AI 先验证再承诺。要求它用日志、工具查询等硬证据确认修复是否生效，而不是改完配置就说"好了"。

坑 2：MCP 服务器配置好≠生效了

这是最容易踩的坑。你在配置文件里加了一个 MCP 服务器，它看起来一切正常——包安装了、授权做了、配置对了——但它就是不工作。

正确做法：

1. 打开 WorkBuddy → 连接器管理（或设置中的 MCP 管理页面）
2. 找到你添加的自定义 MCP 服务器
3. 点击 "信任" 或 "启用"
4. 重启 WorkBuddy，让所有窗口重新加载工具

⚠️ 如果不重启，已打开的窗口不会感知到信任状态的变化。

坑 3：不同窗口的工具集可能不同

不要假设所有任务窗口都有相同的工具。空间下的窗口和独立窗口可能加载了不同的工具集。

正确做法：如果某个窗口读不了飞书文档，先让它检查自己有什么工具。如果它连 Bash 工具都没有，那任何依赖 CLI 的方案都无效。

坑 4：遇到问题先换窗口，不要死磕

这是最实用的一条。

当你在某个窗口反复遇到飞书文档读取问题时，不要花大量积分让 AI 排查。直接换一个能正常读取的窗口工作，把需要读取的文档内容复制过去。

这不是逃避问题，而是高效工作。排查配置问题可以另找时间慢慢搞。

坑 5：积分消耗要心里有数

我在这次踩坑过程中消耗了大量积分，而问题的解决方案其实很简单——换一个窗口或者去 UI 里点一下"信任"。

建议：当 AI 排查问题超过 3 轮还没有解决时，停下来，自己思考一下是不是方向错了。AI 会在错误的方向上越走越远，因为它没有全局视角。

五、总结

飞书是工作中最常用的文档平台之一，WorkBuddy 接入飞书的能力本身是好的。但在跨窗口使用时，信任机制、工具集差异这些隐藏的门槛会让你踩坑。

希望这篇踩坑记录能帮你省下几百积分和半天时间。如果你也遇到过类似的问题，欢迎在评论区交流。