接入新规则集后一次跑出 1240 条 warning，其中 no-explicit-any 占 900 条。三周后 CI 日志里 warning 还在，但没人再看，两个真实的未使用变量也一起被埋了。乍看像缓存或者权限的锅，追下去往往不是。
npx eslint . -f json | jq '[.[].messages[]|select(.severity==1)] | length' npx eslint . --max-warnings 0
追下去是这么回事：规则一次性全开，历史代码的存量问题把新问题淹了。告警没有分级，warning 不阻断构建，自然没人处理。
「规则噪音」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。
具体做法是，先只开 error 级别的规则 warning 单独统计；存量问题加 ignore 文件 逐步清零 不要一次全改；新增代码不允许新增 warning 用 diff 检查；每周看一次 warning 总数 只降不升。
验收就看一点，新增 PR 的 warning 数为 0，仓库 warning 总数每周下降，CI 里没有需要人工忽略的提示。