细雨算法应对：网站规模扩大后哪些工作不适合继续手工做
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2a260785c7fb.html
📄
细雨算法应对：网站规模扩大后哪些工作不适合继续手工做
规模扩大后，最不该继续手工做的不是“所有事”，而是那些重复出现、判断标准稳定、出错代价低且结果可回查的工作。细雨算法应对的核心并不神秘，它关注的是页面质量、内容可信度和用户体验信号；当站点从几十页涨到几千页，手工逐个核对标题、内链、失效链接和旧内容状态，会从“精细”变成“瓶颈”。但有一个反例会让这个结论失效：如果页面类型差异极大、每页都涉及人工判断，比如医疗建议、金融产品说明或复杂法律条款，那么批量处理反而可能放大错误，此时应保留人工审核，只把收集和比对环节自动化。
先分清：哪些手工活已经变成规模负担
判断标准可以看三点：同一动作是否每周重复、判断规则能否写成明确条件、执行结果能否用同一套字段记录。满足这三点的，通常适合交给脚本、模板或批量流程；只满足其中一点的，仍要保留人工抽查。
- 批量检查标题和描述是否缺失或重复：规则清楚，适合自动列出待处理清单，人工只决定如何改写。
- 站内链接的增删与替换：当栏目和文章数量上升后，手工插入内链容易遗漏或过度集中，适合按主题和层级批量生成候选，再人工确认。
- 失效链接和重定向状态巡检：这类工作重复性高，手工点击既慢又难留记录，适合定时抓取并输出异常列表。
- 旧内容退出或保留的初步筛选：可以先按最后更新时间、访问情况、是否仍被其他页面引用等条件分组，再由编辑决定删除、合并、更新还是保留。
这些动作的共同点是：机器负责“找出来”，人负责“做判断”。如果反过来，让人一直做查找和复制，规模越大越容易漏。
哪些工作仍要手工，不能因为量大就全交出去
内容质量判断、合作关系退出、旧系统迁移中的取舍，通常不适合完全自动化。以旧内容退出为例，假设一个站点有三千篇文章，其中八百篇长期没有访问，但其中一部分仍被外部页面引用，或仍在回答用户会搜索的问题。此时如果只按“访问低”批量删除，可能把仍有价值的部分一起清掉。
更稳妥的做法是先设定保留条件，例如：仍被其他内容引用、仍能解决一个明确问题、仍符合当前业务范围。满足其中一条的，进入人工复核；都不满足的，才进入退出流程。这个动作的结果会直接影响下一步：如果复核后发现大量旧文只是缺少更新，那么下一步应是安排更新和重新内链，而不是继续扩大删除范围。
一个可执行的判断顺序
- 把重复工作按“查找、判断、执行、复查”拆开。
- 查找和复查优先自动化；判断和执行保留人工确认。
- 为每类工作写出保留或退出的条件，并注明假设。例如假设“三个月无访问且无内链”可作为退出候选，但仍需检查是否被外部引用。
- 先在一个栏目或一批旧内容上试运行，观察异常列表是否合理，再决定是否扩大范围。
如果试运行后发现异常列表里大量是正常页面，说明条件写得太粗，应先修正条件，而不是直接批量处理。相反，如果异常列表准确且人工只需做少量确认，就可以把这项工作从手工清单中移出。
细雨算法应对下，规模扩大后真正该保留的手工动作
保留手工动作不等于回到逐页修改。更合理的是保留三类人工环节：一是内容是否真正回答用户问题的判断；二是旧内容、旧系统或旧合作关系退出前的价值复核；三是批量处理后的抽样检查。抽样检查不需要每页都看，但要能回答“这批处理有没有把不该退出的部分一起处理掉”。
如果抽样发现错误集中在某一类页面，比如产品旧型号或已停止服务的说明页，那么下一步应针对这一类页面单独设定规则，而不是否定整个批量流程。这样既控制了规模带来的重复劳动，也没有把需要判断的部分交给机器。
最后，把已经稳定的规则写成清单，把仍需判断的部分留给编辑，并定期回看异常列表和抽样结果；当规则不再匹配新页面类型时，先调整规则，再决定是否继续自动化。
