我用小龙虾搞了6个小时从在线文档平台导出了1162份文件

我用小龙虾搞了6小时从在线文档平台"抢救"出了1162份文件一次公司文档迁移引发的技术冒险 | 132个脚本的血泪史1162 成功导出 841M 总数据量 132 迭代脚本

事情是这样的。

公司有个团队，日常工作产出全在某个在线协作文档平台上 -- 产品方案、周报月报、数据报表、汇报PPT... 一年多下来积攒了上千份文档。

然后，公司要求各部门把在线文档迁移到新的平台上。

问题来了：1200多份文档怎么迁？在线文档不像本地文件可以直接拷走，得一份一份导出来。领导发话了："把所有文档都下载保存一份，准备迁移。"

第一反应：这不应该有现成工具吗？

我第一反应是：2026年了，这种需求应该有成熟方案吧？于是开始搜索。

搜了一圈，发现市面上根本没有能用的批量导出工具。几个号称能批量下载的，要么年久失修早就不能用了，要么只支持其他平台。

那平台自己呢？我又仔仔细细翻了一遍管理后台：

三条路，全堵死了管理员批量导出？ -- 不支持。后台根本没有这个功能。数据迁移接口？ -- 没有。开放API里压根没有批量导出的能力。第三方工具？ -- 找不到。搜遍全网，无一可用。

也就是说，唯一的官方途径就是：打开一个文档 -> 手动点"导出" -> 保存 -> 再打开下一个。

一份文档1分钟，1200份文档...嗯，只要20个小时不间断机械操作就行了。

我盯着屏幕上密密麻麻的文件列表，陷入了沉思。

不行。这事我干不了。准确地说，这不是人该干的活。

于是我做了一个决定 --

让AI来干。

- - -

[1] 开局：这不就是自动点点点嘛起步 | 盲目自信

我打开AI对话框，噼里啪啦敲下了需求。AI倒是信心十足，秒回方案 -- 先搞个扫码登录服务器把Cookie存下来，后面的脚本就能自动登录了。

— 核心对话 #1 - 天真的开始 —

我：我们的在线文档平台上有1200多个文件要全部导出保存，但平台不支持批量导出，你能帮我自动化处理吗？

AI：没问题！思路很简单：我用浏览器自动化来模拟操作，逐个打开文档然后触发导出。先让我创建一个登录服务，你扫个码就行...

AI很利索，三下五除二就搭好了框架：模拟人的操作 -- 打开文档、点菜单、点"导出为Word"、等下载完成、下一个。循环，收工。

测试了前面几个文档，嚯，真的能用！文件唰唰地往本地文件夹里落。

我心想，这不就搞定了么？设个循环让它跑着，我去倒杯咖啡。

然后 -- 现实给了我一记漂亮的右勾拳。

- - -

[2] 遭遇最终BOSS：滑块验证码卡壳 | 从巅峰到谷底

导出到第3个文档的时候，页面突然弹出了一个东西。

一个滑块验证码。

就是那种要你把拼图碎片精准滑到缺口位置的验证码 -- 平台自带的反机器人防线。它在说："我知道你不是人。"

当头一棒每导出3-5个文档，就会弹出一次验证码。1200个文档，意味着要手动滑200-400次验证码。这跟一个一个手动导出有什么本质区别？自动化的意义瞬间归零。

但AI不信邪。它决定跟验证码正面刚，由此开启了一场堪称惨烈的"人机大战"：

●	Round 1 - 暴力美学预设几个固定距离，随机选一个滑过去。简单粗暴。成功率：约5%。基本等于闭着眼睛瞎蒙。
●	Round 2 - 上计算机视觉祭出了Canvas像素分析 -- 边缘检测、亮度方差、梯度计算，自动识别拼图缺口位置。成功率：约15%。验证码表示：就这？
●	Round 3 - 装成人类贝塞尔曲线运动轨迹、随机微抖动、加速减速、终点处的小"回弹"。竭尽全力模拟人类手感。成功率：约25%。验证码冷笑：你的灵魂不像人类。
●	Round 4, 5, 6... 15又迭代了十几个版本，什么花活都试了。最终不得不承认：这是一面墙，撞不穿的那种。

到这时候，我已经看着AI写了15个不同的验证码对抗脚本，大半天时间全烧在这上面了。屏幕上满是失败的日志。

— 核心对话 #2 - 绝望中的转机 —

我：兄弟，验证码这条路是不是走不通了？有没有可能完全不走"导出"这条路？

AI：你提醒我了。我一直在想怎么"导出"，但其实我们要的不是"导出"这个动作，而是文档里的内容。让我换个角度 -- 如果我能直接拿到文档的原始数据呢？

这句话像一道闪电劈开了迷雾。对啊，我们要的是数据，不是那个"导出"按钮。

血泪教训 #1永远不要跟验证码正面硬刚。它是守门的，你绕着走就行了。死磕一面墙不如找一扇窗。

- - -

[3] 转折点：看到了数据本身转折 | 柳暗花明又一村

夜深了。验证码那条路彻底放弃，AI开始换一种方式思考这个问题。

它打开了浏览器的开发者工具，开始观察：当你正常打开一个文档的时候，浏览器到底在背后做了什么？

JavaScript// 监听网络请求，观察数据接口page.on('request', req => { const url = req.url(); if (url.includes('export') || url.includes('loadDoc') || url.includes('download')) { // 找到了！ console.log('发现目标接口:', url); }});

然后 -- AI发现了一个让整个项目起死回生的东西。

原来，平台在正常打开每个文档时，都会调用一个内部数据接口，把文档的完整内容加载到浏览器里，然后在前端渲染给你看。

换句话说，每次你打开一个文档，文档的全部数据就已经到你的浏览器里了。

更关键的是：读取这个数据不会触发验证码。因为在平台看来，你只是在正常浏览文档而已 -- 谁会对"打开文档"设验证码呢？

柳暗花明这个数据接口返回的是文档的原始结构化数据 -- 完整的文字内容、格式信息、图片链接，一样不少。也就是说：我们可以自己把这些数据组装成Word文件！不需要"导出"，不需要触碰那个该死的验证码。

但高兴了三秒钟之后，我看了一眼这个数据的格式...好家伙：

接口返回数据 (示意)data_type\nformat\n28456%7B%22content%22%3A%5B%7B%22ops%22%3A%5B%7B%22type%22%3A%22insert%22%2C%22text%22%3A%22%u6587%u6863%u5185%u5BB9... // 是的，就是这么一坨URL编码的JSON// 还混着 %uXXXX 这种非标准编码

— 核心对话 #3 - 凌晨3点的突破 —

我：这一坨是啥啊...能解出来吗？

AI：让我看看... 它用了一种分块传输格式，内容经过URL编码，而且混用了标准编码和非标准的 %uXXXX 编码。给我点时间写个解析器。

AI：解出来了！这是完整的文档结构化数据 -- 文字、段落格式、标题层级、图片引用，全都有。我可以直接用这些数据生成标准的Word文档。

那一刻的心情，大概就是矿工挖了一整天突然看到金子反光的感觉。

AI花了1个小时分析透了这个数据格式，写出了完整的解析器。核心流程是：

1. 解码 -- 先处理 %uXXXX 格式的Unicode编码，再做标准URL解码

2. 解析 -- 把JSON里的"mutations"数组还原成文档结构

3. 下载图片 -- 把文档里引用的图片全部下载下来

4. 组装Word -- 用docx库生成标准的.docx文件

- - -

[4] 三种文档，三种打法深入 | 针对性方案

本以为搞定了数据解析就大功告成了。然而我点开文件列表一看 -- 不只有Word文档，还有383个表格和102个幻灯片。三种文档，底层结构完全不同。

好家伙，一个BOSS还没走远，又来了俩。

Word文档（677份）-- 数据解析大法

前面说的方案，读取加载接口的结构化数据，解析后生成Word。100%成功率，行云流水。

表格文档（383份）-- 剪贴板战术

表格的数据结构...怎么说呢，像俄罗斯套娃一样嵌套了七八层。单元格合并、公式、条件格式，直接解析能把人搞疯。

AI灵机一动，想了个特别接地气的土办法：打开表格 -> Ctrl+A全选 -> Ctrl+C复制 -> 从剪贴板读取HTML格式的表格数据 -> 转成Word里的表格。

— 核心对话 #4 - 土办法往往最管用 —

AI：表格的数据结构嵌套太深了，硬解析得不偿失。但我发现一个有趣的事：浏览器复制表格的时候，剪贴板里会自动生成HTML格式的表格数据。我们直接读剪贴板就行！

我：等一下...Ctrl+C 然后读剪贴板？这也太土了吧？

AI：土是土了点，但它能用，而且不触发验证码。管它土不土呢，能解决问题就是好办法。

不得不说，有时候最"笨"的办法反而最靠谱。

幻灯片（102份）-- 截图拼装术

幻灯片就更离谱了。整个页面都是Canvas画布渲染的，文字和图片全画在画布上，压根没有可提取的DOM元素。

AI试了好几种方案都不行，最后决定用最朴素的方式：逐页高清截图，然后把截图拼装成PPTX文件。虽然不是原生可编辑的PPT，但每一页的内容都完整保留了下来。

文档类型	数量	提取方式	输出格式
Word文档	677	接口数据解析	.docx
表格	383	剪贴板HTML	.docx (含表格)
幻灯片	102	逐页截图	.pptx
合计	1162	-	881个文件

- - -

[5] 最后的马拉松：跑完1200个文档收尾 | 稳定压倒一切

方案有了，三种文档各有打法，接下来就是最枯燥也最关键的部分 -- 让它稳定地跑完1200个文档。

你以为写好脚本点"运行"就完事了？天真。批处理脚本从V1一路崩到V7，每个版本都倒在不同的坑里。整个过程迭代了8个大版本：

●	V1-V5 早期版本基础框架搭建，各种UI自动化尝试，跟验证码斗智斗勇的阶段
●	V6 数据解析版第一次用接口数据方式批量处理Word文档，但Sheet和Slide还没搞定
●	V7 三合一版整合了Doc/Sheet/Slide三种处理方式，但内存管理有问题，跑到200多个就崩
●	V8 终极版 -- 终于站住了断点续传 + 浏览器自动重启 + 智能错误恢复。像一辆老牛一样，慢但稳，一步一步跑完了全部1200个文档。

V8能稳住，靠的是这几个"保命机制"：

断点续传每处理完一个文档，立刻把进度写入JSON文件。脚本崩了不要紧，重新启动会自动跳过已完成的，从断点继续。这个设计在实际运行中救了我们不下10次。

内存管理浏览器跑久了会吃掉大量内存。每处理50个文档，就自动关闭浏览器重新打开一个。虽然慢了点，但保证了不会因为内存溢出而崩溃。

DNS优化文档里嵌入的图片托管在平台CDN上，默认DNS解析经常超时。AI给脚本加了自定义DNS解析器，图片下载成功率从60%飙升到95%+。

- - -

[!] 最终战报132个脚本，无数次崩溃，一个结果

脚本在后台跑了一晚上，第二天早上我打开电脑，终端上停在最后一行日志 -- All documents processed. -- 长出了一口气。

95.5%

总成功率

1,162成功导出

841 MB总文件大小

881输出文件数

132脚本文件数

成功率：95.5% 成功 | 成功 1162 (含286个空表格) | 失败 42

其中42个失败的主要是权限问题（别人设了私有权限的文档）和个别格式异常的文件，属于正常损耗。

打开outputs文件夹，881个文件整整齐齐地码在那里。Word文档、Excel表格、PPT演示文稿，按编号排列，841MB的团队心血，全部安全落地。

- - -

劫后余生：几点感悟

1. AI真的能当"技术搭档"了

这次技术冒险，从开始调试到最终方案成型，实际开发也就6个小时。AI全程参与了方案设计、写代码、排查问题、推翻重来。132个脚本不是一次性写好的，而是在"撞墙 -> 换思路 -> 再撞墙 -> 再换思路"的循环中一个一个迭代出来的。整个过程更像是两个人在结对编程，而不是我在用一个工具。

2. 死磕不如转弯

跟验证码正面刚了15轮，浪费了大半天。最后回头看，真正的突破口根本不在验证码上。有时候你觉得"这个问题必须解决"，但其实你可以让这个问题不存在。

3. 慢就是快

V8版本比V6慢了一倍多 -- 每50个文档重启浏览器、每个文档之间停顿2-3秒。但它跑完了1200个文档一次没崩。在批量任务面前，跑得快但半路翻车的，永远比不上跑得慢但稳稳到终点的。

4. 你的数据，你得自己留一份

这次是公司要求迁移文档倒逼出来的需求。但说实话，就算没有迁移需求，重要数据也应该定期备份。在线协作工具再方便，数据始终在别人的服务器上。云端的便捷和本地的安心，缺一不可。

- - -

技术栈一览

工具/技术	用途
浏览器自动化框架	模拟用户操作，批量浏览文档
Node.js docx库	生成标准Word文档
PptxGenJS	生成PowerPoint文件
Canvas像素分析	验证码视觉识别（虽然最后没用上）
Clipboard API	表格数据提取
自定义DNS解析器	优化图片资源下载稳定性
JSON断点续传	崩溃恢复，进度持久化

- - -

整体方案流程图

说了这么多，最后用一张流程图把整个方案串起来，一目了然：

START

▼

1. 登录 & 保存会话状态用户手动扫码登录 → 保存 Cookie 和鉴权信息到 state.json

▼

2. 扫描文件夹 & 收集URL自动滚动文件列表 → 拦截跳转事件 → 输出 doclist.json（1204条）

▼

3. 按类型分流处理根据URL特征自动识别：doc / sheet / slide

▼ ▼ ▼

文档 (Doc)调用文档加载接口↓解析分块数据↓下载内嵌图片↓→ .docx

表格 (Sheet)打开文档页面↓Ctrl+A / Ctrl+C↓读取剪贴板HTML↓→ .docx 表格

演示 (Slide)逐页导航↓截图每一页↓拼装为演示文稿↓→ .pptx

▼ ▼ ▼

4. 保存 & 断点续传输出文件到 outputs/ → 更新 progress.json → 记录成功/失败状态

▼

5. 稳定性保障 & 循环每50个文档重启浏览器释放内存 → 每个文档间隔2~3秒 → 处理下一个

▼

?. 还有未处理的文档？是 → 返回第3步 | 否 → 结束

▼

DONE ✓1162份文档安全落地，881个文件共841MB

整个流程全自动执行，人工仅需扫码登录 + 启动脚本

- - -

算笔账：这6小时的工作（未占用工作时间）到底值不值？

故事讲完了，最后算一笔实际的经济账。毕竟在公司里，"酷不酷"不重要，"省不省钱"才是硬道理。

如果纯靠人工：

人工成本估算1162份文档 x 1分钟/份 = 约20小时纯操作时间考虑到人不是机器，中间需要休息、切换状态、处理卡顿等，实际每人需要投入约16小时的有效工时。这还是假设一个人不间断操作的情况。如果安排多人分工，沟通协调的成本另算。

来看降本数据：

3.5万部门人均月薪

~3,200公司人均日成本*

16h人均节省工时

* 含社保公积金、办公成本等综合用人成本，约为工资的2倍

单人降本效果3,200 元相当于节省了2个完整工作日的人力成本

而AI这边呢？实际开发调试也就6个小时，主要花在需求描述、方案讨论和调试排错上。脚本写好后挂在后台自动跑，完全不需要人盯着，第二天早上打开电脑，1162份文档已经整整齐齐码好了。

更重要的是：这个方案是可复用的。下次再有类似的批量备份需求，直接改下配置就能跑。第一次是投入，后面每一次都是纯收益。

一句话总结用AI花6个小时搭建的自动化方案，替代了16小时的纯人力重复劳动，为公司节省约3,200元人力成本。而且脚本写好后挂在后台自动运行，完全不占用工作时间。这套方案还可以反复使用 -- 一次投入，长期回报。

- - -

如果你也有类似的批量文档备份需求

或者对AI辅助技术开发感兴趣

欢迎在评论区聊聊，欢迎加我

毕竟，让机器干机器该干的活

才是正经事。

- - -

本文记录了一次真实的企业内部数据备份实践

所有操作均在公司授权范围内进行，用于保障企业数据资产安全

涉及的技术方法仅供学习交流，请在合规合法的前提下使用

-- THE END --