mcpField
N
neuroarxiv

neuroarxiv

github.com/uditakhourii开发43878 次安装6 周前更新
代码仓库

关于 neuroarxiv

NeuroArxiv 是帮助编码 Agent 在重大技术设计前检索 arXiv 先前工作的 Skill,并通过逐篇隔离阅读、评分和聚类形成单一路径建议。仓库还提供 Node/TS 实现和 CLI,可用于脚本或批量运行。

主要功能

  1. 01按技术问题选择 arXiv 分类与检索词
  2. 02逐篇隔离分析论文摘要
  3. 03为论文相关性、可行性与严谨性评分
  4. 04聚类并选出单一实现方向
  5. 05总结风险、替代方案与未解问题
  6. 06提供 Node/TS 实现与 CLI

适用场景

  1. 01重大架构决策前检查相关研究
  2. 02比较缓存、检索或协调机制的先前方案
  3. 03通过脚本批量运行 arXiv 调研

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/uditakhourii/neuroarxiv --skill neuroarxiv

安装后在 Claude Code 中输入/neuroarxiv确认已加载。

详细介绍

NeuroArxiv

Vibecoder 并非因为缺乏技能而浪费数小时。他们浪费数小时,是因为还没确认难题是否已经被解决并发表、相关失败模式是否已为人所知,就开始动手构建。arXiv 是全球最大的“有人做过这件事吗”信息源——但几乎没人会在开始写代码前先去读论文。这个技能让 Agent 先读论文。

预检(在 Phase 1 之前运行)

这项技能成本很高:实际抓取 arXiv 论文,每篇论文通常要单独调用一次 Agent(一般为 10-20 次),此外还有评分、聚类和收敛过程。没有真正的先前研究可查时,不要付出这些成本。

步骤 1:检查是否由用户明确调用。

如果用户输入了 /neuroarxiv,明确要求“检查 arXiv”“检查先前研究”或“运行 NeuroArxiv”,跳过本节其余内容,直接进入 Phase 1。用户已选择启用。

步骤 2:自行判断(仅当步骤 1 不符合时)。

问自己三个问题。只要有一个答案是否,就中止。

  1. 是否有值得研究的技术机制? 给变量命名、连接 CRUD 表单,或把两个有文档说明的 SDK 粘合起来,都没有值得探讨的先前研究问题。设计缓存策略、共识/协调方案、排序或检索方法、ML 训练或推理技术、新协议,或者任何“朴素实现无法规模化”的问题,都值得研究。
  2. 用户是否即将为此投入实际精力? 一次性脚本不值得进行文献检索。会奠定架构基础的组件,或一旦构建错误就难以重做的组件,则值得。
  3. 用户是否尚未确定方案? 如果用户已经指定要使用的具体算法/论文/库,或说“就用最简单的方式实现”,说明方案已经确定——不要重新讨论。中止。

如果三项检查均通过,进入 Phase 1。

如果任一项未通过,则中止并直接实现。也可以附上一句话:“如果你想先对照 arXiv 上的先前研究进行检查,请运行 /neuroarxiv <your problem>。”

循环

分三个阶段。抓取资料并不意味着发散——先找到真实文献,再逐篇独立阅读,最后收敛。跳过独立阅读这一步,就会变成让大模型猜测自己实际上并未读过的论文。

阶段 0 — 分类

将构建问题映射到 3–5 个 arXiv 学科类别和 3–6 个具体搜索词(即技术机制词——“缓存失效”,而不是“缓存系统”)。从下表中选择;如果你确定,也可以指定其他类别 ID。

类别涵盖范围
cs.AI通用 AI 系统、Agent、规划、知识表示
cs.LG学习算法、训练方法、模型架构
cs.CLNLP、语言模型、文本处理
cs.CV图像/视频理解、生成、感知
cs.IR搜索、排序、推荐、检索增强系统
cs.DC分布式系统、共识、分片、复制、调度
cs.DB存储引擎、查询处理、索引、事务、一致性
cs.SE开发实践、测试、程序分析、工具
cs.PL语言设计、类型系统、编译器、运行时
cs.CR协议、身份验证、对抗鲁棒性、隐私
cs.NI路由、拥塞控制、边缘/CDN
cs.OS内核、调度器、内存管理、虚拟化
cs.HC界面设计、易用性、交互模型
cs.MAAgent 之间的协调、协商、涌现行为
cs.RO控制、感知、操控、运动规划
cs.DS算法技术、复杂度、数据结构设计
cs.GT机制设计、拍卖、激励相容系统
stat.ML统计学习理论、概率模型
eess.SP / eess.SY信号处理/控制理论
math.OC优化、调度、资源分配

如果问题纯粹是产品/业务层面的描述,没有明显的技术机制,请直言说明——但仍要尽力提出一个技术角度。大多数构建问题都有相关机制(缓存、一致性、排序、调度、检索),即使问题中没有明确提及。

阶段 1 — 获取(真实 HTTP 请求,不生成内容)

对于每个选定的类别,调用 WebFetch 请求 arXiv 的真实导出 API——不要凭记忆转述这一步,务必实际获取:

https://export.arxiv.org/api/query?search_query=cat:<CATEGORY>+AND+(all:"<term1>"+OR+all:"<term2>")&start=0&max_results=4&sortBy=relevance&sortOrder=descending

要求 WebFetch 针对每个 <entry> 原样返回 arXiv ID、标题、摘要、作者、发表日期以及 abs/pdf 链接;内容必须逐字来自 Feed,不得概述。这是真实的 Atom XML Feed;应将每个字段都视为事实依据,绝不可编造响应中不存在的论文、ID 或细节。

如果某个类别返回的结果少于 2 条,请删除搜索词后重试该类别的查询(仅使用 cat:<CATEGORY>)——不要用不相关的结果凑数。如果所有类别返回的结果都不足,请在输出中如实说明,不要编造发现。

礼貌提示: arXiv 要求每次只发起一个请求,并在请求之间间隔几秒。请依次获取各类别的数据,不要并发请求。

阶段 2 — 发散(分别阅读每篇论文)

对于阶段 1 收集的每篇论文,启动一次并行的 Agent/Task 调用。每篇论文调用一次。每个 Agent 只会获得:

  • 构建问题
  • 那一篇论文的标题、摘要、作者、年份——不包含其他论文
  • 以下说明

你处于发散阅读模式。你只有一篇论文的标题和摘要,以及一个构建问题。你不知道还有哪些其他论文——不要假设、编造或暗示存在更广泛的综述。 请把这篇摘要当作是在为某个准备从零开始构建上述内容的人探查已有技术。切勿连续逐字引用摘要超过几个词——请用自己的话转述。 提取:方法(1-2 句话,说明核心机制)、借鉴点(1 句话,说明最具体且可实现的一项启示——用祈使语气:“使用 X 来实现 Y”;如果关联太弱,请直说)、局限(1 句话,说明关键弱点或失效条件)、相关性说明(用一个简短短语说明与上述问题的契合度)。 仅输出 JSON:{"approach":"...","borrow":"...","limitation":"...","relevanceNote":"..."}

关键不变量。 这些调用必须并行且彼此隔离。读过其他论文摘要的 Agent 会开始总结整组论文,而不是围绕眼前的一篇论文展开——这比 ADHD 的交叉干扰崩溃更隐蔽,也更容易漏掉,因为输出看起来仍像是在分析单篇论文。

阶段 3 — 收敛(选定一条路径,而非列出候选清单)

所有阅读结果返回后:

  1. 评分。 从 0 到 10 为每篇阅读结果评分,维度包括:相关性(与既定问题的契合度)、实用性(小团队无需特殊基础设施即可构建)、严谨性(摘要本身是否展示了真实证据——基准测试、证明、已部署系统——而非纯粹概念)。如果论文自身指出的局限意味着构建者本可能要靠惨痛经验才会发现的失效模式,请标记为“陷阱”。同时务必配上一个“优势”——该论文方法切实做对的一点。
  2. 聚类。 按底层架构思路将阅读结果分为 3-6 个集群(而非按论文或关键词): “缓存失效方案”、“无共识方案”、“学习型索引方案”。
  3. 选定一项。 选择相关性与实用性组合最强的集群——不是最新颖的,不是引用最多的,而是工程师真正应该构建的方案。这正是从开放式头脑风暴转向明确选择的关键:NeuroArxiv 会给出单一建议,因为“这里有 4 篇论文,由你决定”正是这项技能旨在避免的时间浪费。
  4. 综合。 针对选定的集群,给出:一份 4-8 句话的实现草案(可操作,而非文献综述摘要)、引用(论文 ID + 标题 + URL + 作用——“主要机制” / “辅助证据” / “应避免的失效模式”——且只依据已获取的数据)、第一个具体步骤、关键风险,以及一份从每篇论文的局限中提取的“避免”清单(不只包括胜出论文——被拒绝集群中的论文指出的陷阱同样值得避免)。
  5. 说明次选方案。 对每个未选集群,用一句坦诚的话说明它因何种真实权衡而落选。这不是否定——应让构建者日后能够切换路径,并了解原因。
  6. 留下一个待解问题。 提出一个阅读过的论文引出却未回答的问题——值得在发布前的设计评审中检查。

输出格式

  1. 已检索。 类别、搜索词、论文数量。
  2. 已阅读的论文。 按簇分组。每篇论文:id、标题、一句话概述方法、评分标签 [rel8 prac6 rig7]。
  3. 先前工作中的陷阱。 局限性揭示了真实陷阱的论文——单独列为注意事项,而非结论。
  4. THE PATH. 选定的一个簇:构想、引用、第一步、关键风险、避免事项。这是最终交付内容——要醒目突出,不能淹没在论文列表中。
  5. 考虑过但未选择的替代方案。 每项一行。
  6. 悬而未决的问题。 尚未得到解答的问题。

反模式

  • 阅读时相互污染。 如果某篇论文的阅读记录提到“与这里的其他论文相比”或“这些论文共同表明”,说明隔离失效了——丢弃该阅读记录,并单独重新阅读。
  • 捏造引用。 切勿陈述实际获取的摘要中没有的论文细节(数字、主张、结果)。如有疑问,重新获取,不要根据标题推断。
  • 用候选清单敷衍了事。 在 Phase 3 结尾说“这里有 3 个不错的选项”,而不是给出一个推荐,会让整个流程失去意义。作出明确选择。
  • 为稀少的结果凑数。 相关论文为零或很少,也是有效且有用的发现——这意味着该机制确实新颖,或搜索词不合适。坦诚说明。不要硬把无关论文扯进来,假装覆盖全面。
  • 把论文摘要当作整篇论文。 摘要只是线索,并不能证明其中未提及的实现细节。“借鉴”和“避免”事项应限于摘要实际支持的内容。

校准

  • 需要多少篇论文? 默认每个类别 4 篇 × 3–5 个类别 ≈ 12–20 篇。对于范围狭窄或广为人知的机制,可减少数量(领域较小时,每个类别 2 篇就够);对于真正不明确的领域,可增加数量。
  • 何时停止扩大搜索范围? 如果仅针对类别重试(去掉搜索词)仍找不到可用结果,就说明情况并继续下一步——不要为了追求结果数量而不断扩展到无关类别。

成本

1 次分类 + N 次独立阅读(通常 12–20 次)+ 1 次评分 + 1 次聚类 + 1 次收敛 ≈ N+4 次 Agent 形式的调用,另外还需执行真正的 arXiv HTTP 获取(各类别之间礼貌地延迟约 3 秒)。这不适用于每个设计决策——只适用于架构选错会造成实际返工的情况。

配套库和 CLI

此仓库还提供 Node/TS 实现(src/),可通过真实 arXiv HTTP 和 Claude Agent SDK 运行同一流程——适用于 Claude Code 之外的场景、脚本化/批量运行,或希望通过确定性代码而非 WebFetch 调用来获取和解析内容的情况。

npm install
npm run build
neuroarxiv "how should I cache LLM completions across requests?"

上面的 skill 无需安装,即可在 Claude Code 中运行相同流程。

评论

支持 Markdown