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

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

项目	内容
这个作业属于哪个课程	北航2026春软件工程
这个作业的要求在哪里	个人作业：结课总结
我在这个课程的目标是	学习软工方法论，和团队一起加以实践并合力完成一个软件，提升自己的团队协作能力
这个作业在哪个具体方面帮助我实现目标	回顾学期学习历程，梳理知识收获，对软件工程形成体系化的理解

---

原始阅读博客

个人作业：阅读和提问

---

一、对曾经提出的问题进行解答

问题 1：结对编程和 AI 辅助编程相比有哪些优势？

在代码生成和语法细节的层面，AI 确实比人的效率高得多。在结对项目中，我们大量使用了 GitHub Copilot 和 ChatGPT 来辅助编写代码、讨论策略思路，这极大地加速了开发过程。但与此同时，我发现结对编程带给我的价值远不止"写代码"本身。

具体来说，在以下几类任务中，人与人结对编程的优势非常明显：

1. 需求理解和设计决策：在结对项目中，我和搭档需要一起理解"花见小路"的游戏规则，设计判定逻辑和 AI 策略。这个过程涉及大量的讨论、争执和互相说服——"这个规则应该这样理解""这个策略为什么更优"。AI 可以提供方案，但无法代替两个真实的人在对同一个问题的碰撞中产生的共识。

2. 知识传递和互相学习：结对过程中，我注意到搭档擅长文档编写和细节检查，而我更擅长抽象设计和思路梳理。通过实际坐在一起编程，我们互相补充了对方的不足，这在 AI 辅助编程中是做不到的——AI 不会"配合你成长"。

3. 复杂决策中的信任和责任感：在"花见小路"的 AI 策略设计环节，我们讨论了强化学习、蒙特卡洛树搜索等多种方案，最终选择了贪心策略。这种决策不是 AI 能帮我们做的——AI 可以列出选项，但团队需要共同承担选择的后果，这才是结对编程中"人"的核心价值。

问题 2：软件开发强调"以用户为中心"，但很多用户自己也说不清需求是什么？

面对模糊的用户需求，团队应当通过快速原型验证假设，用数据指导判断，并在迭代中逐步收敛需求定义，而不是试图在一开始就通过文档把需求完全固化。同时，在面对互相矛盾的反馈意见时，也要识别哪些意见来自核心用户、哪些意见只是干扰。

问题 3：在 AI 时代，既然产品原型已经很容易生成，那么事先写详细文档和规格说明书还有那么重要吗？

我的结论是：关键设计决策、API 契约、部署方案这类稳定且必须共享的信息需要文档化；而 UI 调整、功能细节这类可能在迭代中频繁变化的内容，用原型和代码本身来表达更有效率。文档的价值在于沟通和记录决策，并且在大多数人使用 AI 辅助生成代码的情况下，文档相当于提供给不同的 AI 一个稳定的上下文，可以比较好地对齐代码。

问题 4：代码能力（语法、语言特性）还属于技能吗？

经过这学期的实践，我认识到：代码能力依然是程序员的核心技能，但它的定义正在从"写代码的能力"转向"理解、审查、设计和调试代码的能力"。

问题 5：在 AI 深度参与开发之后，团队里个人贡献该如何评价？

我认为，在 AI 时代，团队中个人贡献的评价标准应该从"产出了多少代码"转向以下几个维度：

1. 决策质量：在关键节点上是否做出了正确的方向判断。比如在 Alpha 阶段我们决定先做哪些功能、后端选择什么技术栈，这些决策直接影响项目的成功。

2. 解决问题的能力：当出现棘手的 bug 或技术难题时，谁能解决它。比如在移植到正式服务器时遇到的数据库连接问题、部署配置问题等。

3. 团队协作能力：是否能有效地沟通、推动项目前进、帮助其他成员成长。

4. 对最终结果的责任感：是否主动承担任务、对质量负责、在 deadline 前完成承诺的工作。

我的结论是：AI 工具的使用抹平的是执行层面的差距，但不能抹平判断力、责任感、协作能力和创造力的差距。团队评价个人贡献时，应该更关注"做对了什么决定"和"解决了什么问题"，而不是"写了多少代码"。

二、在项目的六个阶段中学到的知识点

1. 需求阶段 —— 需求优先级矩阵

我们最后确定了 Alpha 阶段的关键路径："用户能注册登录 → 看到今日运势 → 提问答案之书 → 写情绪日记 → 分享到广场"。其他功能放在 Beta 阶段或者降级为内部工具。这个决策让团队在前 4 周内就产出了一个可用的闭环产品，而不是在 8 周后产出半个半成品。

这个知识点不是从书上学到的，而是在被 deadline 逼着做选择时深刻体会到的。

2. 设计阶段 —— 面向接口编程与依赖反转

学到的知识点是：面向接口编程（LSP 原则——Liskov Substitution Principle）让系统具有极强的可替换性和可测试性。

通过依赖注入，我们在开发阶段可以用 Mock Provider 快速测试业务逻辑，在演示阶段切换到 Real Provider 展示真实效果。这种设计让系统的灵活性大大提升，并且完全符合"开闭原则"——对扩展开放，对修改关闭。

这是在结对项目的"花见小路"中就开始体会到的道理——我们在 T2 和 T3 中因为缺少合理的接口抽象，导致代码无法复用。这个教训在团队项目中得到了充分的改进。

3. 实现阶段 —— 前后端分离下的契约先行

学到的知识点是：在前后端分离的开发模式下，必须先约定接口契约，然后再分头实现。

我们写下了 API 文档，明确了每个接口的请求方法、参数、响应格式和错误码，前后端的联调效率得到了很大的提升。

4. 测试阶段 —— 分层测试策略

在实践中，我们不是只写一种测试，而是根据不同的测试目标写多种测试：

• 单元测试：测试单个函数/方法的逻辑
• 路由测试：测试 API 端点的正确性
• 服务测试：测试业务逻辑的正确性（Mock 掉外部依赖如 LLM）
• 集成测试：测试全链路是否跑通

学到的知识点是：测试是有成本的，需要在覆盖率和开发效率之间找平衡。 优先保证核心业务逻辑和高风险模块的测试覆盖，对于简单的 CRUD 接口可以通过路由测试一笔带过。

5. 发布阶段 —— 容器化部署与环境一致性

学到的知识点是：环境一致性是发布阶段最关键的问题。 开发环境、测试环境、生产环境之间的差异是导致发布问题的主要原因。

通过 docker 的统一配置，我们能够保证每次部署的环境都是一致的，避免了"在我电脑上能跑"的经典问题。

6. 维护阶段 —— 技术债务的识别与管理

学到的知识点是：技术债务是不可避免的，关键是要有意识地识别和管理它。

1. 记录债务：知道哪些地方是"快但脏"的写法，未来需要偿还。

2. 评估偿还时机：不是所有债务都要立刻还。如果一个模块不会再改动，保持现状反而比重构更经济。但如果一个模块是后续开发的基础，那尽早重构才是明智的。

3. 防止债务蔓延：在添加新功能时，不要继续在"脏代码"上叠加新的脏代码。

这个知识点让我认识到：技术债务管理不是"要不要有债务"的问题，而是"什么时候、以什么方式偿还"的问题。

三、个人项目 / 结对编程 / 团队项目的理解与心得

团队项目（心运岛 / Nexus — AI 情绪陪伴应用）

心得： 团队项目是整个学期收获最大的部分。以下几个方面值得特别记录：

1. 分工与协作的现实

在课程项目中，团队分工从来不是"5 个人平分 5 个模块"那么简单。实际上，不同模块的难度不同、不同成员的能力不同、每个人能投入的时间也不同。我们的做法是让每个成员负责一个或两个核心模块（如我主要负责后端 LLM 生成链路和测试），但所有人在关键节点（如联调、Bug 修复）上需要互相支持。

2. "足够好"的工程

在课程有限的时间内，我们不可能做到教科书式的"完美软件工程"。我们需要做出很多妥协：

• 测试覆盖率没有 100%，但核心逻辑全覆盖
• 文档没有完全写完，但关键决策和 API 契约有记录

我认为这种"在约束条件下做出合理权衡"的能力，本身就是软件工程最重要的能力之一。

四、总结

从学期初阅读《构建之法》时的纸上谈兵，到结课时的实践反思，这一趟"做中学"的旅程让我对软件工程有了全新的认识。

• 我学会了 拥抱变化：需求会变、团队会变、技术方案也会变，好的工程实践能帮你在变化中保持方向感。
• 我学会了 知所取舍：在有限的时间和资源下，做出合理的权衡往往比追求"完美方案"更重要。
• 我学会了 善用工具：AI 工具不是对手，而是放大器。问题不是"要不要用 AI"，而是"怎么用好 AI"。

软件工程是在真实约束下做出合理决策的能力。这也是我在这个学期中最大的收获。