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

项目	内容
这个作业属于哪个课程	BUAA_SE_2026_LR
这个作业的要求在哪里	作业要求链接
我在这个课程的目标是	系统性的学习软件工程的知识，逐步成为一个成熟的软件开发者，与团队、结对成员一起协作完成软件开发，共同成长进步。
这个作业在哪个具体方面帮助我实现目标	阅读邹老师的经典作品，了解软件工程中各方面的知识和非常有趣的思想，通过批判性思维提出自己的思考、问题和看法。

一、对学期初问题的回顾与解答

学期初阅读《构建之法》时，我在第一次阅读作业《个人作业：阅读和提问》中提出的问题更多来自过去个人项目、科研项目和竞赛经历中的直觉：我会担心敏捷是否过于理想化，会怀疑 PM 和结对编程是否适合技术门槛很高的小团队，也会思考 AI 出现后软件创新是否会变成单纯的速度竞赛。一个学期过去后，我经历了个人作业、结对项目、Alpha/Beta 两阶段团队项目，以及团队协作中的转会和分工调整。回头看这些问题，我发现很多问题并不是非黑即白，而是要放到具体项目阶段、团队规模和风险类型中判断。

问题一：敏捷流程中的“欢迎需求改变”，是否适用于底层且严密的基础软件开发？

我现在的理解是：敏捷不是不要设计，也不是随时推翻底层结构。它更强调把不确定的需求放进短周期反馈里处理，而不是假设一开始就能把所有用户需求想清楚。对于底层严密系统，真正应该被冻结的是核心不变量和架构边界，而不是所有功能细节。

在团队项目 杰后余生 中，这一点非常明显。我们做的是 Web 多人在线搜打撤游戏，技术上涉及 shared / server / client 三包 Monorepo、Colyseus 状态同步、Phaser 渲染、房间协议、宝箱、撤离点、战斗和排行榜等共享 Schema。如果这些基础协议和服务端权威状态设计混乱，后面每次加地图、Bot、怪物 AI、黑市道具都会牵一发而动全身。因此，底层架构需要比较严谨的前期设计。

但另一方面，UI 体验、地图内容、Bot 压迫感、BGM、开箱和开门音效，都是在 Alpha 测试反馈之后逐步调整的。Beta 阶段新增地图工坊、人机补位、怪物 AI 和地图选择流程，本质上都是在接受需求变化。因此我现在认为，严密系统也可以敏捷，但敏捷的对象应该是可替换、可演进的功能层；对协议、数据结构、核心算法这类高重构成本部分，要先做足设计，并通过接口约束给后续迭代留空间。

问题二：一个人在“冲刺”时，如何保证自己的冲刺状态，而不被临时改动或功能演示干扰？

我最初的困惑是：如果冲刺进行到一半，产品负责人突然要求做计划外功能，开发者到底应该坚持原计划，还是立刻切过去？经过团队项目实践后，我觉得关键不在于“听不听”，而在于有没有把变更显式化。

在真正的项目中，临时需求不可避免。比如 Alpha 之后，团队发现地图内容少、UI 风格不统一、少人难开局、操作反馈不清楚，这些问题都需要插入 Beta 阶段计划。如果所有需求都口头传达，就会让个人开发状态被打断，也会让后续责任不清。更好的做法是把临时需求变成明确任务：它为什么紧急、替换掉原计划中的哪一项、验收标准是什么、谁负责、什么时候合入。

因此，我现在对冲刺的理解是：冲刺不是完全拒绝变化，而是保护团队免受无成本变化的伤害。如果中途确实需要插入需求，就应该重新协商范围，而不是在原工作量不变的情况下强行加塞。GitHub 分支、Issue、PR、构建检查和 devlog 都是在保护这种状态。它们让“我正在做什么”“为什么改”“改完了吗”变得可追踪，也减少了被口头指令反复打断的成本。

问题三：在小型、高门槛团队中，专职 PM 是否会成为沟通瓶颈？

我的阶段性答案是：PM 这个职责是必要的，但不一定必须由一个完全不碰技术的人担任。尤其在学生科研团队、竞赛团队或课程项目中，如果 PM 完全不了解技术细节，很容易把复杂瓶颈简化成“进度慢”或“多加人就行”，反而增加沟通成本。

在 杰后余生 项目中，PM 负责整体进度、前后端集成、构建部署和最终封板，但团队的需求、玩法、开发、测试和美术并不是完全割裂的。比如地图工坊既是产品功能，也是工程功能；Bot 补位既影响玩法体验，也影响服务端同步和测试；黑市 UI 既有视觉设计，也涉及背包、道具和队伍状态。PM 如果不能理解这些模块之间的依赖，就很难安排合理的迭代顺序。

所以我现在更倾向于把 PM 看成“项目风险和信息流的负责人”，而不是“只做开发和测试之外所有事的人”。在小型高门槛团队中，技术骨干兼任 PM 或者 PM 保持足够技术理解，往往比严格切出一个非技术 PM 更合适。等团队规模变大、流程复杂、对外沟通变多时，再逐步强化专职 PM 的作用。

问题四：当下真的还需要结对编程吗？这种模式是否适合大多数人的成长？

我现在认为，结对编程仍然有价值，但不能机械理解为两个人必须一直坐在一起，一个人敲键盘，另一个人盯着每一行代码。AI 工具确实已经能承担一部分“即时提示”和“低级错误检查”的角色，但它不能替代人与人之间对需求、边界、取舍和责任的对齐。

在课程实践中，结对最有价值的地方不是提高打字速度，而是降低理解偏差。两个人讨论接口怎么设计、异常情况怎么处理、测试样例怎么覆盖，比各自埋头写完后再合并要可靠得多。尤其是遇到不熟悉的代码、复杂 Bug 或需要统一风格的模块时，结对或者至少强制 Code Review，可以很快暴露个人盲区。

在花见小路桌游模拟项目中，我对这一点体会更深。这个项目要求我们模拟卡牌桌游的运行机制，并最终给出一个自动策略 Bot。任务本身既要理解桌游规则，又要把规则转化成可运行的程序逻辑，还要进一步思考自动策略。结对过程中，我们不是简单地两个人同时写代码，而是一起理解题目和项目意图，讨论整体思路，再快速迭代实现。其中一人主要实现代码，另一人作为领航员检查题意理解、代码逻辑和潜在 Bug。这个过程让我感受到结对编程的优势：一个人开发时很容易对题意理解偏掉，等到后期才发现隐藏 Bug；两个人一起工作时，另一个同学可以及时审查思路，也能提出新的策略想法，让实现过程更稳。

但我也修正了自己对结对编程的理解：它不适合所有任务。探索性很强的调研、算法试错、临时代码验证，可能更适合个人先快速发散；等方向相对稳定、要进入工程落地时，再结对讨论接口、测试和边界条件。也就是说，结对编程不是替代个人思考，而是把个人想法转化为团队可维护代码时的一种协作方式。花见小路项目也让我进一步理解了敏捷开发和迭代开发：先让规则模拟跑起来，再逐步改进策略 Bot，而不是一开始就假设能设计出最优方案。

问题五：AI 智能快速涌现的时代，软件领域的创新是否变成了一种竞速比赛？

我现在的答案是：一部分创新确实变成了速度竞赛，但最终竞争力并不只来自速度。

AI 工具降低了从想法到原型的成本。过去一个需要几天搭建的界面、脚本或 Demo，现在可能很快就能生成出来。因此，如果只是“想到一个点子并做出雏形”，速度的重要性明显上升。谁更快验证需求、谁更快迭代体验，谁就更容易抢到反馈。

但团队项目让我看到，真正能上线给别人玩的软件，仍然要靠工程能力。杰后余生 不只是一个搜打撤创意，还要解决联机同步、地图加载、房间状态、Bot 行为、怪物 AI、黑市购买、开箱撤离、构建部署、健康检查和浏览器兼容等问题。AI 可以帮助我们更快产出代码和素材，但它不能替我们承担产品决策、系统一致性、测试验证和长期维护。

所以我现在认为，AI 时代的软件创新更像“高速试错 + 工程落地”的组合。速度决定能不能尽快开始验证，工程质量决定能不能留下来。

二、仍然没有完全弄清的问题

原来的问题大多都有了阶段性答案，但我仍然没有完全弄清一个边界：对于高可靠、高安全或底层复杂系统，究竟如何定量地区分“可以敏捷变化的需求”和“必须冻结的架构约束”？

在课程项目中，我们能凭经验判断共享 Schema、服务端权威状态、地图数据结构等不能频繁乱改；UI、音效、数值和地图内容可以快速迭代。但如果换成更大型的操作系统、数据库、金融系统或航空航天软件，哪些部分必须前期严格形式化，哪些部分可以快速迭代，可能需要更多工程经验和行业规范才能回答。

三、新产生的问题

经过一学期实践，我又产生了几个新的问题：

1. AI 深度参与编码后，团队项目中如何界定个人贡献和代码责任？如果一段代码主要由 AI 生成，但由成员审查、修改、测试并合入，那么贡献应该如何评价？
2. 对于游戏、推荐系统、AI 应用这类体验主观性很强的软件，自动化测试和人工试玩之间应该如何分工？哪些体验问题可以被指标化，哪些只能依赖真实用户反馈？
3. 当项目开放 UGC 能力后，例如地图工坊和公共地图发布，软件工程上如何设计审核、回滚、版本兼容和滥用防护机制？

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

1. 需求阶段：需求不是功能清单，而是用户场景和痛点

在团队项目初期，我们并不是简单说“做一个网页游戏”，而是分析了搜打撤游戏的爽点和痛点：硬件门槛高、学习曲线陡、单局全损挫败感强。我们采访了同学，发现“三局流转”“低保撤离”“一键链接组队”能缓解这些痛点。这个过程让我理解到，需求分析的核心不是列功能，而是说明为什么这些功能值得做。

2. 设计阶段：模块边界决定后期迭代成本

杰后余生 采用前后端分离和服务端权威架构，并通过 shared 包统一维护前后端共用的 Schema 和玩法常量。这个设计让客户端负责表现和交互，服务端负责战斗、宝箱、背包、撤离、门、楼梯和结算等权威状态。设计阶段最重要的知识点是职责分离：模块边界清楚，后期增加地图工坊、Bot 和怪物 AI 才不会每次都重写全系统。

3. 实现阶段：版本控制是团队协作的基础设施

团队项目中，代码托管在 GitHub，通过分支、Pull Request、提交记录和 GitHub Actions 工作流协作。相比个人项目直接在本地改代码，团队开发更需要清楚记录每次改动的目的、范围和合入过程。版本控制不只是保存代码历史，更是让团队成员能并行工作、审查变更和定位问题。

4. 测试阶段：冒烟测试和回归测试保证主流程不被破坏

项目中服务端提供了联机冒烟测试脚本，覆盖双客户端进房、职业同步、大厅准备、黑市购买、地图加载、开箱、战斗、撤离和回合流转等核心流程。这个经历让我认识到，测试不是只在最后找 Bug，而是给频繁迭代提供安全网。尤其是多人游戏这种状态复杂的系统，只靠手动试玩很容易漏掉回归问题。

5. 发布阶段：发布不是把代码传上服务器，而是可重复的流程

Beta 版本发布时，项目已经配置 GitHub Actions、SSH 部署、PM2 reload 和 /healthz 健康检查。发布阶段我学到的知识点是部署自动化：真正可靠的发布流程应该可重复、可检查、可回滚，而不是靠某个人手动复制文件。这样团队才能在后续维护时持续交付，而不是每次上线都像临时救火。

6. 维护阶段：维护是基于反馈持续修正产品和技术债

Alpha 阶段后，用户反馈集中在战斗平衡、地图内容、网络流畅度和 UI 表述不清楚。Beta 阶段我们针对这些反馈加入地图工坊、人机补位、怪物 AI、BGM、音效和地图选择修复。维护阶段最重要的知识点是反馈闭环：不是用户说什么就机械加什么，而是把反馈转化为问题定位，再用设计、实现、测试和发布形成下一轮迭代。

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

个人项目和实验让我先认识到“需求质量”的重要性。在实验 1 中，我分析过 EPP 文献调研助手的需求文档，发现功能编号不连续、批量下载描述复制粘贴错误、评分机制 5 分制和 10 分制混用、异常流程缺失等问题。这些问题看似只是文档瑕疵，但如果进入开发阶段，就会直接变成实现偏差和测试困难。以前我更关注代码能不能跑，现在会更早地关注需求是否完整、一致、可验证。

结对编程让我认识到沟通不是附属工作，而是开发本身的一部分。在花见小路桌游模拟项目中，我和队友需要先共同理解卡牌规则、运行机制和自动策略 Bot 的目标，再进入实现。一个人写代码时，很多假设会默默藏在脑子里；两个人一起讨论时，题意理解、接口设计、异常情况、测试边界和职责划分都会被迫说清楚。结对中，驾驶员负责快速实现，领航员负责检查逻辑和代码质量，这种模式能及时发现隐藏 Bug，也能带来新的策略思路。它不一定适合所有探索性任务，但很适合把需求落到稳定代码之前的关键设计和复查。

团队项目是这门课最让我改变认识的部分。杰后余生 从选题、需求、设计到 Alpha/Beta 发布，经历了完整的软件生命周期。我们做的不只是“写一个游戏”，而是要让一个网页多人游戏真的能被别人打开、组队、进入黑市、搜刮、战斗、撤离和结算。过程中我体会到软件工程的重点不是某一个人的代码能力，而是团队能不能把需求、设计、实现、测试、发布和维护串起来。

中间的转会和分工调整也让我意识到，项目不能只靠“某个人脑子里知道”。当人员流动发生时，README、devlog、Issue、PR 记录、模块边界和运行脚本会直接决定新成员能不能接上工作。如果一个模块只有原作者能改，那就说明团队其实欠下了协作债。软件工程里的文档和规范并不是形式主义，而是在人员变化时保护项目连续性的工具。

在团队项目中，我主要负责美术模块。我制作了 杰后余生 中的人物角色美术，包括刺客、坦克等角色，并充分借助 GPT Image 等 AIGC 工具生成和迭代素材。同时，我也参与制作网页游戏 UI、宣传 Demo 等视觉内容。这个过程让我认识到，AIGC 不是简单地“一键出图”，而是需要根据项目风格、角色定位、界面需求不断筛选、调整和接入。为了让素材真正进入游戏，我还开发了相关的美术素材接口代码，把图片资源和前端表现、角色状态、技能反馈连接起来。这个经历让我更具体地体会到团队代码管理的必要性：美术资源、接口代码、前端渲染和游戏逻辑并不是彼此孤立的，只有在统一的版本控制和协作流程下，团队成员的工作才能合成一个可运行的产品。

这一学期最大的收获是：软件工程并不是一套脱离代码的管理话术，而是让多人在有限时间内持续交付可用软件的方法。个人能力决定一个模块能不能写出来，工程能力决定一个系统能不能被理解、协作、测试、发布和长期维护。回头看学期初的问题，我不再把敏捷、PM、结对编程、测试和发布看成孤立概念，而是把它们看成同一件事的不同侧面：如何在不确定性中，把一个想法稳稳地变成可用的软件。