很多人习惯把 ChatGPT 当成一个聊天窗口问完就把回答复制到笔记里再手动整理成表格。这套流程偶尔用一两次还行一旦你要批量处理几百个问题、把回答接进知识库或者做数据分析复制粘贴就彻底撑不住了。我前阵子在搭 AI 客服知识库的自动化管道就遇到这个需求批量提问、结构化抓取 ChatGPT 回复、直接落库。试了好几个开源方案最后在 AI Bot Scraper 上稳定跑通。这篇文章把我踩过的坑、对比过的方案和最终配置都整理出来给同样有“AI 回答结构化抓取”需求的读者一个参考尤其是准备做评测集、知识库同步、批量 QA 归档的人可以先看结论再决定要不要入坑。AI Bot Scraper 这个名字看起来像个通用爬虫但它的定位其实很明确专门针对 AI 对话产品以 ChatGPT 为主设计的数据采集工具。它能驱动一个浏览器实例替你打开对话页面、输入提示词、等待 AI 回复再把渲染完成的回答按配置好的字段抓到本地输出成 JSON、CSV 这类结构化数据。这和普通爬虫最大的区别在于它要处理的不是静态 HTML 页面而是带流式输出、动态加载、多轮上下文状态的交互式应用。1. 这个项目到底解决什么问题1.1 手动复制粘贴根本撑不住批量场景先说我遇到的具体场景。当时要构建一个客服知识库需要把“用户可能问到的 600 个问题”统一喂给 ChatGPT让它生成标准回答再跟人工编写的话术做对比。一开始我试过手动操作在网页里一个问题一个问题地问回答生成后全选复制粘贴到表格里。结果效率低得吓人平均一个问题要两三分钟中间还要应付回答截断、格式错乱、偶尔触发的人机验证。搞了不到一百条我就放弃了这根本不是写内容是在做流水线工人。后来我换了个思路不追求“好看”的人工整理先把 AI 回复抓下来存成原始数据清洗再用。这就需要一个能批量提交问题、批量拿回答、还能把结果对齐到问题 ID 的工具。市面上的通用爬虫框架当然也能做但要处理登录态、动态渲染、SSE 流式输出、回答长度不确定性、并发限速这些东西全写一遍少说也要一两天。AI Bot Scraper 这类专用工具的价值就在于它把这些都封装好了我只需要关心问题列表和输出字段。1.2 AI Bot Scraper 的边界在哪里明确一下它能做什么、不能做什么避免大家期望过高。能做的事包括自动打开指定 AI 对话页面维护登录会话按脚本逐条发送问题等待回答渲染完成捕获回答正文和消息元数据按配置转成结构化文件支持多任务并发和断点续跑。它本质上是个“浏览器自动化 AI 对话页适配器”不是通用内容采集器也不是 AI 对话代理接口。不能做的事也要说清楚它不能凭空绕过登录限制不能破解付费墙不能把不支持 API 的模型硬包装成高并发接口。如果哪天 ChatGPT 页面结构改版它的选择器需要跟着更新这是所有依赖页面结构的工具都逃不掉的问题。另外它抓的是你账号权限范围内能看到的数据别人私有的、付费专属的内容不该抓也不要抓这是合规底线后文我专门讲。1.3 适合谁来用我做完整个评测后觉得它的目标用户非常集中一是做 NLP 评测集的人需要批量构造“问题-回答”数据对这个工具能把回答过程自动化省掉最枯燥的复制粘贴阶段二是在搭企业内部知识库或 RAG 管道的工程师需要定期从 AI 产品中抓取示例问答作为种子数据或参考语料三是做内容运营的人想批量生成初稿素材再人工润色它比手动一个个问要省时间。反过来如果你只是偶尔查点东西或者对数据格式完全没要求用官方客户端加复制粘贴就够了不值得为这种场景搭一套抓取环境。另外一个建议是如果项目预算允许优先考虑官方的 API 方式更加稳定合规AI Bot Scraper 更适用于“必须走网页端、临时批量拉取、做技术验证”这三类情形。2. 结构化抓取背后的原理拆解2.1 网页版 ChatGPT 的消息流转过程要理解它为什么能抓得先了解 ChatGPT 网页版一条消息是怎么从输入框变成页面上那段回答的。你输入问题并点击发送后页面会向后端发起一次对话请求服务端不会一次性返回完整内容而是通过 SSEServer-Sent Events协议持续推送片段前端收到一个数据块就往页面上追加一段文字同时在码字光标上做增量更新。整个过程中页面的 DOM 不是一开始就有完整答案的它是在几秒到几十秒内不断变化的。这就带来一个关键问题如果在回答没结束时就去抓 DOM拿到的是一截残缺内容如果抓晚了页面可能已经进入新的上下文旧回答被虚拟滚动回收。稳定的抓取时机非常讲究这也是 AI Bot Scraper 这类工具的核心技术点之一。它通常会在发出问题后监听网络空闲状态、滚动条稳定状态以及“停止生成”按钮是否消失综合判断“这条回答已经结束”然后才读取消息节点的文本内容。2.2 抓取路线的选择页面渲染、扩展注入、协议封装市面上实现“抓取 AI 回答”的主流路线有三条理解它们各自的原理才能明白 AI Bot Scraper 为什么选了一条折中路线。第一条是页面渲染加 DOM 解析也是 Playwright、Puppeteer 这类通用自动化框架最常用的方式。浏览器真实渲染页面脚本模拟点击输入再通过 CSS 选择器或 XPath 定位回答节点取文本。优点是所见即所得能处理复杂前端逻辑缺点是需要自己处理登录、等待、重试、并发稍不注意就容易写出“跑一次崩一次”的脚本。第二条是浏览器扩展注入。借助浏览器扩展在页面上下文中注入脚本直接监听页面的状态变更比如 MutationObserver 监听 DOM 变化或者拦截页面内部的消息通道。这种方式响应快、开销小但扩展权限模型限制挺多而且 ChatGPT 的前端代码经过混淆和频繁更新注入点不固定维护成本很高。第三条是协议封装也就是把网页端请求接口逆向后跳过浏览器直接发请求。效率最高、响应最快但这是最“重”的一条路。一旦服务端的参数校验、风控策略调整整套封装就要跟着重构而且合规风险最高我不建议普通开发者在生产环境碰这条线。AI Bot Scraper 主走第一条路线但做了不少工程化封装比如内置常见 AI 平台的选择器预设、可配置的等待策略、任务级别的重试与超时管理。它不会像通用框架那样给你绝对自由但换来的是“开箱即用、配置驱动”的快速落地能力。2.3 为什么流式输出是最大的坑把“流式输出”单独拿出来讲是因为它几乎决定了一次抓取到底能不能成功。网页版 AI 回答不是静态页面是一条不断变长的文字流抓早了截断抓晚了可能被后续操作覆盖。我最早用 Playwright 写抓取脚本时就是没处理好这一点导致一批 50 条数据里 20 条都是半句话清洗时非常痛苦。AI Bot Scraper 的思路是引入“稳定窗口”概念。所谓稳定窗口就是连续 N 秒内目标节点的文本长度没有明显变化并且页面上的生成中状态比如停止按钮已经消失才判定回答结束。这个“N 秒”不能写死成固定值因为简单问题的回复一两秒就稳定了长文内容可能要十几秒甚至更久。配置里建议把稳定窗口设成动态的根据待抓取回答的平均长度预估一个初始值运行中再根据上一轮实际耗时动态调整。我在实际项目中把 N 设在 3 到 5 秒之间大部分情况下都能拿到完整回答。另外流式输出还牵扯到一个结构对齐的问题。有些回答是带标题、列表、代码块的 Markdown前端渲染时这些元素会被拆成多个 DOM 节点直接取 innerText 会把排版信息打平抓回来的数据很难用。更合理的做法是按“消息容器”为单位抓取保留块级元素边界再按 Markdown 语法做轻量还原。AI Bot Scraper 的默认配置在这点上做得不错但导出质量最终还取决于你设置的字段映射规则。3. AI Bot Scraper 实测从配置到跑通第一个任务3.1 环境准备与安装我推荐在 Linux 或 macOS 上跑Windows 也能跑但坑多一点主要是浏览器驱动路径和进程清理的问题。前置条件并不复杂Python 3.10 以上、Node.js 18 以上按需安装、Chrome 或 Edge 浏览器、以及一个保持登录状态的 ChatGPT 账号。AI Bot Scraper 本身以 Python 包形式发布用 pip 或 uv 安装即可具体安装命令以项目 README 为准。安装完之后我习惯先用命令检查一下版本和依赖是否齐全能打印出版本号说明基础环境没问题。接着要准备一个用户数据目录用于保存浏览器的登录态。这里有个小细节不要每次运行都用全新浏览器上下文否则每次都要重新登录、可能触发额外的风控验证。把 user_data_dir 指定到一个固定路径第一次手动登录一次之后脚本复用这个会话能省掉大量登录时间。3.2 一个最小可跑通的配置示例AI Bot Scraper 支持用 JSON 或 YAML 描述抓取任务。我贴一份自己验证过的精简配置结构上覆盖了最关键的四块浏览器设置、任务清单、等待策略、输出配置。browser: headless: false # 首次建议有头模式方便调试 user_data_dir: ./chrome-data # 保存登录态 executable_path: # 留空则自动查找系统 Chrome tasks: - name: 批量问答抓取 url: https://chat.openai.com/ input_selector: #prompt-textarea submit_selector: button[data-testidsend-button] response_selector: [data-message-author-roleassistant] questions: - 用三句话介绍什么是结构化数据 - Python 中如何高效处理 JSON 大文件 - 写一个简单的 FastAPI 接口示例。 wait_strategy: stable_window_seconds: 5 max_wait_seconds: 90 output: format: jsonl path: ./data/answers.jsonl fields: - question - answer - conversation_id - created_at这份配置的核心逻辑是打开 ChatGPT 对话页依次在输入框里敲入 questions 列表中的每个问题点击发送按钮等待回答节点在 5 秒内不再变化然后把回答连同问题原文一起写入 JSONL 文件。我特意用了有头模式做首次调试因为无头模式下出了问题只能看日志很难直观判断定位器是否选错了元素。跑通之后再把 headless 改为 true放到服务器上执行。3.3 字段映射与输出结构设计配置里的 output.fields 不是随便列的它决定了你后续清洗数据时能拿到什么。question 和 answer 是最基础的conversation_id 用来追踪多轮对话所属会话created_at 用来记录抓取时间。如果你的下游要做去重或者增量同步还可以追加 hash 字段由 question 原文和模型名拼接后计算 MD5这样同一条问题重复抓取时能识别出来避免污染数据集。我踩过的一个坑是别把 conversation_id 直接当唯一主键。原因是同一个会话里可以问很多个问题conversation_id 只能区分“是哪次会话”不能区分“是第几个问题”。要保证每条数据唯一最稳的方式是自定义一个 task_id格式类似“任务名问题序号时间戳”在配置模板里用变量动态生成。我在输出字段里加了一列 source_ts记录问题发起时间既方便按时间切片也方便将来回溯抓取顺序。输出格式方面我优先推荐 JSONL 而不是 JSON。JSON 要求整体结构合法任何一条数据写坏整个文件可能都无法解析而 JSONL 是一行一条即使中途任务中断已写入的行也能直接读取断点续跑后的数据合并非常方便。CSV 也可以但如果回答里包含换行符和逗号转义问题会让你怀疑人生除非下游明确要求否则不建议首选 CSV。3.4 首次运行踩过的坑与验证方法第一次跑任务我用的是三个短问题目的是验证链路是否通。结果第一次就翻车了脚本提示找不到输入框。原因不是工具的问题而是 ChatGPT 的页面结构更新后默认的 input_selector 失效了。这也印证了我前面说的页面结构一变选择器就会崩。解决办法是用浏览器开发者工具重新定位输入框把最新的选择器更新到配置里。跑通一次之后我建议做两件事验证数据质量。第一件事是抽样检查回答是否完整拿抓取到的 answer 和网页上肉眼看到的回答做对比重点关注结尾是否被截断、代码块是否闭合。第二件事是检查回答是否符合预期格式比如要求 AI 返回 JSON 时要确认抓下来的内容真的是可解析的 JSON而不是被 Markdown 代码块包着的字符串。这两步看似简单但在批量场景里格式错误的数据比缺失数据更容易被忽视。4. 对比测评AI Bot Scraper 与三类替代方案4.1 我选择的对比维度工具选型不能只看功能列表得结合维护成本、稳定性、上手难度综合判断。我这次对比选了四个维度接入成本从零到跑通第一条数据要多久、稳定性连续跑 100 条任务不中断的能力、可维护性页面改版或需求变更后改动成本多高、合规压力在法律和服务条款层面的风险高低。这四个维度基本覆盖了我在实际选型中最关心的点。4.2 横评结果一览为了直观我把 AI Bot Scraper、通用自动化框架Playwright、浏览器扩展注入、协议直连封装放在一张表里对比。这个表代表的是我实际测试后的主观感受数值不是基准测试的结果但方向是真实的。方案接入成本稳定性可维护性合规压力典型适用场景AI Bot Scraper低中高中中临时批量拉取、个人数据归档、评测集构建Playwright 自研脚本高中低中深度定制场景、需要精细控制浏览器行为浏览器扩展注入中中低低中高轻量采集、快速原型验证协议直连封装低初期低长期极低高高并发自用接口不推荐公开项目使用AI Bot Scraper 的接入成本最低因为它内置了选择器预设和等待策略比如我上一节配置里那套稳定窗口逻辑要是用 Playwright 自己写至少要几十行代码加好几轮调试。稳定性上它比通用框架好一点因为针对 AI 页面做了优化但绝对做不到 API 那种 99.9% 的可用性。可维护性方面它依赖页面结构和通用框架的处境一样只是隔一段时间更新一次就行不用每次改需求都重写脚本。4.3 实测结论与选型建议我自己的结论是如果你的任务量级在“几百到几千条”之间并且想快速跑出一个可用的结构化数据集AI Bot Scraper 是目前最省事的选项。它帮你承担了登录态管理、流式等待、超时重试这些脏活让你能把精力放在问题清单和数据处理上。我实际用它跑了 600 个问题断断续续用了大约四个小时产出 600 条 JSONL 数据完整率约 97%失败的问题通过重试机制补齐整体体验可以接受。如果你需要频繁调整抓取逻辑比如页面元素经常变、要定制多轮对话分支、要对接企业内部系统那通用自动化框架反而更合适。它给你的自由度更高代价是所有细节都要自己维护。协议直连封装我基本不建议碰除非你对逆向很有经验、且能接受较高的维护和合规成本。做技术调研时可以用它验证想法但在生产环境里不稳定和合规风险都会成为定时炸弹。5. 进阶优化并发、超时与流式输出的完整处理5.1 流式输出截断从源头解决我在第二部分说过流式输出是抓取成败的关键这里再展开讲讲实际怎么处理。最笨的办法是等固定时间比如发送请求后无论回答是否结束都等 30 秒再抓这么做的缺点是拿长回答容易截断、短回答浪费时间。更好的做法是引入两个独立判断一个判断“内容是否还在增长”一个判断“生成状态是否结束”。只有内容连续 N 秒没有变化且页面上的生成中控件已经消失才认为回答完整。在 AI Bot Scraper 的配置里稳定窗口期建议设成 5 秒最大等待时间设成 90 秒。如果你的问题大多是长文写作类可以把稳定窗口调大到 8 秒因为长文回答中途会出现短暂的思考停顿如果窗口太短脚本会误判为“已经回答完”提前抓取导致截断。反过来如果都是短问答稳定窗口可以压缩到 2 到 3 秒提高整体吞吐。还有一个容易忽略的点抓取回答后不要立刻进行下一次操作预留 1 到 2 秒的缓冲时间。原因很简单前端可能在回答渲染完毕后还会做一些异步收尾比如更新消息元数据、写入会话历史。等一秒钟再执行下一步能显著减少“回答抓到了但 message_id 没更新”这类次生问题。5.2 并发控制与限速策略批量抓取时不少人会想当然地设置高并发觉得这样快。但 AI 对话服务对账号的请求频次非常敏感短时间大量提问很容易触发风控要么出现人机验证要么直接临时限制对话。我测试时的安全经验是单个账号的并发数控制在 2 到 3 个任务以内而且每个任务之间至少间隔 5 到 10 秒。如果确实需要高吞吐建议多准备几个账号用轮询方式分散请求而不是让一个账号顶着高并发猛冲。AI Bot Scraper 支持多任务队列你可以开启两个任务分别用不同账号跑不同批次数据输出到独立文件最后再合并。这么做既保证速度又降低被封的风险。还要注意给整个流程加上随机抖动请求间隔不要完全固定比如 6 秒、8 秒、7 秒这样来回浮动更像真人操作。5.3 重试机制与任务去重批量任务跑久了一两项失败是常态。我遇到最多的是网络超时和页面元素偶发未加载解决方案是给任务加可重试策略。AI Bot Scraper 配置里可以设置 max_retries 和 retry_interval我推荐重试次数设为 3 次间隔从 10 秒开始逐次加倍避免失败后马上重试再次触发问题。另外还要做任务级去重。因为在断点续跑时你会重新读取问题列表如果没有去重前面已经成功抓取的问题会被再抓一遍浪费配额又污染数据。我建议维护一张“已成功任务表”只要某条结果写入了输出文件就把它的问题 hash 记录到表里。下次启动任务前先比对跳过已完成的条目。这个思路在任何批量抓取工具里都通用不限于 AI Bot Scraper。5.4 登录态与验证码的处理登录态管理是抓取工具不能回避的一环。我的做法是第一次启动用有头模式手动登录让 AI Bot Scraper 把浏览器上下文保存到 user_data_dir之后每次启动直接复用这个上下文。只要账号不退出登录、IP 地址不频繁变化这个会话能维持很久。需要注意的是user_data_dir 里的数据包含敏感会话凭证不要把它提交到代码仓库最好写在 .gitignore 里。至于人机验证我不建议做任何自动化绕过的尝试原因很实际一方面绕过的方案经常失效投入产出比极低另一方面涉及合规风险没有必要为了抓几条数据去碰红线。更健康的做法是降低请求频率或者切换时段再跑。如果某个账号频繁出验证就让它静置几小时换另一个账号继续跑通常能缓解。6. 高频故障排查与合规红线6.1 问题排查速查表运行过程中会碰到不少问题我把高频故障整理成一张表每条都标注了我实测验证过的处理方式方便大家直接对照排查。现象可能原因排查与解决找不到输入框或发送按钮页面结构改版选择器失效用开发者工具重新定位更新配置里的 selector回答内容被截断只有前几句话稳定窗口设置过短把 stable_window_seconds 从 5 调到 8 以上确认停止生成按钮消失后再抓取任务超时但页面看起来正常页面网络请求未完全结束调大 max_wait_seconds检查网络是否稳定必要时手动跑一次确认抓取结果全是空字符串回答节点定位到了错误元素检查 response_selector 是否匹配多个节点取最后一个还是第一个运行一段时间后频繁出现验证页面请求频率过高触发风控降低并发、拉长间隔、轮换账号不要尝试自动化绕过多轮对话上下文混乱问题之间没有清空会话每条问题之间新增对话或清空上下文保证独立会话输出文件中出现乱序数据并发任务间缺少锁或排序为每条数据加上序号输出后按序号排序合并6.2 几条独家避坑经验第一不要在 ChatGPT 的输入框里直接用一个“换行 多行问题”的长文本尤其是当你的问题里包含代码时。前端对换行和特殊字符的处理和你预想的不一样很容易导致输入框内容被截断或触发异常。我在批量运行时习惯把问题做一层 JSON 转义再用普通文本方式填入输入框传入或读取都走统一的编码格式数据边界清晰多了。第二抓取长文回答时要关注浏览器进程的内存占用。我跑 600 个任务时任务跑到后半程浏览器内存一度涨到 2GB 以上页面出现明显卡顿抓取速度也跟着变慢。后来我在每完成 50 个任务后重启一次浏览器上下文内存占用才稳定下来。这个重启逻辑可以通过脚本在任务之间触发不需要人工介入。第三时间戳很重要。AI Bot Scraper 能抓回答正文但不一定能在每个回答上自动保留准确的请求时间。我在输出配置里加了 created_at 字段并且保证所有任务使用同一个时钟源本地时间避免不同机器或不同时区的数据对不上。时间戳不仅方便排序溯源对后续做数据去重和版本对比也很有帮助别省这一步。6.3 合规边界与风险提示抓取工具好用但在正式投入使用前一定要把合规边界想清楚。最重要的原则是优先使用官方 API。OpenAI 提供了完善的接口和文档通过 API 获取结构化数据根本不是难事没必要为了省一点费用去抓网页端。AI Bot Scraper 更适合的场景是你暂时拿不到 API 权限、需要快速验证想法、或者抓取的是你自己账号权限范围内的对话记录。第二个原则是不要绕过权限控制。只抓你有权访问的数据不碰付费墙后的内容不批量下载他人私有对话不把抓取结果用于违反服务条款的用途。特别是涉及个人信息的数据采集后要做好脱敏和权限管理不要为了图方便把整个导出文件扔到公开仓库里。我见过不少人因为疏忽把包含会话记录的 JSONL 文件直接推到 GitHub 上结果后悔都来不及。第三个原则是控制频率和量级给自己留缓冲。即便页面允许你高频操作也不代表这么做是合适的。把抓取任务设计成“低频、小批量、可暂停、可恢复”的模式既保护你的账号也避免给目标服务造成不必要的压力。合规不仅是法律问题更是让自己长期省心的工程问题。我个人现在的做法是优先用官方 API 做生产数据流AI Bot Scraper 只用来补充 API 覆盖不到的边缘场景比如临时构造一批样例、验证前端提示词效果、归档个人对话记录。每次运行前都会过一遍这个检查清单是不是只有自己账号的数据频率是否合理输出文件会不会包含敏感信息确认无误后再启动任务。这样折腾了一个多月数据管道跑得挺稳我也没再因为封号或数据事故回过一次头。 
长河君 · 2026/9/9 4:27:59 · 阅读 1.2k AI Bot Scraper实战：ChatGPT批量回答结构化抓取与自动化数据采集指南
很多人习惯把 ChatGPT 当成一个聊天窗口问完就把回答复制到笔记里再手动整理成表格。这套流程偶尔用一两次还行一旦你要批量处理几百个问题、把回答接进知识库或者做数据分析复制粘贴就彻底撑不住了。我前阵子在搭 AI 客服知识库的自动化管道就遇到这个需求批量提问、结构化抓取 ChatGPT 回复、直接落库。试了好几个开源方案最后在 AI Bot Scraper 上稳定跑通。这篇文章把我踩过的坑、对比过的方案和最终配置都整理出来给同样有“AI 回答结构化抓取”需求的读者一个参考尤其是准备做评测集、知识库同步、批量 QA 归档的人可以先看结论再决定要不要入坑。AI Bot Scraper 这个名字看起来像个通用爬虫但它的定位其实很明确专门针对 AI 对话产品以 ChatGPT 为主设计的数据采集工具。它能驱动一个浏览器实例替你打开对话页面、输入提示词、等待 AI 回复再把渲染完成的回答按配置好的字段抓到本地输出成 JSON、CSV 这类结构化数据。这和普通爬虫最大的区别在于它要处理的不是静态 HTML 页面而是带流式输出、动态加载、多轮上下文状态的交互式应用。1. 这个项目到底解决什么问题1.1 手动复制粘贴根本撑不住批量场景先说我遇到的具体场景。当时要构建一个客服知识库需要把“用户可能问到的 600 个问题”统一喂给 ChatGPT让它生成标准回答再跟人工编写的话术做对比。一开始我试过手动操作在网页里一个问题一个问题地问回答生成后全选复制粘贴到表格里。结果效率低得吓人平均一个问题要两三分钟中间还要应付回答截断、格式错乱、偶尔触发的人机验证。搞了不到一百条我就放弃了这根本不是写内容是在做流水线工人。后来我换了个思路不追求“好看”的人工整理先把 AI 回复抓下来存成原始数据清洗再用。这就需要一个能批量提交问题、批量拿回答、还能把结果对齐到问题 ID 的工具。市面上的通用爬虫框架当然也能做但要处理登录态、动态渲染、SSE 流式输出、回答长度不确定性、并发限速这些东西全写一遍少说也要一两天。AI Bot Scraper 这类专用工具的价值就在于它把这些都封装好了我只需要关心问题列表和输出字段。1.2 AI Bot Scraper 的边界在哪里明确一下它能做什么、不能做什么避免大家期望过高。能做的事包括自动打开指定 AI 对话页面维护登录会话按脚本逐条发送问题等待回答渲染完成捕获回答正文和消息元数据按配置转成结构化文件支持多任务并发和断点续跑。它本质上是个“浏览器自动化 AI 对话页适配器”不是通用内容采集器也不是 AI 对话代理接口。不能做的事也要说清楚它不能凭空绕过登录限制不能破解付费墙不能把不支持 API 的模型硬包装成高并发接口。如果哪天 ChatGPT 页面结构改版它的选择器需要跟着更新这是所有依赖页面结构的工具都逃不掉的问题。另外它抓的是你账号权限范围内能看到的数据别人私有的、付费专属的内容不该抓也不要抓这是合规底线后文我专门讲。1.3 适合谁来用我做完整个评测后觉得它的目标用户非常集中一是做 NLP 评测集的人需要批量构造“问题-回答”数据对这个工具能把回答过程自动化省掉最枯燥的复制粘贴阶段二是在搭企业内部知识库或 RAG 管道的工程师需要定期从 AI 产品中抓取示例问答作为种子数据或参考语料三是做内容运营的人想批量生成初稿素材再人工润色它比手动一个个问要省时间。反过来如果你只是偶尔查点东西或者对数据格式完全没要求用官方客户端加复制粘贴就够了不值得为这种场景搭一套抓取环境。另外一个建议是如果项目预算允许优先考虑官方的 API 方式更加稳定合规AI Bot Scraper 更适用于“必须走网页端、临时批量拉取、做技术验证”这三类情形。2. 结构化抓取背后的原理拆解2.1 网页版 ChatGPT 的消息流转过程要理解它为什么能抓得先了解 ChatGPT 网页版一条消息是怎么从输入框变成页面上那段回答的。你输入问题并点击发送后页面会向后端发起一次对话请求服务端不会一次性返回完整内容而是通过 SSEServer-Sent Events协议持续推送片段前端收到一个数据块就往页面上追加一段文字同时在码字光标上做增量更新。整个过程中页面的 DOM 不是一开始就有完整答案的它是在几秒到几十秒内不断变化的。这就带来一个关键问题如果在回答没结束时就去抓 DOM拿到的是一截残缺内容如果抓晚了页面可能已经进入新的上下文旧回答被虚拟滚动回收。稳定的抓取时机非常讲究这也是 AI Bot Scraper 这类工具的核心技术点之一。它通常会在发出问题后监听网络空闲状态、滚动条稳定状态以及“停止生成”按钮是否消失综合判断“这条回答已经结束”然后才读取消息节点的文本内容。2.2 抓取路线的选择页面渲染、扩展注入、协议封装市面上实现“抓取 AI 回答”的主流路线有三条理解它们各自的原理才能明白 AI Bot Scraper 为什么选了一条折中路线。第一条是页面渲染加 DOM 解析也是 Playwright、Puppeteer 这类通用自动化框架最常用的方式。浏览器真实渲染页面脚本模拟点击输入再通过 CSS 选择器或 XPath 定位回答节点取文本。优点是所见即所得能处理复杂前端逻辑缺点是需要自己处理登录、等待、重试、并发稍不注意就容易写出“跑一次崩一次”的脚本。第二条是浏览器扩展注入。借助浏览器扩展在页面上下文中注入脚本直接监听页面的状态变更比如 MutationObserver 监听 DOM 变化或者拦截页面内部的消息通道。这种方式响应快、开销小但扩展权限模型限制挺多而且 ChatGPT 的前端代码经过混淆和频繁更新注入点不固定维护成本很高。第三条是协议封装也就是把网页端请求接口逆向后跳过浏览器直接发请求。效率最高、响应最快但这是最“重”的一条路。一旦服务端的参数校验、风控策略调整整套封装就要跟着重构而且合规风险最高我不建议普通开发者在生产环境碰这条线。AI Bot Scraper 主走第一条路线但做了不少工程化封装比如内置常见 AI 平台的选择器预设、可配置的等待策略、任务级别的重试与超时管理。它不会像通用框架那样给你绝对自由但换来的是“开箱即用、配置驱动”的快速落地能力。2.3 为什么流式输出是最大的坑把“流式输出”单独拿出来讲是因为它几乎决定了一次抓取到底能不能成功。网页版 AI 回答不是静态页面是一条不断变长的文字流抓早了截断抓晚了可能被后续操作覆盖。我最早用 Playwright 写抓取脚本时就是没处理好这一点导致一批 50 条数据里 20 条都是半句话清洗时非常痛苦。AI Bot Scraper 的思路是引入“稳定窗口”概念。所谓稳定窗口就是连续 N 秒内目标节点的文本长度没有明显变化并且页面上的生成中状态比如停止按钮已经消失才判定回答结束。这个“N 秒”不能写死成固定值因为简单问题的回复一两秒就稳定了长文内容可能要十几秒甚至更久。配置里建议把稳定窗口设成动态的根据待抓取回答的平均长度预估一个初始值运行中再根据上一轮实际耗时动态调整。我在实际项目中把 N 设在 3 到 5 秒之间大部分情况下都能拿到完整回答。另外流式输出还牵扯到一个结构对齐的问题。有些回答是带标题、列表、代码块的 Markdown前端渲染时这些元素会被拆成多个 DOM 节点直接取 innerText 会把排版信息打平抓回来的数据很难用。更合理的做法是按“消息容器”为单位抓取保留块级元素边界再按 Markdown 语法做轻量还原。AI Bot Scraper 的默认配置在这点上做得不错但导出质量最终还取决于你设置的字段映射规则。3. AI Bot Scraper 实测从配置到跑通第一个任务3.1 环境准备与安装我推荐在 Linux 或 macOS 上跑Windows 也能跑但坑多一点主要是浏览器驱动路径和进程清理的问题。前置条件并不复杂Python 3.10 以上、Node.js 18 以上按需安装、Chrome 或 Edge 浏览器、以及一个保持登录状态的 ChatGPT 账号。AI Bot Scraper 本身以 Python 包形式发布用 pip 或 uv 安装即可具体安装命令以项目 README 为准。安装完之后我习惯先用命令检查一下版本和依赖是否齐全能打印出版本号说明基础环境没问题。接着要准备一个用户数据目录用于保存浏览器的登录态。这里有个小细节不要每次运行都用全新浏览器上下文否则每次都要重新登录、可能触发额外的风控验证。把 user_data_dir 指定到一个固定路径第一次手动登录一次之后脚本复用这个会话能省掉大量登录时间。3.2 一个最小可跑通的配置示例AI Bot Scraper 支持用 JSON 或 YAML 描述抓取任务。我贴一份自己验证过的精简配置结构上覆盖了最关键的四块浏览器设置、任务清单、等待策略、输出配置。browser: headless: false # 首次建议有头模式方便调试 user_data_dir: ./chrome-data # 保存登录态 executable_path: # 留空则自动查找系统 Chrome tasks: - name: 批量问答抓取 url: https://chat.openai.com/ input_selector: #prompt-textarea submit_selector: button[data-testidsend-button] response_selector: [data-message-author-roleassistant] questions: - 用三句话介绍什么是结构化数据 - Python 中如何高效处理 JSON 大文件 - 写一个简单的 FastAPI 接口示例。 wait_strategy: stable_window_seconds: 5 max_wait_seconds: 90 output: format: jsonl path: ./data/answers.jsonl fields: - question - answer - conversation_id - created_at这份配置的核心逻辑是打开 ChatGPT 对话页依次在输入框里敲入 questions 列表中的每个问题点击发送按钮等待回答节点在 5 秒内不再变化然后把回答连同问题原文一起写入 JSONL 文件。我特意用了有头模式做首次调试因为无头模式下出了问题只能看日志很难直观判断定位器是否选错了元素。跑通之后再把 headless 改为 true放到服务器上执行。3.3 字段映射与输出结构设计配置里的 output.fields 不是随便列的它决定了你后续清洗数据时能拿到什么。question 和 answer 是最基础的conversation_id 用来追踪多轮对话所属会话created_at 用来记录抓取时间。如果你的下游要做去重或者增量同步还可以追加 hash 字段由 question 原文和模型名拼接后计算 MD5这样同一条问题重复抓取时能识别出来避免污染数据集。我踩过的一个坑是别把 conversation_id 直接当唯一主键。原因是同一个会话里可以问很多个问题conversation_id 只能区分“是哪次会话”不能区分“是第几个问题”。要保证每条数据唯一最稳的方式是自定义一个 task_id格式类似“任务名问题序号时间戳”在配置模板里用变量动态生成。我在输出字段里加了一列 source_ts记录问题发起时间既方便按时间切片也方便将来回溯抓取顺序。输出格式方面我优先推荐 JSONL 而不是 JSON。JSON 要求整体结构合法任何一条数据写坏整个文件可能都无法解析而 JSONL 是一行一条即使中途任务中断已写入的行也能直接读取断点续跑后的数据合并非常方便。CSV 也可以但如果回答里包含换行符和逗号转义问题会让你怀疑人生除非下游明确要求否则不建议首选 CSV。3.4 首次运行踩过的坑与验证方法第一次跑任务我用的是三个短问题目的是验证链路是否通。结果第一次就翻车了脚本提示找不到输入框。原因不是工具的问题而是 ChatGPT 的页面结构更新后默认的 input_selector 失效了。这也印证了我前面说的页面结构一变选择器就会崩。解决办法是用浏览器开发者工具重新定位输入框把最新的选择器更新到配置里。跑通一次之后我建议做两件事验证数据质量。第一件事是抽样检查回答是否完整拿抓取到的 answer 和网页上肉眼看到的回答做对比重点关注结尾是否被截断、代码块是否闭合。第二件事是检查回答是否符合预期格式比如要求 AI 返回 JSON 时要确认抓下来的内容真的是可解析的 JSON而不是被 Markdown 代码块包着的字符串。这两步看似简单但在批量场景里格式错误的数据比缺失数据更容易被忽视。4. 对比测评AI Bot Scraper 与三类替代方案4.1 我选择的对比维度工具选型不能只看功能列表得结合维护成本、稳定性、上手难度综合判断。我这次对比选了四个维度接入成本从零到跑通第一条数据要多久、稳定性连续跑 100 条任务不中断的能力、可维护性页面改版或需求变更后改动成本多高、合规压力在法律和服务条款层面的风险高低。这四个维度基本覆盖了我在实际选型中最关心的点。4.2 横评结果一览为了直观我把 AI Bot Scraper、通用自动化框架Playwright、浏览器扩展注入、协议直连封装放在一张表里对比。这个表代表的是我实际测试后的主观感受数值不是基准测试的结果但方向是真实的。方案接入成本稳定性可维护性合规压力典型适用场景AI Bot Scraper低中高中中临时批量拉取、个人数据归档、评测集构建Playwright 自研脚本高中低中深度定制场景、需要精细控制浏览器行为浏览器扩展注入中中低低中高轻量采集、快速原型验证协议直连封装低初期低长期极低高高并发自用接口不推荐公开项目使用AI Bot Scraper 的接入成本最低因为它内置了选择器预设和等待策略比如我上一节配置里那套稳定窗口逻辑要是用 Playwright 自己写至少要几十行代码加好几轮调试。稳定性上它比通用框架好一点因为针对 AI 页面做了优化但绝对做不到 API 那种 99.9% 的可用性。可维护性方面它依赖页面结构和通用框架的处境一样只是隔一段时间更新一次就行不用每次改需求都重写脚本。4.3 实测结论与选型建议我自己的结论是如果你的任务量级在“几百到几千条”之间并且想快速跑出一个可用的结构化数据集AI Bot Scraper 是目前最省事的选项。它帮你承担了登录态管理、流式等待、超时重试这些脏活让你能把精力放在问题清单和数据处理上。我实际用它跑了 600 个问题断断续续用了大约四个小时产出 600 条 JSONL 数据完整率约 97%失败的问题通过重试机制补齐整体体验可以接受。如果你需要频繁调整抓取逻辑比如页面元素经常变、要定制多轮对话分支、要对接企业内部系统那通用自动化框架反而更合适。它给你的自由度更高代价是所有细节都要自己维护。协议直连封装我基本不建议碰除非你对逆向很有经验、且能接受较高的维护和合规成本。做技术调研时可以用它验证想法但在生产环境里不稳定和合规风险都会成为定时炸弹。5. 进阶优化并发、超时与流式输出的完整处理5.1 流式输出截断从源头解决我在第二部分说过流式输出是抓取成败的关键这里再展开讲讲实际怎么处理。最笨的办法是等固定时间比如发送请求后无论回答是否结束都等 30 秒再抓这么做的缺点是拿长回答容易截断、短回答浪费时间。更好的做法是引入两个独立判断一个判断“内容是否还在增长”一个判断“生成状态是否结束”。只有内容连续 N 秒没有变化且页面上的生成中控件已经消失才认为回答完整。在 AI Bot Scraper 的配置里稳定窗口期建议设成 5 秒最大等待时间设成 90 秒。如果你的问题大多是长文写作类可以把稳定窗口调大到 8 秒因为长文回答中途会出现短暂的思考停顿如果窗口太短脚本会误判为“已经回答完”提前抓取导致截断。反过来如果都是短问答稳定窗口可以压缩到 2 到 3 秒提高整体吞吐。还有一个容易忽略的点抓取回答后不要立刻进行下一次操作预留 1 到 2 秒的缓冲时间。原因很简单前端可能在回答渲染完毕后还会做一些异步收尾比如更新消息元数据、写入会话历史。等一秒钟再执行下一步能显著减少“回答抓到了但 message_id 没更新”这类次生问题。5.2 并发控制与限速策略批量抓取时不少人会想当然地设置高并发觉得这样快。但 AI 对话服务对账号的请求频次非常敏感短时间大量提问很容易触发风控要么出现人机验证要么直接临时限制对话。我测试时的安全经验是单个账号的并发数控制在 2 到 3 个任务以内而且每个任务之间至少间隔 5 到 10 秒。如果确实需要高吞吐建议多准备几个账号用轮询方式分散请求而不是让一个账号顶着高并发猛冲。AI Bot Scraper 支持多任务队列你可以开启两个任务分别用不同账号跑不同批次数据输出到独立文件最后再合并。这么做既保证速度又降低被封的风险。还要注意给整个流程加上随机抖动请求间隔不要完全固定比如 6 秒、8 秒、7 秒这样来回浮动更像真人操作。5.3 重试机制与任务去重批量任务跑久了一两项失败是常态。我遇到最多的是网络超时和页面元素偶发未加载解决方案是给任务加可重试策略。AI Bot Scraper 配置里可以设置 max_retries 和 retry_interval我推荐重试次数设为 3 次间隔从 10 秒开始逐次加倍避免失败后马上重试再次触发问题。另外还要做任务级去重。因为在断点续跑时你会重新读取问题列表如果没有去重前面已经成功抓取的问题会被再抓一遍浪费配额又污染数据。我建议维护一张“已成功任务表”只要某条结果写入了输出文件就把它的问题 hash 记录到表里。下次启动任务前先比对跳过已完成的条目。这个思路在任何批量抓取工具里都通用不限于 AI Bot Scraper。5.4 登录态与验证码的处理登录态管理是抓取工具不能回避的一环。我的做法是第一次启动用有头模式手动登录让 AI Bot Scraper 把浏览器上下文保存到 user_data_dir之后每次启动直接复用这个上下文。只要账号不退出登录、IP 地址不频繁变化这个会话能维持很久。需要注意的是user_data_dir 里的数据包含敏感会话凭证不要把它提交到代码仓库最好写在 .gitignore 里。至于人机验证我不建议做任何自动化绕过的尝试原因很实际一方面绕过的方案经常失效投入产出比极低另一方面涉及合规风险没有必要为了抓几条数据去碰红线。更健康的做法是降低请求频率或者切换时段再跑。如果某个账号频繁出验证就让它静置几小时换另一个账号继续跑通常能缓解。6. 高频故障排查与合规红线6.1 问题排查速查表运行过程中会碰到不少问题我把高频故障整理成一张表每条都标注了我实测验证过的处理方式方便大家直接对照排查。现象可能原因排查与解决找不到输入框或发送按钮页面结构改版选择器失效用开发者工具重新定位更新配置里的 selector回答内容被截断只有前几句话稳定窗口设置过短把 stable_window_seconds 从 5 调到 8 以上确认停止生成按钮消失后再抓取任务超时但页面看起来正常页面网络请求未完全结束调大 max_wait_seconds检查网络是否稳定必要时手动跑一次确认抓取结果全是空字符串回答节点定位到了错误元素检查 response_selector 是否匹配多个节点取最后一个还是第一个运行一段时间后频繁出现验证页面请求频率过高触发风控降低并发、拉长间隔、轮换账号不要尝试自动化绕过多轮对话上下文混乱问题之间没有清空会话每条问题之间新增对话或清空上下文保证独立会话输出文件中出现乱序数据并发任务间缺少锁或排序为每条数据加上序号输出后按序号排序合并6.2 几条独家避坑经验第一不要在 ChatGPT 的输入框里直接用一个“换行 多行问题”的长文本尤其是当你的问题里包含代码时。前端对换行和特殊字符的处理和你预想的不一样很容易导致输入框内容被截断或触发异常。我在批量运行时习惯把问题做一层 JSON 转义再用普通文本方式填入输入框传入或读取都走统一的编码格式数据边界清晰多了。第二抓取长文回答时要关注浏览器进程的内存占用。我跑 600 个任务时任务跑到后半程浏览器内存一度涨到 2GB 以上页面出现明显卡顿抓取速度也跟着变慢。后来我在每完成 50 个任务后重启一次浏览器上下文内存占用才稳定下来。这个重启逻辑可以通过脚本在任务之间触发不需要人工介入。第三时间戳很重要。AI Bot Scraper 能抓回答正文但不一定能在每个回答上自动保留准确的请求时间。我在输出配置里加了 created_at 字段并且保证所有任务使用同一个时钟源本地时间避免不同机器或不同时区的数据对不上。时间戳不仅方便排序溯源对后续做数据去重和版本对比也很有帮助别省这一步。6.3 合规边界与风险提示抓取工具好用但在正式投入使用前一定要把合规边界想清楚。最重要的原则是优先使用官方 API。OpenAI 提供了完善的接口和文档通过 API 获取结构化数据根本不是难事没必要为了省一点费用去抓网页端。AI Bot Scraper 更适合的场景是你暂时拿不到 API 权限、需要快速验证想法、或者抓取的是你自己账号权限范围内的对话记录。第二个原则是不要绕过权限控制。只抓你有权访问的数据不碰付费墙后的内容不批量下载他人私有对话不把抓取结果用于违反服务条款的用途。特别是涉及个人信息的数据采集后要做好脱敏和权限管理不要为了图方便把整个导出文件扔到公开仓库里。我见过不少人因为疏忽把包含会话记录的 JSONL 文件直接推到 GitHub 上结果后悔都来不及。第三个原则是控制频率和量级给自己留缓冲。即便页面允许你高频操作也不代表这么做是合适的。把抓取任务设计成“低频、小批量、可暂停、可恢复”的模式既保护你的账号也避免给目标服务造成不必要的压力。合规不仅是法律问题更是让自己长期省心的工程问题。我个人现在的做法是优先用官方 API 做生产数据流AI Bot Scraper 只用来补充 API 覆盖不到的边缘场景比如临时构造一批样例、验证前端提示词效果、归档个人对话记录。每次运行前都会过一遍这个检查清单是不是只有自己账号的数据频率是否合理输出文件会不会包含敏感信息确认无误后再启动任务。这样折腾了一个多月数据管道跑得挺稳我也没再因为封号或数据事故回过一次头。