[I.2] 个人作业：软件案例分析

[I.2] 个人作业：软件案例分析

项目	内容
这个作业属于哪个课程	2026年春季软件工程 (北京航空航天大学 - 计算机学院)
这个作业的要求在哪里	[I.2] 个人作业：软件案例分析
我在这个课程的目标是	希望能更好地走进真实的软件工程开发
这个作业在哪个具体方面帮助我实现目标	通过真实的调研，了解一个好的软件该如何设计

0 .选题

🧠团队项目选题所针对的软件的案例分析

请选择本团队预定选题相关领域的软件案例进行分析，需要选择 至少两个 软件。

我们团队最初期望做一点AI辅助论文阅读的小软件（但我调研之后发现市面上已经有这样相对成熟的产品了，且和我们的设计构想很类似 😂）

选择软件：alphaxiv（Explore | alphaXiv） 对比软件：Moonlight（https://www.themoonlight.io/）

1.调研评测

1.软件使用

alphaxiv主页

• 搜索栏可以搜索文章或问AI问题

• 页面下面是根据热度或潮流推荐的论文（有点像github的Trending repositories的推荐）

• 左边栏主要是AI助手，我的论文图书馆，通知，个人信息设置等（有趣的是，本平台支持与你的Google scholar/LinkedIn等账号关联，在阅读论文时你可以共同和他人讨论这篇论文）

Paper页（论文阅读）

• 边看论文原文，边随时可以问AI问题（翻译或解释复杂的概念等）

• 右侧的My Notes可以引用文中的话做笔记（Md格式），Comments可以在平台公开的与他人讨论（有点像论文版的大众点评）

Blog页

• Blog是平台AI根据论文生成的易读易理解的精要版原文，包含原文关键插图，公式及实验结果等，支持多种语言
• 右侧的Similar是相关论文推荐
• 你可以注意到最左上角有个点赞数，一定程度上可以表现这篇文章在这个社区里的欢迎度

Resources页

• 这里包含一些常见资源，包括论文代码仓库，引用等
• 当然在左上角的那些小图标，也支持常规的书签，下载，相关信息，分享等功能

PLUS

就如它的名字一样，你可以看到它与arxiv有着一些小小的联系。事实上，如果你在arxiv上发现了一篇不错的论文，你直接修改一下URL就可以直接跳到alphaxiv上的该篇论文阅读页。以下是一个示例。

2.软件分析

基本流程

1. 访问论文：在原本的 arXiv 链接中，将域名中的 arxiv.org 直接替换为 alphaxiv.org，即可进入该论文的讨论页。
2. 在线阅读：平台提供排版优化的阅读界面。
3. 选定标注：用户可以用鼠标选中论文中的特定段落、公式或图表。
4. 发布评论/提问：针对选中的内容发起讨论，支持 LaTeX 数学公式。
5. 互动交流：作者或其他研究者针对评论进行回复，形成学术社区的即时反馈。

部分解决用户需求

• 阅读更容易更快
• 批注、管理更便捷
• 与他人或作者的交流相对更方便（取决于社区活跃度，论文受关注度）

优缺点分析

维度	优点	缺点
数据量	理论上实时镜像 arXiv 全量论文，数据源极其丰富。	只有热门论文（AI、物理等）有大量讨论，大量冷门论文处于零评论状态。
界面	阅读界面清爽，支持深色模式，左右分屏显示讨论和正文，交互直观。	部分转换后的 HTML 格式论文可能出现公式错位或图表显示问题。
功能	划线笔记，评论功能强，支持 Markdown 和 LaTeX，支持绑定 Twitter/X 身份。	目前缺乏深度笔记管理、文献引用分析等。
准确度	直接关联原文，评论多来自同行或原作者，专业度相对较高。	评论区可能存在未经过滤的错误解读或低质量讨论，另外AI生成的部分内容可能也不准确，或者可能有幻觉。
用户体验	只需修改 URL 即可跳转，无需下载插件，阅读体验优于原生 PDF。	受限于服务器位置，加载部分网页较慢

3.改进意见

• 建立类似 OpenReview 的学者认证体系，让真实专家的评论更显眼，防止低质量、AI 生成的水评论淹没专业讨论。
• 目前主要依赖桌面端浏览器，开发轻量化 App 或更好的移动端适配，满足随时随地查看论文或讨论的需求。
• 建立更有效的作者认领与提醒系统，鼓励作者亲自下场答疑，形成“作者-读者”的良性互动回路。

4.用户调研

采访对象：大四hry同学，曾上吴际软工

采访原因：他即将步入科研，论文阅读需求大

使用：论文页阅读

5.评测结论

d) 好，不错 ★★★★☆

维度	分数	简要评价
功能性 (Functionality)	10	更易阅读，还可记笔记、交流
易用性 (Usability)	10	域名替换（arxiv->alphaxiv）逻辑极简，上手成本极低
可靠性 (Reliability)	7	AI生成blog可以很好快速地略读一篇文章，但可能不够准确
效率 (Efficiency)	3	有时加载极慢，体验不佳

6.Bug 分析和提交

操作系统：Windows 11 家庭版 ；操作系统版本 26200.8037
浏览器：Microsoft Edge 版本 146.0.3856.59 (正式版本) (64 位)

量化标准

Bug 严重性	对应问题描述
致命影响 ⭐⭐⭐⭐⭐	致命性系统故障 / 关键数据丢失或损坏 / 严重安全或隐私漏洞 / 核心业务流程完全中断
严重影响 ⭐⭐⭐⭐	重要功能不可用且无替代方案 / 系统频繁崩溃或响应极慢 / 核心交互逻辑错误 / 明显影响用户隐私
中度影响 ⭐⭐⭐	功能可用但体验显著受损 / 业务逻辑在特定场景下失效 / 界面排版严重错乱影响操作 / 存在绕过成本较高的替代方案
轻微影响 ⭐⭐	偶发性显示异常 / 边缘场景下的功能缺陷 / 交互体验不佳但通过重试可恢复 / 次要功能的小幅度偏差
基本无影响 ⭐	界面视觉微瑕（如像素未对齐）/ 文案拼写或翻译错误 / 不影响使用的改进性建议 / 极低概率出现的非干扰性问题

bug1：AI 总结Blog模块中 Markdown 与 LaTeX 混合渲染失效。

现象描述：

在 AlphaXiv 的 AI 论文总结（Blog/Summary）界面，系统无法正确解析并渲染复杂的 LaTeX 数学公式和 Markdown 格式化标签。具体表现为：

1. LaTeX 原码外露：第 3 点中的梯度下降公式未被渲染为数学符号，而是直接以 \theta \leftarrow \theta + \eta ... 的原始代码形式显示。
2. Markdown 语法失效：第 3 点开头的 策略优化 未能解析为加粗文本，而是保留了星号，且由于空格解析问题导致列表序号排版错乱。
3. 公式定界符冲突：公式结尾出现了暴露的 $$ 符号，说明渲染引擎在匹配起始和结束定界符时逻辑崩溃。

(上图是dark mode下AI总结出现乱码的示例（https://www.alphaxiv.org/overview/2504.16084） ：作为一个学术讨论平台，公式渲染是核心需求。图中显示第 2 点的简单公式渲染成功，但第 3 点失败，证明了渲染引擎在处理“嵌套 Markdown 格式+长 LaTeX 字符串”时存在不稳定性，而非 Feature。)

可复现性：

满足特定条件下可能发生（概率约 30%-40%）。查看 AlphaXiv 任意包含复杂数学推导（如 RL/优化理论类）论文的AI Blog

可能发生条件：

1. AI 生成的响应中包含“加粗标签（**）+ 空格 + LaTeX 行内公式”的复杂嵌套结构。
2. 公式中包含 LaTeX 特殊字符（如 \nabla 或下划线 _），且这些字符被前端解析器错误地识别为 Markdown 的强调符号。

Bug 分析：

可能成因：

• 转义字符冲突：AI 在生成 LaTeX 时，有时会为了安全或由于 Prompt 设定对反斜杠进行双重转义（\），但前端解析器只期望单斜杠。
• 定界符匹配算法脆弱：前端正则匹配可能由于 ** 加粗标签的干扰，导致无法正确闭合数学公式的 $$ 区块。

严重性分析：

• 系统功能：功能未瘫痪，但 AI 总结的核心价值（快速理解公式）丧失。
• 用户体验：不好。学术用户对公式的敏感度高，原码外露显得产品不专业。
• 安全性：基本无。
• 量化指标：中度影响 ⭐⭐⭐

为何发布前未修复？

• 测试用例覆盖不足：团队可能在简单的物理/数学论文（公式规整）上测试通过，但忽略了深度学习论文中常见的、带有复杂 Markdown 修饰语的数学混合文本。
• LLM 随机性：由于 AI 每次生成的文本结构（空格、转义方式）不一致，传统的静态 UI 测试很难捕捉这种由内容诱发的随机性渲染 Bug。
• 设计质量不高：前端渲染逻辑没有做足够的 Sanitization（净化处理），直接将 LLM 的原始输出丢给 Markdown 插件处理。

问题反馈

bug2：列表页文章条目偶发性重复渲染。

现象描述：

在论文列表页或搜索结果页中，同一篇论文（标题、作者、摘要及预览图完全一致）在页面上连续出现多次（如配图所示，同一篇文章重复出现了 3 次）。

可复现性：

偶发性发生（极低概率，通常与网络波动或特定交互时机有关）。

可能发生的特定条件：

1. 弱网/波动环境：在页面加载或点击“加载更多”时，网络出现短暂卡顿。
2. 快速重复触发：用户连续快速点击刷新、翻页或搜索按钮。
3. 分页边界异常：当后端数据更新时，分页指针（Offset/Cursor）在特定时刻抓取到了重复的数据块。

Bug 分析：

可能成因：

• 前端状态机冲突：AlphaXiv 可能使用了 React/Vue 等框架，在处理异步 API 返回时，没有根据文章的 arXiv_id 进行去重（Unique Key 检查），而是直接将新抓取的数据 append 到了现有数组中。
• 请求竞态条件 (Race Condition)：当用户触发加载动作时，前端没有设置“锁定（Loading Lock）”状态。如果在第一个请求未返回时发起了第二个相同请求，两个请求几乎同时返回并先后执行了数据添加操作，导致重复。
• 后端分页逻辑失效：后端在处理基于游标的分页时，如果正好有新论文入库导致索引漂移，可能导致上一页的最后一条数据出现在下一页的首位。

严重性分析：

• 系统功能：功能未失效，用户仍能点击进入论文。
• 量化指标：由于其不影响阅读核心流程且发生概率极低，轻微影响 ⭐⭐

为何发布前未修复？

• 测试把关不严：测试环境通常网络状况极佳，这种依赖于“网络延迟+特定交互时机”的 Bug 很难在标准测试流程中被捕捉到。
• 难以复现（Heisenbug）：这类 Bug 具有随机性，开发人员在本地调试时可能无法稳定复现，因此被排在了低优先级。
• 具体设计质量不高：在编写数据追加逻辑时，开发者可能为了省事直接使用了 list = [...list, ...newData]，而没有封装一个带有 ID 去重功能的通用函数。

2.分析

1.工作量分析

针对 AlphaXiv，假设团队由 6 人组成，均为计算机大学毕业生，并有专业 UI 支持。该平台目前不仅是社交工具，更是一个深度集成 AI 的论文Agent。具体功能模块和估计耗时如下：

功能模块	估计耗时（周）
arXiv 数据流与 PDF/HTML 双模渲染引擎	3
划线评论与社交互动系统（含 LaTeX 支持）	2
AI RAG (检索增强生成) 基础架构搭建	2
AI 论文长文本总结与核心贡献提取	1
Chat with Paper（针对特定论文的 AI 问答）	2
AI 公式/代码原理解释功能	1
多语言 AI 实时学术翻译与润色建议	1
AI 交叉文献比对（分析本文与引用文献的关系）	2
向量数据库部署与语义搜索优化	2
用户偏好学习与 AI 论文个性化推荐	1
X/Twitter 社交生态集成与身份认证	1
系统集成、多端适配与 Token 成本控制优化	3
AI 幻觉校对与极端排版下的 Bug 修复	3

总工期估计：约 24 周（约 6 个月）
分析： 尽管 AI 功能开发看似复杂，但得益于现有的 LLM API（如 GPT, Claude） 和开源 RAG 框架（如 LangChain, LlamaIndex），核心 AI 模块的初步搭建极快。团队的工作重心将从“从零开发”转向“提示词工程”与“上下文窗口管理”。

2.软件质量分析

相较于传统的 ReadPaper、ChatPDF 或 arXiv 原生页面，AlphaXiv 具有以下深度集成 AI 后的优势与劣势：

优势

• 不同于单纯的 AI 工具，它将 AI 的自动化总结 与 人类真实评论 放在同一维度，提供更多参考。
• AI 能够理解划线部分的具体语境，针对复杂的公式和图表提供实时解释，这是传统 PDF 阅读器无法比拟的。
• 通过 URL 直接触发 AI 助手，无需用户手动上传 PDF，这种即开即用的体验在同类 AI 学术工具中属于顶尖。

劣势

• 深度集成的 AI 功能会导致页面加载及复杂问答时出现明显的等待。
• 在面对极其前沿或包含大量新定义的数学推导时，AI 的解释往往流于表面或存在幻觉。

名次估计：在“arXiv社交化+AI辅助阅读”垂直细分赛道，目前排名第一 (No.1)

改进建议：在主页的论文推荐系统上还可以继续优化，目前更新频率较低，且暂不支持手动一键再次刷新

3.建议与规划

1. 市场现状

• 市场概况：

  • 直接用户：全球约 200万-300万 活跃科研人员（以 AI/CS/物理领域为主），每日 arXiv 访问量巨大。
  • 潜在用户：约 1000万+ 高校学生及研发工程师。随着 AI 爆发，非学术背景用户阅读论文的需求激增。

• 竞争产品及态势：

  • AlphaXiv：优势：真实专家反馈、Twitter 联动，暂时免费；劣势：暂不支持在线大文本翻译与图片解析。

  • ReadPaper：优势：管理功能强；劣势：功能有限，需付费解锁AI辅助阅读。

    ReadPaper见下示例。

  

  • Moonlight：优势：图表/公式 AI 问答极其流畅，UI 丝滑，支持在线翻译；劣势：纯工具属性，缺乏人与人的互动。

    Moonlight见下示例。

2. 市场与产品生态

• 核心用户画像：
  • 典型用户：20-35 岁，研究生或研究员。
  • 需求：不仅要快速“读懂”，还要知道“这论文靠不靠谱”、“大家怎么看”。
• 用户与产品生态：
  • 用户生态：利用“导师-学生”、“同行评审”关系。如果能让顶尖实验室全员入驻，将形成很好的生态，这将是论文界的github。
  • 产品生态：向上连接 arXiv，向下连接 GitHub (代码) 与 Twitter (讨论)，形成从阅读到复现到传播的闭环。

3. 产品规划

新功能设计：AI -专家共验

NABCD 分析：

维度	说明
Need	Moonlight等AI助手虽能快速解释公式和图表，但存在“AI幻觉”，科研人员不敢全信。用户需要一种既有AI的响应速度，又有领域专家背书的可信解释。
Approach	开发“AI专家共验”功能：1. AI解析时不仅参考正文，还实时索引评论区历史讨论和作者回复；2. 若AI推导与专家评论不一致，系统会高亮标注并展示多方观点。
Benefit	1.用人的智慧修正AI的偏差，解决学术严谨性问题；2. 让历史的高质量评论被AI重新激活，不再被淹没；3. 用户在看AI解析时能顺势参与专家讨论，缩短社交路径。
Competition	对比 Moonlight：Moonlight是封闭的人机对话，解释对错全靠模型；AlphaXiv是开放的“人-机-专家”三方协同。
Delivery	1. 深度优化URL替换插件，默认开启“AI助手”侧边栏；2. 联合顶尖实验室开展“专家入驻计划”，由AI自动归纳并推送其精华见解；3. 在Twitter/X平台分享“AI被专家成功纠错”的案例，树立专业口碑。

创新点：

• 证据链可视化：不只给答案，还展示该答案是如何结合AI推理与专家评论生成的。
• 纠错式社交：将“阅读”行为转化为“发现问题并与专家对质”的互动过程，保留科研的批判精神。

团队角色配置（6人）

角色	人数	职责
产品经理 (PM)	1	核心提示词(Prompt)工程、学术专家关系维护、需求定义及16周进度管控。
AI/后端开发	3	RAG系统搭建（论文+评论向量化）、多模态公式/图表解析、后端API及数据库运维。
前端/PDF开发	1	多端开发，交互实现等。
测试/全栈工程师	1	性能优化、基础架构部署等。

16周详细规划

周次	阶段	主要任务
第1周	需求分析	深度测评Moonlight及ReadPaper，分析其公式/图表解析的短板，确定首批测试论文集。
第2周	产品设计	输出“AI+专家评论”混合展示的PRD，设计三栏排版（正文-AI解释-专家支撑）。
第3周	UI/交互设计	完成高保真设计稿，重点优化窄屏模式下的侧边栏拉伸与公式渲染效果。
第4周	技术架构	搭建RAG基础环境，确立论文向量化存储方案，进行大模型API选型。
第5周	PDF底层优化	解决存在的Bug，实现基于文本偏移而非坐标的精准锚点系统。
第6周	AI核心开发	实现针对复杂LaTeX公式的语义拆解，并能关联到评论区相关的技术讨论。
第7周	多模态解析	实现针对论文图表（Charts/Tables）的AI识图，并能提取数据与专家评论做比对。
第8周	社交功能融合	开发“AI引用评论”组件，支持用户点击AI回答直接追溯到专家原帖。
第9周	翻译与辅助	对标Moonlight，开发学术术语表敏感的在线翻译与高亮功能。
第10周	性能联调	优化大规模向量检索延迟，确保AI响应在2秒以内，解决长论文加载卡顿。
第11周	内部测试	启动针对不同会议模板（CVPR, NeurIPS等）的自动化视觉回归测试，修复可能的UI错位。
第12周	灰度测试	邀请5个深度合作的课题组进行内测，收集AI解释准确性与社交互动的反馈。
第13周	迭代优化	根据反馈优化Prompt策略，重点强化“AI无法回答时自动转人工咨询”的逻辑。
第14周	全量上线	申请域名/CDN扩容，在arXiv社区发布重大版本更新公告，上线“AI专家共验”版本。
第15周	数据监控	监控AI回答的点赞率/纠错率，观察用户从阅读转向评论的转化指标。
第16周	复盘总结	评估“AI+专家”功能对留存的影响，制定下一阶段“专家激励体系”计划。