就像赚点学分有什么不队 共振：把十二个人的声音，汇成一个版本

共振：把十二个人的声音，汇成一个版本

——2025 秋《软件工程》实践团队总结博客（以太校园 Aether Campus）

有些词，只有经历过才会明白它的重量。“共振”就是其中一个。

学期初我们像一盒刚拆封的音叉：每个人都有自己的频率——技术栈不同、作息不同、表达方式不同，连“做到什么算完成”都各有一套理解。大家都在发声，但声音并不总能叠在一起。后来我们才慢慢明白，软件工程最难的从来不是把代码写出来，而是把十二个人的判断标准、节奏和目标校到同一条线上：需求要能对齐，设计要能落地，开发要能衔接，验收要能复现。
项目能跑起来固然重要，但更重要的是，我们真的在某些时刻开始“同向用力”——不是谁更响，而是大家终于能听见同一个版本。

0. 验收入口（项目链接与体验方式）

为了方便老师和助教验收，我们把项目的仓库链接、最终版本、线上地址与体验方式集中放在这里，避免在正文里来回翻找。

• 最终 GitHub 仓库：https://github.com/QishengLiu/unbeatable-grade-hunters

克隆项目到本地

# 首先随便创建一个文件夹
git clone https://github.com/QishengLiu/unbeatable-grade-hunters.git# 进入项目文件夹
cd unbeatable-grade-hunters

找到文件夹final-code，这是我们组最终的代码

1. AetherNet_Admin 是我们组的管理端代码
2. AetherNet_Backend是我们组的后端代码
3. MiniProgram是我们组的小程序代码

管理端代码环境配置

# 这一段代码需要你的电脑安装了node.js# 进入管理端文件夹
cd AetherNet_Admin# 下载依赖库
npm install# 在终端中运行代码
npm run dev

小程序端代码环境配置

小程序端代码你需要在电脑上安装一个微信开发者工具，从而能够跑动我们的代码

这一部分在打开后导入项目就好

导入文件

后端代码环境配置

• 安装jdk-17，下载maven，准备mysql环境,idea

• 打开 src/main/resources/application.yaml

  • 配置数据库username和password

    spring:application:name: AetherNet_Backenddatasource:url: jdbc:mysql://localhost:3306/aethernet?serverTimezone=UTC&useSSL=false&allowPublicKeyRetrieval=trueusername: rootpassword: 123456driver-class-name: com.mysql.cj.jdbc.Driver
    

  • 开通阿里云oss服务后获取修改配置信息（access-key-id，access-key-secret，bucket-name）

    aliyun:oss:endpoint: oss-cn-beijing.aliyuncs.comaccess-key-id: LTAI5tGH39NpTwJBNnVwTQwA		access-key-secret: tZTXTyf95FQ4GYf71skQEH3n9Gle5Bbucket-name: test
    

  • 在阿里云百炼大平台获取api-key，修改配置（api-key）

    ai:openai:api-key: sk-019bcedd770a496d93fawhdjwhkbase-url: https://dashscope.aliyuncs.com/compatible-modechat:options:model: qwen-max	
    

• 创建一个数据库名为：aethernet

  create database aethernet;
  

• 运行 src/main/resources/sql/create_tables.sql 建表脚本

• 点击“运行”按钮，开始运行

1. 我们做了什么：把散在群聊里的需求，接成一个“能跑”的系统

如果只用一句话概括“以太校园”，那应该是：连接每一份校园需求。

我们一开始盯着的不是“做一个多复杂的平台”，而是校园里最常见的几个尴尬：需求散在群聊里、信息碎得像沙、临时求助很难被及时看见；陌生互助的信任成本高；内容治理和审核又常常跟不上。
这些问题如果不解决，平台就算做出来，也只会变成“另一个更大的群”。

所以我们把系统从一开始就按“三位一体”来搭：

• 学生端（The Hands）：微信小程序原生实现，即用即走，把互助任务与校园社交放在同一个入口里，让发布、接单、完成确认这一套流程能顺滑跑完。
• 管理端（The Brain）：用 Web 后台承接治理与管理，不只是“有功能”，而是能把社区管起来——审核、处置、数据可视化都要有。
• 智能核心（The Soul）：我们把 Spring AI 集成进后端，让内容风控不再是纯人工硬扛：用户发帖后 AI 会给出风险评级与建议，并且做了 Fail-Safe 降级策略，AI 服务异常时默认提高风险等级，先保安全。

落到“做出来的东西”上，我们把平台拆成几块清晰的场景：互助板块、以太商城、校园动态（也就是帖子社区）等。
尤其是“校园动态”这一块，为了让它更像真实产品而不是演示页面，我们把治理链路做全：帖子支持评论/点赞，支持举报；举报会进入后台审核流，管理员可以通过/拒绝、下架处置。这样用户端的“热闹”和后台的“秩序”才是一套闭环，而不是各做各的。

说到底，我们交付的目标不是“功能看起来很多”，而是：主流程稳定可用、内容可治理、版本能验收。这也是“共振”的第一个落点——不是每个人各自写一块，而是把所有人的工作汇到同一个版本里。

2. 第一幕：从“要做个项目”到“我们要解决这件事”

学期刚开始那几天，我们其实和大多数小组一样——先是兴奋，接着就会被一个问题追着跑：到底做什么？
如果只为了“能做完”，选一个常见题目当然最稳；但我们很快发现，真正麻烦的不是“做不出来”，而是做出来以后也不知道它解决了什么。

我们后来把讨论的起点放回校园里最具体、最常见的场景：互助需求一直都在，但它们往往散在群聊里，信息被刷掉就没了；就算有人愿意帮，也很难确认“谁来接”“什么时候完成”“有没有变更”。PPT 里我们把它写得很直白：互助需求散落群聊，难以即时触达，同时存在信息碎片化、信任成本高、审核滞后等问题。
这几句话当时听上去像“背景介绍”，后来才发现它其实是我们整个学期的主线——因为每一个功能争议、每一次返工，最后都能追溯到这些痛点有没有被真正解决。

于是我们给项目定下第一句能统一口径的目标：“我们致力于连接每一份校园需求。”
这句话看起来挺像 slogan，但它对我们特别有用，因为它逼着我们把“连接”说清楚：

• 连接不是把信息堆到一个页面上，而是要让需求能被看见、能被回应、能被追踪；
• 连接也不是只做“发布/浏览”，还得想清楚安全与治理，否则平台越热闹越容易失控。

在这个前提下，我们做了一个很关键的收束：不把系统当作“一个端”，而是拆成“三位一体”的方案——学生端（The Hands）+ 管理端（The Brain）+ 智能核心（The Soul）。
这不是为了显得高级，而是因为它恰好对应我们当时最头疼的三类问题：

1. 学生端要“顺手就能用”：微信原生、小程序即用即走，把互助任务和校园社交聚在同一个入口里。
2. 管理端要“能管得住”：我们不想把后台做成摆设，而是要能承担审核与治理，做到“有人能处理、有记录可追”。
3. 智能核心要“跟得上规模”：如果完全靠人工审核，内容一多就会崩。我们在后端集成 Spring AI，让“发帖→AI理解上下文→给风险评级与建议”变成默认流程，并且做了 Fail-Safe 降级：AI 异常时自动提高风险预警，先保证安全。

有了这三条线，我们后面需求讨论的方式也变得更“像项目”一点：
不再是谁的点子更炫，而是回到同一套问题——这项功能放在哪个端？谁负责闭环？出了问题谁能处理？验收怎么跑？
比如帖子模块，我们一开始就决定它不能只是“能发内容”，而要同时考虑治理链路：用户侧有评论、点赞，也要有举报；后台要能接住举报并完成审核处置。它看起来只是一个模块，但其实是我们最早用来检验“平台是否成熟”的试金石——因为只要允许用户发内容，治理能力就必须同步长出来。

这一幕没有什么戏剧化的瞬间，更多是反复确认、反复删改、反复把模糊的话写成清晰的口径。但它决定了后面三个月我们为什么能一路推进：我们不是在堆功能，而是在把“连接”这件事，一层一层做成能跑、能管、能验收的系统。

3. 第二幕：把“共振”写下来——文档、原型与设计，才是团队真正开始变稳的地方

如果说选题阶段我们找到了同一个方向，那接下来真正让团队“像一个团队”的，是一件很朴素的事：把话写清楚，把约定落纸，把分歧提前消化。

十二个人做同一个系统，最危险的时刻往往不是不会写，而是——每个人都在写，但写的不是同一个东西：
有人理解“完成”就是接单人点一下；有人觉得必须发布者确认；
有人以为“举报”点了就下架；有人以为只是进入待审核；
有人把状态当字符串随便写；有人坚持枚举和状态机。
这些差异一开始看不出来，但到了联调和答辩前夜，它们会以最不好看的方式爆出来。

所以我们中期花了很多时间做“慢工”，也算是我作为组长/项目经理最核心的工作内容：文档和设计先行，把团队的共识搭起来。

当时我们给自己定了一个标准：

只要这件事会影响别人写代码，就必须形成可复用的文字/图/口径。

3.1 软件计划书：先把节奏定下来，别让大家靠“感觉”推进

我们先做的不是写功能，而是把一学期拆成可执行的节奏：

• 哪几次作业要交付什么
• Alpha 要跑通到什么程度
• Beta 要冻结哪些内容、怎么验收
• 风险点有哪些（比如：接口频繁改、功能越做越散、演示不稳定），对应的兜底方案是什么

这个计划书看起来像“管理作业”，但它真的救过我们：每当时间紧、需求又想加的时候，我们能回到计划书问一句——现在做这个，会不会影响主流程交付？

3.2 原型：把“我以为你以为”提前砍掉

原型阶段我们吵过很多次，但吵得很值。
因为原型逼着我们把抽象的词落到具体的按钮、页面和流程上：

• 发布任务到底几步？哪些字段必填？
• 任务列表怎么筛？状态怎么展示？
• 帖子页的点赞、评论、举报入口放哪里才不突兀？
• 举报之后用户端要不要提示“已提交处理”？后台怎么看到、怎么处理？

我们在原型里把主流程跑了不止一遍，甚至把“用户会在哪一步卡住”也写进备注里。原型链接发到群里，大家看同一张图讨论，争论立刻变得具体：不是“我觉得”，而是“你看这一步会不会多余”。

3.3 概要设计：给系统定骨架，避免越写越乱

到了概要设计，我们做的事情更像“打地基”——
不只是写某个接口，而是先把整体结构搭稳：模块怎么分、数据怎么流、权限怎么走。

我们当时至少把下面这些写清楚了（后来每一项都用得上）：

• 模块划分：任务、帖子、用户、后台审核/管理等
• 数据库核心表：任务表、帖子表、评论表、点赞/收藏（如有）、举报表、审核记录表、用户与角色表……
• 状态与口径：任务状态怎么流转、帖子/举报状态怎么流转、哪些操作会触发状态变化
• 权限边界：普通用户能做什么，管理员能做什么，哪些接口必须鉴权

尤其是帖子模块，我们特意把“治理链路”写进设计里：
帖子能发 ≠ 平台能用。
能用必须配套：评论/点赞的基本交互 + 举报入口 + 后台审核与处置 + 处理结果可追踪。
这部分写清楚之后，大家才不会各写各的：前端知道页面要预留哪些状态，后端知道接口要支持哪些字段，后台知道要有哪些列表和操作。

3.4 接口口径与验收清单：让“能复现”成为基本要求

中后期我们开始把“验收思维”提前：不是等写完再验收，而是边写边问——这条链路怎么验收？
于是我们把接口字段、错误码、分页规则、状态含义这些东西写成统一口径；同时列了验收清单，至少把主流程和帖子治理流程覆盖掉，例如：

• 任务：发布 → 列表可见 → 接单 → 状态变化 → 完成确认 → 评价/结束
• 帖子：发帖 → 列表/详情 → 评论/点赞 → 举报 → 后台审核 → 下架/处置 → 前台展示变化

这份清单后来在 Beta 阶段非常有用：当大家都很累、很想“差不多就行”的时候，它提醒我们：差不多不算交付，跑通才算。

---

这一幕没有很戏剧化的瞬间，但它让团队的节奏突然变稳了：
我们不再靠“谁在线、谁想起什么就做什么”，而是靠同一套文档、同一套原型、同一套设计口径推进。
从那以后，“共振”不再是一句好听的话，而是变成了一种具体的工作方式：先对齐，再动手；先写清楚，再扩展；先保主流程，再追求完整。

4. 第三幕：Alpha 冲刺——噪音变大时，我们学会守住主旋律

如果把整个学期看成一条线，Alpha 冲刺是最像“真正项目”的那一段：事情突然变密，问题不会排队，昨天还好好的功能，今天合并一下就能把页面送上白屏；你以为只是改了一个字段名，结果牵动了三处接口、两张表、四个页面的逻辑。

那段时间我们最明显的感受是：大家都很努力，但系统并不会因此自动变稳定。
稳定不是“写得多”，而是“守得住”。

4.1 我们怎么在混乱里推进：短站会 + 明确卡点 + 统一口径

Alpha 一开始，我们就把站会“缩短到只剩骨头”——每天十分钟，固定三句话：

• 昨天做了什么
• 今天做什么
• 卡点是什么

当问题密集爆发时，最容易发生的不是“没人做”，而是“大家都以为有人在做”。短站会把这件事硬生生压下去：谁负责、谁协助、什么时候给到可验收的结果——都要落到具体人和具体时间上。

与此同时，我们也做了一个很现实的取舍：先保证主流程能跑通，再谈加功能。
这句话说起来像口号，执行起来很痛：因为每个人都能想到“更完整”的东西，但 Alpha 的目标不是“更全”，而是“能用”。

4.2 最容易翻车的不是代码，是“口径不一致”

Alpha 期间出现的很多问题，表面是 Bug，本质是口径没统一：

• 后端返回字段名和前端期望不一致，列表页直接空；
• 状态码含义没对齐，前端把“未登录”当成“无数据”；
• 分页参数各写各的，数据一多就表现异常；
• 同一个“状态”在不同模块被写成不同枚举，导致逻辑分叉。

我们后来给自己加了一条很硬的规则：

凡是会影响别人开发的变更，必须同步到接口口径/文档里；凡是影响主流程的字段，尽量冻结，不随意改。

这条规则让我们在后半段明显省了返工。因为很多返工并不是“不会写”，而是“反复对齐”。

4.3 帖子模块：我们第一次把“社区热闹”做成“可治理”

Alpha 冲刺里，我们推进得最像“产品”的一个模块是 帖子系统。原因很简单：它逼着我们同时面对两件事——用户体验和治理能力。

用户侧看起来很顺滑：
发帖 → 列表/详情 → 评论 → 点赞 → 举报
但真正决定系统能不能长期用的，是后半段：举报之后怎么办？谁来处理？处理结果怎么影响展示？

所以我们在 Alpha 阶段就把帖子模块做成一条完整链路，而不是“能发就行”：

• 评论：不仅能发，还要考虑评论列表展示、空态与异常提示
• 点赞：不仅是一个按钮，还要考虑是否重复点赞、状态如何回显
• 举报：不仅能提交，还要有明确反馈（已提交/待处理）
• 审核：后台要能看到举报记录、能审核、能下架/处置，并且处置后的帖子在前台会有对应变化（隐藏、不可见、提示等）

做这条链路的时候，我们第一次强烈感受到“工程”的重量：
用户点一下举报，背后其实是权限校验、状态流转、记录留痕、后台操作、前台回显的一整套闭环。把它做通的过程，也让我们整个团队对“平台不能只热闹、还要能管得住”这件事有了更具体的理解。

4.4 Alpha 的阶段性成果：不是“功能变多”，而是“版本变稳”

Alpha 结束时，我们砍掉了一些看起来很酷但不影响主流程的想法，也留下了一些暂时不够优雅但能稳定跑通的实现。现在回头看，这个选择很对：
因为 Alpha 的价值从来不是“堆”，而是“稳”。

我们完成的最大成果不是多了多少页面，而是形成了一种工作节奏：
问题出现 → 能复现 → 能定位 → 有负责人 → 有口径 → 能验收。
当这套节奏跑起来时，团队的“共振”才真正发生——不是大家都很忙，而是忙得方向一致，忙得能把版本往前推。

5. 第四幕：Beta 冲刺——把“能跑”磨成“能交付”

如果说 Alpha 像一场硬仗，目标是把主流程从“纸面”推到“跑起来”；那 Beta 更像收网：不再追求“更多”，而是把已经做出来的东西一点点收束成一个稳定、可验收、可复现的版本。

这一阶段我们的心态变化很明显——从“赶紧把功能写出来”，变成“别再让版本失控”。因为越到后期越清楚：答辩现场不会给我们解释的时间，老师也不会帮我们 debug。系统要么稳稳跑完主流程，要么当场露馅。

5.1 冻结：我们学会对“临时改一改”说不

Beta 的第一件事是冻结。
冻结什么？不是冻结努力，而是冻结那些最容易引发连锁反应的东西：接口字段、状态含义、核心流程的验收口径。

我们给自己定了几条很简单但很管用的规则：

• 主流程相关字段（任务状态、帖子状态、举报处理结果）尽量不改；确需调整必须同步到文档与前端回显逻辑。
• 新需求原则上不进版本，除非能明显提升验收稳定性。
• 修 Bug 优先于加功能；体验细节优先于“看起来更厉害”的扩展。

这些规则不酷，但它们让我们从“不断拆东墙补西墙”的循环里跳出来——版本终于开始稳。

5.2 打磨：把用户真正会遇到的细节补齐

Beta 的大部分时间，我们都在做那种“写进 PPT 很难讲，但用户用起来立刻能感知”的事：

• 页面加载时的 加载态/骨架屏
• 数据为空时的 空态提示
• 出错时的 错误提示与可理解文案
• 操作按钮的 防抖/重复提交
• 管理后台列表的 分页、筛选、状态回显

尤其帖子模块，我们把“社区感”做完整，也把“治理链路”收得更紧：

• 用户端：评论、点赞的交互更稳定，状态回显更一致；举报提交后有明确反馈，不让用户怀疑“到底有没有提交成功”。
• 管理端：举报列表、审核操作、处置结果更清楚；处置后前台展示能立即体现变化，避免出现“后台说下架了但前台还能看到”的尴尬。

细节并不华丽，但它们决定了平台到底是“演示系统”还是“能被真实使用的系统”。

5.3 回归：我们一遍遍跑验收清单，像排练一样排练系统

Beta 里最像“交付”的事情，是我们开始把系统当成一个需要排练的作品。

我们把验收路径拆得很具体，反复回归——每一次回归都当成一次小型演示：

• 任务主流程：发布 → 列表可见 → 接单 → 状态变化 → 完成确认 → 评价/结束
• 帖子治理流程：发帖 → 列表/详情 → 评论/点赞 → 举报 → 后台审核 → 下架/处置 → 前台展示变化

它的意义不只是“检查功能”，更重要的是让我们提前发现：
哪一步容易卡、哪里最容易因为网络/环境差异出问题、哪条链路一旦断了会影响演示。

也就是从这时候起，我们才真正理解“可验收”这件事：
不是你说你做了，而是别人按步骤操作，也能得到同样结果。

5.4 答辩与演示：我们把风险预案也当作交付的一部分

临近答辩，我们做的事情变得很像“上台前的最后检查”：
演示脚本怎么走，现场怎么分工，谁负责讲解，谁负责操作，出现意外怎么兜底。

我们甚至把“可能翻车的点”列出来：

• 网络不稳定怎么办（备用热点/备用设备）
• 服务器临时异常怎么办（备用地址/备用数据）
• 小程序授权异常怎么办（备用账号/备用流程）
  这些听起来有点谨慎，但它们让我们在答辩那天更稳——因为真正的交付不只是功能本身，也包括“出现问题时还能把系统交出去”的能力。

当答辩现场按脚本走完主流程，帖子模块的举报与审核也能顺利演示出来时，我们那一刻的感受很明确：
不是“我们写了多少”，而是“我们真的交付了一个版本”。

6. 投入与产出：把“十二个人的共振”落到可量化的记录里

写到这里，故事似乎已经讲完了一大半：从选题、设计到冲刺、交付，我们把一个版本敲到了最后。但软件工程这门课有一个很重要的维度——它不仅看“讲得好不好”，也看“做了多少、怎么做的、能不能复现”。所以这一章我们把团队的投入与产出集中整理出来，作为验收之外的另一种“证据”。

6.1 团队角色与贡献概览

我们团队共 12 人，每个人都参与了「以太校园 」的设计与开发，只是分工侧重不同：有人主攻前端页面与交互，有人负责后端接口与数据流转，有人承担测试、部署与材料整合；而在这些角色之上，我们也在项目推进中不断补位——因为到了后期，版本不允许“只管自己那一块”。

成员	主要角色/分工	主要贡献点（建议写模块）
1 刘琦晟	PM / 后端参与 / vlog 剪辑	负责项目整体规划与进度控制，参与后端框架搭建，协调团队工作并解决问题，制作项目 vlog
2 孙其煜	管理端前后端联调 / AI 中间层	参与管理端前后端联调，负责 AI 审核接口的中间层封装，确保管理端完整审核闭环。
3 张君锋	小程序前端协作	负责小程序端页面开发、样式优化，并解决编译报错与兼容性问题，提升了系统稳定性与用户体验。
4 卢铃颖	微信小程序前端	负责小程序端核心页面开发，实现了发帖表单、内容校验与图片上传功能。
5 李帅	后端主程 / 数据库核心负责人	担任后端主程，负责数据库设计与优化，主导实现发帖、评论、AI 审核等核心后端功能。
6 王心宏	小程序前后端联调	负责小程序前后端联调，确保接口调用一致，修复发帖、评论等数据格式与状态码问题。
7 陈泽荣	UI 主设计	主导 UI 设计与视觉规范，设计了小程序首页、发帖页、详情页等核心页面。
8 丁浚哲	UI 协作 / 体验优化	参与 UI 设计与页面优化，负责管理后台和审核页的设计，提升了整体用户体验。
9 贺之梅	管理后台前端	负责管理后台前端开发，完成内容审核列表页、审核详情页等功能，优化了审核流程的可视化呈现
10 李玥彤	微信小程序前端	开发了小程序的注册、登录、用户认证模块，并参与个人中心页面的开发与前后端联调
11 赵鑫鑫	后端开发 / 认证与审核协作	参与后端框架搭建，负责用户认证模块与 AI 审核接口的封装与调试，支持前后端联调。
12 俞欢殷	小程序用户模块 / 前端协作	负责小程序端个人信息展示与编辑界面，优化页面样式和布局，提升移动端用户体验。

---

6.2 组员学期回顾引用

按照课程要求，每位组员的学期回顾会在团队博客中引用。我们把每个人的“个人视角”留在这里——它们是我们这学期不同侧面的回声：

• 组长 刘琦晟：https://www.cnblogs.com/atopos018/p/19413371
• 组员 1 孙其煜：https://www.cnblogs.com/sunqyaddda/p/19411804
• 组员 2 张君锋：https://www.cnblogs.com/zjfEdward/p/19411952
• 组员 3 卢铃颖：https://www.cnblogs.com/Lllly6721/p/19412107
• 组员 4 李帅：https://www.cnblogs.com/huwuhu/p/19412114
• 组员 5 王心宏：https://www.cnblogs.com/yesno233233/p/19412130
• 组员 6 陈泽荣：https://www.cnblogs.com/3Chen0/p/19412173
• 组员 7 丁浚哲：https://www.cnblogs.com/matsukiri/p/19412220
• 组员 8 贺之梅：https://www.cnblogs.com/hzmhhh/p/19412516
• 组员 9 李玥彤：https://www.cnblogs.com/lyt1/p/19412606
• 组员 10 赵鑫鑫：https://www.cnblogs.com/wwwzxx/p/19412707
• 组员 11 俞欢殷：https://www.cnblogs.com/yhynote/p/19412802

7. 我们这一学期真正学到的东西：不是“会了更多技术”，而是“更像在做工程”

写完投入与产出，再回头看这一学期，其实最明显的变化不是“又掌握了多少框架”，而是我们对“工程”这两个字的理解更具体了：工程不是灵光乍现，而是把一堆不确定的东西，变成可讨论、可协作、可验收的确定性。

这一章我们把收获分成两部分：技术与工具（能说清楚、能复现），以及技术之外的能力（更像团队、更像项目）。

---

7.1 技术与工具：我们不是“学到了”，而是“用到了”

如果只看技术清单，它可能很长；但对我们更有意义的是——这些东西不是背出来的，是在一次次“卡住—解决—复盘”里被迫掌握的。

• 协作与版本管理（Git / GitHub）
  以前写个人项目，冲突最多是“自己改错了”；这学期写团队项目，冲突是“十二个人在同一个版本上发声”。分支、合并、冲突解决、提交规范这些看似基础的东西，一旦和真实冲刺结合，就会变成版本稳定性的第一道门槛。我们后来越来越依赖它来保证：每一次改动可追溯、出现问题能回滚、重要功能不会被无意覆盖。
• 接口与口径（Swagger / OpenAPI、字段与错误码约定）
  这学期我们最深的教训之一就是：
  联调翻车往往不是不会写，而是“写的不一样”。
  任务状态、分页参数、错误码含义、字段命名——任何一个口径不一致，都能在冲刺阶段把人拖进返工泥潭。我们后来用接口文档把“约定”固定下来，效果很直接：讨论更少靠猜，问题更容易定位，验收路径也更清晰。
• 后端开发与“通用能力”意识（工程骨架、异常处理、鉴权、日志）
  在开发层面，我们越来越意识到：写接口只是表层，真正让系统能撑住迭代的是通用能力。
  比如统一返回格式、异常收敛、鉴权流程、日志与排障信息，这些东西写的时候不显眼，但一旦 Alpha/Beta 进入密集修复期，它们会决定“问题能不能快速定位”。
  而且帖子模块这种带治理链路的功能，本身就更需要这些基础设施：举报记录要留痕、审核要可追踪、处置要可回显，缺一块都会让系统“看起来能用，但经不起验收”。
• 内容治理链路的实现（评论/点赞/举报/审核）
  我们以前做作业，常常只写“正向流程”；这次做平台，第一次把“灰色流程”也做进系统里：
  评论可能被滥用、帖子可能需要下架、举报需要处理、审核需要记录。
  这让我们明白：真正的产品不是“功能实现”，而是“秩序实现”。
  一个能发帖的平台并不难，难的是让它在真实使用时不失控。
• 部署与交付（服务器、环境差异、线上验证）
  直到版本真正上线，我们才明白“在我电脑上能跑”不算完成。环境变量、端口、证书、跨域、数据库连接……每一个小坑都能让系统在验收前夜掉链子。
  但也正是这些坑，让我们第一次体会到交付的质感：把代码从仓库搬到线上，让别人也能打开、也能跑通，这才算把项目交出去。

---

7.2 技术之外：我们学会了怎么一起做事

比起技术本身，这学期更改变我们的是一些“不写进代码里”的能力——它们不会在 README 里发光，但会在项目最紧张的时候决定团队能不能走到最后。

• 对齐能力：把“分歧”提前到文档与设计阶段解决
  我们后来越来越相信：与其在联调时吵，不如在原型和概要设计时吵。
  把争论前置，就能把返工后置的概率压下来。需求写清楚、状态定清楚、验收路径列清楚，团队才能稳定推进。
• 取舍能力：敢砍功能，也敢守住主流程
  Alpha 阶段我们很真实地经历过“功能想要太多”的诱惑；Beta 阶段也经历过“临时再改一下”的冲动。
  但最终我们学会的，是在冲刺里用一个很简单的标准做决定：
  影响主流程稳定性的先修，影响验收复现性的先改，锦上添花的先放。
• 抗压能力：把“慌”变成“可处理的清单”
  最难的时候不是 bug 多，而是 bug 多到让人失去判断力。
  我们后来能稳住，靠的不是情绪更强大，而是方法更具体：复现→定位→分工→回归→记录。
  一旦流程跑起来，压力就会从“压在身上”变成“摆在桌面上”。
• 责任意识：版本属于团队，不属于某个人
  最让人感动的一点，是到了后期真的没人说“这不是我负责的”。
  有人帮忙测主流程，有人补文案，有人改一个小 bug，有人陪着跑回归。版本能交付，不是因为某个人很强，而是因为每个人都愿意把它推到最后。

我们还想留下些什么：遗憾、趣事、以及给后来者的一句话

写到这里，项目的“交付”其实已经完成了，但一学期真正留下来的东西，往往不只在仓库里。它更像一些零散的片段：某次讨论突然达成一致的瞬间、某个深夜把主流程跑通后的沉默、还有答辩前大家把演示一遍遍排练时的疲惫与笃定。

8.1 最有趣的片段：当系统第一次“像真的一样”

我们最开心的一次，不是某个页面做得多好看，而是系统第一次出现那种“真实感”：
有人在小程序里发布任务，有人顺路接单，状态一步步往前走；帖子里有人点赞、有人评论，出现不合适内容时还能被举报，后台能看到记录并完成审核处置，前台展示也会同步变化。
那一刻我们突然意识到：我们做的不是“作业拼图”，而是一个可以被运行的秩序——它有热闹，也有规则；有发生，也有收束。

建议配图：一次任务闭环完成的截图（发布→接单→完成），以及一次举报在后台被处理的截图（举报列表/审核操作/处置结果）。

8.2 最遗憾的一件事：我们仍然想做得更“稳一点”

如果说遗憾，最大的遗憾其实很朴素：我们没能在时间允许的情况下，把测试体系做得更完整。
很多回归仍依赖人工跑流程；一些边界情况（异常网络、重复点击、并发提交）是靠经验和临时补丁挡住的。版本能稳定交付，但我们也知道它离“工业级稳定”还有距离。

不过这种遗憾也很公平：它不是失败，而是一种清醒——让我们知道下一次做项目，应该更早地把质量门槛和自动化回归提上日程，而不是把它留到最后一周才想起来。

8.3 这门课对我们的影响：我们开始把“团队”当成一个系统

这学期最深的改变，是我们开始把“团队协作”也当成一个需要设计的系统：

• 需要明确的输入输出（需求与验收）
• 需要稳定的规则（接口口径、状态含义、文档同步）
• 需要可回溯的过程（版本记录、分工与复盘）

以前我们总觉得“写代码”是核心，这学期才真正看到：工程真正消耗的，是沟通成本与返工成本；真正提升效率的，是把不确定性提前收束。

8.4 给未来学弟学妹的一句话

如果要留一句话，我们想留这句：

别急着把功能做多，先把共识做稳；别怕删减需求，怕的是交付不了一个稳定版本。
你们会发现，软件工程里最值得骄傲的，不是“我做了多少”，而是“我们一起把一个版本敲到了最后”。

9. 致谢：把这一学期的声音，交还给每一个人

如果要感谢，这一段其实很难写。因为“以太校园”从来不是某个人的作品，它更像一段被很多人一起撑起来的时间：有人把需求写清楚，有人把页面磨顺，有人把接口补齐，有人把服务器扛住，也有人在最后几天一遍遍跑回归、把演示排到不出差错。

我想先感谢我们的 12 位队员：

谢谢你们愿意在忙乱里保持回应：群里一句“我来查”，PR 下一个“我改了”，深夜一句“我再跑一遍”，让这个版本没有散掉。很多时候不是我们没遇到难题，而是难题出现时，总有人愿意把它接住。

也想感谢 老师与助教。你们的要求有时很“硬”，但正是这些硬要求，让我们一次次把“差不多”推回到“可验收”：链接要能打开、流程要能跑通、文档要能复现、系统要能交付。我们后来才明白，这不是挑剔，而是在教我们真正的工程标准。

最后想感谢这一学期里那些不起眼的瞬间：会议里反复确认的一张原型图、文档里改了又改的一句口径、答辩前最后一次把主流程跑通时的沉默。它们看起来不浪漫，却很真实——因为它们共同构成了“共振”真正发生的方式：不是谁更响，而是我们终于能把十二个人的声音，汇成同一个版本。

写到这里，就把这一学期收好。
愿我们下次再做项目时，仍然记得这种感觉：同一个目标、同一套口径、同一个版本，一起敲到最后。