live-research

Bright Data — 实时研究

将一个研究问题转化为有引用、经过综合整理的简报：分发意图排序后的 Discover 查询，阅读最优质的来源，并通过内联引用撰写研究发现。这是构建在 discover-api 技能之上的工作流——API 的用法、模式和参数请参阅该技能。

如果交付成果是理解（报告/简报），而不是链接列表（那是 search/discover-api 的用途），也不是常驻系统（那是 rag-pipeline 的用途），就使用此工作流。

设置检查

必须能够访问 Discover。快速检查（CLI 路径）：

command -v bdata >/dev/null 2>&1 || echo "CLI missing — see bright-data-best-practices/references/cli-setup.md"
bdata zones >/dev/null 2>&1 || echo "not authenticated — run: bdata login"

（SDK/REST 路径只需设置 BRIGHTDATA_API_TOKEN。）

方法

步骤 1 — 明确问题范围（首先执行，不要跳过）

如果问题宽泛或含糊，请先提出 2–3 个澄清问题，再调用 API：时间范围、地理区域/市场、深度，以及研究要支持的决策。明确的范围有助于设置更好的 intent 参数。

步骤 2 — 拆解为子问题

将主题拆解为 4–8 个角度（定义、主要参与者、机制、证据、反面证据、近期发展、风险）。每个角度都对应一次 Discover 调用，并设置专门的 intent。这比一个宽泛的查询效果更好——num_results 上限为 20，因此覆盖面来自广泛分布的查询，而不是一次大型调用。

步骤 3 — 按角度运行 Discover（并行），并获取内容

# one call per angle; --include-content so you read sources in the same pass
bdata discover "stablecoin regulation 2026" \
  --intent "recent regulatory actions and proposed legislation, primary sources" \
  --include-content --num-results 15 -o angle_regulation.json &

bdata discover "stablecoin reserve transparency" \
  --intent "audits, attestations, reserve composition disclosures" \
  --include-content --num-results 15 -o angle_reserves.json &
wait

对于难度高的主题，若要获得最全面的覆盖，请使用原始 REST 流程并设置 "mode":"deep"（参阅 discover-api）——deep 模式覆盖全面，但速度较慢，且仅限 REST。

步骤 4 — 合并、去重、排序并通过质量检查

• 每个 bdata discover -o 文件都是一个 {status, results: [...]} 对象——合并前，先从所有文件中展开 .results[]。
• 按 URL 去重（标准化：去掉查询字符串和片段，将主机名转换为小写）。
• 按 relevance_score 降序排序。
• 检查内容质量（即使 relevance_score 很高，内容也可能只是 404 占位页或只有导航的页面）：删除 content 为 null、符合拦截页面特征、短于约 200 个字符或看起来像“未找到”的条目。

# VERIFIED: this is the correct merge. `jq -s 'add | unique_by(.link)'` does NOT work —
# each file is {results:[...]}, so you must flatten .results[] first.
jq -s '
  [ .[].results[] ]                                   # flatten results from all files
  | unique_by(.link)                                  # dedup by URL
  | map(select(
      .content != null
      and (.content | length) > 200                   # drop empty / 404 stubs
      and ((.content | test("just a moment|captcha|access denied|cf-browser|page not found|post not found"; "i")) | not)
    ))
  | sort_by(-.relevance_score)
' angle_*.json > corpus.json
echo "kept $(jq length corpus.json) sources"

或者直接运行辅助脚本（逻辑相同且经过测试）：scripts/merge_corpus.sh -o corpus.json angle_*.json （-m <n> 用于设置内容最小长度）。手动复制 jq 容易出错——建议使用此脚本。

注意：使用 --include-content 时，content 开头部分通常是页面导航/模板内容（菜单、徽标）。提取论据（步骤 5）时，请跳过这些页面装饰，直接阅读文章正文。

步骤 5 — 阅读并提取论据

从每个保留来源的 content 中提取回答子问题的具体论据、数字、日期和引述。记录每条论据的来源 URL，之后需要引用。

步骤 6 — 综合撰写简报

撰写结构化简报（模板见 references/brief-template.md）。每条不显而易见的论据都应添加内联引用 [n]，对应编号来源列表中的条目。来源之间存在分歧时应注明，不要取平均值了事。

步骤 7 — 交付前核实

• 每条论据都能追溯到列表中的来源吗？（没有无来源论据）
• 是否呈现了相互冲突的来源，而非将其隐去？
• 是否明确指出了信息缺口（“未找到 X 的一手来源”）？
• 是否注明了时效性——信息何时收集，来源有多新？

质量标准

• 通过查询拓宽覆盖面，通过内容加深理解。 多个明确的 intent 胜过一个含糊的查询。
• 所有内容都要引用。 没有引用的研究简报只是观点。将每个 [n] 对应到语料中的真实 URL。
• 优先使用一手来源。 当 relevance_score 相近时，优先选择申报文件/文档/公告，而非聚合网站。
• 呈现不同意见。 来源相互冲突时，应说明分歧并注明双方来源。
• 指出信息缺口。 “未能找到……”也是研究发现，不应隐去。

危险信号

• 只调用一次宽泛的 Discover，却称之为“实时研究”——应按不同角度拆分。
• 根据记忆或训练数据撰写结论，而不是依据检索到的 content——每项结论都必须来自语料。
• 编造引文或 relevance_score——如果调用失败，应报告这一缺口。
• 忽略 --include-content，只列出链接——那是 discover-api，不是研究。
• 将来源之间的矛盾平均消解。
• 忘记去重——同一篇文章经由 3 个聚合平台传播，会夸大表面上的共识。

参考资料

• references/brief-template.md — 输出结构（执行摘要、各子问题的发现、矛盾、缺口、编号来源），以及一则完整的引文示例。
• scripts/merge_corpus.sh — 将第 4 步写成经过测试的一行命令：合并各角度文件中的 .results[]，按 URL 去重，通过质量检查（null／过短／404／拦截页），并按 relevance_score 排序。

相关技能

• discover-api — 底层 API（模式、参数、触发／轮询）。请先阅读。
• rag-pipeline — 用户需要可复用的检索系统，而不是一次性报告时使用。
• competitive-intel — 聚焦竞争对手的研究（定价、招聘、定位）。
• brand-listening — 跨 Reddit/X/TikTok 等平台进行社交媒体／情绪研究。