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”时按相关度高低逐篇精读。第二种是“时间优先”排序依据yeararxiv_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更新每月抽一个晚上做人工校准这个节奏既不会占用太多时间又能保证页面里的论文基本保持在前沿状态。