Back to Home
10 min read

自动化操作Chrome下载飞书文档

chrome-dev-tool + Codex 自动化workflow搭建

今天在公众号上看到了这篇文章，于是正好想起来答辩要用的很多evidence都在飞书云文档里面。而飞书的文档界面又没有批量下载，只能一个一个手动点进每个文档再下载。手动太麻烦了，干脆让codex干这个事情试试。以下是实践成功的完整对话了。如果不成功可以让ChatGPT读这篇文章，然后自己再去网上搜搜，得出适合你的解决方案。

结论：可行。 Codex + Chrome DevTools MCP 很适合做这种“固定网页流程的重复点击”。Codex CLI 本身支持接入 MCP 服务器；Chrome DevTools MCP 也明确支持连接到已运行的 Chrome 会话，并提供点击、填写、等待、页面导航等浏览器操作工具。Chrome 144 之后还支持 --autoConnect，能直接复用你当前已经登录飞书的 Chrome 会话。(OpenAI 開發者)

但有一个真正的关键前提：飞书点“下载为 PDF → 导出”之后，必须是直接走 Chrome 下载，落到默认下载目录；一旦弹出系统级“另存为”窗口，自动化成功率就会明显下降。Chrome 官方帮助里说明了，Chrome 会把文件保存到默认下载位置，也可以改默认下载目录，或者切换“是否每次下载都询问保存位置”；而 Chrome DevTools MCP 公布的工具集中有 click、fill、wait_for、navigate_page、upload_file 等，但没有专门公开一个“控制系统另存为窗口/下载管理器”的工具。所以这件事总体可行，可靠程度是“需验证”，关键验证点就在飞书导出是否纯浏览器内完成。 (GitHub)

下面直接给你一套按 macOS 写的实操教程。你的浏览器环境本来就是 Mac，这样最省事。 可靠程度：确定 + 少量推测。 其中安装和连接步骤是确定的；飞书页面里具体按钮文案、是否有特殊弹窗，属于需验证。

一、先把环境弄成“适合自动下载”的状态

  1. 在 Finder 里先建一个空文件夹，比如： ~/Downloads/Feishu Documents
  2. 打开 Chrome，进设置里的下载页，把默认下载位置改到这个文件夹；同时把 “Ask where to save each file before downloading / 每次下载前询问保存位置”关掉。Chrome 官方文档明确支持改默认下载目录，也支持切换是否每次询问保存位置。(Google 支援)
  3. 同一个设置区域里，再确认一下站点的Automatic downloads / 自动下载权限没有被拦。Chrome 官方文档也说明了这个权限入口。(Google 支援)
  4. 强烈建议你单独开一个 Chrome profile（浏览器配置档）专门给飞书下载用，只登录飞书，不开别的敏感页面。原因是 Chrome DevTools MCP 连接到正在运行的 Chrome 时，会拿到该 profile 下所有打开窗口的访问权。这是官方写明的。(GitHub)

二、安装 Codex CLI

先确保你机器上已经有 Node.js 和 npm。然后终端执行：

npm i -g @openai/codex

装好后直接运行：

codex

第一次运行时，Codex 会提示你用 ChatGPT 账号或 API key 登录。OpenAI 官方文档就是这么写的；Codex CLI 也是官方支持的本地终端代理。(OpenAI 開發者)

三、给 Codex 接上 Chrome DevTools MCP

先执行标准安装命令：

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest

这个命令是 Chrome DevTools MCP 官方仓库里给 Codex 的标准接法。(GitHub)

然后编辑 Codex 的配置文件：

mkdir -p ~/.codex
open -e ~/.codex/config.toml

把 chrome-devtools 那段改成下面这样：

[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--autoConnect"]
startup_timeout_sec = 20
tool_timeout_sec = 120

这里的依据是两部分拼起来的： OpenAI 官方文档确认了 Codex 的 MCP 配置文件位置、配置格式、command/args 这些字段；Chrome DevTools MCP 官方文档确认了 --autoConnect 是合法参数，用来连接正在运行的 Chrome。所以这段配置本身是合理推导，不是瞎写。可靠程度：确定。 (OpenAI 開發者)

四、让 Chrome 允许被接管到当前会话

用你刚才那个专门的飞书 Chrome profile，打开 Chrome。 地址栏输入：

chrome://inspect/#remote-debugging

把 remote debugging 打开，然后在弹出的权限界面里点 Allow。 Chrome 官方关于 DevTools MCP 的说明写得很清楚：在 Chrome 144 及以上，可以这样启用 remote debugging，然后让 MCP 用 --autoConnect 复用你当前会话。(GitHub)

这里还有两条你必须知道的限制： 第一，autoConnect 会连到 Chrome 认定的默认 profile；第二，这个 profile 下所有打开窗口都能被访问。所以你跑任务时，最好只留飞书相关页面，别混着你的正常浏览窗口。(GitHub)

五、手动把飞书页面开到正确起点

这一步别让 Codex去找路，你自己先做。 用那个专门的 profile 登录飞书，然后手动进入：

云文档首页 → 归我所有

停在这个列表页，不要再往下点。这样做是为了减少 agent 在站内自己找菜单时绕路出错。 这一步是建议，不是官方要求。可靠程度：推测，但非常实用。

六、启动 Codex，然后直接给它这个任务提示词

先到一个空目录里启动 Codex：

mkdir -p ~/codex-feishu-export
cd ~/codex-feishu-export
codex

进入 Codex 后，直接贴这段：

使用 chrome-devtools MCP 控制我当前已经打开并登录好的 Chrome，会话里现在有飞书“归我所有”的文档列表页。

目标：把列表中的文档从上到下依次导出为 PDF 到 Chrome 默认下载目录。不要修改任何文档内容，不要删除、移动、重命名任何文件，不要离开飞书站点。

严格执行以下规则：

总规则：
1. 不要把“点击过按钮”当成成功。
2. 只有在你观察到真实下载证据后，才能输出“已导出 + 文档标题”。
3. 真实下载证据必须满足以下至少一项：
   - Chrome 页面中出现新的下载气泡或下载项，且文件名是 .pdf
   - 打开 chrome://downloads 后，能看到最新新增的 PDF 下载记录
4. 如果没有看到真实下载证据，就不能报成功。

每个文档的流程：
1. 在“归我所有”列表中，打开第一个尚未处理的文档。
2. 等待文档页面稳定。
3. 点击右上角“更多”菜单。
4. 在弹出的菜单中，找到“下载”这一项。
5. 注意：“下载”是悬停触发二级菜单，不是直接点击触发。
6. 将鼠标悬停在“下载”这一项上，并等待二级菜单稳定出现；等待至少 0.5 秒，直到你明确看到右侧出现“PDF”和“Word”等选项。
7. 只有在确认右侧二级菜单已经出现后，才移动到“PDF”并点击。
8. 如果二级菜单没有出现、闪退、或者 PDF 不可见，就不要继续乱点；从“更多”菜单这一步重新开始。
9. 点击“PDF”后，如果还需要点击“导出”，则点击“导出”。
10. 然后等待真实下载证据出现。不要根据猜测报成功。

失败与重试：
1. 每个文档最多重试 2 次。
2. 第 1 次失败后，从“更多”菜单重新开始，不要接着当前残缺菜单继续点。
3. 第 2 次失败后，打开 chrome://downloads 检查是否其实已经有新 PDF。
4. 如果仍没有新 PDF，则输出：失败 + 文档标题 + 原因“未观察到真实下载证据”，然后跳过该文档。

稳定性要求：
1. 优先使用页面快照、可访问元素、等待，不要用盲目的坐标点击。
2. 每次悬停到“下载”后，必须停顿，确认二级菜单可见。
3. 鼠标移动要慢，不要快速斜切到右边。
4. 如果菜单消失，就回到“更多”菜单重新展开。
5. 完成一个文档后，返回“归我所有”列表页，再处理下一个。
6. 如果列表需要滚动加载更多文档，就在列表页向下滚动后继续。
7. 一直执行到当前页面最底部，没有新文档可处理为止。

这段提示词的核心思路，是逼它机械重复，别让它自由发挥。 Chrome DevTools MCP 的公开工具就是偏这种“点、填、等、切页”的网页自动化；Codex CLI 也就是在终端里跑这种代理式任务。(OpenAI 開發者)

七、我对这事的实际评估

可行性：中高。 不是“玄学碰运气”，是真能做。尤其你这个流程高度重复，而且你还允许它只做机械动作。Codex 能接 MCP，Chrome DevTools MCP 能连已登录 Chrome，会大幅减少“登录态丢失”和“让代理自己登录飞书”的问题。(GitHub)

最可能卡住的点：需验证。 第一个，是飞书“更多 → 下载为 PDF → 导出”这一串按钮在页面结构里是否足够稳定，能不能每次都被快照识别到。 第二个，是点击“导出”之后到底是直接下载，还是某些情况下会弹额外确认、权限提示或系统保存对话框。 第三个，是“归我所有”页面有没有懒加载（滚动到下方才出现更多项）和偶发的悬浮菜单变化。 这些不是我在装神秘，这些就是所有浏览器 agent 真正会翻车的地方。

八、别犯这三个低级错误

第一，不要直接拿你的日常 Chrome 主 profile 跑。 因为官方明确说了，连接到运行中的 Chrome 后，MCP 对该 profile 的所有打开窗口都有访问权。(GitHub)

第二，不要开启“每次下载都询问保存位置”。 你要的是自动落盘，不是每次弹保存框。Chrome 官方帮助也明确说明了这个开关。(Google 支援)

第三，不要一上来就跑几十份。 先拿 3 份试跑。这个不是技术限制，是为了确认飞书这条导出链路到底是不是纯浏览器内流程。 这条属于建议，可靠程度：推测，但很值。