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

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	不仅能实现特定软件功能，也能理解一个项目怎么被组织、协作和交付
这个作业在哪个具体方面帮助我实现目标	回顾这一学期的个人项目、结对项目和团队项目经历

课程初提问回顾与解答

[I.1] 个人作业：阅读和提问

开学初的阅读作业里，我提了五个和 ai、框架、文档相关的问题。那时候还没真正开始做团队项目，很多想法都停留在单纯的思考中。做完结对项目花见小路和团队项目 hexavigil 后，虽然没有确切的标准答案，但对这几个问题有了更切身的体会。

当时的第一个问题是，在 ai 辅助开发的背景下，psp 还能不能继续以编码时间为度量核心。经过这两个项目，我发现如果只记录敲键盘的时间，会漏掉很多隐形的精力消耗。结对项目里我们尝试用 ai 生成复杂的蒙特卡洛算法，代码生成得挺快，实际效果却很不稳定。最终真正耗时的部分全在验证方案和排查代码逻辑漏洞上。如果不把这些试错环节算进去，最后的时间统计根本解释不了项目为何延期。

第二个问题是给落后的项目加 ai 资源会不会触发布鲁克斯法则。这学期体会下来，ai 确实没有人员沟通门槛，但会带来很高的验证要求。团队项目后期让 ai 帮忙处理 ui 资产接入确实提速了，但在 beta 冲刺期，如果项目验收标准本身就不太清晰，ai 只会飞速堆积出大量未经严格测试的功能。大方向和边界把控依然依赖人，单靠 ai 救场并不能纠正方向上的偏差。

第三个问题是用开源框架时要将原理理解到什么程度。经历过几次排查问题，我现在有了一个比较实际的标准，就是至少得懂到能定位问题属于哪一层。像做医院管理系统时，如果不清楚业务规则必须放在 service 层，单在前台拦截，后续修改就会特别混乱。用 godot 也是一样，不需要啃透引擎源码，但必须清楚场景树和 autoload 的运行机制。遇到资源导出报错时，能分清是脚本逻辑出错还是导出设置有误，才是解决问题的前提。

第四个问题是技术门槛降低后，NABCD 里的竞争优势体现在哪。起初我以为技术实现的难度是最关键的优势，拆解完 obs 案例后发现，即便底层再强，如果用户体验不好也会直接放弃。团队项目也印证了这点，我们在 alpha 阶段堆了各种玩法模块，但是没有新手教程。新玩家根本不知道怎么上手。beta 阶段补齐教程后体验才慢慢顺畅。现在的竞争优势更多体现在系统能不能让用户自然理解逻辑并顺畅走完整个流程，这往往比纯粹的技术堆叠更重要。

第五个问题是 ai 自动生成普及后文档的价值是否改变。经历团队协作后我发现，解释代码基础功能的文档变得很容易获取，记录项目约定的全局文档反而变得十分关键。团队项目里约束场景分层和 json 格式的说明，是整支队伍协作的基础。同时过时的文档会带来不小的负担，那些未清理的旧设定不仅会误导队友，也会让 ai 产生理解偏差。文档的价值完全取决于它能不能客观反映当下的真实状态。

课程接近尾声，结合这些经历我又产生了一些新疑问。ai 生成的代码经人工 review 合入（实际是人工调用 AI review）后，其实深层逻辑还是没有多少人了解。在未来会不会出错这件事情上，好像只能相信 ai 足够强大了（对项目保持掌控力是好的，但是赶工进展实在是太快了，项目过后也没有重新梳理的动力）。另外，尽管我们顺利走完开发和发布流程跑通了 ci，项目依旧缺乏真实的玩家试玩与反馈数据，我们对实际体验的了解还是比较有限。这些不足，只能留到以后的开发实践中去慢慢寻找答案了。

项目全流程知识点总结

需求阶段

以前我习惯把需求看作一份功能清单，做课上实验时才发现，真正影响系统运转的往往是业务的限制条件，比如药品关联后的删除限制、病人年龄的逻辑校验。团队项目也是这样，初期大家想法很多，最后逐渐收敛到白天探索经营配合夜晚塔防的核心玩法循环上。需求如果不能落实到具体的业务规则和主路径上，开发时很容易偏离方向，最后变成一个松散的功能集合。

设计阶段

设计阶段最核心的体会是关于边界。当多人并行开发时，缺乏明确的模块边界会让地图、战斗、ui 互相直接调用 api，后期的修改成本会非常高。设计很大程度上是为了规范协作，防止代码在演进中失控。

实现阶段

实现过程中我意识到避免过度迷信复杂方案的重要性。花见小路 t3 我们尝试复杂算法但计算成本太高，最后还是退回了简单的启发式算法。hexavigil 的很多系统同样先做了一个简易的可运行版本。验证可行性后大家再去补充 ui 动效和音效。我们需要先搭建基础，再通过逐步完善去支撑后续的扩展。

测试阶段

测试必须是可以重复验证的。团队项目中我们也逐渐开始用 headless 脚本来测试地图生成和遗物抽取。缺乏自动化测试提供保障，后期面对细微的代码重构都会有些心虚。

发布阶段

项目的发布远比点击一次导出复杂。团队项目通过 github actions 实现了 CD，但在最后的 web 端部署时依然面临包体过大、加载卡顿等问题。尽早列出发布检查项是保证项目平稳收尾的必要条件，全部推迟到最后处理很容易打乱原定的节奏。

维护阶段

维护工作很大一部分是针对流程和文档的。赶进度写下的临时代码、没来得及清理的过期说明，都会在后续变成额外的负担。许多维护阶段的压力，其实在前期为了推进进度而妥协时就已经产生了。

从个人到团队的实践心得

个人实验让我初步接触了软件开发的完整过程，让我切实认识到了对拍和单元测试对于保障正确性的基础作用。

结对项目花见小路给我的一大经验是及时调整方向。我们在 t3 的复杂方案上消耗了过多时间，发现效果不佳时调整得有些晚。两人结对的优势在于面对面沟通，能迅速纠正低级错误，减少理解偏差。在大方向不够明确时，两个人也有可能一起陷入误区。结对的意义更多体现在互相检查和保障代码质量上。

团队项目 hexavigil 是这学期最贴近实际开发的经历。我的工作从前期的架构设计逐渐过渡到后期的 ui 资产整合与发布集成。这与结对项目的直接沟通差异很大，团队协作高度依赖 issue、pr 和代码 review 流程。在后期多人代码频繁合并、需要排查环境报错时，这些流程保障了项目的可追踪性和稳定性。

写在最后

这学期的课程改变了我对软件开发的不少固有认知。过去我倾向于认为只要把代码编写完成项目就宣告结束。现在回头看，写代码仅是整个周期中的一环，甚至在AI时代是最不足为奇的一环。确保需求被准确理解、模块边界清晰、代码具备可测试性、最终能够稳定打包交付，这些统筹和规范构成了软件工程中更具挑战性的部分。

初学时那些 pr 规范、文档同步、ci 构建等流程容易让人觉得只是走过场。在实际的推进中我渐渐明白，缺乏这些底线约束，稍微复杂一点的项目很容易陷入混乱。经历过一整套流程后，未来面对一定规模的开发任务时，我会更注重项目前期的规划与过程中的协作规范，不再仅仅依靠直觉直接开始编码。