站长省钱技巧：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c12e1ba4ace8.html
📄
站长省钱技巧：把人工经验写成脚本需求时怎样描述例外情况
结论是：例外情况不要写成“特殊情况特殊处理”这类模糊表述，而要写成带触发条件、判断依据、期望动作和兜底结果的分支需求。只有当例外可以稳定复现、且触发条件能用日志或页面字段判断时，才值得写进脚本；如果例外依赖人的临场判断，先写成人工复核清单，不要硬塞进脚本。
先分清哪些例外值得进脚本
把人工经验转成脚本需求时，最容易犯的错是把“我平时会看一眼”直接翻译成“脚本自动判断”。判断一个例外是否值得进脚本，看三个条件：触发信号是否可采集、判断规则是否稳定、出错后是否有低成本兜底。
- 可采集：这个例外能从响应码、字段缺失、时间戳、目录结构或文件名规律里看出来。
- 稳定：同样条件下，过去多次处理方式一致，不随当天心情或临时通知变化。
- 有兜底：脚本判断错时，能落到人工队列，而不是直接删除或覆盖。
三个条件都满足，才写成脚本分支。缺一个，就写成人工复核项。这一步决定后续脚本的复杂度，也决定你省下的是时间还是新麻烦。
例外描述要写清四个字段
一条可执行的例外需求，至少包含四个字段，缺一个都会让开发或未来的自己反复追问。
- 触发条件：什么情况下进入这个例外。例如“页面返回 200，但正文区字符数低于阈值”。
- 判断依据：用哪个字段或哪份数据判断。例如“以正文容器内的纯文本长度为准，不含导航和页脚”。
- 期望动作：进入例外后脚本做什么。例如“不自动改写，标记为待复核，写入日志”。
- 兜底结果：判断失败或数据缺失时怎么办。例如“字段缺失按普通流程处理，并单独记录”。
假设一个场景：你有一批旧页面，其中一部分正文很短，但历史上仍带来访问。你希望脚本跳过这些页面，避免误删。需求可以写成：当正文纯文本长度低于 300 字符且页面仍有内链指向时，不进入清理队列，改为输出到待确认清单。这里的数字只是示例阈值，实际取值要用你自己的数据分布来定。动作是先跑一遍只输出清单、不改动的干跑，看清单里误报多不多；如果误报集中在某类模板，就回到触发条件修正，而不是直接放宽动作。
一个会让结论失效的反例
上面这套写法有一个明确的反例：当例外本身来自旧合作关系或旧系统，而对方随时可能改变规则时，把规则写死进脚本反而更贵。比如旧接口的返回格式没有文档，只靠人工观察总结出的“偶尔多一个字段”，这种例外不适合固化成判断分支，因为触发条件不稳定，脚本会频繁误判。
这种情况下，正确做法是把例外降级为“采集 + 告警”，不自动处理。脚本只负责记录异常样本和出现频率，由人定期看。等异常模式稳定了，再升级成自动分支。判断标准很简单：如果同一例外在多次运行中触发条件变化超过你愿意维护的范围，就不要自动化。
用干跑结果决定下一步
写完例外需求后，不要直接上生产。先让脚本在只读模式下跑一遍，输出三类计数：正常处理数、例外命中数、兜底触发数。然后抽查例外命中样本，确认它们确实符合你的判断依据。
如果例外命中里混进了大量正常页面，说明触发条件太宽，回去收紧阈值或增加判断字段。如果兜底触发数很高，说明数据质量不够，先补采集再谈自动化。如果例外命中很少且抽查准确，才可以进入小范围执行，并保留回滚路径。这个顺序让每次改动都有依据，也避免一次误操作把仍有价值的部分一起清掉。
退出旧内容时例外怎么写
退出旧内容、旧系统或旧合作关系时，例外描述的重点是“保留仍有价值的部分”。需求里要明确：哪些页面进入退出队列，哪些因命中例外而保留，保留的依据是什么，保留多久后重新评估。
例如：旧专题页计划下线，但其中被其他页面持续引用的部分不删除，只移除推广模块并保留正文。例外条件写成“存在来自站内其他页面的有效内链”，动作是“保留正文，移除失效模块”，兜底是“内链数据缺失时按保留处理”。这样脚本不会因为一次数据采集失败就误删内容。执行后观察保留清单的变化，再决定是否扩大退出范围。
把例外写清楚，省下的不只是开发沟通时间，更是误删、误改之后的重建成本。先写条件，再写动作，最后写兜底，这三步顺序不要颠倒。
