百度凤巢优化技巧：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a8446b21b458.html
📄
百度凤巢优化技巧：把人工经验写成脚本需求时怎样描述例外情况
例外情况不要写成“特殊处理即可”，而要写成“当某个可观察条件成立时，脚本走哪条分支、记录什么、由谁复核”。人工经验里最值钱的部分往往不是主流程，而是老手看到某个信号后临时改判断。脚本需求如果只描述主流程，执行结果会和人工预期分叉。下面给出两种条件下的不同写法，以及一个假设例子说明动作和下一步。
先判断例外属于哪一类：数据缺失，还是判断分歧
两种例外在脚本里的处理方式完全不同。数据缺失是指字段为空、接口返回异常、记录重复或时间戳错位；判断分歧是指两个角色对同一事实有不同理解，比如运营认为某条计划应暂停，优化师认为还应观察。前者可以用if missing then hold这类分支挡住，后者必须先把分歧转成可核对的字段，再决定脚本是否执行。
选择依据是：如果例外能被一条查询或一次字段比对复现，就归入数据缺失；如果复现时两个人仍会给出不同结论，就归入判断分歧。把判断分歧硬写成数据缺失，脚本会频繁进入等待状态，人工反而要花更多时间解释；把数据缺失写成判断分歧，脚本会继续执行并产生无法追溯的改动。
条件一：例外可复现时，写成守卫条件和退出动作
当例外能通过固定字段组合复现，脚本需求里应给出三段：触发条件、执行动作、退出条件。触发条件要写清楚字段名、比较方式和边界，例如“当计划状态为暂停且过去一个统计周期内无消耗记录时”。执行动作要写脚本做什么，例如“跳过出价调整，仅写入待复核标记”。退出条件要写什么情况下恢复主流程，例如“当该计划重新出现消耗记录，或人工清除标记后”。
实际动作是：把人工经验中“这种情况先别动”的句子，改写成一条可查询的守卫条件。结果会直接影响下一步——如果守卫条件写得太宽，脚本会挡住本应执行的正常计划；如果写得太窄，例外会漏进主流程，事后只能靠人工回滚。判断宽窄的方法不是看感觉，而是拿一段历史数据回放：假设过去一个月里有若干条计划满足该条件，看其中多少条人工当时确实选择了不动。这个比例只用于比较条件松紧，不表示脚本上线后的效果。
条件二：例外是判断分歧时，先转成可核对的项目
当两个角色对同一事实理解不同，脚本需求不能直接写“按运营意见处理”或“按优化师意见处理”，否则等于把分歧藏进代码。更稳的做法是先建立一个核对项目，把分歧拆成几个可独立确认的字段，例如：计划当前状态、最近一次人工操作时间、该操作由谁发起、操作前后的消耗记录是否存在、暂停原因是否已填写。
这些字段的作用不是自动裁决谁对，而是让双方对着同一组记录说话。假设一个例子：运营认为某条计划已暂停，优化师认为仍在投放。脚本需求可以先写成“读取计划状态字段并记录读取时间；若状态字段与人工操作日志不一致，则输出差异清单，不自动调整出价”。这个动作的结果是产生一份差异清单，下一步由人工确认是状态同步延迟、操作日志缺失，还是双方看的统计周期不同。只有确认原因后，才把对应分支写进脚本。
这里要避免一个常见错误：把“不一致”直接当成“数据错误”并触发修正。不一致还有别的合理解释，比如两个角色查看的时间范围不同、一方看的是计划层级另一方看的是单元层级、或者某一方引用了尚未同步的报表。统计上的差异不能单独证明哪一方正确，也不能证明脚本该自动改。
脚本需求里必须写清的例外描述格式
无论例外属于哪一类，描述时至少包含以下五项，缺一项就可能在执行时产生歧义：
- 触发对象：例外发生在计划、单元、关键词还是创意层级，不要只写“账户里”。
- 可观察条件：用字段和比较关系表达，不用“效果差”“不正常”这类主观词。
- 脚本动作：跳过、记录、标记、通知还是继续执行，要明确写出来。
- 记录内容：脚本留下什么证据，例如命中条件的对象标识、命中时间、当时字段值。
- 复核责任：谁在什么情况下查看记录并决定下一步，不写“相关人员”。
这五项写完后，可以让不参与人工经验的人读一遍，看能否在不问原作者的情况下判断脚本会做什么。如果读的人仍需追问“那这种情况到底改不改”，说明例外描述还没落到可核对的项目上。
改完脚本需求后，怎样判断分歧是否真的减少
把需求交给开发或配置之前，先做一次纸面回放：挑几条曾经引发争论的记录，按新写的条件逐条判断脚本会走哪条分支，再和人工当时的实际处理对照。对照结果分三种：一致、脚本更保守、脚本更激进。更保守意味着可能漏掉本应执行的调整，更激进意味着可能产生人工不会做的改动。两种都需要回到条件描述里调整，而不是直接上线后再补。
上线后比较改动前后时，要考虑季节、搜索需求变化和数据采集差异。同一账户在不同周期的消耗波动，可能来自市场变化而非脚本分支；某段时间例外命中次数归零，也可能是统计口径变化、日志延迟或复核流程绕过脚本，不能单独证明例外处理已经正确。更可靠的做法是保留命中记录和人工复核记录，按同一口径对照，而不是只看一个总数。
最后一步是把确认过的例外分支写回需求文档，并注明它来自哪次分歧、由谁确认。这样下一次有人问“为什么脚本在这里要停一下”，答案不在某个人的记忆里，而在可核对的条目里。
