怎么创建自己的博客：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /93db53b32c4f.html
📄
怎么创建自己的博客：把人工经验写成脚本需求时怎样描述例外情况
把人工经验写成脚本需求时，例外情况不能只写“遇到特殊情况就跳过”，而要写清三件事：触发条件、脚本应执行的动作、动作完成后下一步依据什么继续。触发条件越像人工判断，脚本越容易误判，所以优先把例外拆成可观察的信号，再决定是让脚本自动处理还是转人工。
先假设一个场景：批量整理旧文章时的人工例外
假设你新建了一个博客，准备把旧平台导出的几十篇文章重新整理成统一格式。人工操作时，你看到一篇没有日期的草稿，会打开草稿箱确认发布时间；看到一篇正文只有图片的短文，会保留原文并加一句说明；看到标题里带着旧栏目名，会手动删掉栏目前缀。现在要把这些经验写成脚本需求，最容易漏掉的不是正常流程，而是这些人工临时决定。
如果需求里只写“无日期文章按导入时间处理”，脚本会把草稿的导入时间当成发布时间，结果草稿被当成已发布内容。这个偏差不会立刻报错，但会影响后续按时间排序和目录生成。例外描述的价值就在这里：它让脚本在无法确定时停下来，而不是替你做决定。
两种写法需要取舍：枚举信号还是转人工
描述例外时通常有两种做法。第一种是把例外拆成可观察信号，让脚本自动处理；第二种是遇到不确定就转人工，脚本只记录原因。两种都成立，但适用条件不同。
- 枚举信号适合例外数量少、信号稳定、后果可逆的情况。比如正文为空、标题重复、日期格式明显不符合预期。这类例外可以用固定规则判断，误判代价低，脚本自动处理能节省时间。
- 转人工适合例外数量多、信号模糊、后果不可逆的情况。比如一篇文章同时缺日期、缺作者、正文只有图片，还带着旧栏目名。脚本很难判断该保留哪部分，强行处理可能覆盖原始信息。
取舍的依据不是哪种更先进，而是误判后能不能恢复。如果原始文件还在、处理结果可回退，可以先让脚本自动处理；如果处理会覆盖唯一副本，就应转人工并记录原因。
例外描述至少包含哪几个字段
无论选哪种做法，例外描述都应包含四个字段：触发条件、判断依据、执行动作、下一步。触发条件写脚本看到什么；判断依据写为什么认为这是例外；执行动作写跳过、标记还是转人工；下一步写动作完成后继续处理下一条，还是等待人工确认后再继续。
假设需求里写“遇到无日期文章就跳过”，脚本可能跳过整篇，连正文也丢失。如果改成“正文长度大于零但日期字段为空时，标记为待确认，保留原文，不进入发布队列”，脚本的动作和下一步就明确了。人工确认后，再把确认结果写回，脚本才知道这类文章可以继续处理。
一个可执行动作：先做例外清单再写规则
实际动作可以这样安排：先人工处理十篇旧文章，每遇到一次临时决定就记一行，写清当时看到什么、为什么这样处理、处理完继续做什么。十篇处理完后，把记录按触发条件归类，能合并的合并，不能合并的单独列出。然后拿这份清单去写脚本需求，而不是先写正常流程。
这个动作的结果会直接影响下一步：如果清单里大部分例外都能归到三四个稳定信号，就可以先写自动规则；如果每篇的例外都不同，说明人工经验还没有稳定到可以脚本化，应先继续人工处理，或把脚本范围缩小到只做格式转换，不碰日期和栏目名。
验证例外描述是否够用，要看误判后的恢复路径
写完需求后，不要只检查正常流程能否跑通，还要检查例外触发后能否恢复。假设脚本把一篇草稿标记为待确认，人工确认后能否只改这一篇而不影响其他文章？如果脚本已经批量覆盖了原始文件，恢复路径就不存在，例外描述再详细也无法补救。
一次改动前后的比较要考虑季节、搜索需求变化和数据采集差异，不能只凭某天请求量或抓取量归零就判断处理正确。请求量下降也可能来自采集延迟、站点调整或外部需求变化。例外描述的目标不是让脚本永不犯错，而是让错误发生时你能定位到哪条规则触发、影响哪些文章、下一步该改规则还是改人工流程。
