paper-radar — 大型科技公司 AI 論文雷達
無狀態：每次執行 = 一個時間窗口 = 一份報告。不維護論文庫。 arXiv 是唯一的事實來源，重新執行同一個時間窗口必然會產生相同的結果——因此沒有理由保留第二份副本。保留一份只會增加狀態，而狀態會默默地漂移，且脫離版本控制。代價是每次執行都要重新爬取整個時間窗口（3 天約 1 分鐘，14 天約 3 分鐘）；你換來的是可重現性。
請先閱讀此處，否則你會得出錯誤結論
**arXiv 是唯一按發布日期整理的來源。**每家廠商自己的發佈頁面是按 發布年份 / 會議 整理的，這在結構上無法回答「過去兩週發表了什麼」——這是資料模型的差異，而非技術問題。已驗證：
- Google Research：細節頁面僅有年份，且清單不是按時間順序排列；前 8 頁的 85 篇標題中，0 篇落在兩週窗口內，最新條目的 arXiv 發布日期已是三個月前
- Amazon Science：按年份分組，沒有每篇論文的日期
- Microsoft：
/research/feed/是編輯策劃的部落格——同一窗口的覆蓋率約 8% - 13 個中國公司網站：所有網站日期命中數皆為 0——這些是實驗室登陸頁面，而非論文清單
你需要知道的另一個事實：arXiv 中繼資料不攜帶作者所屬機構。
<arxiv:affiliation> 填充率為 1%，Semantic Scholar 為 7%，而 OpenAlex 對預印本返回 0 筆 raw_affiliation_strings（已測量：3/3 為空，而同一端點對已發表的 Nature 論文返回 34/34）。業界標準流程是「出版商存入所屬機構字串 → ML 將其映射到 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 - # 將報告寫入 stdout
時間：對於兩週的窗口（約 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… 序列
提取 (author, marks[]) · (mark, affiliation) · emails · role markers
3 實體 (a) 電子郵件網域 (b) ROR 名稱變體 (c) 實驗室別名表
4 評分 lead_orgs = 第一位作者的所屬機構（可能有多個）；intern = 存在標記
5 補充資料 Apple RSS · MSR 嵌入 JSON · arXiv 團隊名稱
6 報告 依金鑰去除重複（一篇論文可能同時來自作者區塊和官方來源），
寫入 Markdown，保留證據和 matched_on
五項紀律，每一項都曾因錯誤而付出代價
**1. 作者區塊必須嚴格在 ltx_abstract 處截斷。**多取一個字元，摘要就會滲入。已測量的後果：Oracle 73 篇（全部是「oracle access」），MiniMax 17 篇（minimax 演算法），DeepSeek 58 篇（僅是提及該模型的論文）。乾淨截斷後，中位數的作者區塊約為 201 個字元。
**2. 所屬機構清單必須從右向左尋找。**作者序列中的「姓名 + 上標數字」與所屬機構序列中的「數字 + 所屬機構」形狀完全相同，因此從左向右掃描會將 Yuchen Zhao 1 Bingxuan Li 解析為 1 → "Bingxuan Li"。
**3. 永遠不要因為「只匹配到一個公司，所以它主導」就退回。**這只能告訴你其他所屬機構不是你所追蹤的公司。已測量的錯誤歸屬：Filesystem-Based Memory 是 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"無法使用（minimax 演算法產生 5800+ 筆命中）——請使用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 上被討論，而同一窗口內每篇被 Hacker News 討論的論文都來自學術界或新創公司。判斷關注度需要另一個社會訊號。