【学习工作赛道】PaperLens —— AI论文速读助手，粘贴论文一键生成结构化摘要与速读卡片
- Demo 简介
PaperLens 是一款纯前端 AI 论文速读助手，帮助科研人员和研究生快速理解英文学术论文的核心内容。
产品形态： 单HTML文件网页应用，零后端依赖，打开即用。
面向用户： 科研人员、研究生、博士生、跨领域学习者——任何需要快速阅读和理解英文学术论文的人。
核心功能：
一键论文分析： 粘贴论文全文（纯文本），自动提取标题、作者、发表信息、中文摘要翻译、研究背景、研究方法、核心结论、关键词标签
速读卡片生成： 将分析结果浓缩为一张结构化速读卡，支持一键复制到剪贴板，方便分享和笔记
论文对比分析： 两篇论文并排对比，从标题、方法、结论、关键词等 11 个维度进行横向比较
历史记录： 自动保存分析历史（localStorage），随时回顾已读论文
难度评估与阅读时间： 根据术语密度、参考文献数量等自动评估论文难度（入门/中等/进阶），估算阅读时间
暗色模式： 支持日/夜主题切换，保护眼睛
产品截图：
（截图1：首页 - 论文输入界面与示例论文选择） （截图2：分析结果 - 结构化展示论文核心信息） （截图3：速读卡片 - 一键复制分享） （截图4：论文对比 - 两篇论文并排分析）
- Demo 创作思路
灵感来源：
作为一名医学图像识别方向的研究生，我每天需要阅读大量英文学术论文。每次打开一篇新论文，都要经历这样的流程：先看摘要了解大意，再翻到Introduction理解研究背景，然后跳到Methods看方法，最后看Results和Conclusions。这个过程耗时且重复，尤其是跨领域阅读时，大量专业术语让理解变得更加困难。
想解决的问题：
论文阅读效率低： 一篇典型论文20-30页，提炼关键信息需要30-60分钟
跨领域阅读门槛高： 不熟悉的领域中，专业术语和表达方式增加了理解成本
论文管理混乱： 读过的论文容易忘记核心内容，缺乏快速回顾的手段
论文对比困难： 需要对比多篇相关论文时，缺乏结构化的对比工具
为什么做这个方向：
我调研了现有的论文阅读工具（如Scholarcy、Paper Digest、Connected Papers），它们要么需要注册账号，要么依赖后端API，要么功能过于复杂。我希望做一个零门槛、打开即用、纯前端的论文速读工具——不需要注册、不需要网络、不依赖任何后端服务，粘贴文本就能获得结构化的论文分析结果。这正好契合TRAE AI创造力大赛"真实价值、可体验"的理念。
- Demo 体验地址
方式一：在线体验（推荐）
公网访问地址：https://b3302a131552ca9e-223-160-130-105.serveousercontent.com/index.html
（打开后会看到一个Serveo安全提示页面，点击"Continue to Site"即可进入应用。该链接在开发期间有效。）
方式二：下载HTML文件离线体验
将附件中的 index.html 文件下载到本地，双击用浏览器打开即可使用。该文件完全自包含，无任何外部依赖，支持离线使用。
快速体验步骤：
打开页面后，在"论文分析"标签页下，点击任意一篇示例论文（Attention Is All You Need / BERT / Deep Residual Learning）
论文全文会自动填入输入框，点击"一键分析"按钮
等待1-2秒，查看结构化的分析结果（标题、作者、发表信息、中文摘要、研究背景、方法、结论、关键词、统计信息）
点击"复制速读卡"按钮，生成浓缩版速读卡片并复制到剪贴板
切换到"论文对比"标签页，加载两篇示例论文进行对比分析
切换到"历史记录"标签页，查看已分析的论文列表
4. TRAE 实践过程
开发流程
整个开发过程使用 TRAE Work 完成，经历了以下关键步骤：
Step 1：需求分析与创意确定
在TRAE中描述了想做一个科研论文速读工具的需求
讨论了多个方向（科研日报、文献聚合、论文速读），最终确定"论文速读助手"方向
核心决策：纯前端实现，零后端依赖，确保打开即用
Step 2：技术方案设计
确定技术栈：单HTML文件，内嵌CSS + JavaScript
设计分析引擎架构：PaperAnalyzer对象，包含章节识别、关键句提取、关键词匹配、中文翻译等模块
设计UI方案：绿色主题（#07c160），卡片式布局，响应式设计
Step 3：核心功能开发
实现论文分析引擎（PaperAnalyzer.analyze）
章节识别：通过正则表达式匹配Abstract、Introduction、Methods、Results等章节
关键句提取：基于句子评分算法，考虑关键词密度、句子长度、引用密度等因素
中文翻译：基于150+条专业术语词典的关键词替换翻译
关键词提取：技术术语匹配 + 大写多词术语识别
实现速读卡片生成与复制功能
实现论文对比分析功能
实现历史记录（localStorage持久化）
Step 4：示例论文数据准备
整理了3篇经典AI论文的完整文本（Attention Is All You Need、BERT、Deep Residual Learning）
统一章节标题格式，确保分析引擎能准确识别各章节
Step 5：调试与优化
修复正则表达式语法错误（Abstract提取正则未闭合分组）
修复年份提取逻辑（排除References区域的干扰匹配）
修复发表信息提取（在正文区域而非全文范围匹配）
增加难度评估和阅读时间估算功能
增加暗色模式切换
Step 6：深度优化（第二轮迭代）
移除Google Fonts CDN外部依赖，改用系统字体栈，实现完全离线自包含
重构中文翻译引擎：从逐词替换升级为结构化中文摘要生成器，基于句式模式匹配提取"提出了什么"“基于什么”"达到了什么性能"等关键信息，生成自然流畅的中文摘要
修复变量初始化顺序Bug（keywords在generateChineseSummary调用前未定义）
修复论文对比页示例加载按钮的函数调用路径
通过Serveo SSH隧道部署公网访问链接，解决本地URL无法分享的问题
打包为Zip文件供社区上传
Step 7：测试验证
使用3篇示例论文进行完整的功能测试
验证分析结果的准确性（标题、作者、年份、发表信息均正确提取）
验证中文摘要生成质量（结构化输出，可读性强）
验证速读卡片生成和复制功能
验证论文对比功能
验证历史记录的保存和加载
验证离线自包含（断网后所有功能正常）
开发关键步骤截图
（截图1：在TRAE中描述需求，确定论文速读助手方向） （截图2：TRAE生成PaperLens核心代码 - 分析引擎与UI） （截图3：浏览器中测试PaperLens - 加载示例论文并分析） （截图4：分析结果展示 - 结构化论文信息） （截图5：速读卡片生成与复制）
关键任务对话 Session ID
Session 1（需求讨论与方向确定）：6a312d9e024dc263143b2260
Session 2（PaperLens核心代码生成）：6a312d9e024dc263143b2260
Session 3（Bug修复与功能优化）：6a312d9e024dc263143b2260
踩坑与经验总结
正则表达式陷阱： Abstract提取的正则 (?=\n\s*\d+\s+introduction|…) 中遗漏了闭合括号 )，导致整个JavaScript解析失败，页面完全空白。调试时通过浏览器控制台发现 SyntaxError: Invalid regular expression: Unterminated group 才定位到问题。
年份提取的干扰： 示例论文的References区域包含大量"ICLR 2015"、"NeurIPS 2014"等引用，导致年份提取错误地匹配到参考文献中的年份而非论文本身的发表年份。解决方案：在匹配年份前先定位References位置，只在正文区域进行匹配。
纯前端的优势： 之前的版本使用了Flask后端+PubMed API，经常因为网络延迟和API限速导致加载缓慢（30秒+）。切换到纯前端方案后，所有计算在本地完成，响应时间稳定在1-2秒，用户体验大幅提升。
示例数据的重要性： 内置3篇经典论文作为示例，让用户无需准备论文文本就能立即体验全部功能，大大降低了试用门槛。
翻译引擎的演进： 第一版采用逐词替换翻译，产出大量"中英混杂"文本如"dominant 序列 transduction 模型s基于complex 循环"，可读性差。第二版改为结构化摘要生成器，通过句式模式匹配提取"本文提出了…"“该方法基于…”"实验结果达到…"等关键信息点，生成自然流畅的中文摘要。这证明了在没有翻译API的情况下，信息提取+模板生成比逐词替换更有效。
变量初始化顺序： JavaScript的 const 变量在声明前使用会抛出 ReferenceError: Cannot access ‘keywords’ before initialization。这在ES6 const/let 中是"暂时性死区"特性，开发时需注意变量声明顺序。
公网部署的探索： 尝试了多种部署方案——Vercel/Netlify需要登录认证，ngrok安装失败，最终通过 ssh -R 80:localhost:8080 serveo.net 实现零认证的SSH隧道转发，是最轻量的临时公网部署方案。但对于正式比赛提交，Zip文件上传是更可靠的方式。