就想讨点学分有什么不队-冲刺总结

一、作业基本信息

项目 内容
这个作业属于哪个课程 https://edu.cnblogs.com/campus/fzu/202501SoftwareEngineering/
这个作业要求在哪里 https://edu.cnblogs.com/campus/fzu/202501SoftwareEngineering/homework/14586
团队名称 就想讨点学分有什么不队
团队成员-学号 102301227 刘琦晟、102301106 李玥彤、102301105 卢铃颖、102301108 贺之梅、052204124 张君峰、172309011 李帅、102301512 赵鑫鑫、102301522 王心宏、052201142 孙其煜、102301437 丁浚哲、102301303 俞欢殷、102301438 陈泽荣
这个作业的目标 回顾 AetherNet 校园互助平台 Alpha 冲刺过程，对照冲刺计划检查改进点落实情况，总结项目亮点与不足，梳理各成员的实际工作内容与工作量比例，为后续 Beta 冲刺与答辩做准备。

👉 《就想讨点学分有什么不队-冲刺计划》

链接: https://pan.baidu.com/s/1UqK-RyNQyPiOOmu-erULzw?pwd=rcmp 提取码: rcmp

二、与冲刺计划对比：改进完成情况

  1. UI & 原型方面的改进：已完成 ✅
    1. 计划：在原有 Modao 原型基础上，补齐所有主流程页面，并升级为可以直接指导前端开发的高保真稿。
    2. 实际：本次 Alpha 已完成 Pixso 高保真 UI 设计，覆盖：
      • 登录/注册页、首页信息流与校园服务入口；
      • 代拿/任务服务页（列表、筛选、AI 推荐区）；
      • 校园动态聚合页、帖子详情页、发帖页；
      • 个人中心页、后台内容审核页等。
    3. 链接： 👉 Alpha UI（Pixso）：https://pixso.cn/app/design/DhAQDJe9LJKPuezWM9XRcA?icon_type=1&page-id=0%3A1
  2. 后端与接口层面
    1. 完成 后端框架搭建（路由、控制器、服务分层、异常处理等基础骨架）；
    2. 编写并维护了 接口文档（帖子/评论/用户/AI 审核等模块的 API 设计）；
    3. 完成 依赖管理（项目依赖库统一管理、版本控制、打包与运行方式规范）；
    4. 为前后端联调准备并维护了 测试数据集。
  3. 数据库与数据层
    1. 在前期 ER 图和关系模型基础上，实现了实际数据库建表（Users、Posts、Comments、Tags、ModerationLogs 等）；
    2. 进行了数据库优化（如为常用查询添加索引、区分热数据和冷数据、考虑按时间/类别的查询场景）；
    3. 构造了一批 用于联调与测试的样例数据，方便前端展示与功能验证。
  4. 核心业务功能（已跑通）
    1. 发帖功能：
      • 支持发布普通动态/任务贴；
      • 支持标题、正文、标签、图片等字段；
      • 提交后写入数据库并触发审核流程。
    2. 评论区功能：
      • 支持在帖子详情页添加评论、查看评论列表；
      • 评论与用户、帖子正确关联；
      • 评论数实时更新。
    3. 用户认证模块：
      • 实现基本的注册/登录流程；
      • 完成用户身份校验与会话/Token 管理；
      • 为后续“角色区分（学生/管理员）”预留扩展接口。
  5. AI 功能（已经有可用版本）
    1. AI 审核（SafetyBot 初版）：
      • 后端实现帖子内容的自动审核接口；
      • 能对帖子文本进行敏感词与简单规则判断；
      • 审核结果和风险信息写入审核日志表（ModerationLogs），并返回前端显示状态（如“待审核”“已通过”“有风险”）。
    2. AI 发帖辅助（智能发帖助手）：
      • 前端在发帖页面集成了 AI 辅助入口；
      • 后端实现 AI 建议接口：根据用户输入的关键字/草稿，生成或优化帖子内容/标题/标签建议；
      • 已完成与前端的联调，用户可以体验“AI 帮忙润色、补完帖子”的功能。
  6. 前后端联调与可运行版本
    1. 完成了前后端联调：
      • 发帖 → 写库 → AI 审核 → 状态返回；
      • 查看帖子 → 评论 → 刷新评论列表；
      • 登录 → 获取用户信息 → 访问个人中心。
    2. 目前 AetherNet 已具备一个 “基本功能都能跑起来”的 Alpha 版本，可以进行演示和日常功能测试。

✅ 结论：

冲刺计划中对项目的大部分改进不只是“写在文档里”，而是已经实实在在落到了 可运行代码 上。 计划里的“原型升级 + 架构设计”全部完成，核心业务 + AI 能力 + 联调 也基本达成。

三、项目的亮点

1. 真正能跑的 Alpha，而不是纸面设计

  • 完整业务闭环已经打通 从“看原型”到“真机演示”，我们已经跑通了 AetherNet 核心业务链路：
  • 登录/注册 → 用户认证 → 发帖 → AI 审核 → 内容展示 → 评论互动
  • 目前系统已经支持：
    • 用户注册、登录与身份校验；
    • 在发帖页填写标题、正文、标签、上传图片，一键发布；
    • 帖子持久化存入数据库，并进入审核流程；
    • 审核通过的帖子出现在首页信息流 / 列表页；
    • 在帖子详情页查看全文、浏览评论、参与互动。
  • 关键功能不只是“写在文档里”，而是有代码、有数据、有联调 已经实装并通过联调的核心模块包括：
    • 接口文档设计与维护；
    • 数据库设计 + 建表 + 基本优化；
    • 后端框架搭建（路由、控制器、Service 分层、异常处理）；
    • 发帖功能、评论区功能、用户认证与 Token 管理；
    • AI 审核、AI 辅助发帖；
    • 测试数据构造与前后端联调。
  • 整体上，项目已经具备一个可演示、可体验的最小可用产品（MVP）形态。

2. AI 审核：通义千问 + 硬规则双保险

  • 接入通义千问，实现智能审核与文案辅助
    • 我们通过后端中间层接入通义千问，实现两类能力：
      • AI 审核：对帖子内容进行语义分析，识别攻击性言论、灰色表达、潜在风险内容，给出风险等级与理由；
      • AI 发帖助手：在发帖页面，用户输入关键词或草稿，AI 返回优化后的标题/正文/标签建议，辅助用户快速构建优质内容。
    • 前后端已经完成联调，用户可以真实体验“AI 帮忙写帖”和“AI 帮忙审帖”的效果，而不是停留在 PPT 层面的设想。
  • AI 之上再加一层“硬规则”，保证底线可控 针对老师提出的“内容审核不能只靠模型，需要有硬规则兜底”的建议，我们在架构上明确了三层审核结构：
    • 硬规则层（Rule Engine，优先级最高）
      1. 由后端实现的规则引擎：敏感词黑名单、正则规则、黑名单链接等；
      2. 一旦命中必禁规则，内容直接进入“违规/待人工复核”，AI 不能推翻。
    • AI 审核层（通义千问）
      1. 对未命中硬规则的内容做语义分析；
      2. 输出低风险 / 存疑 / 高风险判定及原因，辅助平台发现规避词、擦边球等问题。
    • 人工复核层（管理员后台）
      1. 对“硬规则命中”和“AI 判为高风险”的内容进行人工复查；
      2. 最终处理结果和原因写入审核日志，反向用于更新规则与优化提示词。
  • 简单来说：
  • 硬规则负责画红线，AI 负责补灰区，最终由平台掌握裁决权。 这既保证了内容安全的可控性，也充分利用了大模型在语义理解方面的优势。

3. 前后端分离 + 清晰接口 + 统一依赖管理

  • 从一开始就坚持“前后端分离”架构
    • 后端只做一件事：提供清晰、稳定的 RESTful API，按角色和功能划分为 /api/public、/api/student、/api/admin 三大前缀；
    • 小程序端和管理后台都通过 HTTP 接口拿数据，界面逻辑与业务逻辑彻底解耦，方便以后单独替换前端或后端。
  • 接口文档是真正“可用的协作基准”
    • 不只是列个 URL，而是为每个核心接口都写清楚：
      • 请求方法 + 路径（如 POST /api/public/login、GET /api/student/posts）；
      • 请求体 / 查询参数字段说明；
      • 统一的响应格式（code、message、data、timestamp）和分页结构；
      • 约定好的业务状态码语义，以及典型错误返回示例。
    • 前端、后端在联调时都对照同一份文档进行实现，减少了“口头协议”和“我以为是这样”的沟通成本，Bug 定位更直接（是前端参数还是后端返回结构）。
  • 统一响应与错误码设计，便于扩展与调试
    • 所有接口都使用统一的 JSON 包装结构，并约定了分页数据结构、业务状态码（200/400/401/403/404/500 等）；
    • 这让前端可以写一套通用的请求封装与错误处理逻辑（如统一弹 Toast、跳转登录页），后端新增接口也能无缝接入现有框架。
  • 依赖管理与启动方式统一，项目更容易迁移和部署
    • 后端通过统一的包管理工具管理依赖，前端各子项目也使用固定的依赖版本；
    • 在 README 中写明了后端、管理端、小程序的安装与启动步骤，规范环境变量配置方式；
    • 尽量避免出现“在 A 机器能跑，换一台就起不来”的情况，也为后面上服务器部署、做持续集成留下了空间。

4. 数据库设计从一开始就考虑查询场景与扩展性

  • 数据模型围绕业务而不是围绕“方便建表”来设计
    • Users、Posts、Comments、Tags、ModerationLogs 等表结构，是根据用例、UML 和实际查询需求综合设定的；
    • 例如：
      • Posts 表支持按类别、时间、用户等维度组合查询；
      • ModerationLogs 支持按审核对象、风险等级、审核时间筛选，方便风控与统计。
  • 索引与优化面向“将来要用”的场景
    • 为高频场景（如按 category + created_at 拉取最新帖子）预先设计索引；
    • 为审核日志等表预留查询字段，支持后续做：
      • 违规内容占比统计；
      • 不同时间段的风险分布分析；
      • 简单的推荐与风控策略。

5. 工程实践与团队协作能力的提升

  • 使用 GitHub 做版本管理，分支开发、合并请求、代码审查初步形成习惯；
  • 使用飞书做任务拆分与进度跟踪，每个任务有负责人、截止时间与优先级；
  • 测试同学在 Alpha 就提前介入，用用例 + 手动测试 + 逻辑走查的形式，帮助团队发现不少隐藏问题。

整体上，这次 Alpha 冲刺让团队从“做课程作业”逐渐进入“做一个像样产品”的状态。

四、每位成员的过程体会

  • 刘琦晟 这次冲刺最大的感受是：队伍一多，光“会开好”就已经是挑战。前期我们把时间压在设计上，看起来进度慢，但现在发现这一步是有价值的。接下来希望在保持节奏的同时，把更多精力放到真正能跑的功能上。
  • 陈泽荣 确保注册、登录、内容发布等功能的视觉统一与交互流畅。学习并熟练使用了pixso、figma等软件，对于软件工程这门课程有了更深入的了解。
  • 赵鑫鑫 通过这次的实践，我收获了不在止步于理论上的知识，更积累了在团队中沟通，合作的重要性，高效地完成代码编写离不开团队的合作与沟通。
  • 孙其煜 遇到最多的问题是字段名对不上（比如后端要 categoryId，我写成 category_id，后来就养成了边写边对照文档的习惯，省了不少 debug 时间。
  • 李玥彤 实现点赞、图片上传等交互功能，并对页面跳转逻辑进行统一封装，保障操作流程顺畅。此次经历不仅让我扎实掌握了小程序开发技能，更完成了从理论到实践的重要跨越。
  • 李帅 在项目中完成了核心业务接口的开发与调试，优化了前端交互体验，并高效完成前后端联调。通过本次实践，提升了全栈开发能力，加深了对系统协作与数据交互逻辑的理解。
  • 卢铃颖 在此次项目中对微信开发工具更为熟悉，掌握了底部导航栏的配置与页面跳转，学会了将互动按钮与图片整合，提升了组件整合与交互实现的能力。
  • 贺之梅 从设计到代码的转化需要耐心调试。掌握了前端工具链使用，学会了解决资源路径和兼容性问题。虽然遇到布局偏差等挑战，但最终完成页面的成就感让我对前端开发更有信心。
  • 俞欢殷 服务与订单、帖子状态流转间的高效协同。通过将业务逻辑模块化，协助前端小程序与管理后台的快速迭代，为前后端并行开发提供帮助。
  • 张君锋 过程中需主动同步进度、及时响应前端疑问，兼顾功能实现与用户体验。这不仅提升了我的协作能力，更让我明白精准对接是保障项目高效推进的核心。
  • 丁浚哲 从制定全局规范，到完成高保真可交互原型，再到输出前端切图与标注项目UX设计，从制定全局规范，到完成高保真可交互原型，再到输出前端切图与标注
  • 王心宏 打通了从小程序到后端数据库的数据链路；同时完成了用户认证与核心业务流程的闭环测试，确保了注册、登录及内容发布等关键功能的稳定性，实现了项目从模拟数据到真实交互的质变。

五、目前仍存在的不足与下一步计划

尽管目前基本功能和 AI 审核已经落地，但从“能跑起来”到“真正好用、好看、够稳、可维护”，我们还明显有进步空间。

1. 功能层面：主线顺畅，细节尚需打磨

  • 边界场景覆盖不足
    • 对以下情况还缺乏系统性设计与测试：
      • 超长标题 / 超长正文的输入限制与友好提示；
      • 弱网 / 断网状态下，发帖、评论的失败重试与状态回滚；
      • 用户短时间内频繁操作（如连点发帖、刷点赞）的限流与防滥用机制。
  • 部分模块仍处于“基础版”阶段
    • 任务匹配与推荐系统目前仍以规则和简单查询为主，还不算真正意义上的“智能策略”；
    • 举报、封禁、黑名单体系还没有完全实现，平台风控能力有待加强。

2. 审核与风控体系：硬规则已确立，但仍需系统化建设

  • 黑名单与规则库还不够丰富
    • 目前硬规则主要是初版敏感词和简单正则，覆盖范围有限；
    • 尚未针对校园场景（考试、挂科、作弊信息、造谣等）构建更细化的规则集合。
  • 硬规则的管理方式还偏“手工”
    • 当前敏感词和规则仍依赖代码维护或配置文件修改；
    • 后续需要：
      • 将规则配置化、存入数据库或配置中心；
      • 提供管理界面，支持管理员在线增删规则、调整优先级。
  • 缺少针对审核模块的****系统测试
    • 目前对审核逻辑的验证多依赖人工试验；
    • 后续需要为典型违规内容构建：
      • 一组固定测试用例，保证硬规则永远不会被新版本“意外放行”；
      • 针对不同类型内容（正常 / 擦边 / 明显违规）的分类测试集，验证硬规则 + AI 的组合效果。

下一步目标： 将“通义千问 + 硬规则”的组合，从一个工程实现，提升为一套“可配置、可验证、可演进”的审核系统。

3. 性能与稳定性：目前适合小规模使用，尚未压测

  • 缺少压力测试与性能评估
    • 尚未对高并发发帖/评论、审核日志大量写入等场景做系统压测；
    • 不清楚在几十倍数据量、并发在线用户增加时的响应时间和数据库瓶颈。
  • AI 接口容错与降级策略有待增强
    • 当通义千问响应变慢或出现异常时：
      • 目前提示与降级方案还不够优雅；
      • 理想状态应该是：AI 不可用 ≠ 用户不能发帖，而是临时关闭 AI 辅助功能、使用纯硬规则审核。
  • 日志与监控体系仍然比较“基础”
    • 主要依赖简单的控制台日志/文件日志；
    • 后续可以考虑：
      • 按级别（INFO/WARN/ERROR）规范日志格式；
      • 针对关键接口记录耗时和错误率，为排错与优化提供依据。

4. 用户体验与 UI 打磨：从“能用”到“顺手好用”

  • 交互细节可以更精致
    • 空页面（比如没有帖子 / 没有评论），暂时缺少友好的引导文案或“去发一条”的按钮；
    • 发帖成功/失败、审核中、网络异常等状态的反馈还不够统一、明显；
    • 部分页面缺少加载中的骨架屏或动画，用户容易误以为“卡住了”。
  • 移动端与小屏设备适配仍不完美
    • 在小屏幕下部分布局略显拥挤，操作区域偏小；
    • 筛选面板和复杂表格（如后台审核页）在小屏展示上需要更好的折叠与分步设计。
  • 文案与视觉风格需要进一步统一
    • 不同页面的文案风格、按钮命名还存在轻微不一致；
    • 后续会统一“平台语气”，让产品看起来更“一个整体”。

5. 工程实践与团队协作：有雏形，还未“武装到牙齿”

  • 自动化测试尚未铺开
    • 目前以手动测试 + 临时脚本为主；
    • 后续计划：
      • 为核心业务（发帖、审核、评论、登录）补充单元测试与接口测试；
      • 建立一套“提 PR → 自动跑基本测试”的 CI 流程。
  • 文档与代码同步仍需加强
    • 功能迭代时，偶尔出现“代码已更新、文档没跟上”或“注释与实际行为不完全一致”的情况；
    • 下一步会在流程上约定：涉及接口变更/审核规则更新时，必须同时更新接口文档和开发手册。

6. 下一步计划（面向 Beta 冲刺的 TODO）

简要列出我们在下一阶段的重点：

  1. 完善硬规则库与配置化管理，实现“可维护的内容安全策略”；
  2. 提升任务匹配与推荐系统的策略能力，做出第一版“真可用”的智能匹配；
  3. 补充边界场景处理与限流机制，提升系统鲁棒性；
  4. 优化移动端体验与交互反馈，让页面在各种设备上都更顺手；
  5. 引入基础自动化测试与简单 CI，将“能跑”升级到“敢发版”。

六、团队成员实际分工与工作量说明（Alpha 冲刺）

说明：工作量比例为团队内部根据实际投入与任务复杂度的主观估计，仅用于课程作业说明。

成员 角色定位 / 负责模块 Alpha 冲刺期间实际完成的工作内容 工作量占比（约）
刘琦晟 PM / 后端参与 / vlog 剪辑 统筹整个 Alpha 冲刺节奏，拆分任务并跟进进度；主持站会与阶段复盘；参与后端整体方案讨论与接口文档设计；协助接口联调与 Bug 跟踪；负责本次冲刺 vlog 的脚本设计、素材收集与完整剪辑制作。 9%
陈泽荣 UI 主设计 负责 Pixso 上整体 UI 设计与视觉规范（配色、组件风格）；主导首页、发帖、详情页等关键页面的视觉方案；与前端对齐交互细节，保证设计稿与实际效果高度一致。 8%
丁浚哲 UI 协作 / 体验优化 与 czr 一起完成页面 UI 分配，补充管理后台、审核页等界面的设计；在小程序与后台联调后，对部分页面进行间距、字号、色彩等体验优化；多次进行自测并为 vlog 提供演示素材。 8%
卢铃颖 微信小程序前端（核心） 负责小程序端主要业务页面开发：首页信息流、帖子详情页、发帖页；实现发帖表单、内容校验、图片上传等核心交互；对接发帖 / 评论 / AI 发帖接口；封装通用卡片组件，为后续扩展打基础。 8%
李玥彤 微信小程序前端 负责小程序端登录 / 注册 / 用户认证流程实现（表单校验、Token 存储与过期处理）；开发个人中心相关页面（我的发布、我的收藏等）；参与小程序端前后端联调，修复多处交互与数据展示问题。 8%
贺之梅 管理后台前端 负责管理后台前端开发：内容审核列表页、审核详情页、用户管理页等；实现表格展示、筛选、分页、批量审核操作等前端逻辑；对接 AI 审核结果显示与风险等级标记，在前端侧完成审核流程的可视化呈现。 7%
孙其煜 管理端前后端联调 / AI 中间层 负责管理端前后端联调：打通后台登录、审核列表、审核决策（通过 / 驳回）、审核日志查询等接口；实现通义千问审核的中间层封装（SafetyBot），负责调用 AI 审核接口、解析结果并写入审核日志；与 hzm 一起调通管理端完整审核闭环。 9%
赵鑫鑫 后端开发 / 认证与审核协作 参与后端框架搭建与依赖管理；负责用户认证模块（JWT 生成、校验、中间件权限控制）；配合 ls、sqy 参与 AI 审核与 AI 发帖接口的封装与调试；编写部分测试数据脚本，辅助前后端联调。 7%
张君峰 小程序前端协作 配合 lly、lyt 完成小程序端部分页面与组件的开发（列表展示、按钮交互、部分筛选区域）；根据测试反馈修复展示与样式问题；协助处理小程序编译、构建过程中的报错与兼容性问题。 8%
王心宏 小程序前后端联调 主要负责前后端联调（小程序部分）：整体检查小程序端接口调用是否与后端约定一致；针对发帖、评论、AI 辅助调用中的数据格式 / 状态码问题进行排查与修复；补充加载状态、错误提示等交互细节。 8%
李帅 后端主程 / 数据库核心负责人 担任本次 Alpha 阶段的后端主程：完成接口文档设计、测试数据构造、数据库设计与优化（建表、字段设计、索引考虑）；搭建后端整体框架与依赖管理；主导实现核心业务接口：发帖功能、评论区功能、用户认证、AI 审核、AI 发帖等后端逻辑；参与小程序端与管理端的前后端联调，是后端代码量与复杂度贡献最高的成员。 13%
俞欢殷 小程序用户模块 / 前端协作 负责小程序端个人信息展示与编辑界面（头像、昵称、学院等）；参与个人中心相关状态管理；协助多处页面调试与样式统一；根据 UI 规范优化部分页面在移动端上的布局与点击区域，提升整体体验。 7%