百度指数使用方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0d87aef48c02.html
📄
百度指数使用方法：把人工经验写成脚本需求时怎样描述例外情况
人工看百度指数时能靠直觉跳过异常，脚本却会照单全收。写需求时，例外情况不能只写“特殊情况另行处理”，而要写成可判断的条件和明确的动作：命中条件时保留、改写还是退出，并说明这个动作会怎样改变下一步。缺少完整数据或接口权限时，仍然可以先定义最小可执行动作，但只能验证逻辑是否自洽，不能据此推断真实搜索需求的变化。
先区分三类例外，不要混在一个“其他”里
人工经验里最容易被省略的，是判断依据本身。写脚本需求时先把例外拆成三类，每类的处理前提不同。
- 数据形态例外：某个词在某天没有数值、数值为0、或只有部分日期有值。这不等于需求消失，也可能是采集缺口、词本身太窄、或统计口径变化。
- 业务语义例外：词本身带有歧义，例如同时指向品牌、地名或泛需求。人工会凭上下文跳过，脚本需要写明依据什么字段判断。
- 执行环境例外：缺少登录态、权限不足、请求被限制。这类例外影响的是能否取到数据，不改变对词本身的判断。
把这三类混成一个“异常”分支，脚本最终只能全部丢弃或全部保留，两种都会让后续分析失真。
保留、改写、退出各自成立的前提
面对一个例外，三种动作不是按优劣排序，而是按前提选择。
保留：当缺失本身携带信息时
如果某个词的指数长期为0但业务上确实存在，保留它并标注“低量待观察”比直接删除更有用。适用前提是：你有其他来源能旁证该词有需求，例如站内搜索词或客服记录。此时保留的目的是留待后续比较，而不是断言它一定会涨。
改写：当问题出在描述方式而非词本身时
例如脚本按整词匹配取数，但人工经验里会把词拆成核心词加修饰词分别看。此时应改写需求：把“取该词指数”改成“取核心词指数，并记录修饰词组合”。适用前提是你清楚改写后比较的仍是同一类需求，否则前后数据不可比。
退出：当继续处理只会放大错误时
如果某类词在多次采集中都呈现互相矛盾的值，且无法判断哪个可信，退出并记录原因比强行取平均更稳妥。退出不等于删除，而是把该词移入待人工复核列表，让下一步动作变成“补充依据”而不是“继续计算”。
用条件加动作写，而不是用形容词写
“数据异常时跳过”无法执行，因为“异常”没有边界。可执行的写法是把条件写成可判断的表达式，再绑定一个动作和一条记录。假设一个场景：脚本需要判断某词当日指数是否可用，可以写成如下伪代码。
if 当日指数缺失 and 前7日有值: 动作=保留并标记待观察; 下一步=纳入趋势对比
if 当日指数为0 and 该词属于长尾修饰组合: 动作=退出; 下一步=转入人工复核列表
这里的关键不是代码本身，而是每个条件后面都跟着“下一步会怎样”。如果动作只是丢弃，后续就无法区分“本来就没需求”和“这次没取到”。注明假设：以上阈值只是示例，实际取值应依据你自己的数据分布确定，不能照搬。
缺少权限时能做的最小动作和不能推出的结论
没有完整数据或接口权限，仍然可以先做两件事：一是把例外条件写成清单并用历史人工记录回测，看有多少条能被现有规则覆盖；二是对无法覆盖的部分标注“依据不足”，而不是补一个猜测值。
能得到的结论是：规则本身是否自洽、分支是否互斥、动作是否可追溯。不能得到的结论是：真实搜索需求涨了还是跌了、某个词是否值得投入、以及改动之后多久会看到变化。一次改动前后的差异还可能来自季节、搜索需求本身的波动和数据采集方式的差异，这些因素不能单独归因于你的处理规则。
一个可操作的取舍顺序
- 先列出人工判断时实际看过的字段，哪怕只是日期、词形和数值三项。
- 把每个例外写成“条件—动作—下一步”三列，缺少任何一列就说明需求还没写完。
- 对无法判断的例外统一走退出分支，并保留原始记录，避免后续无法回溯。
- 用一批已知的人工处理结果对照脚本输出，只检查分支是否一致，不检查数值是否好看。
这样做的结果是：脚本不会替你做业务判断，但会把判断依据固定下来。下一次数据不完整时，你能明确知道哪些词是规则主动放弃的，哪些只是暂时没取到，从而决定是补数据还是改规则。
