词雷达一天刷出几百条，先别急着怀疑抓取能力，多数情况是两处配置拧得太松：监测词写成了宽泛词，扫描间隔又设得很短。宽泛词是“包含即报”，短间隔会让同一批内容反复进入候选池，两条叠在一起，输出量自然压不住。可以按“先收紧词表、再拉长间隔、最后用日志和两次运行结果核对”的顺序处理，把每天的条数压到自己能读完的量，再谈要不要放宽。
词雷达产出失控，通常不是扫描器太强，而是词表太宽加间隔太短：宽泛词把大量无关条目拉进来，短间隔让重复内容反复入库。建议先把监测词从单词换成可判定的限定词组，并在配置里固定扫描间隔和单次抓取上限；改完手动执行一次，看日志确认配置被读到，再用两个间隔各跑一次，对比输出条数、去重后新增和人工可读性再定值。词表每次改动都要留成可回滚的版本，否则越调越乱。
先把监测词表从宽泛词换成可判定的词组
宽泛词的问题不在于命中不准，而在于没有判定条件。一个单词既能命中正面讨论，也能命中招聘、课程、转载和旧文重发，扫描器无法区分，只能全部交给你看。限定词组的作用是把“包含即报”改成“满足组合条件才报”，让每一条命中都有可复述的理由。
| 原来的宽泛词 | 换成的限定词组 | 命中差别 |
|---|---|---|
| 涨价 | 涨价 运费 / 涨价 物流 | 宽泛词会连行业评论、历史回顾一起收进来；限定词组只保留同时出现业务词的条目，判定条件单一 |
| AI | AI 客服 上线 / AI 客服 接入 | 单词命中量大且杂；加上落地动作词后，剩下的基本是可用于跟进的事件 |
| 离职 | 离职 高管 并加排除词 招聘 培训 课程 | 宽泛词会把招聘贴和课程广告带进来；排除词把这类版式固定的内容挡在入库前 |
写法上有两点要注意。一是词组里的词要能在正文里自然共现，靠得太死的组合容易一条都命中不到，可以先跑一次看命中量再决定是收紧还是放宽。二是排除词优先挡版式固定的内容，比如招聘、课程、报名、转载声明这类，比事后人工筛省力得多。
在配置里设置扫描间隔和单次抓取上限
词表决定“能命中什么”，间隔和上限决定“一次交给你多少”。两个参数一起设，才不会出现词表收紧了、条数还是很多的情况。下面只是通用骨架，字段名以你所用项目的实际配置为准，替换成对应键名后再使用。
# 通用骨架，字段名以项目实际配置为准
scan:
interval: 6h # 扫描间隔，按项目支持的写法填 30m / 6h / 1d
max_items_per_run: 50 # 单次运行最多入库条数
dry_run: false # 先设 true 只打印不写入
watch_terms:
include:
- "涨价 运费"
- "AI 客服 上线"
exclude:
- "招聘"
- "课程"
output:
dedup: true # 同一条目重复命中时只保留一次
dedup_window: 7d # 去重时间窗，按项目支持的时间写法填单次上限是兜底，不是目标值。设成比“一天能看完的条数”略高的数，正常情况不会触发；一旦频繁触顶，说明词表还需要继续收，而不是把上限往上调。间隔建议从偏长的一侧开始，先保证不漏掉真正要跟的事件，再逐步缩短。
手动执行一次，看日志确认配置被读到
改完配置最常见的失败是“改了但没生效”：配置文件路径不对、被环境变量覆盖、或者进程还在用旧配置。最省事的验证方式是手动跑一次单次执行入口，不要让后台常驻进程替你做这件事。
# 入口命令和参数以项目实际提供为准，这里只示意执行形态
<项目入口命令> `--once` `--config` conf/radar.yaml `--dry-run`启动后的前几行日志里，通常应该能看到配置来源和关键参数被读出来的记录，形式类似下面这样：
loaded config from conf/radar.yaml
scan.interval = 6h
scan.max_items_per_run = 50
watch_terms.include = 2, watch_terms.exclude = 2
dry_run = true, matched = N, written = 0逐项核对：配置路径是不是你改的那份文件，间隔和上限的数值是不是新值，include/exclude 的条目数对不对。如果日志里没有这类读取行，说明项目没打印配置摘要，可以先用 dry_run 输出的命中预览反推——预览里出现的词条数和词表条数对不上，多半是配置没被读到，此时不要继续调词表，先解决加载路径问题。
对比两个间隔下的结果差异再定值
间隔定多少，不要凭感觉。选两个候选间隔各跑一次，把结果记下来对照，比反复改配置试错更可靠。记录时至少填这几列，数字以实际运行日志为准，不要估。
| 运行 | 扫描间隔 | 单次输出条数 | 去重后新增 | 人工可读性 | 是否可用 |
|---|---|---|---|---|---|
| 第 1 次 | 较短间隔（如 1h） | 填写日志中的 matched 数 | 填写去重后实际写入数 | 是否能当天看完，有无大量重复 | 可用 / 偏多 |
| 第 2 次 | 较长间隔（如 6h） | 填写日志中的 matched 数 | 填写去重后实际写入数 | 是否能当天看完，有无漏跟 | 可用 / 偏少 |
判断顺序建议是：先看两次运行人工能不能读完，再看去重后新增和输出条数的差距。差距大说明间隔太短、重复内容多，加长间隔通常比调词表更直接；差距小而条数依旧多，说明问题在词表，回去继续收紧限定词组。定下来的间隔要能长期坚持——取决于你能多快处理这些条目，而不是扫描器最快能跑多快。
把词表变更记成可回滚的版本
词表一旦开始调整，很容易出现“改了几轮，最初能用的版本找不回来”的情况。把配置文件和词表纳入版本管理是最省事的做法；如果暂时不方便，至少在每次改动前留一份带时间戳的副本，例如 conf/radar.yaml.20240101-1200.bak，文件名里的时间以实际操作为准。
每次改动记一行，字段不用多，够回溯就行：
- 时间：改动发生的日期和时间
- 改动内容：具体到词条或参数，例如新增
AI 客服 接入、间隔由 1h 改为 6h - 原因：因为哪类噪声或漏跟而改，一句话即可
- 操作人：谁改的，多人共用词表时必须有
- 回滚方式：对应的提交号或备份文件名
回滚动作本身要简单可执行：用版本管理时，恢复到上一个可用版本或反向提交对应改动；用副本文件时，把备份文件覆盖回去并重启进程，重启后再按前面一次手动执行的方式看日志确认配置被读到。不能在没验证的情况下认为回滚已经生效——词表和间隔都在配置里，回滚后不重新加载，跑的还是旧值。