怎样建博客，把人工经验写成脚本需求时怎样描述例外情况

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

怎样建博客，把人工经验写成脚本需求时怎样描述例外情况

写脚本需求时，例外情况不能只写“遇到异常就跳过”，而要写清触发条件、替代动作和判断依据。对建博客这类流程，先判断例外是“可枚举的固定分支”还是“需要人工判断的模糊情况”：前者写进脚本条件，后者保留人工确认节点。

先分清两类例外，决定写进脚本还是留给人

建博客时的人工经验通常包含大量隐含判断，例如“标题太短就重写”“图片没说明就不发”“分类重复就合并”。这些经验写成脚本需求时，第一件事不是翻译成代码，而是判断例外的性质。

可枚举的固定分支，指触发条件能用字段或状态明确表达。例如文章缺少摘要、标签数量为零、发布日期为空，这类例外可以直接写成脚本判断。模糊情况则不同，例如“内容读起来像凑数”“分类名称虽然不同但语义重复”，这类判断依赖上下文，脚本只能标记出来，不能直接决定。

选择依据很简单：如果两个人看同一条数据会得出相同结论，就写进脚本；如果两个人可能给出不同结论，就保留人工确认节点。这个判断会直接影响下一步，因为把模糊情况硬写成脚本条件，通常会在运行后产生大量误判，反而增加清理成本。

可枚举例外：写成条件分支，并给出替代动作

假设你在建博客时规定：每篇文章必须有摘要、至少一个标签、一个分类。人工操作时，编辑会顺手补上；写成脚本需求时，不能只写“缺少就报错”，而要写清缺什么、补什么、补不了怎么办。

可以按下面的结构描述：

  1. 触发条件：摘要字段为空，或标签数量为零。
  2. 替代动作：摘要为空时，截取正文前若干字符作为临时摘要；标签为零时，保留分类但不自动生成标签。
  3. 停止条件：正文也为空时，不生成临时摘要，直接标记为待人工处理。

这里的实际动作是给每个例外配一个替代动作，而不是只给一个报错。替代动作的结果会决定下一步：如果临时摘要被采用，后续需要人工复核；如果直接标记待处理，脚本可以继续处理其他文章，不阻塞整批任务。

还要注意，例外描述里不要混入正常流程。例如“标签为零时自动从标题提取关键词”看似合理，但如果标题本身也是空的，这个动作就没有输入。例外情况要写成独立分支，避免和主流程互相依赖。

模糊例外：标记、隔离、人工确认，不直接改写

另一类例外无法用简单字段判断。例如人工经验里有一条“分类重复就合并”，但脚本很难判断“技术”和“开发”是否重复。这时更稳妥的做法是让脚本输出候选，而不是直接执行合并。

可以这样描述需求：

这个选择的条件是：例外涉及语义判断、影响面较大、或者一旦改错难以回退。建博客时，分类、固定链接、导航结构都属于影响面较大的部分，适合先标记后确认。相比之下，补摘要、补标签这类局部字段，影响面小，可以直接用替代动作处理。

实际动作是先隔离，再确认。隔离的结果会影响下一步：如果待确认列表很短，人工可以逐条处理；如果列表很长，说明判断条件写得太宽，需要回到脚本需求里收紧触发条件，而不是继续人工清理。

用假设例子检查例外描述是否够用

假设你写了一条需求：“文章没有标签时，自动从正文提取三个词作为标签。”这条描述看起来完整，但没有说明例外。可以补上：

这个假设例子的作用是检查例外是否覆盖了输入为空、结果重复、结果无效三种情况。数字只用于说明比较方法，不代表真实阈值。真正建博客时，阈值应根据自己的内容规模和人工复核成本调整。

如果脚本运行后，待处理数量突然增加，不能直接认定是例外条件写错了。搜索需求变化、内容来源变化、采集字段缺失，都可能导致同一现象。比较改动前后时，要尽量保持其他条件一致，并考虑季节和来源差异，避免把相关当成因果。

把例外写进需求文档的检查顺序

最后给一个可执行的检查顺序，帮助你在建博客时把人工经验转成脚本需求：

  1. 先列出人工操作中所有“如果……就……”的判断。
  2. 逐条标记为可枚举或模糊。
  3. 可枚举的写触发条件、替代动作、停止条件。
  4. 模糊的写标记方式、隔离位置、人工确认入口。
  5. 用一个假设输入跑一遍描述，检查是否有空输入、重复结果、无效结果未覆盖。

完成这一步后，再决定哪些例外进入脚本、哪些留给人。这个决定不是一次性的，脚本运行后如果待处理列表持续过长，说明部分模糊例外可能需要重新拆解成更细的可枚举条件；如果待处理列表过短但错误未被发现，则要检查标记条件是否过宽。例外描述的目标不是让脚本替人做所有判断，而是让需要人判断的地方清晰可见。

图1 图2
nginx