📍 WDQWDWQD987AAAAA:216.73.217.111
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c80328316cdd.html
📄

采集规则编写内容与技术如何协作：从交付结果倒推资料、任务与验收

采集规则编写中的内容与技术协作，核心不是先分谁写规则、谁写代码，而是先确定最终要交付什么结果，再倒推需要哪些资料、由谁完成、按什么标准验收。假设目标是每天稳定产出一份结构化商品数据表，那么内容侧要定义字段含义与取值口径，技术侧要保证选择器、翻页、去重和异常处理可运行，双方共同用同一批样本页面验收。若只讨论工具或只讨论字段，通常会在上线后暴露漏采、错位或重复问题。

先明确交付物，再拆解协作接口

协作的第一步是把“采集规则”翻译成可检查的交付物。建议至少写清四项：

• 输出结构：字段名、字段类型、是否必填、示例值。例如标题为文本必填，价格为数字必填，库存状态为枚举值。
• 数据范围：采集哪些页面、哪些栏目、时间范围或分页深度，以及是否需要增量更新。
• 质量要求：允许的缺失率、重复率、格式错误率，以及发现异常后是跳过、告警还是停止任务。
• 运行方式：手动触发还是定时运行，失败后重试几次，结果输出到文件、数据库还是接口。

这些内容不是技术细节，而是内容与技术共同确认的验收依据。缺少输出结构，技术只能猜测字段；缺少数据范围，内容会误以为所有页面都应被采集。

内容侧要提供什么，技术侧要确认什么

内容侧通常更了解页面语义和业务口径，需要提供：字段定义、同义写法、必填与选填判断、异常值示例、页面样本。技术侧更了解规则实现和运行限制，需要确认：页面结构是否稳定、选择器是否唯一、翻页参数如何变化、是否存在登录或频率限制、数据如何清洗和落库。

两者之间最好用一张对照表沟通。下面是一个假设示例，用于说明协作方式，不代表任何真实项目：

• 内容提出“价格”字段应取促销价，若没有促销价则取原价。
• 技术确认页面中促销价和原价位于不同节点，需要先判断节点是否存在，再决定取值。
• 双方约定验收时随机抽取若干页面，人工核对价格取值是否符合上述优先级。

这样写出的规则才有明确判断条件，而不是把“价格取对”留给运行后再猜。

把任务和责任落到可验收的步骤上

从交付结果倒推，可以按以下顺序推进：

1. 内容侧定义字段字典：每个字段写清含义、格式、必填性和示例。
2. 技术侧编写最小规则：先在一个样本页面上跑通，不急于扩大范围。
3. 双方共同核对样本：内容看语义是否正确，技术看选择器和翻页是否稳定。
4. 补充异常处理：字段缺失、页面改版、重复数据、请求失败时分别怎么处理。
5. 小范围试运行：用一批已知页面验证输出，再决定是否扩大采集范围。
6. 按验收标准确认：检查字段完整率、重复率、格式正确率和异常记录。

责任划分可以简单记为：内容侧对“取什么、为什么取”负责，技术侧对“怎么取、能否稳定取到”负责，双方对“取出来的结果是否符合交付要求”共同负责。

出现漏采或错位时，先收集证据再定位

当结果不符合预期，不要直接改规则。先收集证据：出错页面的地址、采集时间、原始页面片段、规则输出结果、期望结果。然后按下面顺序判断：

• 如果整页没有数据，可能是请求未成功、页面需要登录、或选择器完全不匹配。
• 如果部分字段为空，可能是字段节点不存在、内容由脚本后加载、或取值条件写错。
• 如果字段串位，可能是多个节点顺序变化、列表与详情对应关系错误、或分页重复。
• 如果数据重复，可能是翻页参数未变化、去重键选择不当、或任务被重复触发。

这些只是可能原因，不能仅凭一个现象断定唯一原因。正确做法是用同一页面复现，逐项排除。例如先确认页面源码中是否存在目标字段，再确认规则是否命中该节点，最后确认输出环节是否改写了数据。

验收标准要能判断通过或不通过

验收不是“看起来差不多”，而是给出可判断的条件。可以检查：

• 必填字段是否都有值，缺失时是否有记录。
• 数字、日期、枚举值是否符合约定格式。
• 同一记录是否只出现一次，去重键是否稳定。
• 抽样页面的人工核对结果是否与规则输出一致。
• 失败任务是否有日志，能否定位到具体页面和具体字段。

如果这些检查项无法执行，说明交付物定义还不够具体，应先回到字段字典和数据范围补充，而不是继续扩大采集量。

下一步可以直接拿一份现有采集结果，按上面的字段字典、样本核对和异常记录三项做一次检查，把内容侧与技术侧的分歧写成具体判断条件，再决定是否修改规则。