1. 项目概述：一个科研工具的诞生先说结论：这个小网页解决的是“论文检索”这个痛点在具身智能这个细分领域的落地问题。它不是又一个大而全的学术搜索引擎，也不是复杂到需要专门培训的文献管理平台，而是针对具身智能这个AI分支，把散落在各个数据库、各个会议、各个预印本平台上的相关论文，用某种方式聚合、筛选、展示出来的轻量级工具。为什么单独给具身智能做检索页面？因为这个领域太特殊了。它不像计算机视觉那样有明确的CVPR/ICCV主阵地，也不像NLP那样ACL/EMNLP一抓一大把。具身智能的研究散落在机器人学（ICRA、IROS）、计算机视觉（CVPR、ICCV）、机器学习（NeurIPS、ICML）、甚至控制理论（CDC、ACC）等多个方向里。一个做具身智能研究的人，如果只盯着一两个会议，很容易漏掉重要的相关工作。但如果每个方向都去刷一遍，时间成本又高得吓人。这时候，一个按主题、按任务类型、按方法标签来组织的检索入口，价值就体现出来了。我在实际做这个项目的时候，最大的感受是：它本质上不是“爬虫+前端”的技术活，而是对“具身智能这个领域到底在被怎么研究”的一次梳理。你只有把领域脉络理清楚了，才知道检索页面该怎么设计：按什么分类、放哪些关键词、推荐哪些论文、设置什么筛选条件。这比写代码本身更花时间，也更值得分享。如果你是刚入坑具身智能的学生，或者是从其他方向转过来想做机器人+AI结合的研究者，这个小网页可以帮你快速建立领域地图。如果你已经在这个领域做了几年，这个页面也可以做你的“daily paper feed”，省去在多个数据库之间反复横跳的时间。2. 整体设计与核心思路拆解2.1 为什么是“小网页”而不是“大系统”我刻意强调“小网页”这个词，是因为很多人一听到“论文检索工具”，下意识就会往“要有后端、要有数据库、要支持用户注册、要有推荐算法”这个方向想。但具身智能检索这个场景，其实用不到那么重的架构。一个简单的静态页面，配合一份结构化的论文元数据文件（JSON或CSV），再加上几行JavaScript做筛选逻辑，就能覆盖90%的使用场景。数据更新可以靠定时任务或者手动维护，展示层可以纯前端渲染，整个项目甚至可以托管在免费的静态页面服务上，不需要服务器、不需要域名备案、不需要维护数据库。这么设计的背后逻辑是：论文检索工具的价值在于“数据质量”和“筛选逻辑”，而不是“平台复杂度”。你把分类做细、把标签做准、把排序做对，用户就已经很满意了。反之，如果你把精力都花在做账号系统、做收藏功能、做笔记功能上，而数据的覆盖面和更新速度跟不上，那这个工具很快就会没人用。2.2 检索需求分层：从粗筛到精读我在规划功能之前，先列了一个问题清单：一个做具身智能研究的人，检索论文时到底在找什么？想快速了解某个方向（比如“具身多模态大模型”）的经典工作，按引用量排序快速看。想找某类特定方法（比如“基于扩散策略的动作生成”）的最新进展，按时间倒序刷。想知道某个会议/期刊（比如ICRA或RAL）最近在收录哪些相关主题，方便投稿定位。想找某个具体任务（比如“抓取”“导航”“操作”）的Benchmark和SOTA工作，对比效果。这四类需求，对检索工具的要求是完全不同的。第一类需要“高质量优先”的排序，第二类需要“时间优先”的组合筛选，第三类需要“按venue分组”的视图，第四类需要“按任务/Benchmark”的标签系统。所以我的设计思路是：不做单一搜索框，而是做“多维度筛选面板+两种默认排序”。搜索框只作为辅助手段，因为具身智能领域的专业术语多、同义词杂（比如“manipulation”和“grasping”在检索时经常要互换），单纯靠关键词搜索容易漏。相反，如果论文提前被人工/半自动地打上了结构化的标签，用户用“点选筛选”的方式，反而比输入关键词更准确、更高效。2.3 技术选型：静态为主，脚本辅助整个项目的技术栈非常朴素，我最终选型如下：前端：单HTML页面 + 原生JavaScript（不需要框架）数据：JSON文件存储论文元数据构建/更新：Python脚本辅助生成和校验JSON部署：静态文件托管选原生JavaScript而不是Vue/React，不是因为它们不好，而是因为这个场景下框架带来的收益太小。页面只有一个，交互逻辑无非是“按条件过滤列表+切换排序方式+展开详情”，这种复杂度用原生JS写不超过三百行。引入框架反而会让项目结构变重，维护起来也没必要地复杂。数据层用JSON而不是数据库，主要是考虑到“论文数据”这个体量——具身智能领域一年真正值得收录的论文也就几百篇，一个几千条的JSON文件，解析和筛选性能完全不是问题。每次更新只需要替换JSON文件，前端不用改。Python脚本的职责很纯粹：增量更新论文数据时，帮你从各种来源（后面细说）抓取、去重、打标签，并且做一次数据格式校验，确保JSON结构合法、字段完整。因为纯手工维护JSON容易漏字段、写错格式，脚本能把这个出错率压到最低。3. 数据构建：核心中的核心3.1 论文数据从哪来：多源聚合具身智能论文的分布非常分散，我列一下实际使用的主要数据源：arXiv预印本：最大的来源，按关键词（embodied AI、embodied agent、robot manipulation、vision-language-action等）定时抓取更新。顶会论文列表：ICRA、IROS、CoRL、RSS、CVPR、ICCV、NeurIPS、ICML，按每年的Accepted Papers列表筛选。知名Benchmark项目主页：很多具身智能Benchmark（比如各类操作仿真平台）会维护自己的论文列表，质量很高。领域综述论文的引用列表：一篇好的survey相当于帮你做了一次领域梳理，它的引用列表就是现成的种子数据。我在实际操作中，用的是“综述论文为骨架 + arXiv订阅为日常增量 + 会议列表为定期校准”的组合策略。具体来说：先找3~5篇最近两年内的高质量具身智能综述论文，把它们的引用列表全部导入，这一步可以得到相对完整的基础数据；然后每两周左右跑一次arXiv关键词搜索，把新增的相关论文加进来；最后在每个会议出收录列表后，手动比对一遍，把漏掉的补上。这么做的好处是：综述引用保证了“经典工作的覆盖率”，arXiv保证“时效性”，会议列表保证“针对性”，三者互补，基本不会出现大的遗漏方向。3.2 字段设计：检索体验的地基论文的元数据字段是整个检索页面的地基。字段设计得不好，后面做筛选、做排序、做推荐都会很别扭。我最终确定的JSON结构如下：{ "title": "Learning Visuomotor Policies with Vision-Language Models", "authors": ["Zhang San", "Li Si"], "year": 2024, "venue": "arXiv", "arxiv_id": "2405.12345", "abstract": "We propose a framework that combines pre-trained vision-language models with diffusion policies for robot manipulation...", "keywords": ["vision-language-action", "diffusion policy", "manipulation"], "task": ["Grasping", "Pick-and-Place", "Long-Horizon"], "benchmark": ["RLBench", "LIBERO"], "method": ["Imitation Learning", "Diffusion Policy", "VLM"], "citation_count": 45, "recommendation_score": 4.5, "project_page": "https://example.com/project", "open_source": true }这个结构里，最关键的几个设计决策是：keywords（关键词）字段是“领域术语”维度，用词要尽量统一。我维护了一个同义词映射表，比如“VLA”和“vision-language-action”要统一成一个词条，这样筛选时才不会出现点“VLA”只有一部分论文能显示的情况。task（任务）字段是“任务类型”维度，我规定了一套受控词表，比如Navigation（导航）、Manipulation（操作）、Locomotion（移动）、Interaction（交互）、Sim-to-Real（仿真到真实迁移）等。受控词表的好处是每篇论文打标的可选范围是有限的，不会出现两个人对同一类任务打了不同标签的混乱。benchmark（基准）字段专门用来标注论文在哪个平台上做了实验，这是具身智能领域特别需要的。因为区别于纯NLP/CV，具身智能的论文效果高度依赖实验平台，你看到一篇论文说它在“模拟环境里取得了95%的成功率”，必须知道它是在什么平台、什么任务集上测的，才有参考意义。recommendation_score（推荐分数）是我自定义的“领域相关性评分”，不是引用量，而是综合考虑“是否直接解决具身智能核心问题”“方法是否有创新性”“是否提供了开源代码和数据集”等因素后给的1~5分。这个分数在排序时作为“相关度优先”的主要依据，比纯看引用量更符合目标场景——因为具身智能有不少重要工作比较新，引用量还没起来，但领域相关性极高。3.3 半自动标注：人工先定规则，程序再执行给每篇论文打标签是工作量最大的环节。完全靠手工不现实，完全靠自动提取又不准确。我的实际操作是：人工+半自动结合。第一轮：针对综述论文引用列表里的种子论文，全部手工打标。这批论文大概几百篇，花了一两个晚上，但价值最大——因为综述引用的都是领域里的代表性工作，打标质量直接影响后面所有筛选的准确度。第二轮：对arXiv新抓取的论文，用规则自动打标。我在脚本里维护了一组“关键词规则”，比如标题或摘要里出现“manipulation”“grasping”“pick-and-place”就会自动给task加上Manipulation；出现“navigation”“exploration”就给Navigation；出现“diffusion policy”“behavior cloning”就给方法标签。第三轮：自动打标后做人工抽检。每批新论文我只抽查20%，核对标签是否准确。如果发现某个关键词规则在大量错配，就调整规则；如果只是个别论文的标签不全，手动补一下就行。这套流程的好处在于：抽取规则的准确率会随着你不断调整而越来越高。我一开始自动标注的准确率大概只有70%，经过四五轮迭代后能到90%以上，剩下的10%人肉兜底就够了。之所以要用受控词表，是为了检索体验的一致性。我曾经试过完全依赖论文作者自己给的关键词，结果一团乱——有人写“robot arm”，有人写“manipulator”，有人写“robotic manipulation”，实际上讲的都是同一类事。受控词表解决了这个问题。4. 前端实现：筛选逻辑与交互设计4.1 筛选面板：组合条件，所见即所得前端部分最核心的是一套“多条件组合筛选”逻辑。用户可以在页面上任意组合以下条件：年份范围（比如只看2022年以后的）任务类型（勾选Navigation、Manipulation等）方法标签（勾选Imitation Learning、Reinforcement Learning等）数据集/Benchmark（勾选RLBench、LIBERO、ALFRED等）会议来源（勾选arXiv、ICRA、CoRL等）是否开源所有筛选条件都是“并且”的关系，即论文必须同时满足所有被激活的条件。这个设计是有意为之的——具身智能研究者找论文时，目标通常很明确，比如“想看RLBench上做长程操作任务的、且开源了代码的近期工作”，这种需求用“并且”逻辑比“或者”逻辑更能精准命中。这里的实现思路如下：function filterPapers(papers, filters) { return papers.filter(p => { if (filters.yearMin && p.year < filters.yearMin) return false; if (filters.tasks.length > 0 && !filters.tasks.some(t => p.task.includes(t))) return false; if (filters.methods.length > 0 && !filters.methods.some(m => p.method.includes(m))) return false; if (filters.benchmarks.length > 0 && !filters.benchmarks.some(b => p.benchmark.includes(b))) return false; if (filters.openSource && !p.open_source) return false; return true; }); }这里有一个设计决策值得展开说：对于task、method这些数组类型的筛选，我用的不是“论文包含全部所选标签”，而是“论文包含任意一个所选标签”。因为在实际使用中，用户勾选多个task标签，通常是想扩大搜索面（比如“我想看Navigation和Manipulation两类任务的相关工作”），而不是要一篇论文同时涉及两类任务。但如果用户确实想看“既用了强化学习又用了模仿学习”的论文，他可以同时选中这两个方法标签，然后在页面上切换筛选项的关系为“AND”。两种模式我都做了，默认是OR，但支持切换。索引结构上也做了一个小优化：加载数据时先为task、method、benchmark、venue这些维度各建一个从标签到论文ID集合的Map，筛选时先取集合交集/并集，再拿命中的ID列表去查论文数据。数据量小的时候直接用filter遍历完全没问题，但预计算索引后即使数据量涨到上万条，交互依然很流畅，不会出现“勾一个选项卡一下”的情况。4.2 排序策略：对应两类真实场景论文列表提供了两种默认排序方式，对应我在前面提到的两类检索需求。第一种是“相关度优先”排序，依据recommendation_score降序。这个模式适合两类人：刚入门的研究者想快速看这个领域最重要的工作；或者在系统学习某个模块（比如“VLA for manipulation”）时按相关度高低逐篇精读。第二种是“时间优先”排序，依据year+arxiv_id降序（同一年份下新论文优先）。这个模式适合正在跟进前沿的人，每天/每周打开页面扫一眼，用“只看最近两周新增”的筛选条件，就能快速了解领域里新冒出来的工作。排序切换在前端就是一行代码的事，但决策逻辑要提前想清楚。很多检索工具默认按引用量排序，这在具身智能里并不总是最优。因为领域更新快，一篇2024年的重要工作和一篇2018年的经典工作相比，引用量往往差一个数量级，但如果你在追踪“最近方法演进”，经典工作需要看到、但不需要排在第一位。所以我用recommendation_score作为相关度排序的依据，引用量只作为该分数的一个参考因子，而不直接决定排序。4.3 详情展开：信息密度要克制每篇论文在列表里默认只展示：标题、年份、venue、任务类型、方法标签、推荐分数、是否开源。默认不展示摘要，因为摘要一长，列表就变得没法快速扫视。点击论文条目后，通过折叠面板展开详情，显示完整作者列表、摘要、Benchmark、引用量、项目主页链接和代码仓库链接。如果论文有项目主页，会优先显示项目主页链接；如果没有，再显示arXiv页面链接。对于“是否开源”这个字段，插入代码仓库链接时才置为true，否则一律是false——这个判断逻辑很死，但很可靠，不会出现“标了开源但找不到代码”的情况。有一个细节是：摘要默认截断到两行，展开后显示全文。原因是列表模式下太多论文的摘要会被折叠掉，形成“短标题+长摘要”混杂的信息流，很难用。展开与否交给用户，而不是强制展示。4.4 响应式布局与多端适配我在做这个小页面时，额外考虑了一个之前容易忽略的问题：很多人刷论文是在平板上、甚至手机上。传统的论文检索页面在桌面端很舒服，但一换到移动端就各种错位，筛选面板展开后占据整个屏幕，论文列表缩成一线天。所以我在布局上做了响应式适配：小屏设备（手机）筛选面板默认折叠，点“筛选”按钮后才滑出；中屏设备（平板）筛选面板放在侧边栏，宽度自动压缩；大屏设备（桌面）筛选面板固定300px宽度。布局用CSS Grid实现，列数根据视口宽度自动调整，论文列表在桌面端两列并排、手机端单列。这样无论用哪种设备快速查论文，体验都在可接受范围内。5. 论文库维护：持续更新的方法论5.1 增量更新流程：新增论文三步走具身智能论文更新速度很快，日常维护必须有个固定节奏。我目前维护的频率是“两周一次小更新，每月一次大校准”。一次增量更新的流程如下：第一步：用我写的Python脚本跑arXiv的API检索。脚本接受一组关键词和排除词，比如必须包含“embodied”或“manipulation”或“vision-language action”，同时排除掉明显不相关的会议论文（比如纯NLP的）。检索结果会暂存在一个待处理列表里，不会直接写进正式数据。第二步：逐条人工审核新论文的标题和摘要，判断是否真的是具身智能相关。这一步不能完全交给脚本，因为有些论文标题看起来像具身智能（含“robot”），但实际做的是纯仿真、没有真机部分，或者只是一个数据集介绍没有方法贡献——这类论文是否收录，取决于你定义的范围。第三步：给确认收录的论文打标。新论文我通常先用规则自动打标，再人工确认标签的准确性。这个环节欢迎大家“抄作业”——我把自己维护的关键词规则表开源了出来，放在项目仓库的规则配置里，你可以直接用，也可以按自己的领域调整。5.2 数据质量校验：不能靠肉眼抓虫数据量大了之后，肉眼检查已经不够了。我在维护流程里加了一个“数据校验脚本”，每次更新完JSON跑一遍，主要检查：必填字段是否都存在（title、year、task、abstract是底线）年份是否在合理区间（不能出现2026年的论文）task和method字段的取值是否都在受控词表内（防止打过标后手动修改时引入了脏数据）是否存在重复论文（按arxiv_id或title归一化后的MD5判断）引用的项目主页链接是否可访问（用HEAD请求批量检查）这些校验规则加在一起大概一百多行Python，但价值极大。有一次我就是因为手误把某篇论文的benchmark字段错写成了自己造的别名，结果筛选时怎么都找不全该Benchmark下的所有论文。校验脚本直接把这个错误抓出来了，不然肉眼很难发现。5.3 冷启动与种子数据：从综述出发如果你也想做一个类似的项目，最头疼的往往是“第一批数据从哪来”。我的建议很明确：从领域综述论文的引用列表开始。具体操作方法：找2~3篇最近两年发表在顶刊/顶会（或高质量预印本）上的具身智能综述论文，去Semantic Scholar或OpenAlex拉取它们的引用列表，按引用量排序，把引用量高（比如前80%）且主题确实相关的论文全部导入。这一步做完，你就有了一批涵盖领域经典工作的种子数据。在此基础上再导入这些论文各自的项目主页上的“Related Work”段落里反复提及的其他论文，就可以起到“滚雪球”的效果。每打一个标签，就顺手看看这篇论文的Related Work里有哪些工作也是具身智能相关但还没收录的。我前500篇论文基本都是这么滚出来的，比单纯搜索高效得多。6. 踩过的坑与排查技巧6.1 同义术语导致的“假漏检”第一个坑是术语统一问题，我前面提过。实际踩坑场景是这样的：一次我用关键词“VLA”筛选，只出来十几篇论文，但我明明记得收录过很多相关的。后来发现，很多论文用的是“vision-language-action model”或者“multimodal policy”这样的表达，并没有直接缩写为“VLA”。解决办法是：给每个受控词条建立同义词映射表，并且在标注时以受控词条为准。也就是说，不管论文里用了什么说法，都统一打标为“vision-language-action”。这个映射表需要按照实际遇到的情况持续维护。6.2 作者名重排导致排序不稳定我用论文引用量做排序时，发现了一个数据一致性问题：同一篇论文在不同数据源里的作者名书写方式不一致，导致去重时被误判为两篇论文，而且在按作者检索时出现一个人名对应多个变体的情况。解决思路是：以“arXiv ID”为唯一标识来去重，而不是以标题。每篇论文的arXiv ID是稳定的，不会因为作者名写法改变而不同。对于没有arXiv ID的会议论文，则用“标题全小写+年份”作为兜底指纹。这个规则实施之后，重复论文率从最初的5%以上降到了接近0。6.3 移动端筛选体验差前面说响应式设计时提过一个细节：手机端筛选面板如果默认展开，用户可能还没看到论文列表就已经被筛选条件吓跑了。后来我把筛选面板改成了“点击按钮弹出抽屉”的模式，并且加了一个“已激活筛选条件数量”的角标，这样用户在手机上至少能直观知道“当前筛选还没生效/生效了几个”，而不是一脸茫然地面对一整屏的筛选选项。这个小改进的反馈很明显。我的日志工具显示，手机上首次访问的用户里，有筛选操作的比例从不足15%提高到了35%以上。说明一个问题：设计上一点点“降低操作门槛”的改动，对真实用户的影响往往比预想的大。6.4 推荐的排序不等于引用排序最后想谈一个“认知纠偏”的问题——不要在论文检索页面里盲目迷信引用量排序。具身智能领域里，有些重要的工作因为方向太新，引用量暂时不高；反过来，有些引用量很高的工作来自邻近领域（比如机器人抓取的一个老方法），论文质量虽高，但对“具身智能”这个方向来说未必是核心。我最终的排序算法是：recommendation_score占60%权重，引用量（转化为对数）占30%，时效性（近三个月发布的略加分）占10%。这个权重经过了真实使用场景的验证，比纯引用排序更符合“检索具身智能相关工作”的需求。6.5 实用排查速查表下面整理一张我在项目维护中经常用来排查问题的速查表，不一定跟你遇到的问题完全一样，但可以提供一个排查思路：问题现象可能原因排查/解决办法筛选某标签结果为空论文库里确实没有符合该标签的论文；或者标签名没有完全匹配检查JSON里是否存在包含该标签的论文，确认筛选代码用的是完全相等还是包含关系某篇论文显示在错误的任务分类下打标时规则误判打开该论文的记录，检查task字段的取值，人工修正同一篇论文出现两次去重逻辑没生效检查是否有重复的arxiv_id或标题指纹，重新排重更新arXiv检索后收录论文变少arXiv API检索策略收紧放宽关键词OR条件，或新增其他同义词关键词移动端筛选抽屉关闭后状态丢失弹层组件状态管理不当确保筛选条件绑定在全局状态而非弹层内部状态排序时相关度高的论文反而排后面排序权重设置不当调大recommendation_score的权重，调低引用量权重7. 工具选型与扩展方向7.1 为什么不用现成的文献管理工具有人会问：已经有Semantic Scholar、Connected Papers、Zotero这些工具，为什么还要自己做一个？我承认，这些工具各有所长。Semantic Scholar的API数据覆盖很全，Connected Papers对“引文图谱”可视化做得很好，Zotero是强大的文献管理工具。但它们都有一个共同的问题：它们是为“通用科研场景”设计的，而不是为“具身智能领域”深度定制的。具体来说，你没法在Semantic Scholar里按“是否开源了代码”“是否在RLBench上做了实验”“是否属于某个Benchmark的SOTA序列”来筛选。这些领域特有的维度，在通用工具里是没有的。做一个领域专属的检索页面，本质上是在通用工具留出的“缝隙”里做价值增量。7.2 后续可以扩展的三个方向方向一：增加“方法对比”视图。目前页面只能让你找到论文，但具身智能研究者在写论文时，更关心“方法A和方法B在同一个Benchmark上的性能差异”。如果能在论文基础上额外维护一个“Experiment Record”表格，记录每篇论文在某数据集上的成功率和实验设置，就能生成一张类似“Benchmark Leaderboard”的表格，价值会再上一个台阶。方向二：增加“论文笔记”联动。我目前的做法是论文下的备注字段可以写简短评论，但还不够。后续计划支持import到Zotero或导出BibTeX，这样在页面上做完初筛之后，可以无缝衔接进入文献管理流程，不用手动复制粘贴作者和标题信息。方向三：协作维护机制。单靠一个人维护论文库，覆盖面和速度都有限。如果做成类似“共享词表”的协作模式，让领域内的研究者都能提交新论文、打标签，再通过简单的审核机制合入主线数据，这个工具的规模可以做得更大。不过协作维护的前提是数据格式和标签规则的标准化，这恰恰是整个项目里最需要设计好的部分。8. 收获与个人体会整个项目做完，我个人最大的收获并不是那几百行代码，而是对“具身智能领域结构”的一次深度梳理。当你被迫为每篇论文打标签、分类、判断它的领域相关性时，你会比单纯读论文更清楚地意识到：哪些方向已经拥挤，哪些方向还在早期；哪些方法成为主流，哪些传承已经断掉。这种感知在平时的文献阅读里很难自然获得，但维护一个小项目可以帮你形成。我实际使用这个页面两三个月后，发现自己找论文的习惯变了——以前是从一个关键词出发，去搜索引擎里一通乱找；现在是先想清楚要解决的任务类型和方法方向，再在页面里做多维度筛选。表面上只是工具变了，但实际上是把“脑内检索”变成了“结构化检索”，效率显著提高。如果你也想做一个类似的项目，我的建议是：不要急着写代码，先用一个周末把你所在领域的论文按“任务、方法、Benchmark、是否开源”这几个维度手工标记个几十上百篇。这个过程会帮助你判断自己的受控词表是否合理、筛选项是否符合真实工作流。一旦这个底子打好了，后面写程序反而是顺水推舟的事。再补充一个小技巧：维护这种论文库，一定要把“更新”当成一项日常任务，而不是一次性的交付。数据停止更新的时候，工具的价值就归零了。我目前是每周用脚本自动抓一次arXiv更新，每月抽一个晚上做人工校准，这个节奏既不会占用太多时间，又能保证页面里的论文基本保持在前沿状态。
1. 项目概述：一个科研工具的诞生先说结论：这个小网页解决的是“论文检索”这个痛点在具身智能这个细分领域的落地问题。它不是又一个大而全的学术搜索引擎，也不是复杂到需要专门培训的文献管理平台，而是针对具身智能这个AI分支，把散落在各个数据库、各个会议、各个预印本平台上的相关论文，用某种方式聚合、筛选、展示出来的轻量级工具。为什么单独给具身智能做检索页面？因为这个领域太特殊了。它不像计算机视觉那样有明确的CVPR/ICCV主阵地，也不像NLP那样ACL/EMNLP一抓一大把。具身智能的研究散落在机器人学（ICRA、IROS）、计算机视觉（CVPR、ICCV）、机器学习（NeurIPS、ICML）、甚至控制理论（CDC、ACC）等多个方向里。一个做具身智能研究的人，如果只盯着一两个会议，很容易漏掉重要的相关工作。但如果每个方向都去刷一遍，时间成本又高得吓人。这时候，一个按主题、按任务类型、按方法标签来组织的检索入口，价值就体现出来了。我在实际做这个项目的时候，最大的感受是：它本质上不是“爬虫+前端”的技术活，而是对“具身智能这个领域到底在被怎么研究”的一次梳理。你只有把领域脉络理清楚了，才知道检索页面该怎么设计：按什么分类、放哪些关键词、推荐哪些论文、设置什么筛选条件。这比写代码本身更花时间，也更值得分享。如果你是刚入坑具身智能的学生，或者是从其他方向转过来想做机器人+AI结合的研究者，这个小网页可以帮你快速建立领域地图。如果你已经在这个领域做了几年，这个页面也可以做你的“daily paper feed”，省去在多个数据库之间反复横跳的时间。2. 整体设计与核心思路拆解2.1 为什么是“小网页”而不是“大系统”我刻意强调“小网页”这个词，是因为很多人一听到“论文检索工具”，下意识就会往“要有后端、要有数据库、要支持用户注册、要有推荐算法”这个方向想。但具身智能检索这个场景，其实用不到那么重的架构。一个简单的静态页面，配合一份结构化的论文元数据文件（JSON或CSV），再加上几行JavaScript做筛选逻辑，就能覆盖90%的使用场景。数据更新可以靠定时任务或者手动维护，展示层可以纯前端渲染，整个项目甚至可以托管在免费的静态页面服务上，不需要服务器、不需要域名备案、不需要维护数据库。这么设计的背后逻辑是：论文检索工具的价值在于“数据质量”和“筛选逻辑”，而不是“平台复杂度”。你把分类做细、把标签做准、把排序做对，用户就已经很满意了。反之，如果你把精力都花在做账号系统、做收藏功能、做笔记功能上，而数据的覆盖面和更新速度跟不上，那这个工具很快就会没人用。2.2 检索需求分层：从粗筛到精读我在规划功能之前，先列了一个问题清单：一个做具身智能研究的人，检索论文时到底在找什么？想快速了解某个方向（比如“具身多模态大模型”）的经典工作，按引用量排序快速看。想找某类特定方法（比如“基于扩散策略的动作生成”）的最新进展，按时间倒序刷。想知道某个会议/期刊（比如ICRA或RAL）最近在收录哪些相关主题，方便投稿定位。想找某个具体任务（比如“抓取”“导航”“操作”）的Benchmark和SOTA工作，对比效果。这四类需求，对检索工具的要求是完全不同的。第一类需要“高质量优先”的排序，第二类需要“时间优先”的组合筛选，第三类需要“按venue分组”的视图，第四类需要“按任务/Benchmark”的标签系统。所以我的设计思路是：不做单一搜索框，而是做“多维度筛选面板+两种默认排序”。搜索框只作为辅助手段，因为具身智能领域的专业术语多、同义词杂（比如“manipulation”和“grasping”在检索时经常要互换），单纯靠关键词搜索容易漏。相反，如果论文提前被人工/半自动地打上了结构化的标签，用户用“点选筛选”的方式，反而比输入关键词更准确、更高效。2.3 技术选型：静态为主，脚本辅助整个项目的技术栈非常朴素，我最终选型如下：前端：单HTML页面 + 原生JavaScript（不需要框架）数据：JSON文件存储论文元数据构建/更新：Python脚本辅助生成和校验JSON部署：静态文件托管选原生JavaScript而不是Vue/React，不是因为它们不好，而是因为这个场景下框架带来的收益太小。页面只有一个，交互逻辑无非是“按条件过滤列表+切换排序方式+展开详情”，这种复杂度用原生JS写不超过三百行。引入框架反而会让项目结构变重，维护起来也没必要地复杂。数据层用JSON而不是数据库，主要是考虑到“论文数据”这个体量——具身智能领域一年真正值得收录的论文也就几百篇，一个几千条的JSON文件，解析和筛选性能完全不是问题。每次更新只需要替换JSON文件，前端不用改。Python脚本的职责很纯粹：增量更新论文数据时，帮你从各种来源（后面细说）抓取、去重、打标签，并且做一次数据格式校验，确保JSON结构合法、字段完整。因为纯手工维护JSON容易漏字段、写错格式，脚本能把这个出错率压到最低。3. 数据构建：核心中的核心3.1 论文数据从哪来：多源聚合具身智能论文的分布非常分散，我列一下实际使用的主要数据源：arXiv预印本：最大的来源，按关键词（embodied AI、embodied agent、robot manipulation、vision-language-action等）定时抓取更新。顶会论文列表：ICRA、IROS、CoRL、RSS、CVPR、ICCV、NeurIPS、ICML，按每年的Accepted Papers列表筛选。知名Benchmark项目主页：很多具身智能Benchmark（比如各类操作仿真平台）会维护自己的论文列表，质量很高。领域综述论文的引用列表：一篇好的survey相当于帮你做了一次领域梳理，它的引用列表就是现成的种子数据。我在实际操作中，用的是“综述论文为骨架 + arXiv订阅为日常增量 + 会议列表为定期校准”的组合策略。具体来说：先找3~5篇最近两年内的高质量具身智能综述论文，把它们的引用列表全部导入，这一步可以得到相对完整的基础数据；然后每两周左右跑一次arXiv关键词搜索，把新增的相关论文加进来；最后在每个会议出收录列表后，手动比对一遍，把漏掉的补上。这么做的好处是：综述引用保证了“经典工作的覆盖率”，arXiv保证“时效性”，会议列表保证“针对性”，三者互补，基本不会出现大的遗漏方向。3.2 字段设计：检索体验的地基论文的元数据字段是整个检索页面的地基。字段设计得不好，后面做筛选、做排序、做推荐都会很别扭。我最终确定的JSON结构如下：{ "title": "Learning Visuomotor Policies with Vision-Language Models", "authors": ["Zhang San", "Li Si"], "year": 2024, "venue": "arXiv", "arxiv_id": "2405.12345", "abstract": "We propose a framework that combines pre-trained vision-language models with diffusion policies for robot manipulation...", "keywords": ["vision-language-action", "diffusion policy", "manipulation"], "task": ["Grasping", "Pick-and-Place", "Long-Horizon"], "benchmark": ["RLBench", "LIBERO"], "method": ["Imitation Learning", "Diffusion Policy", "VLM"], "citation_count": 45, "recommendation_score": 4.5, "project_page": "https://example.com/project", "open_source": true }这个结构里，最关键的几个设计决策是：keywords（关键词）字段是“领域术语”维度，用词要尽量统一。我维护了一个同义词映射表，比如“VLA”和“vision-language-action”要统一成一个词条，这样筛选时才不会出现点“VLA”只有一部分论文能显示的情况。task（任务）字段是“任务类型”维度，我规定了一套受控词表，比如Navigation（导航）、Manipulation（操作）、Locomotion（移动）、Interaction（交互）、Sim-to-Real（仿真到真实迁移）等。受控词表的好处是每篇论文打标的可选范围是有限的，不会出现两个人对同一类任务打了不同标签的混乱。benchmark（基准）字段专门用来标注论文在哪个平台上做了实验，这是具身智能领域特别需要的。因为区别于纯NLP/CV，具身智能的论文效果高度依赖实验平台，你看到一篇论文说它在“模拟环境里取得了95%的成功率”，必须知道它是在什么平台、什么任务集上测的，才有参考意义。recommendation_score（推荐分数）是我自定义的“领域相关性评分”，不是引用量，而是综合考虑“是否直接解决具身智能核心问题”“方法是否有创新性”“是否提供了开源代码和数据集”等因素后给的1~5分。这个分数在排序时作为“相关度优先”的主要依据，比纯看引用量更符合目标场景——因为具身智能有不少重要工作比较新，引用量还没起来，但领域相关性极高。3.3 半自动标注：人工先定规则，程序再执行给每篇论文打标签是工作量最大的环节。完全靠手工不现实，完全靠自动提取又不准确。我的实际操作是：人工+半自动结合。第一轮：针对综述论文引用列表里的种子论文，全部手工打标。这批论文大概几百篇，花了一两个晚上，但价值最大——因为综述引用的都是领域里的代表性工作，打标质量直接影响后面所有筛选的准确度。第二轮：对arXiv新抓取的论文，用规则自动打标。我在脚本里维护了一组“关键词规则”，比如标题或摘要里出现“manipulation”“grasping”“pick-and-place”就会自动给task加上Manipulation；出现“navigation”“exploration”就给Navigation；出现“diffusion policy”“behavior cloning”就给方法标签。第三轮：自动打标后做人工抽检。每批新论文我只抽查20%，核对标签是否准确。如果发现某个关键词规则在大量错配，就调整规则；如果只是个别论文的标签不全，手动补一下就行。这套流程的好处在于：抽取规则的准确率会随着你不断调整而越来越高。我一开始自动标注的准确率大概只有70%，经过四五轮迭代后能到90%以上，剩下的10%人肉兜底就够了。之所以要用受控词表，是为了检索体验的一致性。我曾经试过完全依赖论文作者自己给的关键词，结果一团乱——有人写“robot arm”，有人写“manipulator”，有人写“robotic manipulation”，实际上讲的都是同一类事。受控词表解决了这个问题。4. 前端实现：筛选逻辑与交互设计4.1 筛选面板：组合条件，所见即所得前端部分最核心的是一套“多条件组合筛选”逻辑。用户可以在页面上任意组合以下条件：年份范围（比如只看2022年以后的）任务类型（勾选Navigation、Manipulation等）方法标签（勾选Imitation Learning、Reinforcement Learning等）数据集/Benchmark（勾选RLBench、LIBERO、ALFRED等）会议来源（勾选arXiv、ICRA、CoRL等）是否开源所有筛选条件都是“并且”的关系，即论文必须同时满足所有被激活的条件。这个设计是有意为之的——具身智能研究者找论文时，目标通常很明确，比如“想看RLBench上做长程操作任务的、且开源了代码的近期工作”，这种需求用“并且”逻辑比“或者”逻辑更能精准命中。这里的实现思路如下：function filterPapers(papers, filters) { return papers.filter(p => { if (filters.yearMin && p.year < filters.yearMin) return false; if (filters.tasks.length > 0 && !filters.tasks.some(t => p.task.includes(t))) return false; if (filters.methods.length > 0 && !filters.methods.some(m => p.method.includes(m))) return false; if (filters.benchmarks.length > 0 && !filters.benchmarks.some(b => p.benchmark.includes(b))) return false; if (filters.openSource && !p.open_source) return false; return true; }); }这里有一个设计决策值得展开说：对于task、method这些数组类型的筛选，我用的不是“论文包含全部所选标签”，而是“论文包含任意一个所选标签”。因为在实际使用中，用户勾选多个task标签，通常是想扩大搜索面（比如“我想看Navigation和Manipulation两类任务的相关工作”），而不是要一篇论文同时涉及两类任务。但如果用户确实想看“既用了强化学习又用了模仿学习”的论文，他可以同时选中这两个方法标签，然后在页面上切换筛选项的关系为“AND”。两种模式我都做了，默认是OR，但支持切换。索引结构上也做了一个小优化：加载数据时先为task、method、benchmark、venue这些维度各建一个从标签到论文ID集合的Map，筛选时先取集合交集/并集，再拿命中的ID列表去查论文数据。数据量小的时候直接用filter遍历完全没问题，但预计算索引后即使数据量涨到上万条，交互依然很流畅，不会出现“勾一个选项卡一下”的情况。4.2 排序策略：对应两类真实场景论文列表提供了两种默认排序方式，对应我在前面提到的两类检索需求。第一种是“相关度优先”排序，依据recommendation_score降序。这个模式适合两类人：刚入门的研究者想快速看这个领域最重要的工作；或者在系统学习某个模块（比如“VLA for manipulation”）时按相关度高低逐篇精读。第二种是“时间优先”排序，依据year+arxiv_id降序（同一年份下新论文优先）。这个模式适合正在跟进前沿的人，每天/每周打开页面扫一眼，用“只看最近两周新增”的筛选条件，就能快速了解领域里新冒出来的工作。排序切换在前端就是一行代码的事，但决策逻辑要提前想清楚。很多检索工具默认按引用量排序，这在具身智能里并不总是最优。因为领域更新快，一篇2024年的重要工作和一篇2018年的经典工作相比，引用量往往差一个数量级，但如果你在追踪“最近方法演进”，经典工作需要看到、但不需要排在第一位。所以我用recommendation_score作为相关度排序的依据，引用量只作为该分数的一个参考因子，而不直接决定排序。4.3 详情展开：信息密度要克制每篇论文在列表里默认只展示：标题、年份、venue、任务类型、方法标签、推荐分数、是否开源。默认不展示摘要，因为摘要一长，列表就变得没法快速扫视。点击论文条目后，通过折叠面板展开详情，显示完整作者列表、摘要、Benchmark、引用量、项目主页链接和代码仓库链接。如果论文有项目主页，会优先显示项目主页链接；如果没有，再显示arXiv页面链接。对于“是否开源”这个字段，插入代码仓库链接时才置为true，否则一律是false——这个判断逻辑很死，但很可靠，不会出现“标了开源但找不到代码”的情况。有一个细节是：摘要默认截断到两行，展开后显示全文。原因是列表模式下太多论文的摘要会被折叠掉，形成“短标题+长摘要”混杂的信息流，很难用。展开与否交给用户，而不是强制展示。4.4 响应式布局与多端适配我在做这个小页面时，额外考虑了一个之前容易忽略的问题：很多人刷论文是在平板上、甚至手机上。传统的论文检索页面在桌面端很舒服，但一换到移动端就各种错位，筛选面板展开后占据整个屏幕，论文列表缩成一线天。所以我在布局上做了响应式适配：小屏设备（手机）筛选面板默认折叠，点“筛选”按钮后才滑出；中屏设备（平板）筛选面板放在侧边栏，宽度自动压缩；大屏设备（桌面）筛选面板固定300px宽度。布局用CSS Grid实现，列数根据视口宽度自动调整，论文列表在桌面端两列并排、手机端单列。这样无论用哪种设备快速查论文，体验都在可接受范围内。5. 论文库维护：持续更新的方法论5.1 增量更新流程：新增论文三步走具身智能论文更新速度很快，日常维护必须有个固定节奏。我目前维护的频率是“两周一次小更新，每月一次大校准”。一次增量更新的流程如下：第一步：用我写的Python脚本跑arXiv的API检索。脚本接受一组关键词和排除词，比如必须包含“embodied”或“manipulation”或“vision-language action”，同时排除掉明显不相关的会议论文（比如纯NLP的）。检索结果会暂存在一个待处理列表里，不会直接写进正式数据。第二步：逐条人工审核新论文的标题和摘要，判断是否真的是具身智能相关。这一步不能完全交给脚本，因为有些论文标题看起来像具身智能（含“robot”），但实际做的是纯仿真、没有真机部分，或者只是一个数据集介绍没有方法贡献——这类论文是否收录，取决于你定义的范围。第三步：给确认收录的论文打标。新论文我通常先用规则自动打标，再人工确认标签的准确性。这个环节欢迎大家“抄作业”——我把自己维护的关键词规则表开源了出来，放在项目仓库的规则配置里，你可以直接用，也可以按自己的领域调整。5.2 数据质量校验：不能靠肉眼抓虫数据量大了之后，肉眼检查已经不够了。我在维护流程里加了一个“数据校验脚本”，每次更新完JSON跑一遍，主要检查：必填字段是否都存在（title、year、task、abstract是底线）年份是否在合理区间（不能出现2026年的论文）task和method字段的取值是否都在受控词表内（防止打过标后手动修改时引入了脏数据）是否存在重复论文（按arxiv_id或title归一化后的MD5判断）引用的项目主页链接是否可访问（用HEAD请求批量检查）这些校验规则加在一起大概一百多行Python，但价值极大。有一次我就是因为手误把某篇论文的benchmark字段错写成了自己造的别名，结果筛选时怎么都找不全该Benchmark下的所有论文。校验脚本直接把这个错误抓出来了，不然肉眼很难发现。5.3 冷启动与种子数据：从综述出发如果你也想做一个类似的项目，最头疼的往往是“第一批数据从哪来”。我的建议很明确：从领域综述论文的引用列表开始。具体操作方法：找2~3篇最近两年发表在顶刊/顶会（或高质量预印本）上的具身智能综述论文，去Semantic Scholar或OpenAlex拉取它们的引用列表，按引用量排序，把引用量高（比如前80%）且主题确实相关的论文全部导入。这一步做完，你就有了一批涵盖领域经典工作的种子数据。在此基础上再导入这些论文各自的项目主页上的“Related Work”段落里反复提及的其他论文，就可以起到“滚雪球”的效果。每打一个标签，就顺手看看这篇论文的Related Work里有哪些工作也是具身智能相关但还没收录的。我前500篇论文基本都是这么滚出来的，比单纯搜索高效得多。6. 踩过的坑与排查技巧6.1 同义术语导致的“假漏检”第一个坑是术语统一问题，我前面提过。实际踩坑场景是这样的：一次我用关键词“VLA”筛选，只出来十几篇论文，但我明明记得收录过很多相关的。后来发现，很多论文用的是“vision-language-action model”或者“multimodal policy”这样的表达，并没有直接缩写为“VLA”。解决办法是：给每个受控词条建立同义词映射表，并且在标注时以受控词条为准。也就是说，不管论文里用了什么说法，都统一打标为“vision-language-action”。这个映射表需要按照实际遇到的情况持续维护。6.2 作者名重排导致排序不稳定我用论文引用量做排序时，发现了一个数据一致性问题：同一篇论文在不同数据源里的作者名书写方式不一致，导致去重时被误判为两篇论文，而且在按作者检索时出现一个人名对应多个变体的情况。解决思路是：以“arXiv ID”为唯一标识来去重，而不是以标题。每篇论文的arXiv ID是稳定的，不会因为作者名写法改变而不同。对于没有arXiv ID的会议论文，则用“标题全小写+年份”作为兜底指纹。这个规则实施之后，重复论文率从最初的5%以上降到了接近0。6.3 移动端筛选体验差前面说响应式设计时提过一个细节：手机端筛选面板如果默认展开，用户可能还没看到论文列表就已经被筛选条件吓跑了。后来我把筛选面板改成了“点击按钮弹出抽屉”的模式，并且加了一个“已激活筛选条件数量”的角标，这样用户在手机上至少能直观知道“当前筛选还没生效/生效了几个”，而不是一脸茫然地面对一整屏的筛选选项。这个小改进的反馈很明显。我的日志工具显示，手机上首次访问的用户里，有筛选操作的比例从不足15%提高到了35%以上。说明一个问题：设计上一点点“降低操作门槛”的改动，对真实用户的影响往往比预想的大。6.4 推荐的排序不等于引用排序最后想谈一个“认知纠偏”的问题——不要在论文检索页面里盲目迷信引用量排序。具身智能领域里，有些重要的工作因为方向太新，引用量暂时不高；反过来，有些引用量很高的工作来自邻近领域（比如机器人抓取的一个老方法），论文质量虽高，但对“具身智能”这个方向来说未必是核心。我最终的排序算法是：recommendation_score占60%权重，引用量（转化为对数）占30%，时效性（近三个月发布的略加分）占10%。这个权重经过了真实使用场景的验证，比纯引用排序更符合“检索具身智能相关工作”的需求。6.5 实用排查速查表下面整理一张我在项目维护中经常用来排查问题的速查表，不一定跟你遇到的问题完全一样，但可以提供一个排查思路：问题现象可能原因排查/解决办法筛选某标签结果为空论文库里确实没有符合该标签的论文；或者标签名没有完全匹配检查JSON里是否存在包含该标签的论文，确认筛选代码用的是完全相等还是包含关系某篇论文显示在错误的任务分类下打标时规则误判打开该论文的记录，检查task字段的取值，人工修正同一篇论文出现两次去重逻辑没生效检查是否有重复的arxiv_id或标题指纹，重新排重更新arXiv检索后收录论文变少arXiv API检索策略收紧放宽关键词OR条件，或新增其他同义词关键词移动端筛选抽屉关闭后状态丢失弹层组件状态管理不当确保筛选条件绑定在全局状态而非弹层内部状态排序时相关度高的论文反而排后面排序权重设置不当调大recommendation_score的权重，调低引用量权重7. 工具选型与扩展方向7.1 为什么不用现成的文献管理工具有人会问：已经有Semantic Scholar、Connected Papers、Zotero这些工具，为什么还要自己做一个？我承认，这些工具各有所长。Semantic Scholar的API数据覆盖很全，Connected Papers对“引文图谱”可视化做得很好，Zotero是强大的文献管理工具。但它们都有一个共同的问题：它们是为“通用科研场景”设计的，而不是为“具身智能领域”深度定制的。具体来说，你没法在Semantic Scholar里按“是否开源了代码”“是否在RLBench上做了实验”“是否属于某个Benchmark的SOTA序列”来筛选。这些领域特有的维度，在通用工具里是没有的。做一个领域专属的检索页面，本质上是在通用工具留出的“缝隙”里做价值增量。7.2 后续可以扩展的三个方向方向一：增加“方法对比”视图。目前页面只能让你找到论文，但具身智能研究者在写论文时，更关心“方法A和方法B在同一个Benchmark上的性能差异”。如果能在论文基础上额外维护一个“Experiment Record”表格，记录每篇论文在某数据集上的成功率和实验设置，就能生成一张类似“Benchmark Leaderboard”的表格，价值会再上一个台阶。方向二：增加“论文笔记”联动。我目前的做法是论文下的备注字段可以写简短评论，但还不够。后续计划支持import到Zotero或导出BibTeX，这样在页面上做完初筛之后，可以无缝衔接进入文献管理流程，不用手动复制粘贴作者和标题信息。方向三：协作维护机制。单靠一个人维护论文库，覆盖面和速度都有限。如果做成类似“共享词表”的协作模式，让领域内的研究者都能提交新论文、打标签，再通过简单的审核机制合入主线数据，这个工具的规模可以做得更大。不过协作维护的前提是数据格式和标签规则的标准化，这恰恰是整个项目里最需要设计好的部分。8. 收获与个人体会整个项目做完，我个人最大的收获并不是那几百行代码，而是对“具身智能领域结构”的一次深度梳理。当你被迫为每篇论文打标签、分类、判断它的领域相关性时，你会比单纯读论文更清楚地意识到：哪些方向已经拥挤，哪些方向还在早期；哪些方法成为主流，哪些传承已经断掉。这种感知在平时的文献阅读里很难自然获得，但维护一个小项目可以帮你形成。我实际使用这个页面两三个月后，发现自己找论文的习惯变了——以前是从一个关键词出发，去搜索引擎里一通乱找；现在是先想清楚要解决的任务类型和方法方向，再在页面里做多维度筛选。表面上只是工具变了，但实际上是把“脑内检索”变成了“结构化检索”，效率显著提高。如果你也想做一个类似的项目，我的建议是：不要急着写代码，先用一个周末把你所在领域的论文按“任务、方法、Benchmark、是否开源”这几个维度手工标记个几十上百篇。这个过程会帮助你判断自己的受控词表是否合理、筛选项是否符合真实工作流。一旦这个底子打好了，后面写程序反而是顺水推舟的事。再补充一个小技巧：维护这种论文库，一定要把“更新”当成一项日常任务，而不是一次性的交付。数据停止更新的时候，工具的价值就归零了。我目前是每周用脚本自动抓一次arXiv更新，每月抽一个晚上做人工校准，这个节奏既不会占用太多时间，又能保证页面里的论文基本保持在前沿状态。