[l.1] 个人作业：阅读与提问
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR |
| 这个作业的要求在哪里 | [I.1] 个人作业：阅读和提问 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园 |
| 我在这个课程的目标是 | 以构建高并发、高可用的完整软件项目为驱动，磨练从底层原理到上层应用的综合开发实力；在团队协作中精进版本控制（Git）与 Code Review 技巧，培养工业级的代码规范意识。坚持以批判性视角审视技术选型，提升在极端工程约束下破解技术难题的能力，塑造具备职场竞争力的核心技术栈。 |
| 这个作业在哪个具体方面帮助我实现目标 | 从宏观视角重构对软件工程全生命周期的认知，将简单的“编程思维”升级为职业化的“工程思维”。这一过程不仅能锻炼我在复杂系统中的批判性洞察力，更能帮助我建立标准化的项目管理逻辑与协作沟通协议，为构建工业级软件项目和长远的职业发展奠定坚实的理论与实战基础。 |
问题 1：当 AI 辅助编程降低了“技能”门槛，软件工程师的“核心竞争力”该如何重新定义？
原文引用：
“软件开发的过程包含了很多任务，例如：需求分析、设计、编码、测试、维护。而‘编码’只是其中的一环。有些人认为，只要会写代码，就是软件工程师。其实不然。软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护的过程中。”（第一章：概论）
我的困惑和思考：
在 AI 辅助编程工具（如 GitHub Copilot、ChatGPT 等）越来越普及的情况下，编写基础代码的门槛明显降低。例如，在做课程项目时，只需要简单描述需求，AI 就可以生成排序算法实现、后端接口模板，甚至完整的 Web 项目框架。这让我感觉，“编码能力”在软件开发中的比重似乎正在下降。
但书中提到，软件工程不仅是写代码，还包括需求分析、系统设计、测试和维护等一整套工程过程。因此我在想：如果 AI 已经可以帮助完成大量编码工作，那么软件工程师未来真正的核心能力是什么？
例如，在课程项目中，AI 可以生成登录模块或 CRUD 接口代码，但它很难根据具体需求设计合理的系统架构，也很难保证代码在功能不断增加时仍然保持良好的可维护性。因此我在思考：对于大三学生来说，除了学会使用 AI 工具之外，是否更应该重点培养像系统设计能力、需求分析能力以及代码可维护性意识这样的工程能力，而这些能力可能才是短期内 AI 难以取代的部分。
问题 2：在敏捷开发的“小步快跑”中，如何避免 AI 生成的代码变成难以维护的“技术债”？
原文引用：
“很多学生团队在做项目时，往往是‘走一步看一步’，这种‘草鞋式’的开发模式在初期进展很快，但随着功能的增加，系统会变得越来越臃肿，最后谁也改不动。敏捷开发不是没有设计，而是‘演进式设计’。”（第六章：敏捷流程）
我的困惑和思考：
在做课程项目时，很多学生会使用 AI 编程工具（如 GitHub Copilot、ChatGPT 等）快速生成代码，例如登录模块、数据库接口或一些工具函数。这样确实可以让项目在初期推进得很快，符合敏捷开发“小步快跑”的特点。
但我也发现，AI 生成的代码往往只是针对单个问题的局部解决方案，不同模块之间可能缺乏统一的设计。例如有的模块直接写 SQL，有的模块使用 ORM，命名和结构也不统一。随着功能不断增加，这种“拼接式代码”很容易变得难以维护。
因此我在思考，在敏捷开发不断迭代的过程中，如果团队大量使用 AI 生成代码，是否需要建立类似代码评审或架构规范的机制，来检查 AI 生成的代码是否符合整体设计，从而避免项目在后期因为技术债过多而难以维护。
问题 3：在大三的团队项目中，如何量化“贡献度”才算真正的公平？
原文引用：
“在团队中，最难的事情不是技术，而是人。如何衡量每个人的贡献？是看代码行数（LoC）吗？如果一个人重构了代码，删掉了 500 行冗余代码，让系统跑得更快，他的贡献难道是负数吗？我们需要一个科学的评价体系，比如 PSP（个人软件过程）。”（第三章：软件工程师的成长）
我的困惑和思考：
在大三的课程项目中，团队合作是常见形式，但“贡献度如何衡量”一直是比较现实的问题。很多时候，如果只看 Git 提交记录或代码行数（LoC），并不能真正反映每个人的实际贡献。例如，有的人可能写了很多基础代码，但系统的核心架构其实是另一个人设计的；还有的人可能通过重构删除了大量冗余代码，让系统结构更清晰，但从代码行数来看反而像是“负贡献”。
在 AI 编程工具越来越普及的情况下，这个问题似乎变得更加复杂。例如，有的同学可能通过 AI 快速生成大量代码并提交，但这些代码的整体设计和逻辑其实来自团队中负责架构的人；还有的人主要负责需求分析、系统设计或调试复杂 Bug，但提交的代码数量却不多。
例如，在一次课程项目中，有同学负责设计数据库结构和系统模块划分，代码提交不多，但整个系统的逻辑都依赖他的设计；而另一位同学则利用 AI 快速生成了一些接口代码，提交记录很多。从表面数据来看，两人的贡献似乎很难直接比较。
因此我在思考：在学生团队项目中，是否存在一种更合理的方式来衡量贡献，例如综合考虑架构设计、问题解决、代码质量以及团队协作等因素？在 AI 辅助编程越来越普遍的背景下，软件工程课程是否也需要探索一种更符合现代开发模式的团队贡献评价方法。
问题 4：在“为了交作业”的压力下，如何平衡“功能实现”与“技术债”的崩塌？
原文引用：
“技术债（Technical Debt）就像财务债务一样，如果你借了钱不还，利息就会越积越多。在软件开发中，为了赶进度而采用临时性的、不规范的设计，就是欠下了技术债。如果一个团队总是在还债，那么它就无法进行新的开发。”（第十六章：IT行业的创新）
我的困惑和思考：
在课程项目中，由于时间通常只有一学期，很多团队的目标其实是“把功能做出来并顺利演示”。在这种压力下，大家往往会选择一些更快的实现方式，例如直接 Hard Code（硬编码）一些数据、简化异常处理，或者暂时忽略代码结构的问题。这样确实可以让系统在短时间内跑通，但也容易积累很多技术债。
例如，在一次课程项目中，我们为了保证演示成功，把部分配置直接写死在代码里，虽然功能能够正常运行，但一旦需要修改环境或增加新功能，就需要在很多地方手动修改代码，结构也变得比较混乱。
因此我在思考：既然学生项目往往在课程结束后就不会继续维护，那么在这种“短生命周期”的项目中，我们是否真的有必要像书中所说那样认真对待技术债？还是说学生阶段更应该把重点放在快速实现功能上？另一方面，如果在学习阶段长期习惯这种“先跑起来再说”的开发方式，会不会在进入真实的软件项目时，很难适应对代码质量和长期维护的要求？
问题 5：在团队作业中，如何应对“AI 鸿沟”导致的成员能力不均？
原文引用：
“团队协作不是简单的加法。一个高效的团队需要成员之间有默契，有明确的角色分工。如果成员之间的技术水平差距过大，往往会导致‘大神’累死，‘小白’无所事事。”（第五章：团队和流程）
我的困惑和思考：
在现在的大学团队项目中，成员之间的差异不仅体现在编程能力上，还体现在使用 AI 工具的能力上。有的同学非常擅长使用 ChatGPT、Copilot 等工具，通过不断优化 Prompt 可以很快生成可用代码，开发效率明显提高；而有的同学仍然习惯查文档、手写代码，开发速度相对较慢。这种“AI 使用能力”的差异，有时甚至比编程基础的差异更容易导致团队效率失衡。
例如，在一次团队作业中，有同学通过 AI 很快生成了多个接口和页面代码，而另一些同学则主要负责调试和修改这些代码，但由于对整体逻辑理解不够，参与感比较低，容易变成简单的“代码搬运”。久而久之，项目的核心工作就集中在少数会使用 AI 的人身上。
因此我在思考，如果作为团队的 Leader，是否需要制定一些基本规范，例如：要求成员在使用 AI 生成代码后必须理解并讲清楚逻辑，或者通过代码评审、模块负责人制度等方式保证每个人都真正参与到开发过程中。这样既能利用 AI 提高效率，又能避免团队变成“一个人写 Prompt，其他人只是粘贴代码”的情况。
浙公网安备 33010602011771号