神马seo技巧，把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7317123ebbd0.html
📄
神马seo技巧，把人工经验写成脚本需求时怎样描述例外情况
结论先说：例外情况不能写成“特殊情况另行处理”，而要写成可判定的条件、可观察的信号和明确的分支动作。前提是这条经验已经有过至少一次人工执行记录，并且执行人愿意把当时的判断依据说出来。如果连人工执行时都靠“看着不对就停”，那它暂时还不适合写成脚本需求，先补记录比先写代码更有效。
为什么例外描述决定脚本能不能用
人工做优化时，很多判断是隐性的。比如看到某个页面标题和正文主题偏离，人工会跳过不处理；但“偏离”在脚本里必须变成可以核对的条件，否则脚本只能按统一规则执行，把不该改的页面一起改掉。
把例外写成可核对的项目，核心是把三种信息分开：
- 触发条件：什么情况下进入例外分支，例如字段缺失、多个角色对同一事实理解不一致、页面类型无法归类。
- 观察信号：脚本运行后能看到什么，例如被跳过的数量、被标记的条目、日志里出现的具体字段值。
- 分支动作：进入例外后是跳过、标记待人工确认，还是按另一套规则处理。
这三项缺一项，脚本需求就还停留在愿望层面。人工经验里“我一般会看一下”这种描述，对写脚本的人没有可执行价值。
多个角色理解不一致时，先统一哪一层
同一件事实，运营、编辑和技术经常各说各话。运营说“这个页面质量不行”，编辑说“内容完整”，技术看到的是“字段都有值”。这不是谁对谁错，而是三方在描述不同层次。
可行的做法是先把分歧落到一个可以核对的层级上。假设一个场景：三个人对某个页面是否应该进入优化名单有分歧。运营认为它没有搜索需求，编辑认为它内容合格，技术认为它字段齐全。此时不要争论“质量好不好”，而是把分歧转成三个可核对的问题：
- 该页面是否有对应的目标查询词，以及这个词是否在现有记录里出现过。
- 正文是否覆盖了该查询词对应的核心问题，且没有明显偏离。
- 标题、描述等字段是否完整，是否存在空值或重复。
这三个问题各自有可观察的答案。答案不一致的地方，就是例外条件应该写进去的地方。比如“有目标查询词但正文明显偏离”就应该进入人工确认，而不是直接改标题。
一个反例：什么情况下这套写法会失效
如果这条经验只执行过一次，而且执行人自己也说不清当时为什么那样判断，那么把它写成脚本需求会放大错误。脚本会把一次偶然判断固化成规则，后续所有页面都按这个规则处理，而人工原本会在第二次执行时修正判断。
另一个失效场景是例外条件本身依赖外部状态。比如“等搜索需求上升后再处理”，但搜索需求的变化没有稳定的观察窗口，脚本就无法判断什么时候该进入这个分支。这种情况下，例外应该写成“标记待确认”，而不是写成“等待某个条件满足后自动执行”。
把例外写进需求的具体动作
可以按下面的顺序处理。先让执行人用自然语言复述一次完整判断过程，记录每一步他看了什么、比了什么、最后决定做什么。然后把其中“看了什么、比了什么”转成字段和判断条件，把“决定做什么”转成动作。
动作示例：把一条人工经验整理成三列表格，第一列写触发条件，第二列写观察信号，第三列写分支动作。整理完后让另一个角色只看表格执行一次，如果他能做出和执行人相同的判断，说明例外描述基本可用；如果他频繁停下来问“这里什么意思”，说明还有隐性判断没有写出来。
这个动作的结果会直接影响下一步：表格能被执行，就可以进入脚本需求评审；表格不能被执行，就回到记录补充阶段，而不是继续往下写代码。
改完之后怎么判断例外条件是否合理
一次改动前后做比较时，要考虑季节、搜索需求变化和数据采集差异。某个页面被跳过，可能是因为例外条件生效，也可能是因为这段时间该查询词本身的需求在下降，或者数据采集口径发生了变化。这些解释都能造成同样的现象，不能只看一个数字就断定例外条件写对了。
更稳妥的做法是同时看两类信息：被例外跳过的条目清单，以及这些条目在人工判断下是否确实不该处理。如果清单里大部分条目人工看也认为该跳过，说明例外条件方向正确；如果清单里混进了大量本该处理的条目，说明触发条件写得太宽，需要收紧。
例外描述的目标不是让脚本完全替代人工，而是让人工只在真正需要判断的地方介入。把这一点写清楚，脚本需求才算完整。
