网站优化技巧，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /27142e8975e8.html
📄
网站优化技巧，把人工经验写成脚本需求时怎样描述例外情况
先把例外写成“可判定的条件”，再决定它由脚本自动处理还是转人工复核。人工经验里“这个页面看起来不太对”无法执行，必须落成字段、阈值和取值来源；如果例外依赖语义判断或跨系统信息，就保留人工队列，不要硬塞进脚本。
先分清两类例外：可枚举的和需解释的
可枚举的例外能用明确字段判断，例如某类模板、某个目录、某段时间内未更新的页面。需解释的例外依赖语义或上下文，例如“内容质量偏低”“与站内主题重复”。两者在需求文档里的写法完全不同：前者写成条件分支，后者写成人工复核触发条件。
判断方法很简单：让另一个人只看字段和阈值，能否得出和你一样的结论。能，就属于可枚举；不能，就属于需解释。
条件一：字段稳定且来源可核对，写进脚本自动处理
当例外的依据来自稳定字段，例如页面类型、发布时间、URL 路径层级、是否含特定结构化数据，就把它写成脚本里的判断条件。
实施动作：在需求里为每个例外写明字段名、取值来源、比较方式和命中后的动作。例如“路径以 /tag/ 开头且正文少于 300 字，跳过内容更新检查，只记录”。结果会影响下一步：脚本跑完后，这类页面不再进入人工队列，你可以把复核时间集中到真正需要判断的页面上。
这里要注明假设：字段含义和取值方式在脚本运行周期内不变。如果字段定义会随模板调整而变化，例外条件也要跟着改，否则会误判。
条件二：依据依赖语义或跨系统信息，保留人工复核
当例外依据需要读完整段内容、结合业务背景或比对多个系统才能判断，就不要把它写成自动分支。可以写成“标记并转人工”的触发条件，而不是“自动处理”的条件。
实施动作：在需求里把这类例外写成待办清单的输出字段，例如“疑似主题重复，需人工确认”。结果会影响下一步：脚本只负责缩小范围，不负责下结论。这样做的代价是仍需人工时间，但避免了用错误规则批量改动页面。
可核对的证据包括：同一条件在历史数据中是否反复出现、人工判断是否一致、规则命中后是否产生明显误伤。如果同一例外在不同人手里结论不同，说明它还不适合写成脚本条件。
用一段短例子说明阈值和复核的关系
假设你要求脚本找出“长期未更新且流量偏低的页面”。可以写成：发布时间超过 180 天，且近 30 天点击量低于某个阈值，进入待复核清单。这里 180 天和阈值都是假设数字，只用于说明比较方法，不是固定标准。
脚本输出清单后，你抽查若干条，看命中原因是否符合预期。如果大量命中来自季节性页面，说明阈值没有考虑需求波动，需要把季节因素作为例外条件补充进去，或改为人工判断。这个动作的结果是：要么调整规则再跑，要么把这类页面移出自动范围。
写需求时把例外放在动作之前
常见写法是先写“脚本要做什么”，最后补一句“特殊情况人工处理”。更稳妥的顺序是先列例外条件，再写主流程。这样脚本作者能先看到边界，避免把例外当成主流程的一部分。
- 每个例外写明：判断字段、取值来源、比较方式、命中后动作。
- 需要语义判断的例外，输出到人工队列，并写明复核问题。
- 规则上线后先小范围运行，核对命中原因，再决定是否扩大范围。
一次改动前后比较要考虑季节、搜索需求变化和数据采集差异，不能把某次命中数量变化直接当成规则正确的证据。请求量或抓取量归零也有多种合理解释，例如采集口径变化、脚本未运行或页面被排除，需要结合日志和字段核对，不能单独下结论。
