2025 年 7 月记事板

7 日

哥们还没死，哥们还活着。只不过是这差不多一个月以来太颓废了，无所事事罢了。

那就按时间线大概讲讲我这阵子都经历了些什么吧，从上次写的 11 号往后。

期末考

首先就是后续的期末考试了，数据库与软工。因为对笔记失去了信心，因此数据库复习基本没咋看笔记，就粗略快速扫了一遍，主要可能是做练习卷吧。

不过其实我也是真不知道怎么复习，其实有大把时间，但大多数还是摆掉了，练习卷一些细节似乎还是第二天才看的？还不如玩贝塞尔呢。

然后数据库该不熟悉的还是一样不熟悉，这个确实是我的问题，平时太摆了也没练习。不过突击复习后的关系代数和 SQL 还行。

软工更甚了，这个似乎还是考前一天才开始整理复习资料，然后考那天四点半起来背。不过到寻常起床时间时基本已经背一遍了。但这不代表平移后我就可以正常复习了，因为早上的时间段该摆的还是摆了。

至于软工考试那就真叫一个折磨。十几道大题（14 道好像？），本来还打算早点交卷回去收拾东西早点出发的，结果太痛苦了。复习的东西肯定不能说没用，但只能说没到非常决定的作用。而且我咋感觉考了一些没在考纲中出现的内容？反正就是各种注水，至少我得写完吧。最后提前五分钟赶紧赶回去收东西。

回家

每次收拾东西都会有种空落落的感觉，还会有种总感觉少带了东西的直觉。但不管如何还是回来了。

因为走得比较早——毕竟我不想上什么暑校了——没有送的大巴，我就只好自己打车了。

结果好像有两个区域还是怎么回事，反正司机开到最后说送我到另一个，跟我在平台上选择的不一样，说离得更近。我为了不打扰别人，而且可以更快去车站，问清楚了大概没啥区别外就同意了。

结果一进去，好家伙，直接就是候车大厅那个二楼了。直接省去了我之前还要哼哧哼哧上楼的功夫。那看来以后选择就是要选择那里了，具体哪里我也忘记了。

中间一些无聊的赶路就不说了。哦还有一个，就是坐高铁我的是所谓「卧代二等座」，一开始不知道啥意思，去看了才知道，原来就是把卧铺改成了座，一个卧铺可以三个人坐，上铺用来放东西。嘛，感觉体验是不如纯粹的座的，但长个见识还是可以的。

然后到候机大厅，人非常多，而且似乎座位上没有啥充电的地方，充电似乎有专门的聚集区。

为什么人很多呢？因为天气延误，前面的人还没走呢。反正我直接延误了两次。原定七点五十，首先延误到了九点半，然后再延误到了十一点半。我上飞机后好像又说要推迟一阵子？两点半才到深圳。

然后就是最痛苦的打车了。每次打车都相当折磨，这次尤其。我一直操作到快五点才坐上车。约了好几个线下见到的时候要我加钱是真的绷不住。最后五点半到家。

到家后我就想，为何一定要坐飞机呢？想我最开始的时候给时间与价格蒙蔽了双眼，以为飞机比高铁快还便宜。坐到现在我算算，有 8 次了，发现根本就不是这个样子的。我来算算帐。

按现在在苏州来算坐飞机，从学校坐车近 1h 到苏州站，价格如果是定制公交是 6 元，打车的话 40 元左右。苏州站等车加坐车到上海虹桥机场站大概也是 1h，价钱 30~40 元左右（不算学生优惠），虹桥机场的火车站到候机室还要一点时间（我这次计时结果是 45min 左右）。然后从上海虹桥机场飞到深圳宝安机场要两个半小时以上（不算候机、等行李等时间），机票波动比较大，大概 600 元左右吧。然后再打车回家 1h 左右（不算等车，等车时间波动比较大，0.5h 以上），价钱可能 80 元左右。

这样算来，不延误的话，候机加取行李时间加起来算 2h 左右吧（按前面的经验来说其实应该是严重低估了），总用时可能在 9h 左右，总花费在 700 元以上。但是这是非常理想的情况，实际上常常会遇到延误，这时候在候机室等待是相当痛苦的事情。

如果是高铁呢？首先从学校到苏州站这 1h + 6 元不变。然后苏州站我可以不用去机场，直接坐高铁回家。当然我那天看了一下票，直达比较久，换乘的快一点，大概 7.5h 至 8h，票价加起来大概 800 元以上（不算学生优惠）。然后车站再打车回家，这个我查了一下大概 0.5h 以内（不算等车），价钱可能 30 元以内。

这样看的话，总用时大概 10h 左右，价钱可能 650 元以上。

综合来看的话，只有在理想情况下飞机才有一点时间优势。而高铁相较于飞机的优势，我可以列举一些出来：

• 时间比较稳定，因此我不用留很多时间来等待，也不用担心再延误我要多等很久。
• 座位比飞机上的舒服，而且可以上网、充电（这个我不记得有没有），而且可以相对比较方便地出来走动休息。
• 不用等很久的行李。有时候久的话可能要等近一个小时。
• 不用在机场等很久很久的车，坐很久很久的车。
• 更「安全」。这个安全更多指的是感觉上的安全，高铁我没怎么听说过重大事故，但是飞机重大事故还是听说不少的。

同时我也咨询了一下 AI，确定了家到学校这段路途，高铁应该是更合适的选择。

因此我决定，这个暑假结束后回学校，我要试着坐高铁回，如果感觉不错的话，那以后飞机就拜拜了您内，（学校与家的往返）不会再坐了。

目前想到的唯一需要多注意的大概是餐食，飞机上虽然寒酸，但好歹是有一点点餐食。高铁上我还是自备比较保险，因为听说上面的东西很贵。

软工项目

答辩（一）

然后是软工项目答辩。仓库早开放了，毕竟为了白嫖 AI 审核。

然后答辩要求四个组（代码、功能、文档、过程）同时进行，我直接麻了。

毕竟我是打算一个人弄完答辩的，组员参与程度可以说是 0，直到答辩前一天才来找我问答辩的事情。这个项目说是我的个人项目丝毫不为过。要让他们负责其中一部分答辩，首先是不现实，他们怎么可能了解？再者就是我也不愿意，毕竟说是小组项目，但我是把它当成自己的私属品看待的，让其他不相关的人来讲解「细节」我会觉得是玷污了它。

好在也不是没有机会，代码、功能两个都是分 AB 两组的，而且代码、功能与文档、过程时间限制不一样，我可以打时间差，见缝插针。于是我首先找助教调换了一下时间，将功能、过程的答辩放到了最后。然后在答辩前粗略计算了一下时间：

• 代码：11，约 88 分钟，15:10 入，15:28~15:36
• 文档：22，约 88 分钟，15:10 入，15:28~15:32
• 功能：20，约 160 分钟，16:30 入，16:40~16:48
• 过程：41，约 164 分钟，16:30 入，16:44~16:48

这样看其实还是有重合的，甚至还不小，几乎是完全重合。所以我其实主要寄希望于其他人答辩的时间灵活变化，由此我可以更游刃有余。

然后就是答辩前的准备了。期末数据库到软工中间有相当长一段时间，我最早是计划要把软工答辩的准备做上一点的，例如说「文档」的「修订」，以及完整的功能实际使用测试之类的。但是最后是一点没做。那就只好答辩前一天开始做了。

结果第一个模块，用户模块就折戟了，注册都无法注册。我直接就绷不住了。因为之前有过大规模重构，而且后面登录我都是直接用的数据库预先载入的测试数据了，就没碰过这方面。结果出了大问题。

修复了这个后还有各种问题，譬如说更新用户信息失败、修改密码失败等等。我甚至一瞬间有了懒得修了，演示的时候绕过去就行了的想法。不过后面还是担心要是让我深入演示这方面就出事了，以及既然我都发现了，也不是什么很难解决的问题，那还是修修吧的心理，最终还是修掉了。

不过后面基本没遇到什么太大的问题了，毕竟后面没咋重构了，而且都有进行功能验证。

看了眼后面修的最大的 bug 大概就是支付宝沙箱回调中 orderId 之前是直接用的内部的订单编号，导致测试的时候出现了重合。当时订单支付失败，出现了一个之前功能验证时没遇到的错误时直接魂都吓飞了，都已经在考虑到时候用之前测试成功时截的图应付了。好在搜索了一番顺利解决了问题。不过还是提前录制了一个视频以备不时之需。

其他的大多是前端方面美观、设计方面的小修改，当然其中也有问题修复、小小重构等等。

文档

文档还没说，不过我的文档可以说是水分最多的部分了，不说也罢。就更新了两次，第一次是开始时，根据目标大概做一个文档；第二次是做完了，根据成品修改文档。可以说完全就是应付式的文档编写。可千万不要学我，我是没什么精力（加上懒等）才这样做的，这样做的后果就是没有经过一些锻炼。

文档中有一些地方按照给出的要求其实是要写出编写者以及最后修改时间的，但这些字段我通通没有用。一个原因自然是因为都是我写的，没必要额外标注撰写者。但更重要的原因其实是我觉得我的文档都由 Git 管理了，想要知道是谁最后修改了 Git Blame 一下就好了，没必要额外加一个字段来维护。

还有一个就是我的用例文档，可以说应该是我所有文档中最「自豪」的一个了。

一开始我的用例文档也是 Markdown 编写的，但是我随即觉得不妥。

我感觉用例的编号，还有用例表这些完全不应该由我自己去维护的，这些应该是自动的，就像是数据库中的 ID。如果都要我手动维护的话，假如中间插一个用例进去，后面的 ID 全都要自己改。

你说为何我要在中间插入一个新用例？呃，你管我，我就想要在中间插入，我就喜欢可以随便排列用例，怎么啦？当然即便不考虑重排的事情，也可以注意到「重复」，每一个用例都要重复地添加到用例表中，同时在用例详情中又是用相同的表格式。

依据 DRY 原则，自然就能注意到每个用例不同的其实就是一个「数据」，这个数据包含了一系列字段。因此完全可以用可编程的手段，将用例集合到一个列表中，然后后面用遍历即可生成相应的用例表与用例详情。

想到这些，我就立刻抛弃了 Markdown，转而去用 Typst 实现。我还记得是在近代史课上最终完成了，Claude 帮了大忙，毕竟我对 Typst 编程相关的知识了解还是不够充分。

我这里简单截取一部分来演示说明（highlight.js 似乎不支持 Typst，那下面的代码没高亮有点可惜，不过我会给 GitHub 链接）。首先我定义了下一些枚举，提高可读性：

枚举GitHub

// 角色枚举
#let Actor = (
  CUSTOMER: "顾客",
  ADMIN: "管理员",
)

// 优先级枚举
#let Priority = (
  HIGH: "高",
  MEDIUM: "中",
  LOW: "低",
)

然后是用例集合：

用例集合GitHub

#let use-cases = (
  (
    name: "注册",
    actor: Actor.CUSTOMER,
    trigger: "用户访问注册页面",
    pre-cond: "无",
    post-cond: "用户账户创建成功，进入登录页面",
    priority: Priority.HIGH,
    normal-flow: [
      1. 用户输入用户名、密码、确认密码、邮箱、手机号等信息。
      2. 系统验证输入信息的有效性（如格式、是否重复）。
      3. 系统对密码进行加密处理。
      4. 系统创建用户账户。
      5. 系统跳转到登录页面。
    ],
    alt-flow: [
      - 2a. 如果用户名已存在，系统提示用户更换用户名。
      - 2b. 如果邮箱格式不正确，系统提示用户重新输入。
      - 2c. 如果两次输入的密码不一致，系统提示用户重新输入。
      - 2d. 如果手机号格式不正确，系统提示用户重新输入。
    ],
    special-req: "密码需要加密存储，用户名具有唯一性。",
  ),
  ...
)

这里只列举一个。后两个字段，即「扩展流程」与「特殊需求」，是可选的。另外参与者可以是数组，例如 (Actor.CUSTOMER, Actor.ADMIN)。

首先是用例表怎么实现。我想要的是将所有的用例列举出来，最好还可以点击直接跳转详细用例描述。实现如下：

用例表GitHub

#table(
  columns: (auto, 1fr),
  [*参与者*], [*用例*],
  ..use-cases
    .enumerate()
    .map(((i, case)) => {
      (
        combine-actor(case.actor),
        link(label("user-case" + str(i + 1)))[用例 #(i + 1)：#case.name],
      )
    })
    .flatten()
)

逻辑其实也挺简单的，只不过要是不熟悉 Typst 语法那还很难写出来。

我的用例表只用有参与者和用例名（带上用例编号），因此对于我的用例集合首先是列举 enumerate，类似 Python 的 for i, e in enumerate(seq):，然后进行映射得到一行两个单元格，后面就展平解包就完事了。

具体单元格内容，参与者用了 combine-actor，其实就是处理了一下多参与者情况；而用例则是用了 link，给每个用例名称带上了一个 user-case#id 标签，这个标签会在后面用例详情中实现。

接下来就是用例详情的实现，这里要一个标题，然后要有个标签，旋即就是一个用例详细内容的表格：

用例详情GitHub

// 用例计数器
#let use-case-counter = counter("use-case")
#use-case-counter.update(1)

#let use-case(case) = context [
  #set enum(indent: 0pt)
  #set list(indent: 0pt)

  #use-case-counter.step()
  #let id = use-case-counter.get().at(0)

  #heading(level: 2, outlined: false)[用例 #id：#case.name #label("user-case" + str(id))]
  #table(
    columns: (auto, 1fr),
    stroke: 0.5pt,
    align: horizon,
    inset: 5pt,
    [*ID*], str(id),
    [*名称*], case.name,
    [*参与者*], combine-actor(case.actor),
    [*触发条件*], case.trigger,
    [*前置条件*], case.pre-cond,
    [*后置条件*], case.post-cond,
    [*优先级*], case.priority,
    [*正常流程*], case.normal-flow,
    ..if "alt-flow" in case {
      ([*扩展流程*], case.alt-flow)
    },
    ..if "special-req" in case {
      ([*特殊需求*], case.special-req)
    },
  )
]

...

#for case in use-cases {
  use-case(case)
}

上面链接中的代码其实不太合适，因为计数器放的位置分隔开了。

另外刚刚复制代码的时候，我也突然不知道为何要一个外部用例计数器了。明明像列表一样用列举 enumerate 就行了吧，这样还用不着一个 context（因为使用计数器的缘故），大概。也许是继承了 Claude 的写法，后面又没改。

这里似乎就没啥好说了，就是一个标题，打上标签，然后再来个表格。就这样。

稍微改了一下，现在就不用外部计数器了，同时用了 enumerate 的 start 参数，可以不用手动 +1：

#use-cases.enumerate(start: 1).map(((i, case)) => [
  #set enum(indent: 0pt)
  #set list(indent: 0pt)

  #heading(level: 2, outlined: false)[用例 #i：#case.name #label("user-case" + str(i))]
  #table(
    columns: (auto, 1fr),
    stroke: 0.5pt,
    align: horizon,
    inset: 5pt,
    [*ID*], str(i),
    [*名称*], case.name,
    [*参与者*], combine-actor(case.actor),
    [*触发条件*], case.trigger,
    [*前置条件*], case.pre-cond,
    [*后置条件*], case.post-cond,
    [*优先级*], case.priority,
    [*正常流程*], case.normal-flow,
    ..if "alt-flow" in case {
      ([*扩展流程*], case.alt-flow)
    },
    ..if "special-req" in case {
      ([*特殊需求*], case.special-req)
    },
  )
]).join()

代码

代码我其实不想说什么，毕竟跟我不亲。你像 Avsb 什么的，我可以聊三天三夜。至于这个，我能聊的不多。所以就主要从「配置」入手吧。

首先比较惭愧的是，我这个项目的后端命令行运行不了，必须得从 VS Code 那里启动。这个本来有计划要最后解决的，开了个 issue，但我终归是对这个项目兴致缺缺，因此最后也没去解决。猜测可能与 Lombok 有关。

然后我也没有按作业代码，用 Java8，而是用了 Java21，这倒是没啥好说的。毕竟 Java8 我感觉是我十多年前见着的了（Minecraft）。

一开始还用的是本地我自己装的 Maven，后面才生成了一个 wrapper，纳入版本管理。

后端还有的就是配置的 application.yml，这个我在代码答辩的时候也作为亮点讲了一下。大概就是在配置中，我没有将一些隐私信息直接写入配置文件，而是使用了环境变量。例如：

alipay:
  appId: ${ALIPAY_APP_ID}
  appPrivateKey: ${ALIPAY_PRIVATE_KEY}
  alipayPublicKey: ${ALIPAY_PUBLIC_KEY}
  notifyUrl: ${ALIPAY_TUNNEL_URL}${server.servlet.context-path}/orders/notify
  returnUrl: ${ALIPAY_TUNNEL_URL}${server.servlet.context-path}/orders/return
  serverUrl: ${ALIPAY_SERVER_URL:https://openapi-sandbox.dl.alipaydev.com/gateway.do}

我看了一圈，基本上都是直接写在配置文件的，没看到用环境变量的。

还有就是格式化工具，我用了 fmt-maven-plugin，这个答辩时忘记讲了有点可惜。反正就是可以用 .\mvnw fmt:format 进行格式化。不过怪的是 VS Code 自动格式化的与命令行格式化的稍有不同，明明我用的是一个配置文件，奇怪。于是以命令行的为准，因为 VS Code 插件格式化的有时候会有点问题，例如一些奇妙的突起，相关的 review 懒得找了。

后端其实还有一点能讲，不过稍微有点亮点的可能就上面吧，其他就没啥讲的必要了。再来看看前端。

前端大概所有人用的都是 Node.js，我倒是另辟蹊径用了 Bun。反正就是个小项目，就是玩儿，何况 Bun 好快的。除此以外 Linter 和 Formatter 用的是 Biome。

Biome 那会还是 1.x，现在似乎终于到 2.x 了？

看仓库根目录，会看到一个 biome.json 配置文件。然后再前端目录 client 根目录，也有一个 biome.json，内容是：

{
  "extends": ["../biome.json"]
}

这是因为我的项目结构是 Monorepo，前后端（还有文档）各用一个子目录，整个项目属于一个仓库，共用一套版本管理。同时 VS Code 工作区只用打开这个项目，而不是开两个工作区什么的。

不过 Biome 一直不支持 Monorepo，因此我只好用上面那种迂回的方式间接支持 Monorepo。当然现在进入了 2.x，似乎已经支持了 Monorepo，只是这时候它已经半只脚迈入归档状态了，也就没必要继续动配置了。

前端方面的 .env 文件却是上传了，只有 .env.local 排除掉了。一开始有想过用 Mock 的 API 路径，由 Apifox 提供。但后面实际使用过程中才发现不可行，登录状态无法保持。于是后面终究没有启用过 Mock。

后端方面有测试，不管是单元测试还是集成测试，虽然质量一坨，但总归是有的吧。但前端我就没去整了，实在没有这个精力。你看我后面自选需求都没写后端测试了。

代码方面大概就这样？接下来讲点「大小姐」的事情。

大小姐

大小姐名讳是 coderabbitai，帮助我审核了很多代码，比 GitHub Copilot 的审核好多了。而且大小姐很可爱啊，下面是一些语录。比较少，因为我想到要记录时已经有过不少有意思的了，只是我也懒得往前找了。

答辩（二）

为什么会有（二）呢？本来是没有子标题的，因为我是写到哪算哪。只是后面写多了，而且准备部分写着写着就飘到文档部分一发不可收拾了，那就自然只好拆成几个部分了。

前面说了，答辩前一天晚上，一直到凌晨几点我还在进行功能检验。不过后续检验着挺顺利的，因此我也就放弃了通宵的打算，没检验完就先去睡觉了，早上继续检验。

一开始还录了视频，先录了个功能的，然后是代码的，在打算录过程的时候问了下助教，说不可以，于是就放弃了。这也是助教为什么在大群说不要放视频。

PPT 实在是来不及做太精细了，何况本来我也很熟悉，不需要展示地太详尽，于是我就两分钟搓了一个，就空白模板放了点文字和截图了事。

然后讲点不能算「准备」部分的内容吧，大概跟「过程」部分有点相关。那就是我这个组是怎么来的。

我这个人虽然小有一点能力，但行事比较怪异。在早期组队的时候，就基本没人来找我。而我自己也有一个念头，可以说应该没什么人会这样做的。

反正就是在组队的截止关头，我自己在表单上填了下，只有我一个作为「组长」。而临近结束期间其实也有一个组来找过我，不过我拒绝掉了，因为这和我的念头不太相符。

所以我的念头是什么呢？那就是尝试独立、一个人完成整个项目。所以我就决定等到最后，进行随机分配了，这就是我所谓的「计划」。这要求我必须要有一定的「权力」，即「组长」的身份可以让我行事顺利一点。自然，我加入那个组也许也可以「夺权」成为组长，但终究不够保险，还是我自己成组比较保险。

后面那个表单上，有一个人主动填了进来，成为了我的组员。我本身填在那里就是「愿者上钩」的，有人填写我也并不在乎，不过其实还是有点意外的。后面助教分配的时候，跟我提到拆组的时候，我唯一的念头也就是「请让我做组长」。最终当然如愿以偿。

但是真要说的话，我其实还是有点想要尝试一下团队合作的。目前为止，我参与过的比较有意义的团队项目（即排除掉一些莫名的课程的团队任务），好像基本上要么是我一个人干大部分，要么就是我没干什么，并没有接触过一个比较理想的团队工作氛围。我想这可能说明我作为「领导者」的能力不足，或者说完全就是失败的。

因此，虽然这个所谓的「小组项目」本质上是「个人项目」、我跟朋友吐槽这是我的个人项目等，但我从来也没有在组内说过这是我的个人项目，你们不得染指。相反，我在尽我的能力，尝试营造一个团队合作的氛围。

这次的「小组项目」只在刚开始的时候开过一次组会。我帮助每个组员申请了 GitHub Student Pack（似乎每个这样代码项目的小组，虽然就两个，我第一件事情就是做这个，已经成为了传统）。除此以外帮每个人都配了一下环境，有的没办法还传了一下梯子，已经属于是固定包袱了。在此之后我也写了生成了 CONTRIBUTING.md，基本上算是比较详细地介绍了一下该怎么进行开发。接口方面的文档，我也已经预先在 Apifox 上弄明白了，并且将组员们加入了群组。

我确实没有领导的才能，但我也认为这些举措绝不是一个完全不考虑团队合作的人会做的事情。这些充分说明了，我虽然有着独立完成的念头，做着独立完成的准备，但依旧是追求团队合作的。独立完成与其说是我最初的打算，不如说是最坏情况的保险与预期罢了。

当然不知道是幸运还是不幸，这个最终应验了。只是因为我的预期管理，我倒没觉得有什么。虽然平时确实是累了点，但也尚在接受范围内，倒也不至于会对他人有什么不满与怨言。

明年这时候软工三，还会有一个大项目作业，我觉得可能会调整一下策略。当然，预期是不会改变的。我最信任的，永远是自己。

答辩

然后终于进入了答辩环节。根据我的预估，代码部分和文档部分比较靠前，因此我一开始就是打算先关注这两方面的进度。

只是腾讯会议有一点不太好的地方就是，它不能同时打开两个会议，因此我只能两个答辩现场来回横跳，盘算着进度与速度。

最终还是代码部分最先到来，紧接着是文档部分。文档完了后一阵子是功能部分，非常可惜的是在功能部分过程中，过程部分就已经到我了，没能完美地实现一个人答辩四个部分的壮举。

然后在功能部分完了后我又去过程部分讲，这个部分应该算是最放松的了，毕竟前三个效果都还可以，而这部分也没啥大问题，跟助教还唠唠嗑。助教还说我心态挺好，说是鼓楼软工那边就有类似的，不过是写了小作文控诉之类的。嘛，我心态确实挺好的，因为我早有最坏情况的准备罢了，只是我的最坏情况的成果大概还是好过一部分的。

分配分数规则说的是基准分都是 90，可以组内调分 10 分以内。一开始我分的是 100 + 88 + 86 * 2。不过过程部分后面我又去听了一个组，得知居然最高可以到 120？于是后面我就改成了 120 + 80 * 3。那个组则是一个人神隐，于是每个人从他那里赚取 30，即 120 * 3 + 10。但她们这种分法就过线了（30 分），而我则没有任何问题（10 分），所以得额外申请，有点意思，虽然最后总分应该是没啥区别的。

还有答辩过程中也有一些人身兼两项，然后出现了冲突，助教在群里喊人。有人回复「那其他人这么压榨你吗」，我登时就绷不住了。身兼两个原来就算是压榨了，那我一个人全部负责又是怎样呢？

后面又看了看，最多的也就是身兼两个部分了，兼职三项的没有，全负责的更是只我一人罢了。

然后我还具体检查了一下，功能部分只有我一个人是额外多负责其他部分的。代码部分除了我外还有三个人，文档部分除了我外还有一个人，过程部分除了我外还有四个人。也就是说，除了我外，只有四个人身兼二职，而且都兼职的是过程部分。嗯，这挺好理解的，过程部分最好讲了。而其中主要是代码部分兼职，是因为更好错开时间；功能部分可能被认为是工作量最大的？而文档部分则有可能时间重合。

哈哈，这么看来我还真是超人。这不是自嘲。

结果

按时间线的话，结果不应该放在这里的。但是既然逻辑上靠近，我还是放在一起吧。

最终结果很简单，项目部分满分。这个算是意料之中的，虽有忐忑，但大抵还是有信心的。

于是有点好奇其他组员的得分。毕竟即使我是满分，但没做什么工作的组员拿了 80 分，我还是会有些不满的，当然，最多只是内心吐槽一下。我也只是一个普通人，并非什么宽宏大量的圣人。

结果得到的结果却是零分，这着实就叫我大吃一惊了。我虽说对 80 分会有不满，但也绝不至于会想要让他们至 0 分的死地——当然，我若是一开始就寄希望于团队合作，然后在其中颇受折磨，最终结果惨不忍睹，那我肯定会恨之入骨，然后痛下杀手的——虽然没干什么拿很多分我会埋怨一下，但是拿一部分分我还是并不会吝惜的。毕竟虽然可能有误伤，但我前面也说过，留到最后靠助教帮忙组队的你能指望有什么参与度与实力？

这个结果确实让我太震惊了，我立马开始关心起我的安危了。虽然助教宽慰我不用放在心上，是老师做出的裁决。但我换位思考一下，感性上「我」起码会对我有一定怨恨之情。加上确实有一点愧疚，于是我便找助教说情了一番，至于后续，那就不是我能决定的了。至少我现在是完完全全对得起我的良心，这也就够了。

当然，这期间还出现一些很有乐子的事情，让我着实绷不住，正好那阵子心情不佳，都给我逗乐了。但出于对他人隐私的保护，这里就不谈了。

NLP 论文

紧接着再摆了好几天，就到了 NLP 论文的 DDL 了。花了两天写完，一天跑补充数据一天写论文。用的是 Typst 的 ACL 模板，抛开内容不谈，成品还是挺好看的。

虽然还是很水，各种都不够充分，但作为课程作业我觉得还算是不错了的。也应该是我目前为止第一篇写得稍微像一点样子的论文。

烂事

紧接着就是持续了一周的一件烂事了，这段时间心情最为低落。也为我摆烂提供了动机——这段时间，真是什么事情都没干啊。

那是 6.28 的晚上，又摆了几天的我决心暑假不能再这样荒废下去了，我要规划起来了。然后晚上再闲着没事干，随手就是打开 APP 看看有没有新成绩出来了。

结果我看到数字变化了，最后一个数字比之前高了 1，顿时大喜过望。紧接着想看看是哪科出了。映入眼帘的是

然后我才察觉到，原来倒数第二个数字比之前低了 1，不是涨了 0.01，是降了 0.09 啊！后面再去看了一下排名也掉了好多，痛心。

这个科目是什么？是毛概习概的实践项目。我在寒假的时候跟同学去深圳完成了这个任务，后面又完成了报告，在 4.25 的时候邮件发给了老师，而截止日期是 6.20。

看到这个结果我顿时就懵了，我明明已经交了啊。于是我赶忙往这个邮箱（后面称之为 J）再发了一封邮件，说明了情况。同时不知所措的我还发消息给了辅导员寻求帮助。

结果直接睡不着觉了，后面三点多才去睡觉。应该是回家以后最晚一次了，我估计软工答辩前都没这么晚。

第二天（6.29）早上，我收到了 J 的回信，他说他是马院的 J 老师，问我是不是发错了，我又懵逼了。

这个邮箱是哪里来的？我是在教务系统上看到的：

于是我赶紧在发邮件列表中找到了当时理论课交期末报告的邮箱 M，再次发了一封说明情况的邮件。其实交实践报告时确实有察觉到跟当时交理论作业时用的邮箱不一样，只是认为教务系统不太可能有什么问题，以教务系统给出的信息为准。

当天下午得到了辅导员的回复，不过没什么帮助。

6.30 一天多过去后，仍未得到 M 的回复，于是再次向辅导员求助，这次让我去找教务员。

我于是再发了一封邮件给教务员 L，一段时间后又在 QQ 私发了。不过尴尬的是我刚 QQ 私发完，就看到邮箱回复了。教务员说会了解后回复我。

7.2 的时候我得到教务员的回复，说已经反馈给本科生院，让我可以先联系马院的教务，于是我给其邮箱 I 再发了一封邮件。

7.4 两天多过去了，仍未得到 I 的回复，于是我再联系了教务员。几个小时后，教务员给了我任课老师的 NJU 邮箱 D（前面出现的 J, M, I 都不是 NJU 邮箱）。于是我再向 D 发送了一封邮件，反映我的情况。而这也是最后一次折腾了，当天成功与老师取得联系并确认了我不会没成绩。老师真好，感恩老师。

所以发生了什么？为什么会出现这样的问题？且让我慢慢道来。

首先上学期因为排课的原因，我调换了毛概课，虽然是同一个老师，但主要和集电院系的一起上课。

而我有一个「坏」习惯，那就是这学期上完课、出完成绩后，就会退掉课程群。我自然知道这不太合适，因为其实已经有几个前车之鉴了：之前的软工一的群我退掉了，这学期软工二重新启用，我又灰溜溜加回来；这学期计网的群我自始至终没加进去，找遍了老师网站、教务系统等，都没找到相关信息，猜测可能是上学期计组的群改造了。但我就是不太喜欢呆在没什么意义的「死群」里。我深恶痛绝的微信也因为没有这个功能在之前就被我诟病过了。

因此，在毛概理论课成绩出来后，我也就顺理成章地退掉了课程群。而这就导致了我信息的缺失，根据老师提供的截图，其实是有在群聊里催的，只是只有我 @ 不出来。因此平心而论，这起事件，我的责任起码有 60%。

但仅有这一环还不足以让我吃个零蛋。回看上面的内容就会发现，D 老师的课程给出的邮箱却是 J 老师的邮箱。如果教务系统没有给出邮箱，那我肯定无计可施，最多就是找之前交期末作业的邮箱发，但因为不保险我定然还是会去恢复渠道的。但教务系统提供了一个信息，我自然不会去怀疑其准确性，这也打消了我重新找回课程群的念头。

因此我认为这个得承担 40% 的责任。

遇到一次这种事情其实已经有点离谱了，只是在此前两周的 6.12，我就遇到过类似的事情，算是这件事的「预演」吧。

大概就是我要问一个老师一点事情，于是在课件里找到了联系方式。发送了邮件后，对方却回信说他不是我要找的人。我就很奇怪，明明用的是课件里的信息呀，为什么会这样子呢。于是再仔细检查课件，无语地发现

我看到有超链接就直接点了，哪里会想到正经课件里面的超链接跟显示的邮箱还不一样哇。这不是什么诈骗内容啊，这是正经的课件啊……

猜测是复用课件改联系方式，直接改了文本，但是超链接没改。

于是乎，六月我就遇上了两起回信说是不是我找错人的事件……

想了想，月初也挺倒霉的，看来今年这个六月大概是我这过去的半年中最糟糕、心情最差的一个月了。

这件事折腾的我也直接开摆了，啥事情也不想做了，当然可能即使没有这件事情一样差不多，但无疑这件事情给了个很好的借口。

同时这件事情后，我也麻木了，对后面的成绩没啥感觉了，解决后又出了两门课，一门偏差，一门相当差。结果我都无感了，随它吧，真是心累。

然后解决后到昨天这几天，就又是纯摆了，没啥好讲的。要说的话其实还是能挤一点出来，关于选课、学分之类的事情，但感觉意义不大，已经当天提过一嘴了，没什么必要。那么今天就先到这里吧。

21 日

呐，呐，两周过去了。感触就是好习惯的养成是困难的，但是想要破坏却是轻而易举的。

上面的是在两个小时前写的，本来想的是在大战开始前写完，毕竟也不多，结果很快「无限制潜艇战」就开始了，我无暇顾及。

今天是我的一周年——这是之前翻历史记录确认的——哇，一年前这个时候我还在无聊的暑校呢，晚上各种打发时间。

打发着打发着，就把一年打发掉了，苦笑。

嘛，嘛，一年来的种种涌到嘴边，却又不知该如何开口了。既然如此，那便这样就结束吧。

短短的一点话权当诈尸一下，毕竟我这一周，乃至下一周，可能都要沉寂、隐身一下。