结论先给:不要靠“每人写一段”来分摊推理,而要按可验证的中间产物分工。在火车头采集教程的学习小组里,真正容易掉链子的是“规则为什么这样设”这一步——只检查最终任务是否跑通,无法判断谁真的完成了推理。可行的做法是:把采集任务拆成“采集—字段处理—发布”三段,每段都要求成员留下判断依据;若某位成员无法说明某个字段为何这样取,就说明他跳过了推理,需要退回该段重做。
两种切法都成立,但适用条件不同。按流程切(一人负责列表页规则、一人负责内容页字段、一人负责发布配置)适合同一个网站、字段结构稳定的任务,因为接口清晰,前后段可以并行。按站点切(每人独立负责一个目标站点的完整规则)适合网站之间结构差异大、字段命名不统一的情况,因为跨站协调成本高于个人独立完成的成本。
判断依据可以看一个信号:如果小组成员频繁需要问“你这个字段名和我这边对不上”,说明按流程切的接口还没定义清楚,此时要么先统一字段命名再继续,要么改为按站点切。反过来,如果每个人都在重复写同一套翻页和去重逻辑,说明按站点切造成了冗余,应改回按流程切。
采集任务里的推理通常藏在这些地方:列表页翻页规律是 URL 递增还是点击“下一页”;内容页正文是用 XPath 还是用正则截取;字段为空时是跳过还是保留占位。这些判断如果不写下来,只有做的人自己知道,小组其他成员无法复核。
要求每位成员在提交自己那段规则时,附上三样东西:
“反例”这一项最关键。能说出失效条件的人,通常真的理解了规则;说不出的人,多半只是照抄了别人的表达式。假设某成员负责内容页正文提取,他写道“用 <div class="content"> 定位,但如果页面改版把 class 换成 article-body,这条规则就取不到值”,这就构成了一条可验证的推理记录。若他只写“用 class 定位”,则无法判断他是推理后选择,还是碰巧试出来的。
平均分配“每人做几个任务”看似公平,但无法保证每个人都完成推理——有人可能只复制了别人的规则改个网址。更有效的做法是让每人复核另一人的中间产物,重点不是检查任务是否跑通,而是追问“你为什么这样选”。
复核时可以用一个具体动作:让对方口头或书面解释他规则里的每一个定位表达式对应页面上的哪个元素。如果解释与页面实际结构不符,说明推理没有落地。这个动作的结果直接决定下一步——解释通过则进入合并测试;解释不通过则退回该成员重做该段,而不是由复核者代为修改,否则推理仍然只发生在一个人身上。
如果目标网站改版,字段结构整体变化,原本按流程切的接口可能全部失效。此时先判断变化范围:只是个别字段的 class 变了,保留分工、各自改写自己那段的定位规则即可;如果列表页的翻页机制从 URL 递增变成接口请求,那么负责列表页的人需要重做推理,其他段暂时不受影响,仍可保留。
但如果网站改为需要登录才能看到列表,或者内容通过脚本动态加载,原来的静态采集思路整体不成立,这时应考虑退出当前分工方案,先集体重新评估采集方式,再决定是否继续拆段。判断标准是:变化是否触及“数据从哪里来”这一层。只触及字段定位,改写即可;触及数据获取方式,先停下分工,避免各段在错误前提下继续推进。
假设小组三人分别负责列表页、内容页、发布配置。列表页成员声称“翻页规律是 page=1、2、3 递增”。复核者不应只看第一页能否取到数据,而应要求他给出第 2 页和第 3 页的 URL 对比,并说明如果网站改为 page=0 起始会怎样。如果他无法给出这个对比,说明推理未完成,应退回补充;如果他给出了对比并指出“从 page=0 开始会导致第一页重复”,则这条推理成立,可以进入下一段合并。这个例子的数字仅用于说明验证方法,不代表任何具体网站的实际参数。
把这套“中间产物 + 交叉复核 + 变化分级”的做法固定下来,小组分工才不只是分摊工作量,而是让每个人的推理都留下可被追问的痕迹。