paper-radar — 大型科技公司 AI 论文雷达
无状态：一次运行 = 一个时间窗口 = 一份报告。不维护任何论文库。 arXiv 是唯一的事实来源，在相同窗口下重新运行必然产生相同结果——因此无需保留第二份副本。保存副本只会增加状态，且该状态会无声漂移并脱离版本控制。代价是每次运行需重新抓取整个窗口（3 天约 1 分钟，14 天约 3 分钟）；你换来的是可复现性。
请先阅读此内容，否则会得出错误结论
arXiv 是唯一按发布日期组织的来源。 每家厂商自己的出版物页面是按出版年份/会议组织的，这在结构上无法回答“最近两周发布了什么”——这是一个数据模型差异，不是技术问题。实测结果：
- Google Research：详情页面仅包含年份，且列表非按时间排序；前 8 页的 85 篇标题中，在两周窗口内有 0 篇，且最新一篇的 arXiv 发布日期已是三个月前
- Amazon Science：按年份分组，没有每篇论文的具体日期
- Microsoft：
/research/feed/是一个编辑策划的博客——同一窗口内覆盖率仅约 8% - 13 家中国公司网站：所有网站均未命中日期——这些是实验室落地页，而非论文列表
另一个需要了解的事实：arXiv 元数据不包含作者所属机构。
<arxiv:affiliation> 填充率为 1%，Semantic Scholar 为 7%，而 OpenAlex 对预印本返回0 条 raw_affiliation_strings（实测：3/3 为空，而同一接口对已发表的 Nature 论文返回 34/34）。业界标准流程是“出版商提供机构字符串 → 机器学习映射到 ROR”，而 arXiv 从未提供该字符串。因此，机构信息必须从论文本身的作者块中提取。
运行方式
脚本位于此技能目录中，不依赖外部任何内容——纯标准库，无 pip 包。
R=<skill-dir>/scripts/paper_radar.py
python3 $R # 最近 3 天
python3 $R --days 14 # 最近 14 天
python3 $R --from 2026-07-20 --to 2026-08-04
python3 $R --cats cs.AI,cs.CL,cs.LG,cs.CV # 扩大分类范围
python3 $R --no-scrape # 仅官方来源 + 团队名称（秒级 —— 快速公司检查）
python3 $R -o path.md # 将报告写入此处
python3 $R -o - # 将报告输出到标准输出
时间估算：对于两周窗口（约 3000 篇论文），元数据获取约需 2 分钟，作者块抓取约 25 秒（6 个工作线程）。3 天窗口在一分钟内完成。要覆盖更长的历史，请扩大窗口并重新运行——没有可查询的库。
报告输出位置——你来决定，脚本不猜测
脚本不知道，也不应该知道调用项目将其研究存放在何处。若不指定 -o，则写入当前工作目录。
每次运行前决定目标位置：
- 用户指定了路径 → 使用它
- 该研究值得保留 → 写入该项目的研究目录，文件名中包含时间窗口
- 你只是检查一个事实（“小米是否发表了关于自我进化 AI 的论文？”）→ 使用
-o -并且不留文件。一个一次性问题留下的文件，日后会伪装成研究记录
文件
| 路径（相对此技能） | 角色 |
|---|---|
scripts/paper_radar.py | 流水线：获取列表 → 获取作者块 → 解析机构 → 写入报告 |
scripts/affiliation.py | 解析层：上标映射 + 三级匹配 |
scripts/data/ror_anchors.json | 28 个实验室的 ROR ID + 98 个官方名称变体（含中文） |
唯一输出是一个 Markdown 文件（路径见上），包含“总命中数 / 其中主导数”的拆分。技能目录本身不产生任何文件。
六个阶段
0 列表 arXiv API: cat × submittedDate → 按 ID 去重
1 全文 arxiv.org/html/{id} + Range 前 90KB，截取 ltx_authors → ltx_abstract [85%]
2 结构 从右向左扫描，找到最后一个开始递增 1,2,3… 序列的位置
提取 (作者, 标记[]) · (标记, 机构) · 邮箱 · 角色标记
3 实体 (a) 邮箱域名 (b) ROR 名称变体 (c) 实验室别名表
4 评分 lead_orgs = 第一作者的机构（可能多个）；intern = 存在标记
5 补充 Apple RSS · MSR 内嵌 JSON · arXiv 团队名称
6 报告 按键去重（同一篇论文可能同时来自作者块和官方来源），写入 Markdown，保留证据和 matched_on
五项纪律，每一项都用 bug 买过单
1. 作者块必须严格在 ltx_abstract 处截断。 多取一个字符，摘要就会混入。实测后果：Oracle 73 篇（全部是“oracle 访问”）、MiniMax 17 篇（Minimax 算法）、DeepSeek 58 篇（仅仅是提及该模型的论文）。干净截断后，作者块中位长度约为 201 个字符。
2. 机构列表必须从右向左查找。 作者序列中的“姓名 + 上标数字”和机构序列中的“数字 + 机构”形状完全相同，因此从左向右扫描会将 Yuchen Zhao 1 Bingxuan Li 解析为 1 → "Bingxuan Li"。
3. 永远不要回退到“只匹配了一家公司，所以它就是主导”。 这只能告诉你其他机构不是你所追踪的公司。实测误归因：基于文件系统的内存本是 UIUC 主导，但被评分为 Adobe 主导，因为 Adobe 是唯一匹配项。
4. 公司署名不等于公司主导。 报告中只有 * 表示主导。在两周窗口内实测：Google 命中 10 篇但仅主导 4 篇；Google DeepMind 命中 7 篇，主导 2 篇；Adobe 命中 5 篇，主导 0 篇。任何“N 篇大公司论文”的说法都必须说明指的是哪一列。
5. 在列出数字之前，先说明盲点。
- 12% 的投稿纯 PDF，不可见——阶段 1 的硬上限
- Apple 缺失率约 78%（其作者经常省略机构）→ 通过官方 RSS 订阅修补。此补充是必需的，而非可选的
- 当第一作者列出多个机构时，无法排序；两者均获得
* intern是一个标记，而非判断——实习生的论文是否“算数”是一个定义性问题，交由调用者决定
三层错误——不要混淆
| 层 | 问题 | 失败时如何处理 |
|---|---|---|
| 1 提取 | 完全无法获取文本 | 补充来源；今天的每次缺失都在这一层 |
| 2 结构 | 无法将作者映射到机构 | 降级为整块扫描，精度降低 |
| 3 实体 | 该字符串对应哪家公司 | unmatched 保留原始文本用于表格；ROR 仅在此层运作 |
ROR 是一个字符串到 ID 的查找表；你需要先有字符串。 对两篇小米论文的实测：一篇完全没有 HTML，另一篇的作者块包含 8 个人名，却没有一个机构词。ROR 也无法挽救——只有补充来源可以。
为什么保留每一个补充来源
| 来源 | 角色 | 证据 |
|---|---|---|
| Apple RSS | 纠正系统性缺失，必需 | 两周窗口：抓取 2 篇 vs. 官方 9 篇——缺失率 78% |
| arXiv 团队名称 | 覆盖“公司名称出现在作者槽位而非机构槽位”的情况 | Xiaomi MiMo Team / Kimi Team；新增 2 篇论文，零冗余 |
| MSR 内嵌 JSON | 交叉检查探针 | 抓取 25 篇 vs. 官方 7 篇——冗余，但保留作为一次运行内的对照：若官方来源有作者块未抓到的论文，则阶段 1 有问题 |
当某公司显示为零时——按此顺序检查
- 窗口错误——arXiv 索引延迟 1-2 天，且周末不发布；先扩大窗口
- 分类错误——默认分类为 cs.AI/cs.CL/cs.LG；机器人学为 cs.RO，视觉为 cs.CV，系统为 cs.SE
- 团队名称搜索——
all:"Xiaomi"/"Hunyuan"/"Kimi Team"可行；all:"MiniMax"不可用（5800+ 来自 minimax 算法的命中）——请使用au:"MiniMax" - 官方渠道——Apple RSS、Meta 的
ai.meta.com/results/?content_types[0]=publication（注意/research/publications/对纯 curl 返回 400）、NVIDIAresearch.nvidia.com/publications - 仅当上述所有项均为空时，你才能说“该公司在该窗口内未发表任何内容”
路线图
- 将 TeX 源作为阶段 1 的第二层——解压
arxiv.org/e-print/{id}并读取\author{}。已验证：没有 HTML 的论文通常有 TeX，且上标完好。成本最低的覆盖率提升途径 - 一次运行内的健康自检——将阶段 1 的作者块命中率，以及“官方来源有而作者块没有”的计数，直接放入报告头部。防止 arXiv 更改其标记时发生静默故障（78% 的 Apple 缺失是偶然发现的）。不要为此重新引入存储的历史命中率——一次运行内的交叉检查已足够
还有一件事
论文数量是供应量，不是热度。 实测：在一个两周窗口内的 231 篇大公司论文中，有 0 篇在 Hacker News 上被讨论，而同窗口内每篇在 HN 上被讨论的论文都来自学术界或初创公司。判断热度需要单独的社会信号。