如何做网站seo：把人工经验写成脚本需求时怎样描述例外情况

📍 WDQWDWQD987AAAAA:216.73.217.7
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f8fc1d56969e.html
📄

如何做网站seo：把人工经验写成脚本需求时怎样描述例外情况

直接回答：不要用“遇到特殊情况再说”这类描述，而要把每个例外写成“触发条件 + 判断依据 + 处理动作 + 后续影响”四段式。例如，人工判断某页标题过长时，脚本需求不能只写“标题超过32字就截断”，而要写“若标题超过32字且末尾是品牌名，则删除品牌名后再判断；若删除后仍超长，则保留原标题并标记待审”。这样脚本才知道何时停下、何时继续、何时交回人工。

先区分两类例外：可枚举的和需要判断的

你手里通常有一份人工处理记录，比如“检查了50个页面，发现12个标题过长，其中3个是因为品牌名重复，2个是因为栏目名堆叠，其余是纯描述过长”。把这12个例子逐个看一遍，会发现它们分成两类。

取舍条件：如果某类例外在人工记录中出现次数少，但每次都要花5分钟判断，优先写成“标记待审”；如果出现次数多且判断标准稳定，才写成自动处理。代价是，自动处理会漏掉边界情况，标记待审会增加人工工作量，但不会误改页面。

把例外写进脚本需求的四段式模板

以你正在处理的页面为例，假设人工经验是“有些页面标题太长，但直接截断会丢掉品牌名，所以我会手动调整”。这条经验不能直接写成“标题超过32字就截断”，因为脚本不知道品牌名在哪里、截断后是否可读。改成四段式：

  1. 触发条件：标题字符数大于32，且标题末尾20个字符内包含品牌词。
  2. 判断依据：品牌词是否在标题中出现两次；标题去掉品牌词后是否仍大于32字符。
  3. 处理动作：若品牌词出现两次，删除末尾一次；若删除后仍大于32字符，保留原标题并写入待审列表。
  4. 后续影响：待审列表中的页面不自动修改，由人工决定是否重写标题；脚本继续处理其他页面。

这样写的好处是，脚本遇到“标题超长且品牌名重复”时不会直接截断，而是先尝试删除重复品牌名。删除后如果仍然超长，它不会继续猜，而是停下并交回人工。下一步你可以根据待审列表的数量判断：如果待审页面很少，说明规则覆盖足够；如果待审页面很多，说明判断依据需要继续细化。

用假设例子验证例外描述是否可执行

假设你有一个页面，标题是“如何做网站seo：从收录到排名的完整检查清单 - 示例品牌”。人工经验认为这个标题偏长，但直接截断会丢掉“示例品牌”。按四段式描述，脚本先判断品牌词“示例品牌”是否出现两次——这里只出现一次，所以不触发删除动作；再判断去掉品牌词后标题是否仍大于32字符——去掉后仍然大于32字符，于是脚本保留原标题并标记待审。

这个假设例子说明：例外描述必须让脚本能做出“不处理”的决定。很多脚本需求只写了“超长就截断”，结果把品牌名截掉，反而需要人工回滚。加入“删除后仍超长则保留并标记”这一条，脚本的行为就从“强行修改”变成“有限尝试后交回”。

你可以用一个短检查清单验证：把人工记录里的每个例外拿出来，问自己“脚本能否只靠页面字段做出同样判断”。如果答案是否定的，就把这个例外写成待审，而不是写成自动规则。

例外描述里必须写清的三个边界

第一，数据缺失时怎么办。例如脚本要读取标题字段，但某页标题为空。需求里要写“若标题为空，跳过该页并记录原因”，而不是默认空字符串参与判断。第二，多个例外同时命中时的优先级。例如某页既标题超长又正文过短，脚本应先处理哪个？通常先处理影响页面可读性的那个，或者直接标记待审，避免两个自动动作互相覆盖。第三，例外处理后的复查方式。脚本跑完后，你需要抽查待审列表中的页面，确认标记原因是否准确。如果标记原因和人工判断不一致，说明触发条件写得过宽或过窄，下一步应调整条件而不是直接扩大自动处理范围。

一次改动前后比较时，要注意季节和搜索需求变化的影响。例如你调整了标题处理脚本，两周后某些页面点击率上升，这不能单独证明脚本处理正确，因为同期搜索需求本身可能变化。更稳妥的做法是保留一份未处理页面的对照清单，比较同类页面的表现差异，而不是只看改动页面的绝对值。

什么时候该把例外交回人工而不是继续加规则

当你发现同一条例外需要不断追加“如果……但是……除非……”时，说明它已经不适合写成脚本规则。例如标题重写涉及语义通顺、关键词自然度、品牌语气，这些判断很难用字段条件穷尽。此时正确的动作是：脚本只负责筛选出候选页面，输出标题、字数、品牌词位置等基础信息，由人工决定是否修改。代价是处理速度变慢，但避免了脚本批量改出不通顺标题后需要大面积回滚。

判断标准很简单：如果例外描述超过三行条件仍然无法覆盖你最近处理过的两个例子，就把它归入“标记待审”，而不是继续加条件。脚本需求的目标不是替代人工判断，而是把人工判断中稳定、可枚举的部分固定下来，把不稳定的部分明确交回。这样你下一步无论是扩大处理范围还是调整规则，都有清晰的依据。

图1 图2
nginx