最近几篇播客文章就是这个链路的结果。不是先手动整理完再让 AI 润色，而是从音频下载、转写、纪要、提炼到成文，中间每一步都开始被 Agent 接住。

1. 划重点

• 这几天实践了怎么把 飞书 接进 Codex 的工作流。
• 飞书 CLI 和 飞书 MCP 的配置，基本都是直接和 Codex 一起完成的。
  • 现在很少还需要看什么安装教程了
  • 未来这些所谓的文档都是写给 Agent 看的了
• 最有感的是 飞书 CLI，它能把云文档、妙记这些素材入口接起来。
• 最近几篇关于播客的文章，基本都是沿着这条链路做出来的：
  • 小宇宙技能 下载音频 -> 飞书妙记 转写 -> 智能纪要 -> Codex 整理、提炼、转译 -> 写成 note。

2. 小事

以前飞书里的东西，更多只是我自己打开看。现在至少有几条路可以被 Codex 接住：

• 直接读 飞书文档
• 通过 飞书 MCP 接云文档
• 通过 飞书 CLI 查会议、妙记和其它素材
• 通过 飞书妙记 把音频转成文字

播客这条链路尤其具体，而且已经不是“试一下”。

最近几篇关于播客的文章，基本都是这么来的：我先用 小宇宙技能 下载播客音频，再交给 飞书妙记 转写。拿到文字和智能纪要以后，再让 Codex 做整理、提炼、转译，最后写成 note。

所以这条链路不是抽象设想，而是已经变成了一个稳定的小生产线。

连接飞书这件事，不只是为了“能查飞书”，而是把飞书里已经存在的材料，以及飞书本身已经做得不错的一些能力，比如妙记，接进 Codex 的处理链路里。

3. 最后，为什么是 CLI 和 MCP

为什么现在各种 IM 工具、办公软件、SaaS 平台，都开始补 CLI 和 MCP。

过去这些平台主要是给人用的。人打开界面，搜索文档，点开会议记录，上传音频，等妙记转写，再把结果复制出去。

但 Agent 不适合这样用软件。Agent 需要的是稳定入口：

• MCP 让它能读到平台里的上下文
• CLI 让它能调用平台里的能力

所以 CLI 和 MCP 本质上不是开发者玩具，而是 SaaS 平台给 Agent 留出来的新入口。

飞书这个案例很小，但能说明问题：文档、妙记、音频转写这些能力本来就在飞书里。接上 飞书 CLI 和 飞书 MCP 以后，Codex 这样的Agent才能把它们串成一条可执行的素材链路。