装好 last30days-skill 之后，第一件事不是把能想到的平台全填进配置跑全量，而是先确认两件可以被验证的事：工具实际认哪些来源键名，以及一次任务的时间窗和单源上限该开多大。这两项没对齐，跑完拿到的结果里大半会是和话题无关的旧帖、转载和短回复。下面这套流程按「改配置 → 跑一次 → 看日志 → 看落盘 → 存快照」推进，每一步都有可观察的输出来判断范围是否合理。

适用场景：首次接入 last30days-skill、准备抓跨平台评论做话题梳理。操作动作：先只启用一到两个来源，时间窗压到 1 天跑通链路，再逐步放宽到目标窗口。验证方式：以请求日志里的状态码与 items 条数、落盘文件的 topic/source/published_at 三个字段是否有值为准，而不是凭结果文件大小判断。风险边界：字段名和参数名随版本变化，本文骨架需要按本机 `--help` 与默认配置文件替换，不要直接照抄上线。

在配置文件里逐项核对来源字段

last30days-skill 的 sources 段通常按「来源类型 + 站点标识」两层组织。name 是工具内部识别的键名，有固定取值，不能当成备注随意起名；key 才是站点或平台标识。先把默认配置或 `--help` 列出的键名抄下来，再决定启用哪几个，避免自己发明一个键名然后被静默忽略。

# config.example.yaml —— 字段名以本机版本为准
sources:
  - name: forum        # 社区/论坛类来源，键名需与工具内置列表一致
    enabled: true
    key: "<站点标识>"
  - name: video        # 视频平台评论区
    enabled: false
    key: "<平台标识>"
  - name: social       # 社媒帖子与回复
    enabled: true
    key: "<平台标识>"
window:
  days: 30             # 时间窗，单位天
limits:
  per_source: 200      # 单源条数上限

写错的典型表现是「不报错但没数据」：日志里出现 unknown source、source not found 或 skipping disabled source，或者配置里写了某个来源却完全没有对应的请求行。遇到来源条数为 0 而其他来源正常时，先回配置核对 name 是否拼错、enabled 是否为 true、key 是否为空，再怀疑接口本身。

用最小时间窗跑一次并看请求日志

把时间窗压到一天，只留一个来源，先确认链路能打通。命令入口按实际安装方式替换，下面的写法只是参数骨架：

python -m last30days_skill run \
  `--config` ./config.example.yaml \
  `--topic` "产品改名" \
  `--window-days` 1 \
  `--dry-run`

日志里要盯三类行：请求行（打到哪个接口）、结果行（该接口返回多少条）、过滤行（时间窗内保留多少条、丢弃多少条）。例如 [fetch] source=forum status=200 items=37 说明接口通了且有返回；[filter] window=1d kept=12 dropped=25 说明时间过滤在起作用。状态码差异要分清：401/403 是凭据或权限问题，429 是频率限制，timeout 是网络问题，这三种都不是「数据源没有内容」；只有状态正常而 items=0，才说明该时间窗内确实没抓到东西。

按返回条数调整时间窗与单源上限

范围收敛的判断标准不是「越多越好」，而是抓回来的量能人工过一遍。可以先保持话题不变，只改一个参数：把 window.days 从 1 提到 7 或 30，或把 limits.per_source 从 200 降到 50，然后对比日志里的 items 与落盘行数。同一话题、同一来源、同一时间点跑两次，对比 kept 与最终条数，比所谓效果指标更可靠。

window:
  days: 7
limits:
  per_source: 50

如果放宽时间窗后条数暴涨而话题相关度明显下降，说明这个来源的历史内容噪音大，优先降低 per_source 而不是继续拉长窗口；反过来，如果窗口内保留条数远低于上限，说明当前窗口太窄，可以按天逐步加。

核对落盘结果的字段结构

结果通常按行写入 jsonl 或 csv，先抽几行确认话题、来源、时间三个字段都有值：

{"topic":"产品改名","source":"forum","published_at":"2025-01-01T10:00:00Z","text":"...","url":"..."}

topic 为空说明话题参数没传进任务；source 为空或统一是同一个值，回看 sources 配置是否只启用了一个来源；published_at 为空则要检查时间解析环节和过滤条件，因为按时间过滤的前提是字段可解析。三个字段齐了，才谈得上按时间和来源切分结果。

保存一份可复现的配置快照

把配置文件、实际执行的命令、工具版本号、话题词、时间窗和单源上限一起存下来，下次复跑用同一份快照，才能判断条数变化是数据变了还是参数变了。

runs/2025-01-01-产品改名/
  config.yaml
  command.txt      # 完整命令行
  version.txt      # 工具 `--version` 输出
  result.jsonl

复跑时逐项比对：来源列表是否一致、时间窗起止时间是否一致、日志中每个来源的 items 与 kept 是否落在同一量级。只要有一项对不上，就先把参数对齐再比较结果，否则容易把配置差异误判成数据质量问题。