个人作业：提问回顾与个人总结

[I.3] 个人作业：提问回顾与个人总结

项目	内容
这个作业属于哪个课程	软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	以构建较完整的软件项目为驱动，提升从需求分析、系统设计、编码实现到测试发布的综合工程能力；在团队协作中熟悉 Git、Code Review、接口约定、迭代管理等工程实践，逐步从“会写代码”转向“会做软件”。
这个作业在哪个具体方面帮助我实现目标	通过回顾学期初提出的问题，并结合个人项目、结对项目和团队项目的实践经历，重新审视自己对软件工程的理解，梳理在做中学过程中真正获得的知识点和工程意识。

一、提问回顾

链接到以前提问题的博客：[l.1] 个人作业：阅读与提问

Q1：当 AI 辅助编程降低了“技能”门槛，软件工程师的“核心竞争力”该如何重新定义？

学期初我比较担心：如果 AI 可以生成大量基础代码，那么“会写代码”这件事本身是不是会变得不再重要。经过这一学期的实践后，我的答案变得更清晰了：AI 确实降低了写出代码片段的门槛，但没有降低做出可靠软件的门槛。

在个人项目和结对项目中，AI 可以帮助我快速生成函数框架、测试样例或者某些模板代码，但真正耗费精力的部分往往不是“把代码敲出来”，而是判断需求是否被理解正确、边界条件是否覆盖、模块之间的关系是否清晰、生成的代码是否符合已有结构。尤其是在团队项目中，一个接口的字段命名、错误码格式、数据库表设计、前后端交互流程，都会影响其他成员的工作。AI 能给出建议，但无法替团队承担最终的工程判断。

所以我现在认为，软件工程师的核心竞争力并不是单纯的编码速度，而是把模糊问题拆成清晰需求、把局部实现放进整体架构、并对最终质量负责的能力。AI 更像是放大器：它能放大一个人解决问题的效率，也会放大一个人设计不清、验证不足带来的混乱。

Q2：在敏捷开发的“小步快跑”中，如何避免 AI 生成的代码变成难以维护的“技术债”？

这个问题在团队项目中得到了比较直接的验证。刚开始迭代时，为了尽快跑通功能，我们很容易接受一段“看起来能用”的代码。但是当 Alpha 阶段进入联调、Beta 阶段需要继续扩展功能时，之前一些没有统一风格、没有抽象边界、缺少异常处理的代码就会暴露问题。它们短期提升了速度，长期却增加了理解和修改成本。

我后来意识到，敏捷开发并不等于没有设计，也不等于每次只追求当下能跑。比较合理的做法是保留“小步快跑”的节奏，但给每一步设置最低工程约束。例如：AI 生成的代码必须经过人工阅读；新增接口必须符合统一文档；关键逻辑必须有测试；同类功能的实现方式要保持一致；发现重复代码时及时重构，而不是等到完全改不动再处理。

因此，避免 AI 代码形成技术债的关键不是少用 AI，而是把 AI 生成结果纳入正常的软件工程流程：需求确认、设计约束、代码审查、测试验证和持续维护。AI 只能提供初稿，不能替代审查。

Q3：在大三的团队项目中，如何量化“贡献度”才算真正的公平？

经过团队项目和中途转会环节后，我对这个问题的感受更深了。只看代码行数、提交次数或者任务数量，都很难公平反映贡献。有人负责需求梳理、接口设计、联调沟通和 Bug 定位，代码提交可能不多，但对项目推进非常关键；有人提交量很大，但如果代码质量不高，也可能给后续维护带来额外成本。

转会环节尤其让我意识到，贡献还包括“让别人接得住”。一个成员留下清晰的文档、规范的接口说明、可运行的环境配置，能极大降低新成员接手成本；反过来，如果只有代码没有说明，即使功能已经实现，也会让团队在交接中付出很高代价。

所以我现在认为，贡献度评价应该是多维的，至少要同时看功能交付、代码质量、问题解决、协作沟通和文档沉淀。PSP、开发日志、Issue 记录、PR 讨论、测试报告等材料都可以成为证据。它不可能做到完全客观，但比单纯看代码行数更接近真实贡献。

Q4：在“为了交作业”的压力下，如何平衡“功能实现”与“技术债”的崩塌？

学期初我觉得学生项目生命周期短，也许不用太认真对待技术债。现在我的想法有所变化：学生项目确实不需要像长期商业系统那样追求所有细节的完美，但仍然需要有选择地控制技术债，因为技术债不一定等到“长期维护”才爆发，它可能在下一次迭代、下一次联调、下一次演示前就让团队付出代价。

在课程项目中，合理的取舍应该是：对演示无关、风险很低、后续几乎不会再动的部分，可以接受较简单的实现；但对核心流程、公共接口、数据库结构、配置管理、异常处理等会被反复依赖的部分，不能随便硬编码或临时拼接。否则 Alpha 阶段省下的时间，往往会在 Beta 阶段成倍还回去。

所以我对技术债的理解从“要不要欠债”变成了“能不能知道自己欠了什么债、什么时候必须还”。有意识地记录技术债、区分债务优先级，比盲目追求零技术债更现实。

Q5：在团队作业中，如何应对“AI 鸿沟”导致的成员能力不均？

这个问题也在实践中得到了部分回答。AI 使用能力确实会拉开开发效率差距，但团队不能把效率完全建立在少数会使用 AI 的成员身上。否则表面上项目推进很快，实际上知识集中在少数人手里，其他成员难以理解整体逻辑，后期联调和维护都会受影响。

比较可行的做法是把 AI 使用过程透明化。使用 AI 生成代码后，提交者需要能够解释这段代码解决了什么问题、有哪些边界、为什么这样设计。团队也可以在 Code Review 中重点检查 AI 生成代码的正确性和一致性，而不是只看功能是否跑通。同时，Leader 应该把任务拆成不同难度，让每个人都有真正负责的模块，而不是让部分同学只做复制、粘贴和轻微修改。

我现在认为，“AI 鸿沟”不能只靠禁止或放任来处理，而应该通过规范、分享和审查来缩小。真正好的团队不是让最强的人完成所有事，而是让工具提高整体协作效率。

二、仍未完全明白的问题

大部分问题都通过看书、实践和讨论获得了阶段性答案，但“贡献度如何真正公平量化”仍然没有完全解决。

我现在能接受多维评价比单一指标更合理，但多维评价仍然会有主观性。例如架构设计、沟通协调、Bug 定位这类贡献很重要，却很难像代码提交一样自动记录；AI 参与后，代码产出和个人能力之间的关系也更复杂。课程中的开发日志、PSP、Git 记录和组内互评可以缓解这个问题，但还不能完全消除偏差。也许真正的公平不是找到一个绝对公式，而是尽量保留过程证据，并让评价规则提前公开、持续透明。

三、新产生的问题

Q1：团队项目中应该如何记录 AI 的参与程度？

AI 已经能参与需求分析、代码生成、测试用例设计和文档撰写。如果只记录最终提交，很难看出哪些内容来自个人思考，哪些内容主要由 AI 生成。那么在课程项目或真实项目中，是否应该建立 AI 使用记录？记录到什么程度才既能保证诚信和可追溯，又不会增加过多流程负担？

Q2：转会或人员变动时，怎样设计更低成本的知识交接机制？

经历转会环节后，我发现团队项目并不只是“把功能做出来”，还要让后来的人能理解和继续维护。代码、接口文档、环境配置、任务背景、未解决问题都需要交接。那么，怎样的文档结构和协作流程，才能让新成员在最短时间内进入状态？这可能也是团队项目中很重要但容易被忽视的工程能力。

四、各阶段学到的知识点

需求阶段：用户故事与优先级排序

需求阶段我学到的知识点是把模糊需求转化为用户故事，并根据价值和成本进行优先级排序。团队项目初期大家往往会提出很多想做的功能，但时间和人力有限，不可能全部实现。通过区分核心需求和附加需求，先保证最小可用版本，团队才能在有限周期内形成可展示、可迭代的成果。

设计阶段：模块边界与接口契约

设计阶段我体会最深的是接口契约的重要性。多人开发时，如果前后端字段、错误码、数据格式和调用时机没有提前约定，后期联调会非常痛苦。清晰的模块边界和接口文档能让成员并行开发，也能降低转会或人员交接时的理解成本。

实现阶段：代码规范与可维护性

实现阶段我学到的是代码规范不是形式主义，而是协作效率的一部分。统一命名、目录结构、提交信息和异常处理方式，可以减少阅读成本，也方便他人 Review。尤其在使用 AI 辅助编程时，统一规范能避免生成代码风格杂乱，减少后续维护压力。

测试阶段：边界测试与回归测试

测试阶段我学到的是，只验证正常流程远远不够。真正容易出问题的地方往往是空输入、非法输入、重复操作、权限异常和网络异常等边界场景。每次修复 Bug 或增加功能后，还需要做回归测试，避免新改动破坏原有功能。

发布阶段：可运行环境与发布检查

发布阶段我学到的是，能在本地跑通不等于能稳定发布。发布前需要确认依赖、配置、数据库、账号权限、接口地址等环境因素，并准备基本的检查清单。对于课程项目来说，一份清晰的部署说明和演示前检查流程，往往能避免很多临场问题。

维护阶段：日志与问题追踪

维护阶段我学到的是日志和 Issue 记录的价值。系统出现问题时，如果没有日志，只能依赖猜测和重复尝试；有了日志和问题记录，就可以更快定位错误来源，也方便团队成员同步进展。维护不是项目结束后的附加工作，而是从开发阶段就要开始准备的能力。

五、个人心得体会

个人项目

个人项目让我意识到，独立完成一个任务和“看懂别人怎么做”完全不是一回事。独立开发时，需求理解、方案设计、代码实现、调试和测试都要自己承担，没有人可以替自己兜底。这个过程暴露了我很多基础问题，比如对边界条件考虑不够、调试时缺少系统方法、写完功能后容易忽视测试。

但也正因为没有队友可以依赖，个人项目逼着我把问题拆开，一步步定位原因。它让我建立了最基本的工程自信：遇到问题时，不是立刻怀疑整个方向，而是先复现、再缩小范围、再验证假设。这个能力对后面的结对和团队项目都有帮助。

结对编程

结对编程让我体会到沟通本身就是生产力。两个人一起写代码时，驾驶员更关注具体实现，领航员更容易发现逻辑漏洞、边界遗漏和命名不清的问题。很多我自己写代码时可能要调试很久才发现的问题，在结对过程中会被同伴及时指出。

同时，结对也暴露了协作成本。如果两个人编码习惯不同、对需求理解不同，就很容易在小问题上反复讨论。后来我认识到，结对编程不是两个人简单坐在一起写代码，而是要先对齐目标、分工、命名和测试标准。好的结对能提高质量，前提是双方都愿意解释自己的思路，也愿意接受对方的质疑。

团队项目

团队项目是这一学期最接近真实软件工程的部分。相比个人项目和结对项目，团队项目的难点不只是技术实现，而是如何让多人在同一个目标下持续协作。需求会变化，接口会调整，成员会有不同节奏，中途还可能出现转会和任务交接。项目推进过程中，我逐渐明白流程不是为了增加负担，而是为了减少混乱。

Alpha 阶段让我看到快速实现核心功能的重要性，Beta 阶段让我意识到前期设计和技术债会影响后续迭代。转会环节则让我更直观地理解了文档、接口规范和代码可读性的价值：一个项目不是只有原作者能跑起来才算成功，而是其他成员也能理解、接手和继续推进。

回顾整个学期，我最大的收获是对“软件工程”的理解发生了变化。以前我更关注代码能不能写出来，现在我更关注需求是否清楚、设计是否可扩展、协作是否顺畅、测试是否可靠、发布和维护是否有准备。软件工程不是把代码写多，而是在有限时间、有限人力和不断变化的需求下，尽量稳定地交付有价值的软件。