1. 从“千问办公批量导出”这个需求说起“千问办公能不能电脑批量导出”这个问题我最近在好几个技术群里都看到有人问。问的人背景五花八门有做运营的要把几十份周报一次性存成Word归档有做教务的要批量导出学生评语还有做电商的把商品文案从千问办公里一条条复制出来贴到表格里。大家的痛点出奇一致单篇导出没问题批量导出找不到入口。我花了大概两周时间把千问办公的导出链路从页面层扒到接口层中间踩了不少坑也试了一些取巧的办法。最后落地的方案是一个浏览器插件配合页面脚本注入的思路我给它起了个名字叫“AI导出鸭”——不是说真有个叫这名字的现成工具而是这套底层逻辑本身就像一只帮你把内容叼出来的鸭子。这篇文章就把这套逻辑完整拆开讲清楚包括为什么官方没有批量导出、浏览器插件怎么介入、页面JS函数怎么调用、导出的Word怎么处理格式问题以及中间遇到的各种坑。适合谁看如果你手头有大量千问办公里的内容需要落到Word或者本地文件又不想一条条手动复制那这篇就是写给你的。不需要你懂前端框架但需要你会装浏览器插件、能看懂一点点JavaScript剩下的我尽量说人话。2. 为什么千问办公没有“批量导出”这个按钮2.1 产品逻辑上的取舍先别急着骂产品经理。我研究了一圈同类办公协作产品发现批量导出这个功能缺席是有原因的。千问办公的定位是“协作AI生成”它的内容形态不是静态文档而是带对话上下文、带版本迭代、带协作批注的动态对象。你看到的每一篇内容背后可能关联着一段对话历史、若干个引用来源、甚至其他协作者的修改记录。如果官方做一个“批量导出Word”它要面对几个绕不开的问题导出的是当前版本还是所有历史版本对话上下文要不要一起导出协作批注怎么处理这些问题的答案因用户场景而异产品团队很难用一个按钮覆盖所有情况。所以他们的选择是只做单篇导出把批量需求留给用户自己解决。这个逻辑我理解但不代表我接受。实际工作中我就是需要把三十篇内容一次性变成Word文件一篇篇点导出再重命名手都要废掉。2.2 单篇导出的技术链路要理解怎么批量先得搞清楚单篇导出是怎么走的。我抓包看了下千问办公的单篇导出大致分三步前端发起一个导出请求带上文档ID和导出格式参数服务端根据文档ID拉取内容做格式转换通常是转成docx的二进制流前端收到二进制流触发浏览器下载关键点在于这个导出接口是存在的只是前端没有提供批量调用的入口。也就是说如果我们能拿到文档ID列表然后循环调用这个接口理论上就能实现批量导出。这就是“AI导出鸭”思路的起点。2.3 浏览器插件为什么是合适的切入点有人会问为什么不直接写个Python脚本调接口原因有两个一是登录态和鉴权token在浏览器里脚本要模拟登录比较麻烦二是千问办公的接口可能有动态签名或者CSRF token这些在页面上下文里是现成的脱离浏览器环境反而复杂。浏览器插件的优势就在这里它运行在页面上下文里能直接读取当前登录用户的cookie和token能调用页面已经加载好的JS函数能操作DOM拿到文档列表。相当于你派了一个小助手坐在浏览器里帮你点那些你不想手点的按钮。注意这里说的浏览器插件是通用的扩展机制任何主流浏览器都支持跟具体品牌无关。插件的能力边界由浏览器提供的API决定核心是content script和页面JS的交互。3. 拆解“AI导出鸭”的底层逻辑3.1 整体架构三层协作这套方案的架构不复杂分三层第一层是页面脚本注入通过浏览器插件的content script往千问办公的页面里注入一段JS用来获取文档列表和调用导出接口。第二层是插件后台负责接收页面脚本发来的文档ID列表循环触发导出请求并管理下载队列。第三层是本地文件处理下载下来的Word文件可能需要重命名、合并或者格式修正这部分可以用本地脚本或者Word宏来处理。三层之间通过浏览器插件提供的消息传递机制通信。页面脚本发消息给后台后台处理完再回消息给页面脚本更新进度。3.2 核心难点怎么拿到文档ID列表这是整个方案里最需要动脑筋的地方。千问办公的文档列表是动态渲染的DOM结构可能随时变。我试过三种拿ID的方式第一种是直接解析DOM从列表项的属性或者链接里提取ID。这种方式最直接但脆弱页面一改版就失效。第二种是拦截页面发出的列表请求从响应里拿ID。这种方式稳定一些但需要插件有拦截网络请求的能力而且要注意别把敏感信息泄露出去。第三种是调用页面自身的JS函数。如果千问办公的前端代码里有一个获取文档列表的函数我们可以直接在控制台或者注入脚本里调用它。这种方式最优雅但需要你先找到这个函数。我最后用的是第二种和第三种结合优先尝试调用页面JS函数拿不到再降级到拦截请求。下面重点讲第三种因为这是“调用页面JS函数”这个热词的核心。3.3 调用页面JS函数的实操方法在浏览器控制台里你可以通过window对象访问页面加载的全局变量和函数。但问题是现代前端框架React、Vue等通常不会把内部函数挂到window上而是藏在模块闭包里。我试了几个办法来突破这个限制办法一搜索全局对象。在控制台输入Object.keys(window).filter(k k.toLowerCase().includes(doc))看看有没有跟文档相关的全局对象。千问办公的页面里我找到了一个类似__INITIAL_STATE__的对象里面存了当前页面的初始数据包括文档列表。办法二Hook XHR/fetch。在页面脚本加载之前注入一段代码包装XMLHttpRequest和fetch把请求和响应记录下来。这样当页面自己请求文档列表时你就能拿到数据。代码大概长这样const originalFetch window.fetch; window.fetch function(...args) { return originalFetch.apply(this, args).then(response { const url args[0]; if (url.includes(/api/doc/list)) { response.clone().json().then(data { window.__capturedDocList data; }); } return response; }); };这段代码的意思是把原来的fetch函数保存下来然后用一个新的函数替换它。新函数在调用原函数之后检查请求的URL是不是文档列表接口如果是就把响应克隆一份解析成JSON存到全局变量里。注意要用response.clone()因为响应流只能读一次。办法三利用框架的开发者工具。React DevTools和Vue DevTools能让你查看组件树和组件状态。如果你在组件状态里找到了文档列表可以进一步找到对应的组件实例调用它的方法。这个办法比较依赖具体框架通用性差一些但在紧急情况下能救场。实操心得注入Hook代码的时机很关键。如果页面已经加载完了你再注入可能已经错过了列表请求。所以浏览器插件的content script要配置成document_start运行确保在页面脚本之前执行。3.4 循环调用导出接口拿到文档ID列表之后下一步就是循环调用导出接口。这里有几个细节要注意请求频率控制。别一次性发几十个请求容易被限流。我的做法是每发一个请求等1到2秒根据返回状态动态调整。如果连续几个请求都成功可以适当加快如果遇到429状态码就退避更长时间。导出格式参数。千问办公的导出接口通常支持多种格式比如docx、pdf、markdown。你要在请求里指定格式。我一般默认用docx因为后续在Word里处理最方便。文件名处理。接口返回的二进制流本身不带文件名或者带的是乱码文件名。你需要在触发下载的时候自己指定文件名。文件名可以从文档标题来但要注意去掉非法字符比如/、\、:、*、?、、、、|。错误重试。网络请求难免失败要有重试机制。我一般设置最多重试3次每次间隔递增。下面是一个简化的循环导出代码示例async function batchExport(docIds, format docx) { const results []; for (let i 0; i docIds.length; i) { const docId docIds[i]; let success false; for (let retry 0; retry 3 !success; retry) { try { const response await fetch(/api/doc/export?id${docId}format${format}, { method: GET, credentials: include }); if (response.ok) { const blob await response.blob(); const url URL.createObjectURL(blob); const a document.createElement(a); a.href url; a.download doc_${docId}.${format}; a.click(); URL.revokeObjectURL(url); success true; results.push({ docId, status: success }); } else if (response.status 429) { await sleep(5000 * (retry 1)); } else { await sleep(1000); } } catch (e) { await sleep(2000); } } if (!success) { results.push({ docId, status: failed }); } await sleep(1500); } return results; }这段代码的逻辑是遍历文档ID列表对每个ID发起导出请求。如果成功把返回的二进制流转成Blob创建一个临时链接触发下载然后释放链接。如果遇到429就等更长时间再重试。每个文档之间固定等1.5秒。4. 从导出到可用Word文件的后续处理4.1 批量重命名下载下来的文件如果名字是doc_12345.docx这种你根本不知道哪个是哪个。所以导出的时候最好能从页面拿到文档标题用标题做文件名。如果标题里有非法字符替换成下划线。如果已经下载了一堆乱名文件可以用本地脚本批量重命名。Windows上可以用PowerShellMac上可以用Shell脚本。思路是读取一个映射表文档ID到标题然后遍历文件重命名。4.2 格式修正公式、表格、图片千问办公导出的Word文件格式上可能有几个问题公式变成图片。这是最常见的问题。如果原文里有数学公式导出后可能变成图片没法编辑。这时候你需要“公式图片转Word”的工具或者手动用MathType重新录入。如果公式不多手动处理可以接受如果多可以考虑用支持公式识别的工具先转成LaTeX再嵌入Word。表格列宽异常。有时候导出的表格列宽不对拖也拖不动。这通常是表格属性里的tblLayout设置成了fixed但列宽值又不合理。解决办法是选中表格在Word里把布局改成“自动调整”或者用VBA宏批量修正。图片丢失或错位。如果原文里的图片是外链导出时可能没被包含进来。这种情况需要在导出前确认图片是否已经上传到服务器。如果是外链图片可能需要先下载再手动插入。4.3 合并多个Word文件如果你需要把导出的多个Word合并成一份有几种办法Word自带功能插入 - 对象 - 文件中的文字可以选多个文件合并。但文件多了会卡。VBA宏写一段宏循环插入文件效率高一些。Python脚本用python-docx库读取每个文件的内容写入一个新文件。这种方式最灵活但要注意样式和编号的保留。我用的是Python方案因为可以顺便做格式清理。核心代码不复杂就是遍历文件把段落和表格逐个复制到新文档里。但要注意python-docx对复杂格式的支持有限如果原文有复杂的页眉页脚或者分栏可能会丢失。4.4 关闭Word时的卡顿问题批量处理Word文件时你可能会遇到“关闭Word时卡顿”或者“Word关闭慢”的问题。这通常是因为Word在关闭时要处理大量的撤销记录、临时文件或者加载项。几个缓解办法一是处理完一个文件就关掉Word再开下一个别一次性开几十个二是禁用不必要的加载项特别是那些COM加载项三是清理Word的临时文件目录。如果问题严重可以试试在Word选项里关闭“硬件图形加速”。5. 常见问题与排查技巧实录5.1 插件装了但页面脚本没生效这是最常见的问题。排查步骤打开浏览器开发者工具的Console面板看看有没有报错。检查插件的content script配置确认matches字段包含了千问办公的域名。确认run_at设置成了document_start否则可能错过页面初始化。如果页面有CSP内容安全策略可能会阻止内联脚本执行。这时候需要把脚本放到独立文件里通过src引入。5.2 导出请求返回403或401这说明鉴权有问题。检查几点请求有没有带上cookie在fetch里设置credentials: include。需不需要额外的header比如X-CSRF-Token。这个token通常在页面的meta标签或者cookie里你可以从页面读取。token是不是过期了刷新页面重新登录。5.3 下载的文件打不开如果下载的Word文件打不开可能是这几个原因返回的不是二进制流而是JSON错误信息。检查响应的Content-Type。文件被截断了。检查Content-Length和实际下载大小是否一致。格式参数不对。确认接口支持的格式列表。5.4 批量导出到一半卡住如果导出到一半不动了可能是触发了限流。看Network面板里有没有429或者503。浏览器内存不够。几十个Blob对象同时存在会占内存要及时revokeObjectURL。页面被切到后台定时器被节流。Chrome对后台标签页的setTimeout有最小间隔限制可能导致你的等待逻辑变慢。解决办法是用Web Worker跑定时器或者让用户保持页面在前台。5.5 常见问题速查表问题现象可能原因排查方法解决思路插件无反应content script未注入看Console有无插件日志检查matches和run_at配置请求401/403鉴权失败看请求头有无cookie加credentials补CSRF token文件打不开响应非二进制看Content-Type检查接口参数和登录态导出中途停止限流或内存不足看Network状态码降速、释放Blob、前台运行公式变图片导出格式限制打开文件确认用公式识别工具转换表格列宽异常表格属性问题查看表格布局设置改为自动调整或VBA修正避坑技巧在正式批量导出之前先用两三个文档做测试确认整个链路通了再全量跑。我一开始贪快直接对五十个文档发起导出结果因为一个参数写错全部失败白白等了十几分钟。6. 扩展思路这套逻辑还能用在哪些场景这套“页面脚本注入接口调用”的逻辑不只能用在千问办公。任何有网页版、有列表页、有单篇导出功能的产品理论上都可以用类似思路做批量导出。比如在线文档、笔记应用、邮件系统、甚至某些后台管理系统。关键判断点是单篇导出的接口是否可以被复用。如果接口需要动态签名或者一次性token那就麻烦一些需要从页面里实时获取。如果接口就是简单的GET请求带个ID那就很容易。另外如果你不想写代码也可以看看有没有现成的网页内容提取工具或者浏览器插件能帮上忙。有些插件专门做“网页内容提取”能识别页面上的列表并批量抓取。但这类工具通常对动态渲染的页面支持不好还是自己写脚本更可控。最后说一个我个人的体会批量导出这件事技术上的难点其实不大真正花时间的是处理各种边界情况和格式问题。导出只是第一步导出之后怎么让文件可用、好找、格式正确才是真正耗精力的地方。所以如果你要做类似的事情建议把至少一半的精力留给后处理环节别指望导出完就万事大吉。