DevPulse组-软件工程实践团队作业——种子队选拔、团队展示及选题

[DevPulse组]

DevPulse——团队展示

项目	内容
这个作业属于哪个课程	2601_FZU_SE 软件工程实践社区
这个作业要求在哪里	软件工程实践团队作业——种子队选拔、团队展示及选题
这个作业的目标	完成团队组建与选题论证，明确团队愿景和绩效考核方案，并通过 NABCD 分析展示项目价值
其他参考文献	[1] 邹欣.《构建之法》[M]. 人民邮电出版社. [2] Lewis P, et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. [3] LangChain 官方文档. [4] Milvus 官方文档

目录

• DevPulse——团队展示
• 一、团队介绍
• 1.1 队名：DevPulse
• 1.2 队员风采
• 成员一
• 成员二
• 成员三
• 成员四
• 成员五
• 二、团队选题
• 2.1 一句话选题
• 2.2 选题背景
• 2.3 目标用户与使用场景
• 三、NABCD 分析
• N：Need，需求
• A：Approach，做法
• B：Benefit，好处
• C：Competitors，竞品
• D：Delivery，交付
• 四、项目功能范围
• 4.1 核心功能
• 4.2 扩展功能
• 五、团队绩效考核方案
• 5.1 考核原则
• 5.2 考核维度
• 5.3 数据来源与计算方式
• 5.4 执行节奏
• 六、团队愿景
• 七、可行性、风险与迭代计划
• 7.1 可行性
• 7.2 主要风险与应对
• 7.3 迭代计划
• 八、选题 PDF 文档
• 九、结语

一、团队介绍

1.1 队名：DevPulse

DevPulse 由 Dev 和 Pulse 组成。Dev 代表持续开发与工程实践，Pulse 代表对知识、反馈和变化的感知。我们希望团队像脉搏一样保持稳定的协作节奏，也希望通过智能问答助手，让沉睡在文档中的知识重新流动起来。

1.2 队员风采

成员一

• 学号：102400135
• 成员姓名或昵称：郑宇凌
• 成员 CSDN 地址：https://blog.csdn.net/zzzzyyll?type=blog
• 成员性格：稳重细致，遇到问题先定位原因，再和团队同步结论。
• 擅长的技术：Java、Spring Boot、MySQL、Git，了解 Docker 基础使用。
• 兴趣爱好：跑步、研究效率工具、整理技术笔记。
• 希望的软工角色：后端开发。
• 一句 slogan：把复杂逻辑拆成清晰、可验证的接口。

成员二

• 学号：102400210
• 成员姓名或昵称：陈仕杰
• 成员 CSDN 地址：https://blog.csdn.net/J_I_E_JIE?spm=1010.2135.3001.5343
• 成员性格：外向有耐心，善于沟通，愿意主动收集使用反馈。
• 擅长的技术：Vue 3、TypeScript、HTML/CSS，了解前端工程化和接口联调。
• 兴趣爱好：摄影、体验新产品、打羽毛球。
• 希望的软工角色：前端开发。
• 一句 slogan：让知识入口更清晰，让每一次交互都有反馈。

成员三

• 学号：102400335
• 成员姓名或昵称：郑栋兴
• 成员 CSDN 地址：https://blog.csdn.net/2601_96962275?type=sub&subType=community
• 成员性格：沉稳务实，遇到问题先定位原因，再和团队同步结论。
• 擅长的技术：Java、Spring Boot、MySQL，了解接口设计和基础部署。
• 兴趣爱好：篮球、跑步、研究效率工具。
• 希望的软工角色：后端开发。
• 一句 slogan：把每一次提交都变成可复用的积累。

成员四

• 学号：102400334
• 成员姓名或昵称：张幼
• 成员 CSDN 地址：https://blog.csdn.net/z3245474782?spm=1000.2115.3001.5343
• 成员性格：细致耐心，重视表达和用户体验，愿意主动整理资料。
• 擅长的技术：Vue 3、HTML/CSS、产品原型和项目文档编写。
• 兴趣爱好：阅读、摄影、手绘。
• 希望的软工角色：前端与文档。
• 一句 slogan：好的界面，让复杂知识变得容易靠近。

成员五

• 学号：152402114
• 成员姓名或昵称：郑天一
• 成员 CSDN 地址：https://blog.csdn.net/z200511?type=bbs
• 成员性格：思路开放，乐于尝试新方案，习惯用测试和数据验证结果。
• 擅长的技术：Python、软件测试、数据处理和自动化脚本。
• 兴趣爱好：玩游戏、听音乐、打羽毛球。
• 希望的软工角色：测试与数据处理。
• 一句 slogan：先验证，再相信；先记录，再优化。

  二、团队选题

2.1 一句话选题

DevPulse 智能问答助手，是一个把团队文档、课程资料和常见问题整理成可检索、可追溯、可反馈的知识库，并通过检索增强生成技术提供可信回答的 Web 应用。

2.2 选题背景

在课程学习、社团工作和项目协作中，信息通常散落在聊天记录、在线文档、会议纪要、课程资料和网页中。成员遇到问题时，往往需要在多个平台反复搜索，或者直接询问已经处理过同类问题的人。这样的过程存在三个明显问题：

1. 查找成本高。同一个问题可能被不同成员重复提问。
2. 答案难追溯。只给结论、不说明来源，使用者难以判断答案是否可信。
3. 知识难沉淀。问题解决后没有形成可复用的知识资产，人员变动后经验容易流失。

大语言模型可以生成流畅的回答，但如果只依赖模型自身知识，容易出现事实过期、来源不明和内容幻觉。检索增强生成（RAG）先检索与问题相关的文档，再让模型基于检索结果组织答案，能够在一定程度上缓解这些问题。因此，我们希望把大模型能力和团队知识库结合起来，做一个更贴近真实学习与协作场景的智能问答助手。

2.3 目标用户与使用场景

目标用户包括课程班级、学生团队、社团、实验室小组和小型项目组。典型场景如下：

• 新成员加入后，直接询问规章制度、项目背景、开发流程和常用链接。
• 项目成员查询接口说明、部署步骤、历史决策和常见故障处理方式。
• 教师或助教查询课程资料、作业说明和常见问题。
• 团队管理者通过知识缺口分析，发现文档中没有讲清楚的内容。

三、NABCD 分析

N：Need，需求

用户的真实需求不是“再做一个聊天机器人”，而是用更低成本获得有依据、可追溯、能持续更新的答案。具体需求可以拆解为：

1. 支持导入多种格式的资料，包括 Markdown、TXT、PDF、Word、网页和常见问答对。
2. 支持自然语言提问，答案需要附带来源片段和原文位置。
3. 支持多轮追问，能够结合上下文理解“这个”“上面提到的”等指代。
4. 支持知识更新、删除和权限管理，避免旧文档继续影响新答案。
5. 支持用户反馈，把回答质量差或知识缺失的问题记录下来，形成改进闭环。

A：Approach，做法

项目采用前后端分离和 RAG 架构，先完成可运行的最小可行产品，再逐步扩展。

1. 知识入库：用户上传文档后，系统进行格式解析、文本清洗、分块、向量化和元数据登记。
2. 检索增强：使用向量检索和关键词检索混合召回，再通过重排序筛选最相关的内容。
3. 答案生成：把用户问题、对话历史和相关文档片段交给大语言模型，要求模型只依据给定材料作答。
4. 引用展示：答案下方展示引用来源，点击后可以定位到原文片段。
5. 反馈闭环：用户对回答进行评价，系统记录低质量回答和未命中问题，供管理员补文档或调整检索策略。
6. 权限与管理：管理员维护知识库、成员和访问权限，普通用户只能查看被授权的内容。

建议技术路线如下：

• 前端：Vue 3 + TypeScript，负责知识库管理、对话界面和引用展示。
• 后端：FastAPI，负责用户、知识库、会话、文档处理和反馈接口。
• AI 编排：LangChain 或 LangGraph，负责检索、重排序、提示词和回答生成流程。
• 向量检索：Chroma 或 Milvus，存储文档向量和元数据。
• 关系数据库：MySQL 或 SQLite，存储用户、知识库、会话和反馈记录。
• 模型调用：使用支持 OpenAI 兼容接口的大模型服务，并保留替换模型的配置能力。
• 部署：Docker Compose，降低课程演示和云端部署成本。

B：Benefit，好处

1. 对使用者：不用在多份文档和聊天记录中反复搜索，可以直接获得带来源的回答。
2. 对团队：新成员能够更快了解项目背景，减少重复沟通和重复答疑。
3. 对知识管理：文档、问答和反馈形成闭环，知识库可以持续更新，而不是一次性整理。
4. 对工程实践：团队可以完整经历需求分析、架构设计、数据处理、接口开发、前端实现、测试和部署。
5. 对可信度：答案有引用来源，用户可以核对原文，降低盲目信任模型输出的风险。

C：Competitors，竞品

竞品或替代方案	优点	不足与差异
通用聊天机器人	使用门槛低，回答速度快	不了解团队私有资料，答案来源不透明，文档更新后无法自动同步
传统关键词搜索	结果可解释，实现简单	依赖关键词匹配，无法理解同义表达和上下文，难以直接回答复杂问题
在线文档搜索	适合人工查找原始资料	需要用户自己阅读和归纳，不能直接生成带引用的回答
企业知识库产品	功能完整，管理能力强	成本较高，配置复杂，对课程小组来说过重

DevPulse 的差异点不是追求通用能力，而是围绕课程和团队协作场景，做一个轻量、透明、可解释的知识问答工具。用户可以看见答案从哪里来，也可以参与反馈和知识维护。

D：Delivery，交付

项目计划分阶段交付：

1. 第一阶段：完成需求分析、原型设计、数据库设计和接口约定。
2. 第二阶段：完成文档导入、文本分块、向量化、检索和单轮问答。
3. 第三阶段：完成多轮对话、来源引用、用户反馈和知识库管理。
4. 第四阶段：完成测试、部署、演示数据和项目文档。

每个阶段都保留可演示成果。即使后续功能来不及全部实现，也必须保证“上传知识、提出问题、返回带来源的答案”这条主链路可以稳定运行。

四、项目功能范围

4.1 核心功能

1. 知识库管理：创建知识库，上传、查看和删除文档。
2. 文档处理：解析文本，切分片段，生成向量并记录来源。
3. 智能问答：输入自然语言问题，返回结构化答案。
4. 来源引用：展示答案引用的文档、段落和相似度信息。
5. 多轮对话：保留上下文，支持连续追问。
6. 用户反馈：对回答进行有用或无用评价，记录知识缺口。

4.2 扩展功能

1. 角色与权限：区分管理员、普通成员和访客。
2. 知识缺口分析：统计高频未命中问题和低分回答。
3. 文档版本管理：记录文档更新历史，避免使用过期内容。
4. 回答质量评估：用固定问题集测试检索命中率、引用准确率和回答一致性。

五、团队绩效考核方案

5.1 考核原则

团队绩效考核的目的，是让每个人的投入和贡献被看见，并帮助团队及时调整分工，而不是制造内耗。结合《构建之法》中关于团队绩效管理和成员投入程度的讨论，我们采用“过程记录为主、结果质量并重、互评补充、规则透明”的考核方式。

考核遵循以下原则：

1. 公开透明：考核维度、权重和数据来源在项目开始时向所有成员说明。
2. 过程与结果并重：不仅看最终代码，也看需求、设计、测试、文档、协调和复盘。
3. 可追溯：以任务看板、Git 提交、代码评审、会议记录和交付物为主要依据。
4. 可申诉：成员如果对评分有异议，可以在结果公布后 24 小时内提出，由团队共同复核。

5.2 考核维度

考核维度	分值	主要观察点
任务完成度	35	是否按约定完成分配任务，是否主动同步进度和风险
成果质量	25	代码、文档、设计、测试和演示材料的质量与可维护性
协作与沟通	20	是否及时回复、主动帮助、积极参与讨论、尊重他人意见
过程规范	10	是否遵守 Git 规范、会议记录、命名约定和交付要求
额外贡献	10	关键问题攻关、额外测试、知识分享、组织协调等

基础总分为 100 分。对于严重拖延、失联或重复不履行承诺的情况，团队先进行提醒和任务调整；如果仍未改善，再在过程规范维度中扣分，并记录原因。

5.3 数据来源与计算方式

1. 任务完成度、成果质量和过程规范以任务看板、Git 提交记录、代码评审和交付物检查为依据。
2. 协作与沟通采用成员互评，去掉一个最高分和一个最低分后取平均；人数较少时直接取平均。
3. 额外贡献由成员自荐或他人提名，团队讨论后确认。
4. 个人绩效得分 = 任务完成度 + 成果质量 + 协作与沟通 + 过程规范 + 额外贡献。
5. 当需要按贡献度分配团队成绩时，先计算个人系数：个人系数 = 个人绩效得分 ÷ 团队平均绩效得分。
6. 为了避免个别评分失真，个人系数限制在 0.8 至 1.2 之间，再按比例归一化，使所有成员系数之和等于团队人数。

示例：如果团队最终成绩为 90 分，某成员归一化后的个人系数为 1.05，则该成员成绩为 94.5 分；如果另一名成员系数为 0.95，则成绩为 85.5 分。具体是否启用贡献度分配，以老师后续作业要求为准。

5.4 执行节奏

1. 每周一次短会，确认本周任务、负责人和截止时间。
2. 每次会议记录结论、待办和风险，发到团队群。
3. 每两周进行一次互评，重点看协作问题和任务阻塞，不等到期末才反馈。
4. 每个阶段结束后进行一次复盘，记录做得好的地方和需要改进的地方。
5. 所有成员都阅读《构建之法》中关于团队绩效和成员投入程度的相关内容，并在讨论中形成最终规则。

六、团队愿景

我们希望 DevPulse 智能问答助手从课程项目出发，逐步成为可复用的知识问答基础设施：把分散在文档、网页和聊天记录中的知识整理成可信、可追溯的答案，让使用者少找资料、少重复提问，把时间留给判断和创造。项目初期先完成知识导入、检索增强问答、答案引用和反馈闭环，保证回答有依据、错误可定位；后续扩展多轮对话、权限管理和知识缺口分析，服务班级、社团和小型团队。我们也希望每位成员在真实协作中提升需求分析、工程实现、测试和表达能力。

七、可行性、风险与迭代计划

7.1 可行性

1. 技术可行性：RAG 是相对成熟的方案，文档解析、向量检索和大模型调用都有现成组件。
2. 数据可行性：课程资料、项目文档和常见问答可以作为初始知识库，不需要额外购买数据。
3. 时间可行性：先做单知识库、单轮问答和引用展示，再扩展多轮对话和权限管理，适合分阶段完成。
4. 成本可行性：优先使用本地向量库和按量调用的大模型接口，课程演示阶段可以控制成本。

7.2 主要风险与应对

风险	影响	应对措施
模型产生无依据回答	答案不可信	强制基于检索片段回答，展示引用来源，低置信度时提示用户核对原文
文档解析效果差	检索不到有效内容	支持多种解析器，保留原文页码或段落，必要时允许人工修正
检索结果不相关	回答偏离问题	采用向量检索与关键词检索混合召回，并加入重排序和固定测试集
接口调用延迟或失败	使用体验下降	增加超时、重试、缓存和降级提示，保留模型切换配置
隐私与权限问题	资料泄露	知识库分级授权，敏感文档不入公共库，接口统一鉴权
团队进度不一致	交付延期	每周检查任务看板，提前暴露风险，关键模块设置备份负责人

7.3 迭代计划

阶段	主要任务	阶段成果
第一阶段	需求分析、原型、架构、数据库和接口设计	可评审的选题材料与设计文档
第二阶段	文档上传、解析、分块、向量化和检索	可检索的知识库
第三阶段	问答、引用、多轮对话和反馈	可演示的问答主链路
第四阶段	测试、部署、性能优化和演示准备	可访问的课程项目成品

八、选题 PDF 文档

选题 PDF 文档链接：

06_选题说明.pdf 394.62K

九、结语

DevPulse 想解决的不是一个抽象的技术问题，而是团队协作中反复出现的知识查找和知识沉淀问题。我们希望用软件工程的方法把需求、设计、实现、测试和反馈连成一条完整链路，也希望通过这个项目练习如何做出一个真正有用、可解释、能持续迭代的产品。