一、案例背景与采集目标
社区问答平台上有一种特别的数据:一个提问,下面挂着几十个回答,每个回答还有点赞数、评论数、作者、发布时间。它和新闻不一样——新闻是机构发的,问答是普通人写的;新闻有正文,问答是一问多答。这类数据里藏着大量真实经验与观点,是做内容分析的常见素材。
结构上,它属于我们前面见过的两级抓取:列表页给出问题和链接,详情页才有那几十个回答。区别在于,这一次详情页里的条目数量很多、长短不一,还牵涉到翻页和请求节奏,比采一篇新闻正文要讲究。
1.1 这一篇用哪些真实站点
示范站点是知乎,入口用它的发现页 https://www.zhihu.com/explore。这一页会把一批正在被关注的问题推给你,每个问题带标题、回答数与关注数;点进任意一个问题(地址形如 https://www.zhihu.com/question/1000123)就是详情页,回答按平台默认的口径排列,每条回答带点赞数(知乎叫「赞同」)、评论数、作者与时间。要注意:知乎对未登录访问有较强限制,同一会话里浏览多了会弹出登录墙,因此课堂练习只取少量公开可见的问题与回答,控制频率、不登录。
延伸站点可作对照:V2EX https://www.v2ex.com/?tab=hot(话题与回复数)、CSDN 问答 https://ask.csdn.net/(技术问答,含「已采纳」标记)。
1.2 这个案例要拿到什么
- 从列表页取回一批问题:标题、链接、回答数、关注数、问题标签;
- 顺着链接进入详情页,取回答正文、点赞数、评论数、作者、回答时间;
- 回答按点赞从高到低排序,只保留前若干条;
- 分页把列表翻几页,凑够目标数量;
- 控制请求节奏:每条之间留间隔,总量设上限。
1.3 两级抓取这一次的新问题
| 新问题 | 具体表现 | 对策 |
|---|---|---|
| 回答数量多 | 一个热门问题下几十上百个回答 | 只取前 N 条(如按点赞前 20 条),别全量 |
| 回答长短悬殊 | 有的几句话,有的几千字 | 长文本单独存文本文件,表格里只放摘要 |
| 口径要选 | 按点赞排还是按时间排,结果完全不同 | 在提示词里写死排序口径 |
| 请求量大 | 一页问题 × 每页回答,请求数会翻倍 | 设总量上限,间隔 2 秒,分批进行 |
| 有登录墙 | 知乎浏览频繁会要求登录,回答还会折叠 | 只采公开可见部分,不含折叠回答,不绕过登录 |
1.4 这一案例的取舍原则
新闻类采集讲究「尽量全」,而问答类采集更讲究「按价值取」。一个热门问题下排名靠后的回答,往往点赞寥寥、信息量也不高。把精力放在每页前若干条高赞回答上,既能拿到有代表性的内容,又能把请求量压到合理范围。
1.5 知乎回答的「折叠」要提前说清
知乎的问题页上,并不是每个回答都会老老实实排在列表里。点赞少、被举报或被平台判为「无帮助」的回答,会被折叠到「被折叠的回答」入口里;此外还有「作者精选」「编辑推荐」这类排序标签。
这对采集意味着两件事:一是口径要写清——只取默认展示的回答,还是把折叠回答也算进来;二是预期要放平——你采到的条数,很可能小于页面上标注的「回答总数」。这两点不写进提示词,验收时就说不清「为什么少了」。
目标站点与交付产物
下表是本篇用到的真实站点。绿色是课堂可稳定复现的示范站点;橙色是延伸站点,多数有登录墙或风控,课堂上只讲结构、原理与合规边界,不教绕过。
| 项目 | 内容 |
|---|---|
| 示范站点 | 知乎问题页与回答列表 https://www.zhihu.com/explore 列表页 + 详情页两级结构清晰,回答排序口径多样,适合练分页与长文本处理 |
| 延伸站点 |
|
| 交付产物 |
|
| 难度 | ★★☆ 中 |
| 合规提示 | 公开问答内容可采集,但不得采集用户身份信息,不得把昵称与真实身份做关联;回答正文引用需注明作者与链接。 |
二、数据源与字段设计
数据源是知乎的问题列表页与问题详情页两级结构。我们先在列表页上拿问题清单,再逐条进入详情页取回答。出于合规与效率考虑,本案例只采公开可见的问答区,只取每页前若干条高赞回答,不含被折叠的回答。
2.1 站点信息表
| 站点全称 | 网址 | 页面形态与接口 | 规模与角色 |
|---|---|---|---|
| 知乎 · 发现页(问题列表)与问题详情页 | https://www.zhihu.com/explore | 两级结构:列表页给问题入口,详情页给回答(形如 /question/问题号) | 热门问题下回答可达数十上百条;未登录可见范围受限,浏览频繁会弹登录墙 |
| V2EX · 热门主题 | https://www.v2ex.com/?tab=hot | 列表 + 详情两级,含话题标题、回复数 | 技术社区,结构简单,可作对照 |
| CSDN 问答 | https://ask.csdn.net/ | 问题列表 + 答案页,含「已采纳」标记 | 技术问答,采纳标记是很有用的一个特色字段 |
| 豆瓣 · 小组讨论 | https://www.douban.com/group/explore | 长贴与楼层回复结构 | 长文本多,适合练「长文本外置」 |
2.2 问题级字段表(列表页取)
| 字段名 | 字段含义 | 示例值 | 口径与备注 |
|---|---|---|---|
问题标题 | 问题的题目 | 零基础怎样学好数据分析 | 保持原文,不改写、不截断 |
问题链接 | 详情页地址 | https://www.zhihu.com/question/1000123 | 绝对地址,作为主键 |
问题编号 | 知乎的问题号 | 1000123 | 从链接里的 /question/ 之后取,比标题更稳定 |
回答数 | 该问题下的回答总数 | 128 | 数字,便于排序;注意「128 个回答」要去掉单位 |
关注数 | 有多少人关注 | 560 | 数字型;部分入口不显示,允许为空 |
问题标签 | 问题所属话题标签 | 数据分析;职业规划 | 多个标签用分号连接,用于分领域统计 |
列表页页码 | 来自第几页 | 2 | 便于回溯这条线索是在哪一页捞到的 |
2.3 回答级字段表(详情页取)
| 字段名 | 字段含义 | 示例值 | 口径与备注 |
|---|---|---|---|
问题编号 | 所属问题 | 1000123 | 与问题表对齐的关联键 |
回答编号 | 回答的唯一编号 | 884210011 | 从链接 /answer/ 之后取,回答的主键 |
回答链接 | 回答的永久地址 | https://www.zhihu.com/answer/884210011 | 绝对地址,引用时用来注明出处 |
回答排序 | 按点赞从高到低的名次 | 1 | 本次口径为按点赞;不同口径结果不同 |
回答正文 | 回答文本 | (长文本,示例:先明确目标,再选工具…) | 去除「相关推荐」「作者简介」等无关块 |
字数 | 正文字数 | 420 | 注明是否含标点 |
点赞数 | 该回答获得的赞同数 | 1350 | 有的写成「1.3 万」,要换算成 13000 |
评论数 | 该回答下的评论条数 | 42 | 热度参考;与点赞数配合看互动质量 |
作者昵称 | 回答者昵称 | 示例用户A | 只作统计,不点名评价、不做身份关联 |
作者类型 | 机构号 / 个人号 | 机构号 | 知乎会给机构认证账号打标,做来源分析时区分 |
回答时间 | 发布时间 | 2026-09-30 14:20 | 相对时间(如「3 天前」)需换算或原样保留 |
编辑状态 | 是否被编辑过 | 未编辑 | 有的显示「编辑于…」,做数据新鲜度判断用 |
2.4 排序口径对照表
| 排序口径 | 页面表现 | 适合回答的问题 | 口径提醒 |
|---|---|---|---|
| 按点赞(默认) | 高赞回答排在最前 | 大家最认可哪种说法 | 本次案例采用的口径 |
| 按时间 | 最新回答排在最前 | 最近又有什么新观点 | 与按点赞的结果差异很大 |
| 作者精选 / 编辑推荐 | 带精选或推荐标签 | 平台更想推哪类内容 | 标签是平台行为,不等于用户态度 |
AI 助手小贴士|长文本字段塞进表格会把文件撑得很大、阅读也不方便。让 AI 在表格里只放正文前若干字作为摘要,完整正文另存文本文件。
打开 WorkBuddy 或任意 AI 对话工具,试试这样问:回答正文太长,请把表格里的正文截成前 100 字作为摘要,完整正文按「问题编号_回答序号.txt」另存到 responses 目录。
课程思政|工匠精神与严谨求实 · 口径不同,结论就不同
「热门回答」这四个字并不精确:按点赞是第一梯队,按时间又是另一批。做数据的人要习惯追问一句「这个排名是按什么排的」,并把答案写进文档。一个说不清口径的榜单,看起来越漂亮,越容易误导人。
三、零代码操作步骤
工具与技能|先看清三个角色,再动手
本篇全程零代码:你把要求说清楚,AI 去执行,你负责验收。三个角色分工如下——浏览器技能指的是腾讯开源的 BrowserSkill,它能让 AI 直接操作你电脑上真实的浏览器(可复用已经登录的状态),自己开一个独立窗口干活,不打扰你正在看的网页;遇到验证码、登录或确认弹窗,它会停下来交给你本人处理。
| 角色 | 负责什么 | 在本案例里具体做什么 |
|---|---|---|
| 你 | 确认字段清单、验收结果、清洗与合规把关 | 盯字段清单、核对结果、处理异常(如验证码) |
| WorkBuddy | 接中文指令:探字段 → 批量采 → 清洗 → 导出交付物 | 拆解本篇的采集任务并跑完全量、产出交付物 |
| 浏览器技能 BrowserSkill | 以真实浏览器打开页面:跑脚本渲染、滚动 / 翻页 / 点开详情、截图留证;可复用本机浏览器已登录状态,遇到验证码或登录弹窗会停下来交给你处理 | 打开问答列表页,确认「列表页 + 详情页」两级结构能不能翻页 |
五步操作主线(全课程统一,每一篇都按这个顺序推进):
- 定目标与字段:先看本篇第二节的字段表,把「要哪几列、每列什么口径、要多少条」说清楚——字段清单就是验收标准,说不清就会拿回一张字段乱七八糟的表。
- 现场踩点(浏览器技能 BrowserSkill):打开
https://www.zhihu.com/explore,取第 1 页的问题标题、链接、回答数,并问它「这个列表有没有下一页」。 - 小样试采(WorkBuddy):只进一个问题的详情页,先只取按点赞排的前 5 条回答。
- 核对与清洗:① 点赞数「1.3 万」这类写法有没有换算;② 回答时间格式统一了没有;③ 正文有没有夹进推荐位;④ 总量上限与请求间隔说了没有(每个问题 ≤20 条、间隔 2 秒)。
- 导出与归档:导出交付物(数据明细表 / 可筛选明细页 / 数据看板 / 可复用的技能包),文件名带上采集日期,并写清数据来源、采集时间与已知局限。
用浏览器技能 BrowserSkill 打开 https://www.zhihu.com/explore(知乎问题页与回答列表),把这一页每条记录能采到的字段名和示例值列出来,先不要采集。- 先采问题列表页。让 WorkBuddy 打开
https://www.zhihu.com/explore取第 1 页的问题标题、链接、回答数,先做小样本。 - 确认能翻页。问它「这个列表有没有下一页」,有的话就翻到第 2 页,合并时按问题编号去重。
- 只取前几条高赞回答。进入一个问题的详情页,先只取按点赞排的前 5 条,看看字段齐不齐。
- 核对回答字段。重点看点赞数(有没有「1.3 万」这类写法)、评论数、回答时间格式、正文有没有夹进推荐位。
- 约定总量上限。说「最多采 10 个问题,每个问题最多前 20 条回答,总共不超过 200 条」。
- 设定请求节奏。要求「每条详情页之间间隔 2 秒,不要并发,失败的重试 1 次即可」。
- 长文本另存。说「长正文单独存 txt,表格里留摘要和字数」。
- 导出并归档。问题表与回答表分开导出,方便后续按问题编号关联。
四、提示词模板与追问技巧
下面这段可以直接复制。它把真实网址、两级抓取、排序口径、总量上限、请求节奏、长文本处理这几件事一次交代清楚。
请帮我采集知乎的问答数据(两级抓取)。
【目标页面】知乎发现页,地址:https://www.zhihu.com/explore
【延伸站点】若受限,可改用 V2EX 热门 https://www.v2ex.com/?tab=hot
【第一级:问题列表】
地址:https://www.zhihu.com/explore
字段:问题标题、问题链接、问题编号、回答数、关注数、问题标签、列表页页码
范围:第 1 页(约 20 个问题)
【第二级:问题详情页的回答】
从上面挑 10 个问题,逐条进入详情页(形如 https://www.zhihu.com/question/1000123)采集回答:
字段:问题编号、回答编号、回答链接、回答排序、回答正文、字数、
点赞数、评论数、作者昵称、作者类型、回答时间、编辑状态
排序口径:按「点赞数从高到低」,每个问题只取前 20 条
点赞数若是「1.3 万」这样的写法,请换算成 13000
【输出要求】
1. 问题表与回答表分成两个工作表
2. 回答正文超过 200 字的,表格里只放前 100 字摘要,
完整正文按 问题编号_回答序号.txt 另存到 responses 目录
3. 导出 qa_questions_20261008.xlsx 与 qa_answers_20261008.xlsx
【执行要求】
- 每条详情页之间间隔 2 秒以上,不要并发
- 总量上限 200 条回答,够了就停
- 失败的重试 1 次,仍失败就记录原因,不要一直重试
- 只采公开可见的问答内容,不含被折叠的回答,不要登录、不要绕过访问限制
- 出现登录墙立即停止并告诉我
4.1 三条常用追问指令
追问一(换排序口径):
请把这 10 个问题的回答改成按「时间从新到旧」取前 20 条,
和按点赞排的结果分开保存,我要对比两种口径的差异。
追问二(控制节奏):
请求看起来有点密,请把间隔改成每条 3 秒,
并把这次实际发出的请求次数统计给我。
追问三(长文本处理):
回答正文里混进了「相关推荐」「关注作者」这类内容,
请把这类块去掉,只保留回答本身,并重新统计字数。
AI 助手小贴士|「量太大」是问答类采集最常见的翻车点。让 AI 在动手前先估算总请求数,你确认可接受再开始。
打开 WorkBuddy 或任意 AI 对话工具,试试这样问:请先只估算这次任务总共要发多少次请求,把算式列出来给我看,先不要开始采集。
五、结果核对、清洗与保存
回答表的结果样例(节选,示例数据):
| 问题编号 | 回答排序 | 点赞数 | 评论数 | 字数 | 作者类型 | 回答时间 | 正文摘要 |
|---|---|---|---|---|---|---|---|
| 1000123 | 1 | 1350 | 42 | 420 | 机构号 | 2026-09-30 14:20 | 先明确目标,再选工具… |
| 1000123 | 2 | 980 | 18 | 286 | 个人号 | 2026-10-01 09:05 | 从一个小数据集练起… |
| 1000456 | 1 | 2100 | 63 | 610 | 个人号 | 2026-09-28 20:11 | 先看合同条款,再谈押金… |
| 1000456 | 2 | 760 | 9 | 155 | 个人号 | 2026-10-02 08:40 | 拍照留证很关键… |
5.1 四项核对
- 条数:10 个问题是否都取到了,每个问题是否够(或超过)约定条数;
- 排序:点赞数是不是从高到低排列,有没有乱序;
- 长文本:摘要截断位置是否干净,完整正文文件有没有按约定命名;
- 作者与时间:作者昵称与作者类型是否为空,回答时间格式是否统一。
5.2 清洗指令与文件组织
请对回答表做以下处理:
① 去掉正文摘要与作者昵称的首尾空格;
② 点赞数统一成整数(1.3 万 → 13000);
③ 回答时间统一成 YYYY-MM-DD HH:MM;
④ 新增一列「字数区间」:短(≤100)/ 中(101~500)/ 长(大于 500);
⑤ 按问题编号与回答排序,保持每个问题内部的有序性。
文件组织:
qa_questions_20261008.xlsx ← 问题表
qa_answers_20261008.xlsx ← 回答表(含摘要与字数)
qa_answers_clean.xlsx ← 清洗版
responses/ ← 完整回答正文(每个回答一个 txt)
qa_log.txt ← 日志:请求次数、成功/失败条数
5.3 两级表怎么配合着用
问题表和回答表分开存之后,分析时要靠问题编号把它们接起来。常见的两种接法:
- 从问题看回答:挑回答数最多的问题,看它的高赞回答都在说什么;
- 从回答看问题:把所有回答按字数或点赞数排序,回看它们分别挂在哪个问题上。
长正文已经外置成 txt,表格里只留摘要,所以做词频或主题分析时,直接读 responses 目录里的文本文件即可,不必再从单元格里抠字。
AI 助手小贴士|统计「平均每个问题有多少条高赞回答」「平均字数是多少」这类指标,能让数据从「一堆文本」变成「可比较的结果」。
打开 WorkBuddy 或任意 AI 对话工具,试试这样问:请基于回答表告诉我:每个问题的回答条数、平均字数、平均点赞数,并按平均点赞数给问题排个序。
课程思政|数据安全与法治素养 · 别人的话,不是你的素材库
问答平台上的回答,是具体的人写下的具体表达,受著作权保护,也关联到个人。我们可以做统计、可以看趋势、可以做文本分析,但不应把某个人的整段回答搬去公开发布,更不应对个体评头论足。理解数据背后是人,是这一行的底色。
六、常见问题与合规红线
6.1 五个高频问题
| 现象 | 原因 | 怎么处理 |
|---|---|---|
| 回答采到一半就停了 | 请求太密被限流,或触发了登录墙 | 立即停,加大间隔,分批小量重试 |
| 点赞数一会儿是数字一会儿是 1.3 万 | 页面用了单位缩写 | 统一换算成整数,原文另存一列以便核对 |
| 两次采集结果对不上 | 排序口径不同(一次按赞、一次按时间) | 在提示词里写死口径,两次必须一致 |
| 表格文件特别大、打开很慢 | 长正文整段塞进了单元格 | 表格只留摘要,完整正文另存 txt |
| 回答里混进「相关推荐」 | 推荐位与回答在同一容器 | 让 AI 按结构剔除,再抽查 3 条确认 |
6.2 三条合规红线
- 只采公开可见内容,不登录、不绕过限制;个人主页、私信、关注关系一律不碰。
- 总量与频率要克制,设上限、留间隔,课堂练习以跑通方法为目的,不追求规模。
- 不点评、不公开原作者内容,分析结论只呈现整体统计,避免把个体推到台前。
还有一条容易忽略的经验:回答的「作者类型」值得单独看一眼。机构号发的回答往往带品牌视角,个人号更偏经验分享;做来源分析时把两者分开统计,结论会稳得多——但无论哪种,都只对内容做统计,不对具体的人做评价。
课程思政|诚信与职业操守 · 看见数据背后的人
把回答看成一行行文本时,很容易忘记每一段后面都坐着一个真人。做数据的人要有一种自觉:允许自己分析和统计,但拒绝把别人的表达占为己有、拒绝用断章取义的方式消费他人。技术中立,用技术的人不能没有分寸。
七、随堂自测(10 题)
点击选项即可判分,答错的题会立刻显示解析。
1问答类采集为什么多是「两级抓取」?
- A. 因为列表页没有标题
- B. 列表页给问题入口,详情页才有具体回答
- C. 因为详情页不需要链接
- D. 两级抓取一定更快
2同一问题下,「按点赞排」和「按时间排」的区别是?
- A. 完全一样
- B. 只是显示顺序不同,内容不变
- C. 可能选出完全不同的回答,代表不同含义
- D. 按时间排不需要翻页
310 个问题、每个取前 20 条回答,大致会产生多少次详情页请求?
- A. 10 次
- B. 20 次
- C. 30 次
- D. 200 次左右
4点赞数显示为「1.3 万」,应该怎么处理?
- A. 原样保留
- B. 换算成 13000
- C. 删除这条
- D. 改成 1.3
5回答正文很长,放进表格前更恰当的做法是?
- A. 整段塞进单元格
- B. 直接删掉
- C. 把这一列改成图片
- D. 表格只放摘要,完整正文另存为文本文件
6采集过程中被限流、出现登录墙,正确反应是?
- A. 立即停止,加大间隔、降低总量
- B. 换 IP 继续
- C. 换账号继续
- D. 把请求数翻倍冲一冲
7要把问题表和回答表关联起来,最稳妥的关联字段是?
- A. 问题标题
- B. 回答作者
- C. 问题编号
- D. 列表页页码
8下面哪一项超出了本案例的合理边界?
- A. 统计各问题的平均点赞数
- B. 分析回答的字数分布
- C. 把某个用户的整段回答原样搬去公开转载
- D. 对高赞回答做词频统计
9为什么本案例主张「只取前若干条高赞回答」?
- A. 既拿到有代表性的内容,又控制请求量在合理范围
- B. 因为技术做不到全量
- C. 因为后面的回答都是错的
- D. 为了让表格更短
10保存问答数据时,比较规范的组织方式是?
- A. 把回答都塞进问题表的一行里
- B. 问题表与回答表分开,用问题编号关联,长正文单独存文件
- C. 只存一个巨大的纯文本
- D. 每次覆盖上一个文件