不鸽工程队 —— α 冲刺总结随笔

目录

一、 项目预期计划与现实进展

1. 项目预期计划

在本次为期 7 天的 α 冲刺开始前，我们团队基于《需求规格说明书》确立了核心目标：优先跑通“注册登录 -> 活动发布 -> 多维筛选 -> 报名互评”这一最核心的业务闭环。 我们计划交付一个包含前后端完整交互、具备基础信用约束机制的可运行版本，并为后续的 β 冲刺（完善边缘功能与自动化测试）打下坚实基础。

2. 现实进展：基本跑通与云端上线

项目在推进过程中并非一帆风顺，甚至一度遭遇了核心成员前期缺勤、代码仅有空壳无法运行、鉴权体系缺失导致联调卡死的巨大危机。但通过团队在 Day 4 的极限重构与 Day 5-6 的云端部署攻坚，我们成功将系统从本地环境推向了真实的公网生产环境。

目前，系统已稳定部署在华为云 ECS 服务器上，采用 Nginx 托管前端静态资源并反向代理后端 API，数据已接入云端 MySQL 真实落库。

👉 公网访问链接：http://139.159.247.163/ （无需本地启动，评审老师可直接在浏览器打开体验）

(注：该燃尽图真实记录了团队从 Day 2 因人员变动落后 8 个点，到 Day 4 重构后断崖式反超，最终 Day 6 提前锁定胜局的完整逆袭过程。)

项目完成情况

【基础功能】

• 用户端：登录（JWT）、个人中心查看 ✅；注册（未安装 Redis，暂用 Mock 验证码跑通核心流程）⚠️
• 活动端：发布（含时间/人数校验）、列表（多维筛选）、详情 ✅
• 报名端：一键报名/退出（防超卖）、满员自动截止 ✅

【进阶功能】

• 智能推荐：基于“兴趣标签+常去地点”的个性化推荐 ✅
• 信用体系：互评机制（准时/友好/靠谱）、低分（<60）限制报名 ✅
• 放鸽子扣分：定时任务自动扫描扣分 ✅
• 消息通知：基于 Spring Event 的异步站内信 ✅

3. 核心功能线上实拍演示

以下是系统在公网环境下跑通的核心业务链路截图，均为真实接口与真实数据：

【一、安全鉴权与注册登录】
以下为：注册 / 登录界面截图

说明：系统接入了 JWT 鉴权机制，密码使用 BCrypt 加密传输与存储。登录成功后，JWT Token 将持久化在本地，支撑后续的所有业务请求。

【二、活动广场与智能推荐】
以下为：登录后的主界面（含智能推荐页面）截图

说明：首页直观展示“招募中活动”、“今日可参加”与“我的信用分”三项核心指标。同时基于用户标签与常去地点，实现了“为你推荐”的个性化活动流。

【三、多维条件筛选与状态过滤】
以下为：筛选（以跑步为例） / 筛选（已满员）截图

说明：支持按时间、地点、标签（如拼饭、跑步）及状态进行多维度组合筛选。活动卡片上清晰标注了报名进度条，满员活动会自动标记“已满员”并关闭报名入口。

【四、活动详情与发布闭环】
以下为：活动详情 / 发布活动 / 发布成功截图

说明：详情页前置展示了发起人的信用分与活动的信用规则约束；发布表单严格校验了时间先后逻辑与人数上限；发布成功后立刻在列表可见，完成了创作端的完整闭环。

【五、个人中心与消息触达】
以下为：我的活动 / 消息界面 / 个人主页截图

说明：个人中心集成了“发布”与“参加”的双视角管理；消息中心基于 Spring Event 实现了异步站内信落库，未读角标实时更新；个人主页完整展示了信用档案与历史变动明细。

⚠️ 局部功能说明（诚实交付）：
受限于 7 天的冲刺周期与联调优先级，部分非主流程接口尚未完全上线，具体包括：

1. 真实短信验证码接入：目前开发环境采用固定验证码（Mock）跑通注册流程。
2. 个人信息修改：后端接口已就绪，前端表单暂未接入。
3. 取消活动接口：后端已实现逻辑删除，前端入口暂未开放（涉及后续的级联退费与通知机制）。

以上遗留项已作为最高优先级（P0）纳入下一阶段 β 冲刺的规划中。我们选择坦诚暴露短板，因为真实的敏捷开发就是在不断迭代中趋于完美的。

二、 团队成员收获与心得体会

1. 李佳（组长 / 后端 / 运维 / 汇报）

一、这一阶段的收获

这个阶段我主要承担了组长统筹、后端重构、云端部署与全链路测试统筹，收获最深刻的是“极限环境下的工程兜底能力”。

• 从“绝望重构”中理解架构：面对前期核心成员缺勤留下的半成品代码，我第一次系统地复盘了 Controller、Service 到 Mapper 的链路，利用 AI 辅助迅速重构了用户与活动模块。这让我对前后端分离架构、JWT 鉴权体系、ThreadLocal 上下文透传有了肌肉记忆般的理解。
• 跨越“本地跑通”到“真实上线”的鸿沟：部署到华为云 ECS 的过程是一场地狱级拉练。从配置安全组、用 nohup 挂载后台、到被 Nginx 的 Permission denied 权限黑洞卡住，再到解决 MySQL 密码不一致导致程序崩溃。我真正懂得了“开发不仅是敲代码，更是对操作系统、网络协议和运维基础的综合考验”。
• 用“契约”对抗混乱：在联调阶段，因为前端打包漏掉 /api 前缀、时间格式不带 T、实体字段未映射，产生了大量 5000 报错。这让我深刻认识到：在多人协作中，口头约定无效，只有像 Apifox 接口文档、统一的 Result 返回类、.editorconfig 格式规范这些“硬机制”，才能保障交付质量。

二、心得体会

• “问题暴露得越早，代价越小。” 这次冲刺开局遭遇了人员变动，进度一度落后理想线 8 个点。但正因为每晚 21:00 的腾讯会议站会将阻塞摆在了桌面上，我们才能在 Day 4 决定“推倒重来，重构后端”，并在 Day 6 顺利实现了全链路的断崖式反超。
• “作为组长，就是要在关键时刻兜底。” 当发现部分模块无法推进时，我意识到抱怨解决不了问题，必须立刻接管。从写信用模块，到接手用户和活动，再到日夜排查云端 Bug，支撑我的不再是“完成作业”，而是“绝不能让团队的努力白费”。看懂 server.log 并顺藤摸瓜找根因，成了我那几天最强的生存技能。

2. 林严泽（后端开发 / 测试 / PPT）

一、这一阶段的收获
这个阶段我主要承担后端开发、测试和答辩 PPT 三块，收获最实的是后端两件事。

• 第一是高并发报名防超卖：第一次在真实业务里用乐观锁方案，理解了"带版本号条件更新 + 影响行数判断"和直接扣库存的本质区别，也踩过没给活动 id 加索引导致更新变慢查询的坑，对数据库层面的并发有了手感。

• 第二是基于 Spring Event 的消息异步落库，把通知类逻辑从报名主流程里解出来，体会到"主流程只做必须同步的事"这个设计原则。
  测试方面，我从"手动点一遍"转到了用例驱动：写了端到端的报名闭环测试和分页查询单测，学会了正向路径和异常边界分开设计用例。另外整理 Apifox 接口文档的过程让我真正理解了接口契约的价值——前端能拿 Mock 并行开发、后端改接口实时同步，联调扯皮的时间明显变少。最后是答辩 PPT，第一次从"讲什么故事"的角度去组织材料，把燃尽图的落后、反超、锁定三个阶段串成一条线来讲，而不是罗列进度。

二、心得体会

• 最大的体会是"问题不过夜"真的有用。每晚 21:00 的站会看似打断开发，实际上把接口路径缺失、云端权限报错这类阻塞当天就暴露掉了，第二天大家上手都是干净的。其次是云上联调：项目一开始就部署到华为云 ECS，在真实公网环境里跨域、网络、环境变量的问题提前全冒了出来，比到最后一天才发现要强太多。

• 另一个感触是文档不是负担而是协作工具。Apifox 上每改一个字段都是一次广播，前后端不需要互相"喊话"。这一个月让我意识到，软件工程里沟通成本和代码质量同样重要，而好的机制（站会、契约、Git 留痕）就是在系统性降低沟通成本。

3. 施乐山（前端开发）

一、这一阶段的收获

• 技术栈掌握：Vue3 + Vite + Element Plus，从项目初始化到组件拆分，掌握了 Composition API、响应式系统、路由守卫、Pinia 状态管理在真实业务中的用法。10 个页面组件（Login、Register、ActivityList、ActivityDetail、ActivityPublish、MyActivities、ActivityRate、Profile、Notifications、AppHeader）全部从零实现。
• 前后端联调：学会了通过 Apifox 文档对齐接口契约，包括路径前缀（/api）、请求方法（GET/POST/PUT/DELETE）、请求体格式（JSON vs x-www-form-urlencoded）、响应结构（{code, msg, data}）的完整对齐流程。
• 构建与部署：掌握了 Vite 打包产物 dist 的生成与压缩，以及部署到云服务器后通过浏览器 Network 面板排查线上问题的方法。
• 业务理解与工程能力：理解了活动发布-报名-签到-评价的完整业务闭环，以及信用分机制如何约束"放鸽子"行为；实现了"为你推荐"功能（按类型命中 +3 分、地点命中 +3 分、招募中 +1 分的打分模型，排序取前 3 条推荐）。建立了"列后端 Controller → 列前端调用 → 逐一比对路径/方法/字段"的系统化排查方法，以及从"只看 HTTP 状态码"进化到"看业务 code、看异常类型、抓 Network 真实请求、解码 JWT 看真实身份"的多层排查思路。

二、心得体会与教训

• 5000 错误的教训：发布活动返回 5000 时，我一开始怀疑是 Content-Type 没发对，加了请求头、写了拦截器强制 JSON，结果仍然 5000。最后通过解码浏览器 JWT 才发现，登录用的 userId=1111111 在数据库中根本不存在，publisher_id 外键约束 INSERT 失败。教训：5000 是未捕获异常，4001 才是参数校验失败。不能只看 HTTP 状态码（都是 200），要看业务 code。排查要从"假设"走向"证据"——用 PowerShell 对照实验（userId=1 成功 vs 1111111 失败）是最有力的确认手段。
• 保底数据的隐蔽性：Profile 页面无论谁登录都显示"陈望"，原因是 API 路径写错（/api/users/me 不存在），请求 404 后降级到了 mock 数据，界面看起来"正常"但数据全是假的。教训：catch 块里的 mock 降级是双刃剑——它防止白屏，但也会掩盖接口错位问题。联调阶段应该让接口失败时显式报错，而不是静默降级，或者至少在控制台打出明显的警告。
• 接口对齐要全面：一天内集中排查了 19 处 axios 调用，发现了 2 处路径完全错误（/participants、/api/reviews）、1 处字段结构不匹配（前端单 score vs 后端三维评分）、多处硬编码兜底数据。教训：接口对齐不能"改一个算一个"，要一次性把所有调用点拉出来和后端 Controller 做全量比对，否则会出现"修了登录、注册又错了；修了注册、评价又错了"的打地鼠局面。
• 时间格式的坑：deadline 用 toISOString() 会转成 UTC 时间，比本地时间早 8 小时，导致后端"截止时间不能晚于开始时间"的校验误判。改为手动拼接 YYYY-MM-DDTHH:mm:ss 本地时间才解决。教训：涉及时间的字段，前后端一定要明确时区约定，不能想当然用 toISOString()。

4. 徐鑫（测试）

一、这一阶段的收获

这个阶段我主要承担测试工作支持，收获最实在的是"从开发者视角切换到测试者视角"的过程。

• 完成从"写代码"到"测试代码"的视角切换：之前总觉得代码写完能跑就完事了，这周专门负责黑盒测试工作，用 Apifox 对云端部署的接口做测试，从重复注册拦截、未登录 Token 鉴权、参数格式校验到错误密码提示，一个场景一个场景地验证。写了 14 条测试用例，覆盖正常流程和异常边界，才发现自己之前写接口的时候漏考虑了多少边界情况——比如一开始以为中文乱码是后端编码问题，折腾了半天才发现是 PowerShell 终端的显示差异，这种"踩坑"的经历是看多少教程都学不到的。

• 完整走通一个 Web 项目从 0 到 1 的落地闭环：真正经历了在 CodeArts 上克隆团队仓库、按照分层架构规范创建 controller/service/mapper/entity 四层包结构、用 Lombok 注解编写实体类、提交 git commit 推送到远程仓库、和团队成员在同一个代码仓库里协作开发、最后把整个 SpringBoot 项目打包部署到华为云 ECS 服务器上，通过公网 IP + 端口提供接口服务。整个流程走下来，才真正理解之前书本里讲的"版本控制"、"分层开发"、"前后端分离"到底在实际项目里是怎么运转的。

• 对工程化协作有了真实体感：之前一个人写作业的时候，想怎么写就怎么写，这次团队 4 个人同时在一个仓库里开发不同模块，大家通过 Apifox 对齐接口文档、通过 git 提交代码、通过每日站立会同步进度，才明白为什么企业里要花那么多时间做接口设计、做代码规范——不是为了走形式，是为了 4 个人写的代码能真正拼到一起跑通。

二、心得体会

• 开发之前先对齐，比写完再改效率高 10 倍。 一开始我们写接口的时候，各写各的，等到联调的时候才发现，我定义的返回字段是 userId，前端同学期望的是 id；我注册接口要手机号，前端页面收集的是学号，这种低级错误如果在开发前花半小时在 Apifox 里把接口字段对一遍，根本不会出现。这周测试的时候，看到很多问题其实都是"没提前对齐"导致的，不是技术难题，是沟通问题。

• "能跑"和"能用"是两回事。 我写的注册接口，在本地 Postman 里点一下能返回 200，我就觉得写完了。等到部署到云端，做黑盒测试的时候才发现：重复注册有没有拦截？密码错误提示清不清楚？没登录访问会不会跳回登录页？这些"边角料"的场景，才是真正决定一个系统好不好用的地方。作为开发者很容易陷入"我的代码没问题"的思维定势，站在测试的角度看自己写的接口，马上就能发现一堆问题。

• 团队里每个人的分工不是"各干各的"，是要互相兜底。 这周我负责测试的时候，发现接口有问题，马上找对应的后端同学调整；前端同学联调的时候遇到字段不对，我也马上配合改接口。没有哪个模块是独立存在的，一个报名接口，要用户模块给信用分、活动模块判断名额满没满、消息模块发通知，哪一个环节出问题，整个流程就跑不通。

三、 组员分工与工作量比例

在本次冲刺中，面对突发危机，团队分工进行了动态补位，每个人都在其他人的主线上出现过。

1. 实际分工与核心产出

2. Alpha 阶段贡献度比例

⚠️ 贡献度特别说明：
在冲刺初期，徐鑫同学因个人原因出现过几次缺勤，导致关键路径（用户与活动模块）一度阻塞，严重拖累了团队的进度。为保证项目顺利交付，这部分开发任务由组长紧急接管补齐。
在冲刺中后期，徐鑫同学积极调整状态，承担了全系统 14 条黑盒测试用例的编写与执行，并输出了完整的测试报告。团队经慎重商议，决定保留其 14% 的基础测试贡献度。

四、 回顾 AI 技术员的表现与下一阶段展望

在本次 α 冲刺中，AI 技术员不再是单纯的“问答机器人”，而是深度融入了我们的研发流水线。团队根据不同的开发阶段，将 AI 划分为“程序员、测试员、设计师”三大岗位。以下是全组同学在不同岗位上的真实协作经历与反思：

1. AI 程序员（辅助编码）

选用工具： Seed-Code（前端）、通义灵码（后端）、WorkBuddy（后端）

具体职责与团队经历：

• 模板代码生成与样板搭建（林严泽）： 在实现高并发防超卖时，利用 AI 辅助生成了乐观锁方案的初版代码和单测骨架，林严泽在此基础改成了符合项目表结构的实现；基于 Spring Event 的消息解耦，也是先让 AI 给出了两三种方案对比后再敲定的。
• 用户模块和活动模块的架构重构（李佳）： 面对前期缺勤留下的半成品代码，组长李佳利用通义灵码迅速扫描代码库，精准列出了一份“接口状态与缺陷盘点表”（如漏写分页、明文密码漏洞）。随后，AI 生成了包含 @Transactional、乐观锁的完整 Service 代码，为极限救场省去了至少两天的开发时间。
• 复杂组件生成（施乐山）： 前端开发中，借助 Seed-Code 快速编写了 10 个 Vue 组件（如推荐匹配算法的打分逻辑、星级评价组件等），大幅提升了 UI 产出效率。
• 反思与局限： AI 虽然生成速度极快，但常常缺乏全局上下文（如忽略外键约束、API 版本差异）。大家达成共识：AI 只能负责“起草”，最终的 Review 和验证必须由人来兜底。

2. AI 测试员（辅助测试与排错）

选用工具： DeepSeek、WorkBuddy、豆包

具体职责与团队经历：

• 通过日志“云端排雷”（李佳）： 部署华为云 ECS 时，满屏的 Linux 报错和 HTTP 5000 令人崩溃。组长将 Nginx error.log 抛给 DeepSeek，AI 瞬间提取出 NoResourceFoundException 和 Permission denied，一针见血地指出：“Nginx 用户没权限读 root 目录”、“前端路径漏了 /api”，极大缩短了运维排障路径。
• 系统化根因定位（施乐山）： 发布活动报 5000 时，AI 提出了“解码 JWT 看真实 userId”的关键思路，并设计了 PowerShell 对照实验（userId=1 成功 vs 1111111 失败），一次性确认了外键约束失败的根因，避免了盲目打地鼠式的排查。
• 边界用例生成（林严泽/徐鑫）： 在测试报名闭环时，借助 AI 快速生成了覆盖正常、异常、权限拦截等边界的测试用例，有效弥补了人工思考的盲区。

3. AI 设计师（辅助设计与选型）

选用工具： Seed-Code

具体职责与团队经历：

• UI 交互实现（施乐山）： 在开发活动列表时，利用 AI 快速实现了“报名进度条（el-progress）”的交互逻辑，以及“未登录时自动隐藏 AppHeader”的样式设计。
• 技术选型与避坑（施乐山/林严泽）： 前端在评估依赖库时，借助 AI 规避了 pinia 4.x 和过新 element-plus 的版本崩溃坑，AI 给出了合理的降级建议；后端在梳理两份不同的建表脚本时，AI 自动比对差异并辅助完成了列名映射的修复。

4. 下一阶段（β 冲刺）如何更好地利用 AI？

基于 α 阶段的经验，团队对 β 阶段提出了以下 AI 协作升级计划：

1. 前置化接口契约审查（前端）： 在写前端代码前，先让 AI 读取后端所有 Controller 和 DTO，生成一份“接口契约清单”（路径、方法、字段），开发时严格对照，把“事后返工”变成“事前对齐”。
2. 代码审查常态化（后端）： 每次 Push 代码前，让 AI 对 commit 做一遍审查（命名、空指针、事务边界），把低级问题挡在远程仓库之外。
3. 测试生成与自动化回归（后端）： 新接口提交前用 AI 生成单测和边界用例初稿，并尝试利用 AI 编写自动化回归脚本，把“手动点”变成“自动跑”。
4. 沉淀团队 Prompt 库（全组）： 把本次冲刺中诸如“排查 Nginx 权限”、“解码 JWT 定位 5000”等高效提问方式整理成团队共享文档，让 AI 经验在队内无缝复用。

五、 答辩 PPT 链接

本次 α 冲刺的答辩PPT链接如下：

不鸽工程队-α阶段答辩PPT.pdf 1.07M

六、 对下阶段（β 冲刺）展望

结合本次 α 冲刺暴露出的遗留问题与系统的实际运行情况，我们对 β 阶段制定了明确的优先级规划，不并行铺开，而是按“先闭环、再体验、后性能”三步走：

1. 补齐遗留功能闭环（最高优先级 P0）

这是 β 阶段首先要拿下的硬骨头，因为它们是完整业务不可或缺的一环。

• 用户模块：接入真实的短信验证码 API，完善个人信息修改与头像上传逻辑。
• 活动模块：实现取消活动接口，并补全级联逻辑（如取消后自动退回报名者名额、发送取消通知）。
• 报名模块：完善签到机制的前端交互，让线下活动的履约过程也能在系统中形成闭环。

2. 视觉与交互体验升级（P1）

在功能跑通的基础上，提升系统的“产品感”。

• UI 精细化：为页面切换增加过渡动画，优化空状态（如无活动时）的插画提示，提升视觉质感。
• 消息触达：增加“活动开始前 1 小时”的强提醒弹窗，用产品手段减少实际放鸽子率。

3. 性能优化与质量保障（P2）

为系统上保险，避免后续迭代引入新 Bug。

• 自动化测试：将当前手动的核心黑盒测试用例，转化为 CI/CD 流程中的自动化接口测试脚本，实现每次提交自动回归。
• 系统压测：对“活动列表查询”和“报名”这两个高并发接口进行压测，优化索引和 Redis 缓存，提升系统吞吐量。