yelban/ljg-skills.tw · Archived

ljg-paper

Paper reader for non-academics. Takes a paper and extracts its ideas for personal use. Focuses on understanding, not academic critique. Use when user shares an arxiv link, paper URL, PDF, or asks to analyze a research paper. Trigger words: '讀論文', '分析論文', 'paper', or when user shares an academic paper.

First seen Mar 27, 2026

Installation

$ npx skills add yelban/ljg-skills.tw --skill ljg-paper

Summary

  • Paper reader for non-academics.
  • Takes a paper and extracts its ideas for personal use.
  • Focuses on understanding, not academic critique.
  • Use when user shares an arxiv link, paper URL, PDF, or asks to analyze a research paper.
  • Trigger words: '讀論文', '分析論文', 'paper', or when user shares an academic paper.

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from yelban/ljg-skills.tw · top by installs.

npx skills add yelban/ljg-skills.tw

Browse all from yelban/ljg-skills.tw

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Default branch master
Status Archived

Skill metadata

Parsed from SKILL.md frontmatter.

Version4.4.0

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 9,415 B
  • docs SUMMARY.md 333 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 6 installs

SKILL.md

ljg-paper: 讀論文

讀論文不是做學術,是獵取思想。把別人的發現拆解成自己能用的認知。

格式約束

Org-mode 語法

  • 加粗用 bold(單星號),禁止 bold
  • 標題層級從 * 開始,不跳級

ASCII Art

所有圖表用純 ASCII 字元。允許:+ - | / \ > < v ^ * = ~ . : # [ ] ( ) _ , ; ! ' " 和空格。禁止 Unicode 繪圖符號。

模板權威性

輸出結構依據 references/template.org。禁止參考 ~/Documents/notes/ 中已有論文檔案的章節結構——舊檔案可能使用過期模板。

Denote 檔案規範

  • 時間戳:date +%Y%m%dT%H%M%S
  • 可讀時間:date "+%Y-%m-%d %a %H:%M"
  • 檔名:{時間戳}--paper-{簡短標題}__paper.org
  • 輸出目錄:~/Documents/notes/

Org 檔案頭

#+title:      paper-{簡短標題}
#+date:       [{YYYY-MM-DD Day HH:MM}]
#+filetags:   :paper:
#+identifier: {YYYYMMDDTHHMMSS}
#+source:     {URL 或來源描述}
#+authors:    {作者列表}
#+venue:      {發表場所/年份}

檔案寫入後報告路徑。

紅線(每條必須過)

  1. 口語檢驗 — 你會這樣跟朋友介紹一篇論文嗎?不會→改。學術腔是預設敵人
  2. 零術語 — 先用大白話落地,再順帶提術語名。如果必須用原文術語才能解釋,說明還沒懂
  3. 短詞優先 — 能用兩個字說的不用四個字。「本文提出了一種新的框架」→「他們做了個東西」
  4. 一句一事 — 每句只推一步
  5. 具體 — 名詞看得見,動詞有力氣。形容詞能砍就砍
  6. 開頭給理由 — 問題部分的第一句讓人想知道答案
  7. 不填充 — 刪學術套話(「近年來隨著...的發展」「值得注意的是」)。每句幹活
  8. 信任讀者 — 說一遍夠了。不重複結論
  9. 誠實 — 論文有硬傷就說有硬傷。看不懂的部分說看不懂

寫作原則

四條核心原則,決定文章是"活人在說話"還是"機器在彙報":

  1. 一個錨點撐全文 — 找到一個具象的中心隱喻(一張圖、一個場景、一個動作),讓所有概念圍繞它生長。不是並列羅列五個概念,是一根繩子串起來。錨點在「翻譯」開頭就要出現,後續章節可以反覆回到它
  2. 推理外顯 — 模擬"一個人想明白的過程",而非呈現"想明白之後的結果"。用"既然A是B,那能不能C也是D?"帶讀者一起推。讓讀者覺得結論差一步就是自己想到的
  3. 變形替代定義 — 解釋兩個概念的關係時,把A連續變形成B,不要說"A和B是XX關係"。「把LSTM變形→看起來像ResNet」比「LSTM和ResNet是對偶的」有力十倍
  4. 落點在能用 — 給出"這意味著你可以",而非"這讓我們重新思考"。讀者讀完要帶走一個能動手的東西,不是一個值得沉思的感慨

工具箱(選用)

講解論文時可以拿的工具,沒有哪個是必須的:

  • 類比 — 承重的,方法的關鍵元件都能對映上。沿著類比走一遍方法
  • ASCII 圖 — 展示元件關係、資料流、結構對比。讀者有概念腳手架後再畫
  • 餐巾紙速寫 — 「以前這麼想,現在應該這麼想」的並排對比
  • 好問題 — 把論文解決的困境變成一個讓外行也好奇的問題
  • 遞進例子 — 從簡單到複雜,一步步搭建理解
  • 反問入鏈 — 遇到隱含假設,用問題開啟

執行

1. 獲取內容

  • arxiv URL → WebFetch
  • PDF → Read(注意 pages 引數限制)
  • 本地檔案 → Read
  • 論文名稱 → WebSearch

確保拿到:標題、作者、摘要、核心方法、結果。

如果論文有一張承載全文核心思路的總覽圖(overview / architecture diagram,通常是 Figure 1),提取並儲存到 ~/Documents/notes/images/,檔名 {identifier}--paper-{簡短標題}-overview.png

判斷標準:這張圖讓人一看就抓住論文在做什麼。不是所有論文都有——沒有就跳過,不要硬找。

提取方法:

  • arxiv → 訪問 HTML 版(arxiv.org/html/...),找到圖片 URL,WebFetch 下載
  • PDF → 擷取含圖頁面儲存為圖片

2. 定位:它在解決什麼?

找到那個真實的困境——某件事做不到、某個現象解釋不通、某條路走不下去。用一段話講清來龍去脈。

不是「本文提出了一種新的 XXX 框架」,是「大模型明明很聰明,為什麼一問具體事實就開始胡說?」

3. 費曼:讓外行懂

把論文的核心想法講到一個不懂這個領域的聰明人能跟上。形式自由——類比、圖、例子、遞進講解,選最適合這篇論文的方式。

開頭先立錨點:找到一個具象的中心隱喻或畫面,在翻譯的第一段就亮出來。後面所有概念圍繞這個錨點生長,不是並列羅列。

推理帶著讀者走:不要直接給結論。模擬"一步步想明白"的過程——"既然X是這樣,那Y能不能也這樣?"讓讀者覺得結論差一步就是自己想到的。

需要覆蓋:

  • 它怎麼做的(核心機制/方法)
  • 做出來效果如何(挑最說明問題的兩三個結果)
  • 理解全文需要的鑰匙概念(如果有)

費曼翻譯部分的子標題按內容需要組織,不必固定。

4. 核心概念:把術語變成直覺

挑出論文中最關鍵的 1 至 3 個概念(方法名、架構元件、數學物件、新定義……),逐個拆解。

每個概念:

  • 一句話:這東西是什麼,幹什麼用的
  • 類比或例子:讓沒接觸過的人秒懂。解釋兩個概念的關係時,優先用"把A變形成B"而非"A和B是XX關係"——變形比定義有力
  • 為什麼重要:少了它論文的邏輯鏈斷在哪裡

選概念的標準:讀者如果不懂這個,後面的洞見和審稿就跟不上。已經在「翻譯」裡講透的不重複選。

5. 洞見:思想結晶

整篇論文最值錢的往往就一個點——作者真正找到的那顆新結晶。

用一句話把它說出來。這句話應該讓讀者覺得「這個想法我可以帶走」,而不是「哦,論文說了這麼個事」。

檢驗標準:把這句話單獨抽出來,脫離論文上下文,它還有沒有力量?如果只是在複述論文結論,那不是洞見。洞見是你讀完之後自己看到的那個東西——論文裡未必直說,但邏輯指向它。

說不出來就重讀第三步。如果論文確實沒有思想火花,直說「這篇論文是工程改進,沒有認知層面的新發現」。不要硬擠。

6. 博導審稿

換身份:這個方向上帶了二十年研究生的博導。學生拿著論文來找你,你判斷這東西值不值得認真對待。

用白話說,像在辦公室跟學生聊:

  • 選題眼光:問題值不值得做?真缺口還是人造缺口?
  • 方法成熟度:巧勁還是蠻力?有沒有更自然的做法被忽略?
  • 實驗誠意:baseline 公不公道?消融到位沒?數字經不經得起追問?
  • 寫作功力:最該說清楚的地方有沒有偷懶?
  • 判決:strong accept / weak accept / borderline / weak reject / strong reject,一句話理由

好的說好,差的說差在哪兒。

7. 啟發:對我的提醒

落點在"能用",不在"能想"。給出"這意味著你可以",而非"這讓我們重新思考"。

用三個視角試探連線,命中展開,沒命中跳過,全沒命中說「沒有」:

  • 遷移:論文的某個機制/視角能移植升級我體系的某個零件嗎?具體怎麼接?
  • 混搭:論文的某個元件和我已有的東西組合能產生新東西嗎?產出什麼?
  • 反轉:論文的做法和我的預設假設相反嗎?該停下什麼、開始什麼?

8. 過紅線

逐條掃紅線。額外檢查:

  • 破公式——否定式排比全文不超過兩處,三段式改兩項或四項
  • 變節奏——長短句交替
  • 殺金句——聽起來像可引用的,重寫
  • 查跳躍——邏輯每步可追

列修改清單確認後生成檔案。

9. 生成 Org 檔案

按 Denote 規範獲取時間戳,讀 references/template.org,寫入 ~/Documents/notes/

驗收

  • 問題勾人:讓不懂的人也想知道答案
  • 有錨點:翻譯部分有一個具象的中心隱喻,後續概念圍繞它生長
  • 帶著推:讀者能感受到"一步步想明白"的過程,而非接收打包好的結論
  • 外行能跟:不懂這個領域的聰明人讀完能複述核心思路
  • 博導像博導:有判斷力有分寸,最後一句判決
  • 啟發能動手:啟發部分的落點是"你可以",不是"值得思考"
  • 零割裂感:讀完像一個人在跟你說「我讀了篇論文,發現了個有意思的事」