网站优化方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /dc7a15c0288a.html
📄
网站优化方法：把人工经验写成脚本需求时怎样描述例外情况
直接回答：例外情况要写成“触发条件 + 判断依据 + 默认动作 + 人工接管出口”，而不是写成“遇到特殊情况再说”。在网站优化方法里，脚本需求最容易漏掉的不是正常流程，而是那些与直觉相反、却真实存在的页面状态；把这些状态提前描述清楚，脚本才不会在边界处做出错误动作。
先看一个假设情境：为什么脚本会做出相反动作
假设你负责一个内容站，人工检查时发现：某批旧页面标题过短，需要补足核心词。你把经验写成脚本需求：“抓取标题字符数少于 20 的页面，自动在末尾追加站点名。”上线后你发现，部分页面标题反而变得更长、更不相关。
这不是脚本坏了，而是例外情况没写进去。人工操作时，你会看一眼页面类型：如果是栏目页，标题短可能是合理的；如果是活动页，末尾加站点名可能破坏原有信息；如果是已下线但仍有访问的页面，修改标题没有意义。脚本只认字符数，就会把这些页面一并处理。这个假设情境说明：例外描述的目标不是穷举所有情况，而是让脚本在无法判断时停下来，交给人工。
例外的四种类型：按“谁来决定”分类
把人工经验转成脚本需求时，可以先问：这个例外由谁决定？不同决定者对应不同写法。
- 由数据决定：例如标题字符数、更新时间、访问状态。写法是给出阈值和取值来源，并说明阈值取不到时怎么办。
- 由页面类型决定：例如栏目页、详情页、聚合页。写法是列出允许处理的类型，其余默认跳过。
- 由人工判断决定：例如标题是否偏离主题、是否涉及品牌口径。写法是标记待确认，不自动修改。
- 由外部状态决定：例如页面已下线、正在改版、被其他流程占用。写法是先查状态，状态不明则不动作。
这四类里，最容易被漏掉的是第三类和第四类。因为它们无法只靠一个字段判断，脚本需求里必须留出“标记 + 暂停”的分支，而不是硬编码一个默认值。
描述例外时，必须写清的四件事
无论例外属于哪一类，需求里都要能回答四个问题：
- 触发条件：什么情况下进入例外分支？条件要可核对，比如“标题为空”比“标题不合适”更可执行。
- 判断依据：依据来自哪个字段、哪次抓取、哪份清单？如果依据缺失，视为例外还是视为正常，要明确。
- 默认动作：进入例外后，是跳过、标记、还是保留原样？默认动作应当是可逆的，避免直接覆盖。
- 人工接管出口：例外记录写到哪里、由谁看、看完后如何回到流程？没有出口，例外就会变成沉默失败。
一个可执行的写法示例：若标题字段为空，则跳过修改并记录页面地址与抓取时间；若标题字符数少于阈值但页面类型为栏目页，则标记待确认，不自动追加站点名。这里没有承诺任何效果，只描述动作和去向。
用可核对证据区分“脚本错了”和“例外没写全”
当结果与直觉相反时，不要先改脚本，先收集三类证据：
- 改动记录：哪些页面被处理、处理前后的字段值分别是什么。
- 页面状态：这些页面当时的类型、访问状态、是否在其他流程中被修改。
- 时间对照：改动前后的数据变化是否与季节、搜索需求变化或采集差异同时发生。
如果被处理的页面集中在某一类型，说明例外条件写窄了；如果被处理页面分散且无共同特征，说明判断依据本身不可靠；如果只有个别页面异常，优先检查人工接管出口是否被跳过。一次改动前后的比较要考虑季节、搜索需求变化和数据采集差异，不能把同时发生的变化直接当成改动效果。
实际动作可以是：先暂停自动修改，把已处理页面导出，按页面类型分组，再决定是补充例外条件还是回退。这个动作的结果会直接影响下一步——如果分组后能看出稳定特征，就补进需求；如果看不出，就说明当前经验还不足以写成脚本，应先保留人工确认环节。
例外描述写完之后，先做小范围验证
需求写完后，不要直接全量运行。先选一批包含正常页和已知例外页的样本，按脚本逻辑走一遍，核对三件事：正常页是否被正确处理、例外页是否被正确跳过或标记、人工接管出口是否真的有人能看到。验证通过后再扩大范围，并在扩大后继续保留回退路径。
网站优化方法里，脚本的价值不在于替代人工，而在于把人工已经想清楚的判断固定下来。例外情况描述得越具体，脚本越知道什么时候该停；停下来交给人工，往往比自动做完更接近你想要的结果。
