content/skills/academic-skills/paper-interpretation/SKILL.md
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.
npx skillsauth add bahayonghang/my-claude-code-settings paper-interpretationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
读论文不是做学术,是猎取思想。把别人的发现拆解成自己能用的认知。
*bold*(单星号),禁止 **bold*** 开始,不跳级所有图表用纯 ASCII 字符。允许:+ - | / \ > < v ^ * = ~ . : # [ ] ( ) _ , ; ! ' " 和空格。禁止 Unicode 绘图符号。
输出结构依据 references/template.org。禁止参考 ~/Documents/notes/ 中已有论文文件的章节结构——旧文件可能使用过期模板。
date +%Y%m%dT%H%M%Sdate "+%Y-%m-%d %a %H:%M"{时间戳}--paper-{简短标题}__paper.org~/Documents/notes/#+title: paper-{简短标题}
#+date: [{YYYY-MM-DD Day HH:MM}]
#+filetags: :paper:
#+identifier: {YYYYMMDDTHHMMSS}
#+source: {URL 或来源描述}
#+authors: {作者列表}
#+venue: {发表场所/年份}
文件写入后报告路径。
四条核心原则,决定文章是"活人在说话"还是"机器在汇报":
讲解论文时可以拿的工具,没有哪个是必须的:
确保拿到:标题、作者、摘要、核心方法、结果。
找到那个真实的困境——某件事做不到、某个现象解释不通、某条路走不下去。用一段话讲清来龙去脉。
不是「本文提出了一种新的 XXX 框架」,是「大模型明明很聪明,为什么一问具体事实就开始胡说?」
把论文的核心想法讲到一个不懂这个领域的聪明人能跟上。形式自由——类比、图、例子、递进讲解,选最适合这篇论文的方式。
开头先立锚点:找到一个具象的中心隐喻或画面,在翻译的第一段就亮出来。后面所有概念围绕这个锚点生长,不是并列罗列。
推理带着读者走:不要直接给结论。模拟"一步步想明白"的过程——"既然X是这样,那Y能不能也这样?"让读者觉得结论差一步就是自己想到的。
需要覆盖:
费曼翻译部分的子标题按内容需要组织,不必固定。
挑出论文中最关键的 1 至 3 个概念(方法名、架构组件、数学对象、新定义……),逐个拆解。
每个概念:
选概念的标准:读者如果不懂这个,后面的洞见和审稿就跟不上。已经在「翻译」里讲透的不重复选。
整篇论文最值钱的往往就一个点——作者真正找到的那颗新结晶。
用一句话把它说出来。这句话应该让读者觉得「这个想法我可以带走」,而不是「哦,论文说了这么个事」。
检验标准:把这句话单独抽出来,脱离论文上下文,它还有没有力量?如果只是在复述论文结论,那不是洞见。洞见是你读完之后自己看到的那个东西——论文里未必直说,但逻辑指向它。
说不出来就重读第三步。如果论文确实没有思想火花,直说「这篇论文是工程改进,没有认知层面的新发现」。不要硬挤。
换身份:这个方向上带了二十年研究生的博导。学生拿着论文来找你,你判断这东西值不值得认真对待。
用白话说,像在办公室跟学生聊:
好的说好,差的说差在哪儿。
落点在"能用",不在"能想"。给出"这意味着你可以___",而非"这让我们重新思考___"。
用三个视角试探连接,命中展开,没命中跳过,全没命中说「没有」:
逐条扫红线。额外检查:
列修改清单确认后生成文件。
按 Denote 规范获取时间戳,读 references/template.org,写入 ~/Documents/notes/。
development
Use only when the user explicitly asks for swarm, subagents, parallel agents, dynamic workflow, multi-agent orchestration, 多智能体编排, or when the task truly needs coordinated research plus implementation plus review plus verification packets. Do not use for ordinary code review, planning-only work, single-line bugfixes, routine audits, or migrations unless orchestration is requested or at least two independent workflow dimensions are present.
development
Run a code quality review focused on maintainability, structure, abstraction quality, file growth, branching complexity, boundary cleanliness, and refactoring opportunities. Use when the user asks for code quality review, code review, maintainability review, architecture quality review, PR code quality feedback, 代码质量审查, 代码质量 review, 可维护性审查, 架构质量审查, or review comments about code structure. Do not use for pure security review, formatting-only review, performance profiling, or implementation tasks unless the user also asks for a code quality review.
development
Plan-first brainstorming workflow that turns an idea into an approved Markdown implementation plan by default. Use when the user wants to brainstorm, design, scope, or plan a feature/spec before implementation. Spark explores project context, asks only blocking questions, writes the plan under the project root's .plannings/YYYY-MM-DD-feature-slug.md path, self-reviews it, and waits for user approval. Create an HTML or visual plan/spec only when the user explicitly asks for HTML, browser-viewable, or visual output; save the paired .html beside the Markdown plan.
development
Run a code quality review focused on maintainability, structure, abstraction quality, file growth, branching complexity, boundary cleanliness, and refactoring opportunities. Use when the user asks for code quality review, code review, maintainability review, architecture quality review, PR code quality feedback, 代码质量审查, 代码质量 review, 可维护性审查, 架构质量审查, or review comments about code structure. Do not use for pure security review, formatting-only review, performance profiling, or implementation tasks unless the user also asks for a code quality review.