采集规则编写 - 用交付验收倒推真正的搜索需求
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4b6f7d6de51e.html
📄
采集规则编写 - 用交付验收倒推真正的搜索需求
真正的搜索需求，不是“用户会搜什么词”这类猜测，而是能写进采集规则、被机器稳定识别、并且交付后可通过验收的结果。判断标准很简单：如果一条需求无法转化为明确的字段、匹配条件、异常处理和验收样例，它就还不是需求，只是想法。多人协作时，把这一步做扎实，能显著减少返工。
先定交付物，再谈需求
采集规则编写的交付物通常不是“能跑起来”，而是一份可交接的规则说明加可复现的结果。倒推时先问：下游拿这份数据做什么？如果是比价，就必须有价格、规格、库存状态、更新时间；如果是内容聚合，就必须有标题、正文、发布时间、来源标识。字段清单一旦确定，搜索需求就被约束成“必须覆盖哪些页面、哪些状态、哪些边界”。
一个可执行的做法是写验收样例：选3到5个代表性页面，人工标注正确结果，作为规则通过与否的依据。假设某电商列表页，验收样例可以包括正常商品、售罄商品、带促销标签的商品各一个——这是假设示例，用于说明方法，不是真实项目结论。
区分“能抓到”和“该抓到”
采集规则容易把“页面上有的”当成“需求要的”。真正的需求判断要过三关：
- 必要性：缺这个字段，下游任务是否无法完成？不能，就删。
- 稳定性：该字段在不同页面、不同状态下是否一致存在？只在部分页面出现，就要定义缺失时的处理方式。
- 可验证性：能否用一条明确规则判断对错？比如价格必须匹配数字加货币符号，否则记为异常。
三关都过，才进入规则编写。只过第一关的，标记为“待确认”，不要直接写死。
把责任和验收写进同一张表
多人协作返工多的原因，往往是需求、规则、验收三份东西分开维护。建议用一张表串起来，每行一条需求：
- 需求描述：要解决什么问题，一句话。
- 对应字段与取值规则：写清匹配条件、默认值、异常标记。
- 责任人：谁写规则，谁提供样例，谁做验收。
- 验收标准：通过样例数量、允许的异常比例、失败后的处理动作。
这样当规则跑出偏差时，能立刻定位是需求没定义清楚，还是规则实现有误，而不是互相推诿。
用异常清单反向校验需求
规则编写中最能暴露伪需求的就是异常处理。列出可能遇到的异常：页面结构变化、字段为空、重复数据、编码错误、分页边界。对每类异常问一句：这是需求本身要覆盖的情况，还是应该直接丢弃？
例如，某字段在目标页面中本就不存在，却因为“别人家的采集有”而被写进需求，这就是典型的伪需求。真正的搜索需求应当来自下游任务的实际缺口，而不是字段清单的攀比。
下一步：先写验收样例，再写第一行规则
如果现在就要开始一个采集规则编写任务，先别打开编辑器。找下游使用方确认三个验收样例页面，人工标出正确结果，再据此写字段和匹配条件。样例不过关，规则不交付；样例过关，规则才算真正对应了搜索需求。
