seo技巧总结：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3f93d8958185.html
📄
seo技巧总结：把人工经验写成脚本需求时怎样描述例外情况
可以写成脚本需求，但前提是把例外描述成“可判定的条件+可观察的结果”，而不是“看情况处理”。如果例外只能靠人的模糊判断，脚本要么误伤正常页面，要么频繁跳过，最终仍需人工兜底；这时更合理的做法是先缩小脚本适用范围。
例外要写成条件，而不是形容词
人工经验里常出现“标题明显重复”“内容质量差”“结构不合理”这类表述。写成需求时，要把它们换成脚本能读取的字段和阈值。例如：
- “标题太像”改成“两页标题去空格后完全相同，或前12个字符相同且正文前100字重合超过某比例”。
- “内容太薄”改成“正文可见字符数低于某值，且不包含列表、图片说明或表格”。
- “不该动”改成“页面带有特定模板标记、属于某目录、或最近一次改动时间在N天内”。
这些条件需要注明假设：阈值是人为设定的，不是平台规则。动作上，先让脚本只输出“命中/未命中”清单，不直接改页面；检查清单里有多少是误判，再决定是否收紧阈值。这一步的结果会直接影响下一步——如果误判集中在某类模板，就应把该模板整体列为例外，而不是继续调数字。
缺少数据或权限时，先写可执行的最小例外
没有完整日志、后台导出或抓取权限时，不要试图描述所有例外。可以执行的最小动作是：只针对能拿到的那部分字段写脚本，例如页面标题、正文长度、内链数量。对拿不到的字段，明确写成“暂不判断”，而不是用猜测代替。
这样做能得到的结论有限：只能说明在可见字段上哪些页面符合或不符合条件，不能推出这些页面在搜索表现上一定有问题，也不能推出改动后一定改善。请求量或抓取量归零也不能单独证明处理正确，它可能来自采集周期变化、需求波动或权限调整。下一步动作是先保留人工抽查样本，用同一批条件复核，再决定是否扩大脚本范围。
一个会让结论失效的反例
假设你总结出一条经验：正文少于300字的页面应合并。写成脚本后，例外设为“带有产品参数表的页面不合并”。但如果某类页面正文短、参数表由脚本动态加载，抓取时看不到表格，脚本就会把它当成普通短页处理。此时“短页应合并”的结论在这类页面上失效。
反例的价值在于提醒：例外描述必须包含“数据是否可见”这一层。若无法确认动态内容是否被读取，就不要把该模板纳入自动处理，而应单独列出并人工确认。动作上，把这类页面从脚本输出中排除，观察排除后剩余清单的误判是否下降；若下降，说明例外条件有效，可继续；若没有下降，说明问题不在该模板，需要重新检查字段来源。
比较改动效果时，别把季节和采集差异算成脚本功劳
脚本上线前后做比较，要考虑搜索需求本身的季节变化、采集时间差和样本差异。一次改动前后对比，不能只看总量升降。更稳妥的做法是保留一组未改动的相似页面作为对照，比较两组在同期的相对变化。若没有对照条件，只能描述“改了什么、观察到了什么”，不能把变化归因于脚本。
下一步动作取决于对照结果：如果改动组与对照组差异方向一致，说明变化可能来自外部因素，应继续观察；如果只有改动组出现同向变化，再考虑扩大应用范围。无论哪种结果，都不承诺固定见效时间。
把例外写成可复查的清单
最终交付给脚本的例外部分，建议按这个顺序写：判定字段、阈值或标记、命中后的动作、无法判断时的动作、复查方式。复查方式要具体到“抽多少页、看哪些字段、由谁确认”。这样即使脚本运行后出现异常，也能回到清单定位是条件写错、字段缺失还是阈值过紧。
如果例外条件写不清，正确做法不是让脚本“智能处理”，而是缩小范围或暂缓自动化。能稳定执行的脚本，通常来自边界清楚的经验，而不是覆盖所有情况的愿望。
