图片SEO技巧，人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6ef3422a0f45.html
📄
图片SEO技巧，人工经验写成脚本需求时怎样描述例外情况
结论：把人工判断写成脚本需求，例外情况不能只写“特殊处理”，而要写成可判定的条件、可观察的证据和明确的默认动作。否则脚本只能覆盖常规路径，遇到边界样本时要么误改，要么静默跳过，你拿到的结果无法反推是规则错了还是数据本身特殊。
先确认例外属于哪一类，再决定写进脚本还是留给人工
人工处理图片时，经验往往藏在“这张看着不对”里。写成脚本需求前，先把它拆成三类：可量化条件、可枚举状态、只能主观判断的取舍。可量化条件适合直接写进脚本，例如图片宽度小于页面主内容区宽度、文件体积超过同组中位数的一定倍数、文件名与所在栏目主题完全不相关。可枚举状态适合写成白名单或黑名单，例如图片位于页脚、作者头像区、广告位、商品规格图区。只能主观判断的部分，比如某张配图是否真的表达了段落重点，不要硬塞进脚本，应输出候选清单交回人工。
一个实际动作是先抽一批样本，把每张图的处理动作和判断理由并排记录。如果同一理由在不同样本上导向不同动作，说明这个理由还不是可执行条件，需要继续拆细。这个动作的结果会直接决定下一步：能拆成条件就进入脚本规则，拆不动就保留人工复核环节，而不是让脚本猜。
例外描述必须带默认动作，不能只写“跳过”
很多脚本需求写到例外时只写“遇到异常跳过”。问题在于，跳过之后这张图既不进入处理队列，也不进入待确认队列，后续没人知道它被略过了。更可用的写法是给每个例外指定一个默认动作，例如保留原状并记录、降级为人工复核、或按最保守方案处理。
假设一个场景：脚本要批量补全图片的替代文本。规则可以写成，当图片位于正文且缺少替代文本时，按段落主题生成候选；当图片位于页脚或导航区时，不生成，直接标记为结构性图片；当图片同时出现在正文和推荐位时，以正文位置为准，推荐位复用同一结果。这里的“同时出现”就是例外条件，默认动作是“以正文为准”，而不是“跳过”。
这样写的好处是，脚本跑完后你能看到三类输出：已处理、按例外保留、待人工确认。下一步动作取决于哪一类数量异常，而不是凭感觉判断脚本有没有生效。
用反例检验规则：哪一种情况会让当前描述失效
任何一套例外规则都有失效边界。对图片SEO脚本来说，最常见的失效情况是同一张图在不同页面承担不同角色。比如同一张产品图，在分类页是列表缩略图，在详情页是主图，在帮助文档里是操作示意。如果脚本只按文件路径或文件名判断，就可能把三种角色当成同一种处理。
这时前面“按位置决定动作”的结论就会失效。失效的信号不是脚本报错，而是输出结果看起来都对，但人工抽查时发现某类页面的图片被统一改成了不合适的描述。要检验这一点，可以在规则里加一条反例测试：找出同一文件被三个以上不同模板引用的图片，分别检查脚本给出的动作是否一致。如果不一致且无法解释，说明位置判断的粒度不够，需要把模板类型也纳入条件。
这里要说明一个必要前提：上述判断依赖你能拿到图片引用位置和模板类型的数据。如果数据里只有图片地址，没有引用上下文，那么基于位置的例外规则无法成立，应先补数据，而不是先写更复杂的规则。
把例外写成可回滚的步骤，方便比较改动前后
脚本处理图片时，建议把例外动作设计成可逆的。具体做法是保留原值，把新值写在另一列或另一个字段，先不覆盖。这样你可以先比较处理前后同一批图片的差异，再决定是否正式应用。
比较时要注意，图片相关的表现变化可能同时受季节、内容更新频率和数据采集差异影响。某次改动后指标变化，不能单独归因于这次脚本处理。合理的做法是固定一批不处理的对照图片，和处理组在同一时间段观察，看差异是否稳定。如果差异只出现在个别页面，优先检查这些页面是否有其他改动，而不是直接调整规则。
下一步动作可以这样安排：先在小范围页面应用例外规则，导出处理清单和保留清单；人工抽查保留清单里是否有本应处理的图片；如果有，回到条件描述补充可判定依据，再扩大范围。这个顺序能让每次调整都有依据，而不是反复重写整段脚本需求。
交付脚本需求时，例外部分至少写清四件事
- 触发条件：什么数据状态下判定为例外，条件要能用字段或阈值表达。
- 默认动作：例外发生后是保留、标记、降级还是进入人工队列。
- 证据输出：脚本要留下什么记录，方便你回查为什么这张图被特殊处理。
- 失效反例：哪一类样本会让当前规则不成立，以及发现后先补数据还是先改规则。
把这四件事写进需求，人工经验才不会在转成脚本时被压成一句模糊的“特殊情况特殊处理”。你拿到的也不只是一次批量执行结果，而是一份能继续修正的判断依据。
