bear-scoop

name	bear-scoop
description	在你投入一个研究方向之前，先看看有谁已经在做同样的事。把 idea 拆成多个不同角度分别去检索，返回一张"邻近程度地图"，重点标出最危险的撞车候选。底层走真实检索（scimaster-cli），不做主观新颖性判断。 **以下情况请主动触发本技能**：用户说"这个选题有没有人做过"、"我会不会被抢发"、"这个方向还有空间吗"、"我的 idea 新不新"、"要不要查一下有没有撞车"、"这个想法是不是已经有人发了"——即使用户没有说"bear-scoop"，只要意图是**在提交或动笔前确认 idea 的独特性**，就使用本技能。加 `-r` flag 只看近两年和预印本，适合担心被抢发的场景。 不适用于：为已有观点找支持文献（用 bear-support）、找反对文献（用 bear-counter）、概念地图（用 bear-map）、溯源演化史（用 bear-trace）。

bear-scoop · 选题撞车检测

一个任务：在你投入之前，看看谁坐在离你最近的位置。抢发你的那组人，用的词往往不是你会用的词——这里从你不会想到的角度去搜。

先读 references/sci-cli.md——CLI 检测步骤、用法和铁律。 再读 references/output-system.md——三层输出体系和 HTML 外壳规范。

Flags

• 默认：全角度扫描
• -r：只看近一两年和预印本（撞车风险最高的地方）

步骤（固定顺序）

Step 0 — 确认 CLI 可用 运行 sci --version。未安装就给安装命令并停止；认证错误就提示 sci init 并停止。

Step 1 — 压缩 idea 把 idea 提炼成一句话并确认。模糊的 idea 搜出来的是噪音，不是信号。

Step 2 — 分解成 5–6 个正交角度 同一项工作，从不同立场描述：

1. 字面表述（用户自己的说法）
2. 方法中心（技术 / 工具，剥离应用场景）
3. 问题中心（要解决的问题，剥离方法）
4. 结论中心（预期会声称的具体结果）
5. 相邻领域的表达方式（另一个学科会怎么叫这件事）
6. 抢发者的标题（如果有人比你快发了，那篇论文会叫什么）

在输出里明确列出这 5–6 个角度，每个附一行说明和实际使用的查询词。 用户需要看见你从哪些方向搜了，才能判断覆盖是否够全，也能自己补充遗漏的角度。列完后直接开始检索，不等待用户确认（除非 idea 本身太模糊）。

Step 3 — 分角度检索 宽泛角度用 ultra_low（免费），有收获的两三个用 low 复跑。加 -r 时偏向近期结果。每个角度用独立的 --prefix。

Step 4 — 合并去重 按 DOI 或标题去重。

Step 5 — 按邻近程度分四层

• 直接撞车：问题 + 方法 + 结论都重叠
• 方法孪生：你的方法，别人的问题
• 问题孪生：你的问题，别人的方法
• 邻居：相关但不重叠

每篇附一行"为什么它在这一层"。最危险的那篇单独在最上方点名。

分层前先给每篇候选做四轴评分，每轴 0 到 2 分：

1. 问题重叠：是否解决同一个问题
2. 方法重叠：是否使用同一技术路线
3. 结论重叠：是否会声称相同或高度相似的发现
4. 场景重叠：人群、数据、材料、任务或应用场景是否接近

分层规则：

1. 直接撞车：总分 7 到 8，且问题、方法、结论三轴都不低于 1
2. 方法孪生：方法 2 分，问题或场景明显不同
3. 问题孪生：问题 2 分，方法明显不同
4. 邻居：总分 1 到 3，或只共享背景领域

如果评分和直觉冲突，按评分分层，并在"为什么它在这一层"里解释冲突。

输出格式

搜索角度列表后，直接给撞车地图（★ 是你的 idea，从危险到安全向外展开）：

── 撞车地图 ──────────────── [你的 idea] ──

[!] 直接撞车
    Smith 2023 — "论文标题"
    邻近度  ████████░░

    方法孪生
    Jones 2022 — "论文标题"
    邻近度  ██████░░░░

    问题孪生
    Wang 2021 — "论文标题"
    邻近度  ████░░░░░░

    邻居
    Li 2020 — "论文标题"
    邻近度  ██░░░░░░░░

──────────────────────────────────────────

没有文献的层：— [层名] 此层未检索到，不从地图消失。 结尾两句：哪里拥挤，哪里安静。

输出物

检索结束后创建 {topic-slug}/ 子文件夹，输出四个东西：

1. 终端 — 直接 print TUI 格式（撞车地图 ASCII）
2. report.md — 按 output-system.md 的结构化 Markdown 规范生成：稳定 YAML front matter + 一眼结论 + 撞车分层 + 选题动作建议 + 证据表 + 详细证据 + 检索透明度 + 可复用 JSON
3. report.html — 自包含 HTML，按 output-system.md 规范生成
4. references.bib — 合并所有 query 生成的 .bib 文件，去重后只保留报告中实际引用的文献条目

HTML 签名体验：SVG 撞车雷达 + 四层文献 tabs，强调色 #2563eb（蓝）。雷达悬停 tooltip 用 JS mousemove 实现（不用 <title>）。HTML 组件规范见 output-system.md 的 bear-scoop 节。

简单查询只给 1–2 条轻量下一步。开题或担心抢发时给具体建议：是否继续推进、该避开哪个点、题目怎么改。

诚实边界

没有检索到直接撞车，不等于你是新的。可能是刚刚发出的预印本、付费墙后面的文章、未收录的期刊、或者根本还没人投稿。报告检索到的内容和它说明了什么——不要说"你是安全的"。完整的新颖性论证是产品级任务，交给 SciMaster。

Gotchas

• 雷达图点位不能为空：用 CSS div 同心圆时无法在圆环上放置点位，必须用 SVG。空圆环对用户没有任何信息价值。
• 四轴评分不要过于严格：问题/方法/结论/场景四轴各 0-2 分，总分 8 分。现实中 7 分和 8 分的文献对用户来说撞车风险相同，不要因为一轴差 1 分就把论文从"直接撞车"降到"方法孪生"，这会低估真实风险。
• 综述类文献不要放进直接撞车：综述和原创研究的竞争性质不同。综述几乎不构成"你的选题被抢发"的威胁，应归入"邻居"层。
• 不要因为找不到直接撞车就报告"安全"：数据库覆盖有限，这个结论没有依据。