[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	2026年春季软件工程 - 北京航空航天大学
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	在团队协作中经历软件开发的全部流程，积累软件工程经验
这个作业在哪个具体方面帮助我实现目标	回顾一学期的项目实践，总结自己对软件工程知识点的理解变化

个人作业：结课总结

一、对开学阅读提问的回顾

开学时的提问博客链接：I.1 个人作业：阅读与提问

当时我围绕《构建之法》提出了五个问题。一个学期之后，再回看这些问题，我的感受是：很多问题本身没有完全“被推翻”，但是我对它们的理解从比较理想化、工具化，变成了更偏工程权衡。

1. 在 vibe coding 时代，“过早优化问题”是否已经不存在了？

我当时的观点比较激进：既然 AI 可以很快写出性能更好的代码，那么过早优化带来的时间成本似乎被大幅压缩，甚至可以忽略。

经过个人项目、结对项目和团队项目之后，我现在的回答是：过早优化的问题仍然存在，只是形式变了。 AI 确实能降低写代码的成本，但并不能消除“优化方向错误”的成本。团队项目“杰后余生”中，我们遇到的主要瓶颈并不是某个函数运行慢，而是功能边界、状态同步、地图规则、前后端协议是否稳定。如果一开始就把局部实现做得很复杂，后面需求变化时反而更难改。

例如多人游戏中的地图、楼层、宝箱、撤离点、Bot、怪物 AI 都会互相影响。早期最重要的是先跑通“组队 - 黑市 - 战场 - 搜刮 - 撤离 - 结算”的闭环，而不是把某个局部逻辑优化到极致。AI 生成代码越快，越容易让人产生“多写一点也没关系”的错觉，但代码量本身也会变成维护成本。我的新认识是：AI 可以加速实现，但不能替代判断“现在最该解决什么问题”。

2. Code Review 前的程序员自测为何不借助单元测试和回归测试？

这个问题我现在仍然认为自己当时的方向是对的：单元测试、回归测试和 Code Review 并不互斥，应该结合使用。

但是我现在能更理解书中强调“程序员必须自己测试过代码”的原因。自动化测试可以覆盖已知路径，却不能完全替代开发者对代码行为的理解。结对项目中，我们为花见小路的规则判定模块设计了多类测试用例，覆盖分值胜利、倾心标记胜利、第三轮总分判定、最高档位判定和平局等情况。这让我确认，规则类模块确实适合用单元测试来避免漏判和错判。

团队项目中，CI/CD 的作用也非常明显。我们使用 GitHub Actions 做构建和部署，后续又通过共享逻辑测试、联机冒烟测试来降低回归风险。我的理解变成了：Code Review 更适合发现设计问题、可维护性问题和隐含假设；自动化测试更适合稳定地守住功能边界。两者关注点不同，应该形成互补。

3. Scrum 的燃尽图、看板是否过于形式主义？

开学时我认为燃尽图和看板可能只是形式主义，不如飞书 ToDo 或任务列表灵活。团队项目之后，我的回答是：它们可以是形式主义，也可以是真实暴露问题的工具，关键在于是否与真实任务流绑定。

Alpha 阶段我们确实使用了 GitHub Issue、飞书、微信和例会来推进任务。燃尽图反映出一个很真实的问题：前期推进较慢，任务容易堆到后期集中完成。这个现象如果只靠口头感觉，很容易被“最后还是做完了”掩盖；但从燃尽图上看，问题就比较清楚。

所以我现在不再认为燃尽图天然无用。它的价值不是“画得好看”，而是帮助团队观察节奏是否稳定。如果团队只是为了交作业而补图，那就是形式主义；如果 Issue 的创建、关闭和验收都和真实任务绑定，它就能暴露管理问题。

4. 过程创新的重要性为何要被放到这么高？

我当时认为 PM 不一定要做“过程创新”，更多是选择合适流程。现在这个观点有一部分保留，但需要修正。

在“杰后余生”项目中，我作为 PM / 前后端集成 / 部署负责人，体会到流程不是照搬 Scrum 就能解决问题。我们的团队成员能力、时间分布、岗位差异都比较明显：有人负责美术，有人负责玩法，有人负责测试，有人参与前后端开发。Alpha 阶段最初设想的分工，在实际推进中并不完全适合，因为多人协作和 AI 辅助开发使得代码产出速度、联调方式、任务转移都发生了变化。

所以我现在认为：PM 不一定要发明一套全新的流程，但需要做“局部过程改造”。例如贡献分规则中，我们强调可提交、可验收、可复现的成果，而不是只看主观印象；Beta 阶段又把地图工坊、怪物 AI、人机角色拆成可验收 Issue。这些不算宏大的流程创新，但确实是根据团队情况调整流程。过程创新的重要性不在于“创新”两个字，而在于流程必须服务当前团队的真实问题。

5. 测试人员是否应该从用户角度测试，而不是严格按照 Spec 测试？

这个问题我现在的答案发生了明显变化。开学时我更倾向于“测试人员严格按照 Spec 测试，用户体验问题应该回到需求阶段修正 Spec”。现在我认为：测试当然要验证 Spec，但如果只按 Spec 测，仍然是不够的。

在个人作业 I.2 中，我分析 MAA 的 Bug 时，就已经接触到这种情况：有些问题并不一定违反某条明确规格，但会在真实用户场景下造成体验损失。团队项目中这一点更明显。比如 Alpha 阶段主流程已经跑通，功能上可以创建房间、进入黑市、开箱、战斗、撤离和结算，但真实用户第一次进入战场时可能不知道下一步该做什么。这个问题不是简单的“功能没实现”，而是“用户能不能理解和使用”。

因此我现在认为，测试人员至少要承担两类职责：第一，按 Spec 验证功能是否正确；第二，站在用户角度发现 Spec 没有覆盖但会影响产品质量的问题。测试人员不应该私自改变验收标准，但应该把这些问题反馈给 PM 和团队，让它们进入需求或 Issue。

二、仍然不完全明白的问题

原来的五个问题中，我觉得仍然没有完全想清楚的是：在 AI 大量参与开发后，如何评价代码贡献和工程能力？

我们在团队贡献分规则中引入了 AIGC 人工处理系数，要求保留工具记录、草稿留档、修改说明和验收材料。这在课程项目里是一个可执行的方案，但它仍然比较粗糙。因为 AI 参与开发后，一个人的价值可能体现在任务拆解、提示词设计、代码审查、测试构造、架构判断，而不只是最终代码行数。如何更公平地评价这些工作，我还没有形成特别成熟的答案。

三、新产生的问题

经过团队项目后，我产生了一个新的问题：

当 AI 能显著提高功能实现速度时，软件工程课程或真实团队应该如何重新定义“最小可行产品”的边界？

过去 MVP 的边界很大程度受人力实现速度限制；现在 AI 可以很快堆出更多功能，团队很容易把“能做”误认为“该做”。Beta 阶段我们加入了地图工坊、Bot、怪物 AI、音效和地图选择，这些功能都提升了展示效果，但也同时增加了状态一致性、测试和维护成本。未来做项目时，我需要更早地区分“展示价值高的功能”和“长期维护价值高的功能”。

四、六个阶段中学到的知识点

1. 需求阶段：用户场景比功能列表更重要

团队项目最初不是简单列“做一个游戏”，而是围绕典型用户场景来定义功能：熟人玩家希望通过链接快速组局，轻度玩家希望失败代价不要太高，核心玩家希望有搜刮、战斗、撤离和翻盘空间。因此我们设计了 Web 即开即玩、三局制、黑市、常规撤离和丢包撤离。

这让我理解到，需求分析不能只写功能点，还要说明这些功能解决了谁的什么问题。没有用户场景，功能很容易堆砌；有了场景，才知道哪些功能必须优先完成。

2. 设计阶段：共享模型能降低前后端协作成本

“杰后余生”采用 shared、server、client 三包 Monorepo。地图结构、Colyseus Schema、职业配置、楼层空间判定等公共规则放在 shared 中，前后端共同使用。

这个设计的知识点是：复杂系统要尽量减少“同一规则写两遍”。多人游戏里，如果前端认为某个点可走、后端认为不可走，玩家体验就会立刻出问题。共享模型虽然前期设计成本更高，但能减少后续联调中的规则不一致。

3. 实现阶段：服务端权威是多人游戏的基本原则

在实现阶段，我对“服务端权威”有了更具体的理解。客户端只负责发送操作意图和渲染状态，关键判定如移动、攻击、开箱、撤离、楼层切换都应该以服务端状态为准。

这不仅是为了防作弊，也是为了让多人状态保持一致。单机逻辑里，客户端怎么判断都可以；多人联机中，如果每个客户端都自行计算结果，就会出现不同玩家看到不同世界的问题。

4. 测试阶段：冒烟测试适合守住核心链路

团队项目中，我们不可能在有限时间内把所有 UI 和游戏状态都写满测试。因此一个重要知识点是：先用冒烟测试守住核心链路。

例如联机冒烟测试可以模拟双客户端进房、准备、黑市购买、地图加载、开箱、楼层切换、战斗、撤离和回合流转。它不一定覆盖每个边界，但能保证主流程没有断。对课程项目这种迭代很快的项目来说，冒烟测试的收益很高。

5. 发布阶段：CI/CD 的价值是降低人为失误

我们的项目依赖服务器运行，每次修改后都需要构建并部署。团队配置了 GitHub Actions，在推送到 main 后执行依赖安装、构建、SSH 登录服务器、部署脚本、PM2 重载和健康检查。

我学到的知识点是：CI/CD 不只是“自动化很酷”，而是把容易漏掉的步骤固化下来。多人项目后期改动频繁，如果每次靠手工部署，很容易出现本地能跑、线上没更新、依赖没装、进程没重启等问题。

6. 维护阶段：文档和可追溯记录决定后续能不能接着改

Beta 阶段新增地图工坊、怪物 AI、人机补位后，项目复杂度明显上升。如果没有 README、技术规格、Issue、Scrum Meeting、devlog 和贡献记录，后续很难判断一个功能为什么这样设计、有哪些风险、谁负责验收。

维护阶段我学到的知识点是：文档不是项目结束后补给老师看的，而是为了让团队在下一轮迭代中还能理解自己写过什么。特别是多人项目中，状态机、共享协议、部署方式和测试入口都必须记录清楚。

五、结合个人项目、结对编程和团队项目的心得

1. 个人项目：从“会用软件”到“分析软件”

I.2 中我分析了 MAA。以前我只是长期使用它，觉得它稳定、好用、节省时间；做案例分析时，我开始从需求、用户、Bug、竞品、工作量和产品规划角度重新看这个软件。

这让我意识到，一个软件的质量不只是有没有 Bug。MAA 的价值来自非常明确的用户需求：帮助玩家自动完成重复任务。它的 Bug 有些长期存在，但因为触发条件特殊、修复成本高、替代方案明确，所以团队未必会优先修复。这和我之前“发现 Bug 就应该修”的直觉不完全一样，软件工程中还要考虑收益、成本和优先级。

2. 结对编程：测试能迫使规则表达清楚

结对项目中，我们从不了解 Wasm 和花见小路规则开始，实现了规则判定和测试用例。这个过程让我感受到，结对编程的价值不只是两个人一起写代码，而是两个人一起对齐理解。

尤其是规则判定模块，如果只靠一个人读题，很容易默认某个分支“应该没问题”；但设计测试用例时，必须明确每个输入对应哪类规则。测试会迫使我们把模糊理解变成可执行断言。

3. 团队项目：软件工程的困难主要在协作和变化

团队项目是这一学期最接近真实软件开发的部分。我作为 PM / 前后端集成 / 构建部署参与“杰后余生”，最大的感受是：真正困难的不是写出某段代码，而是让很多段代码、很多人、很多任务在同一个时间点形成可发布的软件。

Alpha 阶段我们完成了网页端多人搜打撤的核心闭环；Beta 阶段又补充了地图工坊、人机补位、怪物 AI、地图选择、音效和反馈。这个过程中，需求会变化，分工会变化，任务优先级会变化，线上环境也会出问题。软件工程的很多方法，比如 Issue、CI/CD、测试、规格说明、贡献分规则、例会，并不是为了形式完整，而是为了在变化中仍然能推进项目。

4. 对“做中学”的理解

这门课之前，我对软件工程知识点的理解更像概念记忆：需求分析、设计、实现、测试、发布、维护分别是什么。但做完项目之后，我更能理解它们之间的连续关系。

需求写得不清楚，设计就会摇摆；设计没有共享边界，实现就会各写各的；实现缺少测试，发布就会不敢动；发布没有自动化，维护就会被重复操作拖住；维护没有记录，下一轮迭代就会重新踩坑。

所以我对“做中学”的理解是：软件工程不是把每个知识点单独背下来，而是在一个真实项目中看到它们如何互相影响。经历过一次之后，再回看开学时的问题，很多答案不是书上某句话能直接给出的，而是在项目推进、出错、修复、发布和复盘中慢慢形成的。