如何网络宣传：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5397ca521884.html
📄
如何网络宣传：把人工经验写成脚本需求时怎样描述例外情况
先把例外情况写成“触发条件 + 期望动作 + 可核对结果”三行，再交给写脚本的人。人工经验里最容易被漏掉的不是常规流程，而是那些“看情况”的瞬间；如果只写“遇到问题就跳过”，脚本执行者无法判断该跳过、该停下还是该记录后继续。下面以一份手工整理的页面资料为对象，逐步把分歧转成可核对的方案。
先找出人工经验里最含糊的三种句子
把操作者的口述整理成文字后，通常会出现三类含糊表达。第一类是判断类，例如“标题看起来不相关就换掉”；第二类是程度类，例如“内容太短就补一段”；第三类是兜底类，例如“其他情况按常规处理”。这三类句子直接写进脚本需求，执行者只能凭自己的理解补全，结果就是同一份资料被处理成不同样子。
处理办法是逐句追问：你当时看到了什么具体信号，才做出这个判断？把回答里的名词和数值记下来。例如“标题看起来不相关”可能对应“标题没有出现资料主题词，且首段也没有出现”。这一步不追求一次写全，只要求把已经能说清的部分先固定下来。
把“看情况”拆成触发条件与默认动作
每个例外都写成一条独立规则，格式固定为：当满足什么条件时，执行什么动作，留下什么记录。触发条件尽量用资料中客观存在的内容描述，例如字段是否为空、文本是否包含某个词、同一资料是否出现两个互相矛盾的取值。默认动作只能从有限选项中选：跳过并记录、停下等人确认、按主规则执行但标记异常。
假设一份资料里同时出现两个不同的联系时段，一个来自页面正文，一个来自页脚。人工处理时可能“以正文为准”，但脚本需要知道：如果两者不一致，是取正文、取页脚，还是标记为冲突后不写入。把这三个选项写清楚，执行者才能做出与操作者一致的选择。这里的关键不是选哪个更对，而是让选择可复核。
用一份资料做对照，验证规则是否可执行
规则写完后，不要直接进入批量处理。先拿一份已经人工处理过的资料，按新规则重新走一遍，比较两边的结果。比较时重点看三处：触发条件是否真的被命中、默认动作是否产生预期结果、异常记录是否足够让人回查。如果规则在这份资料上产生的结果与人工结果不同，先判断是规则写错了，还是人工当时做了规则之外的临时决定。
这个动作的结果会直接影响下一步：如果差异来自规则本身，就修改规则再测一份；如果差异来自人工临时决定，就把这个决定补成一条新的例外规则，或者明确写下“这种情况不纳入脚本，保留人工处理”。两种处理都成立，区别在于前者扩大脚本覆盖范围，后者控制脚本复杂度。
把分歧转成可核对的项目，而不是继续争论
多个角色对同一事实有不同理解时，争论往往停留在“应该怎样”。更有效的做法是把分歧写成一张核对项：同一份资料、同一个字段、两种不同取值，分别对应什么处理结果。谁主张哪种处理，就由谁指出在资料中看到的具体依据。这样讨论的对象从观点变成证据，也方便后续复查。
- 把每个例外规则编号，方便在讨论和修改时指代。
- 在规则旁注明它来自哪次人工处理或哪份资料，便于追溯。
- 对暂时无法统一的例外，明确写成“停下等人确认”，不要留空。
- 规则变更后，重新用同一份对照资料验证，避免只看新规则不看旧结果。
改动规则后，怎样判断变化来自规则本身
规则调整前后，处理结果可能变化，但变化不一定来自规则。资料的构成、处理时段、人工介入次数都会影响观察到的结果。比较时尽量保持对照资料不变，只改一条规则，并记录改动前后的差异。如果同时改了多条规则，或者换了一份差异很大的资料，就很难判断是哪一处改动起了作用。
还要注意，某条规则命中次数下降，不等于规则失效。可能是资料本身变了，也可能是上游筛选条件变了，甚至只是这次抽到的样本恰好不同。把命中次数、跳过次数、停下确认次数分开记录，比只看一个总数更容易发现原因。一次改动后不必急于下结论，先确认规则在对照资料上的表现是否符合预期，再决定是否扩大到更多资料。
最终交付给写脚本的人时，除了规则清单，还应附上那份对照资料和人工处理结果。这样对方遇到模糊之处，可以回到具体资料上核对，而不是继续猜“看情况”到底指什么。规则可以逐步完善，但每一条例外都应当能回答：什么条件下触发、触发后做什么、做完留下什么可核对的结果。
