怎样创建自己的博客：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /615dafa7e749.html
📄
怎样创建自己的博客：把人工经验写成脚本需求时怎样描述例外情况
先给结论：不要试图在一条需求里穷举所有例外，而是把例外分成三类——保留人工判断、改写成可验证的规则、直接退出自动化。判断依据不是例外多不多，而是这个例外能否用你手头已有的数据字段稳定识别出来。能识别就改写，识别不了就保留人工，识别出来但处理成本高于收益就退出。
先分清“样本例外”和“规模化例外”
你在创建博客、批量处理文章时，往往先拿几篇样本试跑，跑通了就以为规则成立。但样本阶段成立和规模化后成立是两回事。常见原因是：样本恰好都是结构规整的文章，而真实数据里混着草稿、转载、旧格式、缺字段的条目。
写脚本需求前，先做一个动作：把最近一批真实数据按“是否触发过人工干预”打标，统计每类干预出现的条目数。如果某类干预只出现在极少数条目上，且这些条目共享一个稳定字段（比如某个固定标记、某个固定栏目），那它属于可改写；如果干预原因每次都不一样，那它属于保留人工。这一步的结果直接决定你后面写“保留”还是“改写”，而不是凭感觉选。
保留人工：例外无法用现有字段稳定识别时
保留不是偷懒，而是承认当前数据不足以支撑自动判断。适用前提有三个，满足任意一个就该保留：
- 例外原因每次不同，没有共同字段可以筛选。
- 误判代价高，比如误删、误改会影响已发布内容。
- 这类条目占比很低，自动化省下的时间抵不上维护规则的精力。
在需求里怎么写：不要写“特殊情况人工处理”，这句话等于没写。要写成可执行的交接条件，例如“当条目标题与正文首段主题词不一致，且无法从现有字段判断归属时，输出到待人工队列，并附上原始字段快照”。这样接手的人知道看什么、判断什么。保留人工的结果是：脚本不处理这类条目，你的下一步是评估这些条目是否值得单独建一个字段来识别，而不是继续扩大规则。
改写规则：例外能用字段识别，但需要缩小适用范围
改写的前提是：你能用一个明确条件把例外圈出来，并且圈出来之后，剩下的条目规则依然成立。比如你原本的规则是“所有文章统一处理标题”，但发现带某种固定前缀的文章不能照搬。这时不是放弃规则，而是把需求改成“除带该前缀的条目外，其余按原规则处理；带前缀的条目走另一条分支”。
写需求时要写清三件事：判断条件、命中后的动作、未命中时的动作。判断条件必须是你实际能取到的字段，而不是“看起来像”“感觉不对”这类描述。命中后的动作要具体到输出什么、写到哪。未命中时保持原逻辑，避免规则互相覆盖。
这里有个容易忽略的点：缩小适用范围后，规则覆盖的条目变少了，你要重新确认剩下的条目是否还值得自动化。如果缩小后只剩很少条目，那这条规则可能应该并入“保留人工”。
退出自动化：处理成本高于收益，或规则本身不稳定
退出不是失败，而是一种取舍。适用前提：例外占比高到规则频繁触发分支，或者每次数据更新后规则都要重调。这种情况下继续维护脚本，成本会持续累积。
判断方法可以这样假设：假设你每月处理一批数据，其中需要人工干预的条目占比很高，且每次干预原因都在变。那么即使脚本能跑，你每月花在调规则上的时间也可能超过直接人工处理。此时退出的实际动作是：把脚本降级为“只做初步分组”，把判断交回人工，并在需求文档里注明退出条件和重新评估的触发点，比如“当某类例外连续多批消失，再考虑恢复自动化”。
退出后的下一步不是放着不管，而是记录每次人工干预的原因。积累一段时间后，你可能会发现某个原因反复出现，那时它就从“无法识别”变成了“可以用字段识别”，可以重新走改写路线。
写需求时怎么描述例外，才不会被误读
避免三类写法：一是“特殊情况特殊处理”，没有可执行内容；二是“尽量”“酌情”，无法验证；三是把多个例外塞进一条规则，导致命中条件互相干扰。
可用的写法是分条列出，每条包含：触发条件、命中动作、未命中动作、该条目的后续归属。触发条件尽量用可观测的字段或明确的文本特征描述，不用主观词。这样写出来的需求，无论是自己后续维护还是交给别人执行，都能对照检查，而不是靠猜。
最后提醒一点：例外描述写完不等于一劳永逸。数据格式会变，新的例外会出现。所以需求里应留一个“重新评估”的位置，说明什么情况下需要回头看这些例外分类，而不是假设一次写清就永久有效。
