Feed优化，网站规模扩大后哪些工作不适合继续手工做
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dca4214e4700.html
📄
Feed优化，网站规模扩大后哪些工作不适合继续手工做
当站点从几十条URL涨到几千条，最先撑不住的往往不是服务器，而是手工维护Feed的流程：人工改XML、逐个补字段、凭记忆核对分类。判断哪些工作该交出去，关键看三件事：动作是否重复、结果是否可验证、出错后影响面是否成片。只要同时满足，就适合做成规则或脚本，而不是继续手工扛。
先拿一份现有Feed当样本，判断手工是否已经失控
不要凭感觉说“量大了”，先取一份当前正在用的Feed文件，做三项检查。
- 统计条目总数，以及其中字段缺失或格式不一致的条目占比。
- 找出最近一次手工修改的记录，看这次修改涉及几个条目、花了多少时间。
- 列出这类修改多久发生一次，是每周一次还是每次上新都要做。
假设一份Feed有五千条记录，其中约两百条的分类标签写法不统一，每次上新又要手工复制旧模板。这时手工的问题不是“慢”，而是每次改动都要重新判断一遍规则，判断标准还留在某个人脑子里。这种工作应当优先转为校验规则加批量替换，而不是继续逐条改。
三类工作适合从手工转为规则化处理
字段格式的批量统一
价格写法、库存状态、分类路径、图片链接这类字段，如果要求全站一致，就不该靠人工记忆。做法是写一份校验清单，明确每个字段允许的取值和格式，让脚本在生成Feed时自动检查。动作上可以先跑一次全量校验，把不符合的条目导出成清单，再决定是修正源数据还是修正生成规则。结果会直接影响下一步：如果错误集中在源数据，就要回到内容录入环节改流程；如果集中在生成环节，改模板即可。
条目的准入与退出判断
旧内容、下架商品、失效合作方的条目要不要保留，手工逐条判断在规模扩大后几乎不可行。更适合的做法是设定可执行的退出条件，例如“连续多个更新周期未发生变化且不再出现在站内导航中”，由脚本标记为候选退出，再由人复核。这里要注意，标记为候选不等于删除，保留仍被引用的条目、保留有历史价值的页面，都需要在规则里单独写明例外。
重复性提交与同步动作
如果同一份数据要同时用于站内页面和外部Feed，手工同步两份内容迟早会不一致。可把源数据作为唯一入口，由生成流程产出不同格式的输出。动作是先确定哪一份是主数据，再把另一份改为自动派生。结果是后续修改只需要动一处，下一步要验证的是派生结果是否与主数据保持一致。
哪些工作暂时仍值得保留人工判断
并非所有环节都该自动化。以下情况手工或人工复核仍有必要：
- 涉及内容质量取舍，例如某篇旧文是否仍有读者价值，规则难以准确判断。
- 涉及合作关系或授权状态，退出前需要确认是否有未结事项。
- 首次出现的异常，例如某类条目突然大面积缺失，先人工定位原因，再决定是否写成规则。
区别在于：重复且判断标准明确的工作交给规则，一次性或标准模糊的工作留给人。把这两类混在一起，就会出现“自动化了却没人敢用”的情况。
把判断落成一个可执行的处理顺序
- 选一份当前Feed作为样本，记录条目数、字段缺失情况和最近一次手工修改的耗时。
- 把手工动作按“重复频率”和“判断标准是否明确”分类，明确标准且高频的先处理。
- 为选中的动作写出校验规则或退出条件，先在全量数据上试跑，只生成报告不直接改动。
- 复核报告，确认误判比例可接受后，再让流程自动执行，并保留人工抽查入口。
- 记录这次改动后，下一次同类问题是否还需要人工介入，以此判断规则是否够用。
需要说明的是，抓取量、索引量或某项统计归零，并不能单独证明某次处理正确，也可能是抓取节奏、页面结构调整或数据延迟造成的。判断规则是否有效，应结合源数据变化和实际处理结果一起看，而不是只看单一指标。规模扩大后真正该放弃的，是那些每次都要重新判断、结果又难以核对的手工动作；保留下来的是需要经验和取舍的判断，两者分开处理，Feed维护才不会随着站点增长而失控。
