26软工实践天生一队团队展示与选题报告

26软工实践 天生一队 团队展示与选题报告

项目	内容
作业所属课程	2026-01 软件工程与软件工程实践
作业要求	团队作业（一）：团队展示 + 选题报告 + 需求分析
作业的目标	按"领域智能体 + 软件"的思路完成一次完整的选题与需求分析：选定一个有真实需求的领域，说明智能体要替谁完成什么任务、如何定制，并给出可验收的功能边界与迭代计划，为后续开发与答辩打底。
团队名称	天生一队
团队组员学号-姓名	032401135沈文驰，052405110陈佳慧，102401607梁倩，102402101章玲，102402102张佩琪，102402103吴雅晴，102402104王可人，102402107陈瑀涵，102402116蔡靖熹，102402139徐张睿，102402152庄剑钇，102402138吴政迅（组长）

---

一、团队展示

1.1 队名：天生一队

"天生一队"取"天生一对"的谐音：十二个人性格、技术栈、擅长的事都不一样，凑在一起刚好互补——有人能写 Agent 管线，有人能把页面做得好看，有人愿意把需求文档逐条抠清楚。名字里也藏着一点自嘲和一点野心：既然凑成了一队，就得对得起"天生"这两个字。

1.2 团队合照

天生一队第一次合照。

1.3 团队风采

下表是大家自己填的“期望角色”；实际分工见 1.4——有人被安排到了非首选的岗位，也都接了。

学号 / 姓名	性格	擅长的技术	兴趣爱好	期望角色
102402138 吴政迅	沉稳随和	依赖 AI Coding，有一定的组织活动与协调沟通能力	阅读网文（《异常生物见闻录》《儒道至圣》《亏成首富从游戏开始》……）、玩手游（原神）	PM
102402101 章玲	外向	善用 AI；数学建模、文档整理排版、数据处理与可视化；了解一点 VLA 和深度学习	看小说，打羽毛球、乒乓球	MLE
102402102 张佩琪	活泼随和	需求梳理、调查问卷设计、文档整理与排版；前端页面与交互测试、后端接口测试，能用 AI 工具辅助测试用例设计和问题排查	唱歌、做手工	需求分析、技术文档编写、前端开发与软件测试
102402103 吴雅晴	安静内敛	MySQL 数据库建模与知识库表结构设计	羽毛球、听歌	后端
102402104 王可人	安静内敛	与 AI 沟通；色彩搭配与排版；使用 Figma/墨刀制作低保真原型	看动漫、绘画创作	测试 / UI 设计
102402107 陈瑀涵	善于沟通、耐心细致	AI 工具使用、Python、Agent 流程开发与知识检索	学习新事物	Agent 与检索模块开发
102402116 蔡靖熹	理性务实	数据处理与计算机交叉学科技巧；Linux 环境配置、Git 版本管理、模型开发经验	高尔夫；对计算机技术、生物信息学与跨学科研究感兴趣	后端开发 / 算法开发
102402139 徐张睿	豪爽	使用 AI	打游戏	后端开发
102402152 庄剑钇	沉稳	使用 AI，对数据整合有一定了解	打游戏、摄影	测试
052405110 陈佳慧	活泼	AI 交互式前端	羽毛球、玩游戏	前端
032401135 沈文驰	思维活跃，注重页面观感，乐于尝试新组件	使用 AI	动漫、摄影	前端开发
102401607 梁倩	安静内敛	vibe coding，跟 AI 沟通	听音乐、玩游戏	测试

1.4 团队分工

分工	负责人	主要职责
分工 1：选题与需求	梁倩	与同学讨论、选择领域知识，最终敲定选题；明确需求，说明目标用户、使用场景和要解决的问题；软件功能设计，绘制思维导图
分工 2：需求文档	张佩琪	撰写需求分析，维护迭代记录、类图等文档
分工 3：数据库与知识库	吴雅晴	数据库（知识库）相关工作：领域知识库整理、Agent 提示词
分工 4：编程小组组长	徐张睿	负责编写项目主体代码，管理编程小组，分配前端、后端、Agent 对接任务
分工 5：编程成员	陈瑀涵、沈文驰、陈佳慧	前端页面 / 后端服务 / Agent 接口联调，在编程小组组长指挥下完成代码任务
分工 6：答辩与博客	章玲、庄剑钇、王可人	1–2 人现场答辩、1 人负责 PPT、1 人负责团队博客排版编写与提交；三人协商互助完成任务
分工 7：统筹补位	吴政迅（组长）	协调沟通、督促工作进度、查缺补漏，处理没被安排的任务
分工 8：机动救火	蔡靖熹	滚动调整、灵活机动；紧急问题处理，最坏情况下预备扛起整个项目代码

分工按组长在群里发布的方案执行。分工 7、8 是“兜底位”：一个盯进度、随时补缺，一个机动救火、关键时候能接手代码。实际推进中，编程组内部又按“Agent 管线 / 后端与数据 / 前端页面”做了二次拆分，需求与博客组互相补位：评测数据由编程组提供，文档排版与博客整合由答辩博客组统一。

1.5 团队愿景

我们认为做好一件事并非指把一件事做出花来，而是把一件事做稳做实。我们希望做的不是一个"会总结课件"的工具，而是一份敢标出处、经得起追问的笔记：上传一份课件，十分钟后你能指着某个知识点说"这就是老师在第 13 章讲的"。天生一队，想把这件事做扎实。

---

二、选题：大学生课程课件笔记整理与知识梳理 Agent

2.1 我们看到的痛点（含问卷数据）

大学生（尤其是理工科）每学期要面对大量 PPT 和 PDF 课件：信息密度高、重点散落、公式和手写笔记混在一起。复习时最常发生的事是——翻了三遍 PPT，还是不知道老师到底想考什么。
为了不拍脑袋，我们先做了一轮问卷（问卷星，10 月 18 日—20 日，回收 64 份；以大三大二、计算机相关专业为主，属于校内便利样本，不作为全体大学生的推断；问卷由张佩琪设计并分析）。结果和组内试用一致，困难集中在"串不起来"和"太费时间"：

困难	选择比例
知识点分散，难以建立章节之间的联系	76.56%（49/64）
材料多，整理耗时	75.00%（48/64）
不易提取重点	60.94%
担心遗漏需要的内容	43.75%
多份材料需要手动合并	34.38%
整理结果有误，核对困难	26.56%
结合访谈，归纳成四个问题：

1. 整理成本高：45.31% 每次整理要 30 分钟以上，23.44% 超过 1 小时；
2. 章节联系断：76.56% 觉得知识点散、串不起来——这也是我们坚持"按章节组织"的原因；
3. 重点抓不住：60.94% 不易提取重点，43.75% 担心漏；
4. 结果不敢信：26.56% 遇到过整理结果有误、核对困难；直接问通用大模型，会"脑补"课件里没有的内容，更难核对。
   需求侧也给得很明确：功能上最想要按章节的结构化笔记（67.19%）和提炼重点（65.63%）；资料不足时，59.38% 希望"先说明哪里没依据、再给推测性参考"，只有 25% 接受直接下结论。这直接决定了我们的设计——每条笔记必须能点回原文，答不出就说答不出。

2.2 目标用户与使用场景

目标用户：在校本科生，以计算机、数学、物理、电子等理工科专业为主；也适用于需要整理公开讲义、技术文档的高年级学生和研究生。
核心场景：

• 课后：上传本周课件，10 分钟内得到结构化笔记 + 考点清单 + 思维导图；
• 答疑：针对课件内容提问，答案只来自上传的课件与课程知识库，并附原文出处；
• 考前：按章节或考试范围筛选重点，导出 Markdown / LaTeX 继续加工；
• 补料：老师后续补发的讲义，合并进已有笔记，而不是再生成一份新的。

2.3 智能体要完成的任务

一句话：把一份课件，变成一份能查回原文的结构化笔记。
具体包括：

1. 读取 PDF/PPTX/DOCX 等课件，识别章节结构；
2. 提取核心知识点、剔除冗余描述，按"章节 → 知识点 → 要点"组织；
3. 为每个知识点标注出处（第几章、第几页 / 第几张幻灯片），支持点击回看原文；
4. 提炼考点清单，生成文本版思维导图；
5. 基于课件与知识库回答用户提问，答不出就说答不出，不编造；
6. 按固定权重框架（核心功能 85% / 结构化 10% / 拓展关联 5%）对输出自查评分；
7. 导出 Markdown / LaTeX；
8. 可选：例题整理、手写公式转 LaTeX、笔记增量合并、考试范围复习笔记。

2.4 定制思路：让它"懂这门课"，而不是"会聊天"

我们没有把系统做成"套壳聊天框"，而是在四个层面做了定制：

层面	做法	解决的问题
领域知识库	课件与讲义向量化、教材知识点、章节关联库、出处索引；检索用 SQLite FTS5 + 二元组覆盖率重排	让回答有据可查，无关问题零召回
提示词工程	固定角色、固定输出结构、强制"仅基于原文"、固定权重自评框架	抑制幻觉，保证每次输出结构一致、可评分
工具调用	文件解析、知识库检索、导出、增量合并、OCR（可选）等工具由任务流调度	把"一次对话"变成"一条可复现的处理流水线"
任务流与校验	解析 → 提知识点 → 自评 → 生成笔记/考点/导图 → 出处回填 → 输出安全校验	出错可定位，结果可复核
防幻觉是这套设计里最硬的一条：每个知识点都必须带着原文引文。答辩时我们可以点开任意一条角标，看到它对应的课件原文。

2.5 软件形态与核心功能

形态是 Web 应用（B/S 架构），前后端分离：

• 前端：Vue 3 + Vite，登录 / 上传 / 进度 / 结果 / 历史 / 问答六个页面；
• 后端：Python 3.12 + FastAPI，12 组 REST 端点，异步任务 + 真实进度；
• 数据：SQLite，业务库 17 张表与领域知识库 6 张表物理分离；
• 模型：DeepSeek（OpenAI 兼容协议），temperature 0.2；
• 部署：阿里云 ECS 2 核 4G / Ubuntu 22.04，systemd 守护、开机自启。
  核心功能（必做）：课件上传与解析（8 种格式）、结构化笔记生成、考点清单与思维导图、知识点问答（带出处）、质量自评、历史记录、导出 Markdown/LaTeX。
  可选功能：例题整理、手写公式转 LaTeX、笔记增量合并、考试范围复习笔记。

2.6 进度安排

阶段	时间	内容	状态
立项与需求	10 月上旬	选题、需求清单、SRS、思维导图与类图	✅ 已完成
开发与联调	10 月中旬 – 10/20	前后端与 Agent 管线开发、合并整合、部署上线	✅ 已完成，线上跑通
答辩准备	10/21 – 10/23	PPT 与讲稿、演示动线、验收自查、兜底录屏	🔄 进行中
答辩与提交	10/24 – 10/25	现场答辩（10/24）、团队博客提交（10/25）	⏳

---

三、需求分析

完整的需求分析文档（含用例、接口、数据与验收标准）在这里：

📄 需求分析文档：《大学生课程课件笔记整理与知识梳理 Agent 需求与设计方案》
系统整体结构：

功能上分为四块：

• 用户前端：登录注册、文件上传、AI 对话、结果展示（笔记 / 考点 / 导图 / 出处）、导出、历史记录；
• 后端服务：账号与会话、文件存储与解析、知识库检索、Agent 网关、数据库、版本与合并；
• Agent 核心：领域知识库、提示词工程、工具编排、任务流规划、输出安全校验；
• 管理员：课件入库、例题库维护、测试案例管理、Agent 效果对比测试。
  验收口径（可量化，不"画大饼"）：
  | 验收项 | 标准 | 现状 |
  | --- | --- | --- |
  | 知识点覆盖率 | 参考知识点 36 条，覆盖率 ≥ 60% | 66.67%（24/36） |
  | 无依据陈述比例 | 0%（每条知识点可回查原文） | 0% |
  | 问答正确率 | ≥ 80% | 83.33%（5/6） |
  | 整理时延 | 6 页课件 ≤ 30 秒 | 12 秒 |
  | 导出 | Markdown / LaTeX 均可下载且可编译 | 已通过 |
  | 稳定性 | 边界输入（加密 PDF、损坏文件、超大文件）有可读提示 | 已覆盖并有测试 |

---

四、我们已经跑起来了

这一部分不是规划，是已经发生的事实。

4.1 线上环境

项	内容
访问地址	http://47.114.55.115:8000
演示账号	verify_37777bd6 / verify123（只读演示，请不要修改密码）
接口文档	http://47.114.55.115:8000/docs
部署	阿里云 ECS 2 核 4G / Ubuntu 22.04，systemd 守护、开机自启

线上环境（演示账号）的历史任务：三次真实课件整理全部成功，均可回看与导出。

4.2 一次真实整理：18 秒，6 个知识点，每条都带出处

刚用一份真实课件（《第四章 Scrapy 框架爬虫程序 4.2》，10 张幻灯片）跑了一遍：

• 解析：0.2 秒，10 张幻灯片 → 10 个片段；
• 整理：18.1 秒（逐块抽取知识点 → 归并 → 生成笔记 → 自评）；
• 产出：6 个知识点，每条右侧带「第 N 张幻灯片」出处角标；
• 质量自评：82.4 分（核心 82 / 结构 88 / 拓展关联 78）；
• 导出：Markdown 4.4 KB、LaTeX 正常下载。
  

结果页：顶部的 85%/10%/5% 加权自评、每条知识点旁的出处角标，点开可以看原文引文。

重点清单与导出入口（Markdown / LaTeX）。

历史任务列表：每个任务都能回看结果、重新导出。

4.3 技术亮点（答辩用大白话）

1. 每条笔记都能点回原文。 系统要求每个知识点都能在课件里找到原句，找不到就丢掉、不给用户看——"编造"在流程里就被卡掉了。
2. 先找相关页，再让模型回答。 不是把整份课件丢给模型硬总结，而是先检索出最相关的几段，再基于这几段回答；检索不到就直接说"材料里没有"。
3. 模型出问题，不会毁掉整篇。 调用失败会自动重试、自动换备用 key；某一段失败就跳过并标注，其余照常出结果，任务显示"部分成功"。
4. 前后端先说好格式，再动手写。 三端共用一份数据格式定义，接口先定稿再开发，合并时不用互相猜字段。
5. 有自动化测试兜底。 37 项测试覆盖接口、解析和整理流程，改完先跑测试再合并；上线前还有一套边界用例（加密 PDF、损坏文件、超大文件）。

4.4 自检抓到的真实缺陷

项目里有一张“开发过程中被自检抓到的缺陷”清单，挑四条最能说明问题的：

问题	不修会怎样	怎么修
问"量子力学"，系统却拿"导数"那一章的原文来回答	答案看着有出处，其实是错的	先按相关度排序，低于阈值就不回答
章节标题只在一页内有效，翻页就丢	一份课件只整理出 1 条笔记	翻页时把章节状态带过去
数据库语句的参数个数对不上（3 处）	材料列表、课程列表、问答历史页直接打不开	改成带名字的参数，并加一个自动检查脚本
导出的文件名里有中文	导出直接失败	按标准方式编码文件名

4.5 更多实测数据

• 用一份 6 页 / 4 MB 的课件跑通全流程：12 秒生成 10 个带出处的知识点，质量自评 87.9（另一轮评测 82.1）；
• 68 页整章课件：约 2 分钟完成，49,167 tokens，成本约 1~2 元；
• 同一份课件对比：定制 Agent 覆盖率 66.67%，裸模型 38.89%；无依据陈述比例 0% vs 100%；
• 自动化测试 37 项，合并后全部通过。

4.6 也知道自己的短板

问卷里 43.75% 的人希望把结果复制到 Word / WPS / 飞书，我们目前只做了 Markdown / LaTeX 下载，复制体验还没补上。覆盖率的口径是“保守文本匹配”，不是人工语义覆盖率；例题、公式、增量合并、考试范围这些可选功能，有的做完了、有的只是接口预留。这些在文档里都按实现状态如实标注了，答辩时也会主动说明。

五、收尾安排

1. 10/21 – 10/23：按验收口径逐条自查，PPT、讲稿、演示动线定稿，录一段 90 秒兜底屏；
2. 10/24：现场答辩 16 分钟（讲 10 + 问 6）；
3. 10/25：这篇博客由团队博客统一发布（只发一篇）；
4. 答辩后：源码、SRS、评测报告与演示材料归档，这门课的团队作业就收尾了。

---

六、写在最后

十二个人，从"连选题都要开会吵两小时"到"线上能跑出一条完整链路"，中间踩的坑比想象中多：格式解析失败、模型返回的 JSON 解析不了、前端字段名写错导致历史列表空白、.env 里的行内注释让配置整段失效……
但也正是这些问题，让我们第一次认真体会了"软件工程"这四个字：需求要写清楚，接口要定契约，改动要能回滚，演示要有兜底。
天生一队，继续把这份笔记做扎实。