[T.13] 团队项目：Scider Alpha 阶段项目展示

这个作业属于哪个课程	北航2026年春季软件工程
这个作业的要求在哪里	[T.13] 团队项目：Alpha 阶段项目展示
我在这个课程的目标是	体验完整软件开发流程，交付一款真正解决科研阅读痛点的软件产品
这个作业在哪个具体方面帮助我实现目标	完成 Alpha 阶段项目展示

一、项目与团队总结

1. 团队成员与分工

团队成员简介与个人博客地址

姓名	角色	个人博客地址
肖清心	PM / 前端 / 测试	https://www.cnblogs.com/xqxllll
华家璇	前端开发 / 运维	https://www.cnblogs.com/marigoldarly
吴长骏	后端开发	https://www.cnblogs.com/327hhhhh
廉晟	后端开发 / 部署	https://www.cnblogs.com/wh04m1222
周嘉祺	后端开发	https://www.cnblogs.com/404-error-64
覃宇航	后端开发	https://www.cnblogs.com/waterdroplet

分工协作与经验教训

团队采用模块化分工策略，按功能模块划分职责：

• 肖清心（PM + 前端 + 测试）：统筹项目管理，同时负责文库、图谱、检索等主要前端模块的具体实现
• 华家璇（前端 + 运维）：负责前端架构搭建、登录注册、CI/CD、部署与LLM配置
• 吴长骏（后端）：负责数据层（ER图、ORM、数据库）和认证体系（注册、登录、JWT）
• 廉晟（后端 + 部署）：负责PDF上传、文件夹CRUD、Celery对接、服务器部署与容器编排
• 周嘉祺（后端）：负责AI异步解析、大模型调用、知识图谱数据接口与性能优化
• 覃宇航（后端）：负责检索接口、PDF文本提取、文本清洗分段与单元测试

经验：每2日一次的srcum meeting能有效保证项目的逐渐推进（push大家每天干点活）；Github pr机制与代码审查能够保证dev主分支的代码质量；按模块分配任务可以尽量避免因他人负责的前置任务未完成造成的工期延误

教训：测试工作应该尽早开始规划实施，不要堆在发布前导致需要紧急修一堆bug（）

项目管理方式：

项目任务分配与管理：飞书

项目开始时根据文档预分配任务并根据依赖关系排期
使用 飞书-项目管理 功能管理项目进度与文档

---

项目进展交流 : 飞书 + 微信

使用 飞书-视频会议 每2日召开一次线上会议，汇报工作进展和规划，交流出现的问题
会议记录详见[T.9] 团队项目：每日例会报告

平时也通过微信小组群交流

---

项目开发管理 ：GitHub + Apifox
在GitHub上进行代码管理：https://github.com/XiaCang/Scider

项目结构为：

• docs/: 项目详尽文档、设计方案与技术调研
• scripts/: 开发、部署及数据处理相关的自动化脚本
• src/: 核心源代码
  • backend/: 后端服务
  • frontend/: 前端用户界面

成员各自创建分支开发，完成后pr到仓库，测试通过后merge到主开发分支dev

在Apifox上进行接口管理与调试

时间/质量/资源平衡策略

• 时间管理：通过任务预分配和依赖关系排期，将DDL分层设卡（4.24基础搭建、4.26认证、4.28核心功能、4.30-5.2联调与优化），分阶段验收降低整体风险
• 质量保障：PR评审机制强制代码审查；前后端均有单元测试覆盖；接口统一在Apifox管理确保一致性
• 资源调配：团队成员兼具开发与运维能力（如华家璇兼做DevOps、廉晟兼做部署），避免等待专职运维导致的资源瓶颈

项目实际进展

Alpha阶段按时完成了全部核心功能：

• 用户认证：注册（邮箱+激活Mock）、登录（JWT）、鉴权中间件、用户信息接口
• 发现论文：Semantic Scholar API检索、分页格式化、单篇导入与异步解析触发
• 我的文库：PDF上传（校验、MD5去重、存储）、文件夹CRUD、上传后Celery异步解析触发
• 异步解析：PDF文本提取（PyMuPDF）、文本清洗分段、大模型四要素提取、确认后向量化触发
• 知识图谱：Embedding与pgvector存储、相似度计算、图数据接口（节点+边，200节点限制）
• 部署与联调：ECS+Docker Compose编排、Nginx+HTTPS、全量功能联调

总体按照任务排期稳步推进，偶有因依赖关系而导致的略微延期，但影响不大

成员贡献量化

我们将团队贡献总分分为60+150+90三部分，分别分配给选题规划、alpha、beta三个阶段，以下是alpha阶段贡献分分配表格：

2. 典型用户场景与软件满足情况

典型用户场景

典型用户： 研一新生张同学，面临导师布置的文献调研任务，需要快速了解陌生领域的研究脉络。

软件满足情况

详见[T.12]团队项目：Scider Alpha 阶段发布说明

Demo 展示

【Scider智能学术论文管理平台-Alpha版本demo展示】 https://www.bilibili.com/video/BV1wg546HEfw/?share_source=copy_web&vd_source=6fc0dc8dd29d47b3308721ca722fb745

3. 杀手级功能

AI 智能解析与四要素提取

与竞品仅提供论文摘要或关键词不同，Scider 模拟研究者“理解和拆解”论文的过程。上传 PDF 后，AI 自动提取并结构化展示“研究背景”、“研究方法”、“创新点”和“研究结论”四大核心要素，并允许用户编辑确认，将被动阅读变为主动知识沉淀

知识图谱可视化

竞品多为“收藏夹式”管理，论文间孤立无链。Scider 能将已确认的论文，基于语义相似度自动聚合成“知识网络”，以力导向图形式直观呈现研究簇、交叉领域及潜在研究空白，让用户像探索地图一样梳理学术版图

4. 项目发布努力

完成公网访问交付

推广

主要通过私信与朋友圈进行内测邀请

收到了一些优化反馈

5. 软件工程质量

维度	实践情况	量化指标
文档	飞书项目文档中心（架构/API/需求/会议）、代码管理规范、前后端 README	4+ 份规范文档，2 份工程约束文件
代码规范	Conventional Commits 提交规范、前端开发分层约定、后端模块分离	9 类 commit 类型约束，3 项前端开发约定
单元测试	后端数据库功能测试、检索逻辑测试、手动回归测试	2+ 个测试文件
接口管理	Apifox 集中管理全部 API，分 7 组覆盖所有模块	7 个接口分组，20+ 个接口
CI/CD	GitHub Actions 自动化构建与测试	1 条工作流 pipeline
代码审查	Pull Request 评审机制，设计变更必须先更新文档	33 次提交全部经由 PR 合入 dev 分支

文档与代码规范

文档体系：

• 飞书项目文档中心：存放架构设计文档、API文档、需求文档、会议记录
• GitHub代码仓库：docs/目录存放项目详尽文档与设计方案
• 代码管理规范、前后端README

代码规范：

• Conventional Commits 提交规范（9类commit类型约束：feat/fix/docs/style/refactor/perf/test/chore）
• 前端开发分层约定：组件层→业务层→API层分离
• 后端模块分离：routes→services→repositories→models清晰分层

新开发者体验：
一个新学生要在一台新机器上编译并运行Scider项目，需执行：

1. 克隆仓库
2. 参考 src/backend 和 src/frontend 下的 README 安装依赖
3. 根据各模块的启动命令运行
4. 通过 docker-compose 一键启动数据库等依赖服务

文档中对环境变量配置、数据库迁移、Celery Worker启动等均有明确说明

单元测试

• 后端数据库功能测试（manual_db_test.py）
• 检索逻辑单元测试（覃宇航编写，覆盖检索接口核心逻辑）
• 手动回归测试覆盖核心用户路径

CI/CD与代码审查

CI/CD：采用GitHub Actions自动化构建与测试

代码审查：Pull Request评审机制，所有变更必须先更新文档，33次提交全部经由PR合入dev分支

接口管理

Apifox集中管理全部API，分为7个接口分组（认证、论文检索、文库管理、PDF上传、解析任务、知识图谱、用户信息），共管理20+个API接口。

6.反思与Beta阶段大体计划

功能方面

目前项目在核心功能部分特点不够突出，需要强化杀手级功能；同时优化项目整体完成度。

• 功能完善：批量导入、论文笔记管理体系优化、知识图谱支持可编辑、AI Agent辅助阅读、个人中心增强
• 性能优化：图谱渲染优化、检索速度与精度优化、PDF解析缓存机制
• 用户体验打磨：加载状态提示、操作反馈优化、移动端适配
• 正式推广：公开公网访问、收集真实用户反馈、优化产品体验、争取更多种子用户

测试方面

alpha阶段将测试工作放在开发结束后，结果工作量超出预期，导致反复返工、压缩发布时间；因此需要在beta阶段就规划好测试工作，并与开发任务同步进行。