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

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

项目	内容
这个作业属于哪个课程	2026 年春季软件工程 - 北京航空航天大学
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	参与一次较完整的软件工程实践，理解从需求分析、设计实现到测试发布、维护迭代的全过程，并在结对与团队协作中提升工程能力
这个作业在哪个具体方面帮助我实现目标	通过回顾学期初提出的问题，总结一个学期中在个人作业、结对项目和团队项目中的实践收获，重新理解软件工程中的流程、协作、质量与责任

学期初的阅读和提问博客：[I.1] 个人作业：阅读和提问

一、学期初问题回顾

在本学期完成第一篇个人博客时，我提出了五个问题。现在回头看，这些问题本身并没有一个绝对固定的答案，但经过个人作业、结对项目 “花见小路” 的开发，以及团队项目 “启元知微——面向北航学生的一体化智能学习平台” 的 Alpha、Beta 两阶段开发，我对这些问题的理解已经不再停留在抽象判断上，而是逐渐有了实践中的依据。

1. 在 AI 时代，软件工程师的“刻意练习”是否应该转向学会高效与 AI 沟通？

我现在的理解是：AI 时代的刻意练习确实应该发生变化，但它并不是从练习编程变成只练习提示词，而是从单纯追求手写代码的熟练度，转向更综合的工程判断能力。

在结对项目 “花见小路” 中，我很明显地感受到，AI 对局部代码生成、函数补全、测试样例构造和已有代码解释确实有帮助。对于一些边界清楚、目标明确的任务，只要我能把输入输出、约束条件和预期行为描述清楚，AI 往往可以很快给出一个可用的初稿。相比完全手写，它确实节省了许多重复劳动。

但实践也让我意识到，AI 并不会自动保证代码是正确的，更不会自动保证设计是合理的。比如在本次结对作业中，真正重要的并不是写出几个函数，而是要准确理解游戏规则、回合流程、计分逻辑和策略选择。如果我自己没有理解清楚，AI 生成得越快，错误也可能扩散得越快。到了团队项目开发阶段，这种感受更明显。一个智能知识服务平台并不是把前端页面、后端接口、知识库检索和问答逻辑简单拼起来就可以了。我们必须判断模块边界是否清晰，接口是否稳定，用户提问后系统能否给出可信回答，检索不到信息时是否应该拒答或提示，而不是编造一个看似流畅的答案。

所以我现在认为，AI 时代仍然需要刻意练习，只是练习重点变得更高层了：一是练习把需求讲清楚，二是练习拆分任务和设计接口，三是练习审查 AI 生成内容是否真的符合要求，四是练习用测试和实际运行结果验证代码。基础代码能力仍然重要，因为如果看不懂代码，就谈不上判断它是否正确；但仅仅会写代码已经不够了，更重要的是能对代码、需求和系统整体负责。

2. 现代软件开发是不是正在走向一种“没有明显阶段边界”的模型？

学期初我怀疑，现代软件开发可能已经不是严格的 “需求 - 设计 - 实现 - 测试 - 发布” 串行过程。现在我基本确认：现实中的软件开发确实很难把阶段完全切开，但这些阶段仍然有价值。

在团队项目 “启元知微” 的开发中，我们并不是先把所有需求写完，再一次性完成设计，然后才开始实现。实际情况是，很多需求是在原型跑起来之后才变得清楚的。例如，一开始我们可以很粗略的说为北航学生提供更便利和舒适的学习体验，但只有当用户真的开始输入问题、查看回答、尝试检索资料时，我们才会发现：用户到底更关心课程考纲信息、相关知识点的 “航味” 解答，还是具体的往年题练习；软件更应该像一个伴读助教，还是一个严格判题的教书先生；当知识库中没有充分依据时，系统应该如何反馈——这些都不是在项目开始时凭空想清楚的。

Alpha 阶段的重点是让核心闭环先跑通，让用户能够完成一次完整的使用流程。Beta 阶段则更多是在真实反馈基础上调整体验、补充测试、修复问题、完善文档和发布流程。这个过程更像一个不断循环的系统：实现会反过来暴露需求问题，测试会反过来推动设计修改，发布会反过来检验前面所有环节是否真的可靠。

但是，我也不认为因此就可以抛弃这些阶段。需求、设计、实现、测试、发布、维护并不一定是严格按顺序排列的六个时间段，而更像是六种不同的思考视角。我们可以在实现时重新审视需求，也可以在测试时发现设计缺陷，但前提是团队知道自己此刻在解决什么问题。阶段的意义不在于把开发过程切死，而在于帮助团队在快速迭代中不迷失方向。

3. 面对大量用户反馈，团队到底应该“听用户的话”，还是“读懂用户真正想要的东西”？

经过团队项目后，我对这个问题的体会更加具体：用户反馈必须重视，但不能简单照字面执行。真正重要的是把用户原话转化成可分析、可验证、可落地的需求。

以我们的团队项目为例，“启元知微” 的目标用户是北航学生。这个群体的需求表面上可能很分散：有人希望查课程资料，有人希望获得一手的考试题信息，有人希望平台相比于主流模型回答得更快，有人希望内容更全，还有人可能只是觉得界面用着不够顺手（比如同学反馈提出：界面不如洛谷好看）。如果团队只是把所有反馈原样加入待办列表，最后一定会变成需求堆积，甚至互相冲突。

我逐渐意识到，用户说出来的往往是表层表达，背后才是真正的需求。例如用户说 “回答不好用”，这句话本身还不能直接指导开发。它可能意味着检索结果不准确，也可能意味着回答太长、来源不清楚、页面交互不方便，或者用户期待的是办事流程而不是概念解释。团队需要继续追问：用户在什么场景下提出这个问题？他原本想完成什么任务？当前系统在哪一步阻碍了他？这个问题是个别偏好，还是多个用户都会遇到的共性问题？

所以我现在对以用户为中心的理解，不是用户说什么就做什么，而是尊重用户的真实处境，识别用户反馈背后的任务、痛点和约束。用户提供的是问题线索，团队需要把线索加工成工程需求，再通过设计、实现和测试去验证它是否真正改善了体验。

4. AI 工具越来越强之后，书里这些经典团队模式还会长期成立吗？

我现在的回答是：经典团队模式不会完全失效，但它们需要被重新理解。团队组织方式的核心不是固定头衔，而是让责任、沟通和集成更有效。

在团队项目中，AI 和自动化工具确实提高了个人完成局部工作的效率。很多文档整理、代码解释、测试样例设计、接口草稿生成，都可以借助工具更快完成。但工具越强，我越感觉到团队协作本身并不会消失，反而会变得更重要。因为软件最终不是许多个孤立模块的堆叠，而是一个需要稳定集成、统一体验和持续维护的整体。

在 “启元知微” 项目的开发过程中，前端、后端、知识库、智能问答、测试、文档和发布之间都存在依赖关系。某位同学可以借助 AI 快速完成一个模块，但如果接口没有约定好、数据格式没有统一、异常情况没有讨论清楚，最终集成时仍然会出现问题。AI 可以降低个人产出成本，却不能自动降低团队协调成本。

因此，我现在更倾向于把团队模式理解成一种动态协作机制。对于低风险、边界清楚的任务，可以让成员独立推进，再通过代码审查和测试合并；对于架构设计、核心接口、发布标准这类影响全局的任务，就必须集中讨论，明确责任人。未来团队可能会更小、更灵活，但并不意味着不需要分工。相反，越是快速迭代，越需要清楚地知道每个模块由谁负责、谁参与讨论、谁最终拍板、出了问题谁来修复。

5. 在现实团队里，怎么避免“承担很少风险的人，却拥有很大的决策权”？

这个问题是我学期初最关心的问题之一。经过团队项目后，我的理解是：只写清楚角色还不够，责任划分必须和实际决策权、交付义务、验收标准结合起来。

在团队项目中，如果一个成员只是提出想法，却不参与实现、不承担测试、不负责后续维护，那么这个想法即使听起来很好，也不能直接变成项目决策。因为每一个功能都会带来成本：开发成本、集成成本、测试成本、维护成本，以及可能破坏原有结构的风险。真正负责实现的人，必须有机会参与需求取舍和技术方案讨论，否则就很容易出现“别人决定方向，自己承担后果”的情况。

我也认识到，责任并不只是意味着这段代码是谁写的。更完整的责任应该包括：这个模块为什么这样设计，如何验证它是正确的，它和其他模块如何交互，出现问题后谁来定位，未来别人如何继续维护。只有当一个人愿意承担这些后果时，他的意见才应该在决策中具有相应的权重。

所以我现在认为，RASCI 这类模型的价值不只是写在文档里，而是提醒团队在每个关键事项上明确：谁最终负责，谁可以做决定，谁需要参与讨论，谁只需要被同步。真正有效的责任划分，应该让负责的人拥有相应的话语权，也让拥有话语权的人承担相应后果。

二、仍未完全解决的问题与新问题

经过一个学期，原来的五个问题都有了阶段性答案，但也产生了一些新的问题。

第一个问题是：AI 参与开发后，代码责任应该如何界定？

现在我们可以要求成员理解自己提交的代码，也可以通过测试和代码审查保证质量。但如果某段代码主要由 AI 生成，人工只做了少量修改，那么出现问题时，责任仍然必须由提交者承担。可是如何证明提交者真正理解了代码，如何在团队贡献评价中区分 “生成、理解、修改、验证” 的不同价值，仍然不是很容易回答。

第二个问题是：智能知识服务平台的可信应该如何测试？

传统功能测试可以检查按钮能不能点击、接口能不能返回、页面能不能渲染，但对于我们所设计的智能问答平台，更难测试的是回答是否可靠、是否有依据、是否符合用户真实需求。以往年题模块为例，鉴于时间和体量的限制，部分简答题答案由 AI 助教生成，如何设计更系统的评测指标，是我们整个团队在项目后仍然觉得值得继续思考的问题。

第三个问题是：团队项目中如何在快速迭代和长期可维护之间保持平衡？

课程项目时间有限，很多时候为了赶上 Alpha 或 Beta 发布，我们会优先选择最快能跑通的方案。但软件工程又不断提醒我们，短期方便可能会变成长期负担。如何判断一个地方应该先快速实现，还是必须提前做好抽象和文档，是我认为自己还需要继续训练的工程判断能力。

三、软件生命周期六个阶段中学到的知识点

阶段	我学到的一个知识点	结合项目的理解
需求	需求要能够被验证	在团队项目开发中，经过前期调研，做出一个 “面向北航学生的智能知识服务平台” 只是目标，并不是可验收需求。更具体的需求应该说明用户在什么场景下提出什么问题，系统应该如何检索、如何回答、没有依据时如何提示。只有能被验证的需求，才真正能指导开发
设计	模块边界决定后续协作成本	在结对编程中，如果没有事先做清晰的规划与设计，把规则判断、状态更新和策略选择等混在一起，后续调试将会变得非常困难；团队开发也是如此，前端交互、后端接口、RAG 专用模块这三大仓库主线既需要分清边界，也需要做好交互。良好的设计不是画几张复杂架构图自欺欺人，而是为了纲举目张、提纲挈领，让开发过程有法可依
实现	先跑通主流程，再逐步扩展	团队项目让我认识到，多个孤立功能完成并不等于产品完成，有时候写一个模块容易，但多个模块的协同难度却会成几何倍数增加。Alpha 阶段最重要的是先形成可运行闭环，让用户能完整体验一次核心流程；Beta 阶段再逐步补充细节、优化体验和修复问题，尽可能把用户使用中遇到的所有 bug 都做兜底保护
测试	测试是对需求和规则的证据化表达	在结对项目中，很多规则细节仅靠阅读代码并不可靠，因为我们的认知和想象力都是有限的，很多 bug 必须要通过样例和边界测试才能逐渐暴露；在团队开发中亦然如此，很多问题在设计之初是很难被考虑全面的，需要通过多名同学反复做接口测试、场景测试和人工体验测试共同验证系统质量，测试不是最后补救，而是开发过程中的证据
发布	发布需要明确出口条件	发布不是把代码部署到服务器上就算结束，而是要确认核心功能无 bug、各类突发情况有应对措施、文档和使用说明同步、尽可能全面的考虑了用户使用的各种状况，以及团队成员知道当前版本的状态。如果只是感觉 “貌似没什么问题了” 就草草发布，后续也会出很多问题，也不是一个合格的开发者应有的情怀
维护	可维护性来自持续留下线索	代码段命名、模块划分、前后端接口约定、测试样例、必要的注释、Issue 记录和文档说明，都是给未来维护者留下的重要线索。维护不是项目结束后的事情，而是在第一次设计、第一次 push / merge、第一次完成 bug 修复时就早已开始，并且会伴随整个项目完整的生命周期，一直进行下去

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

1. 结对项目：协作的核心是共享问题模型

结对项目让我比较真实地体验了结对编程的价值：两个人一起做题，并不是简单地把工作量平分，也不是一个人写代码、另一个人在旁边看。更重要的是，两个人在交流中不断校准对规则、状态和策略的理解。

在这个项目中，我感受到领航员和驾驶员关注点不同。驾驶员更容易沉浸在当前代码实现中，关心这一行怎么写、这个函数怎么调通；领航员则更容易从整体上检查规则是否遗漏、模块是否混乱、当前实现会不会影响后续扩展。角色互换之后，我也能更明显地看到，当自己负责写代码时，来自搭档的及时提醒可以减少很多返工。

但结对项目也让我看到，结对不能替代测试。两个人如果对同一个规则都理解错了，那么一起看代码也可能一起遗漏错误。真正可靠的方式应该是讨论、实现、测试、复审结合起来。结对编程最大的意义不是保证不出错，而是让问题暴露得更早，让隐性的理解差异尽快被说出来，这是未来我在敏捷开发与结对编程中弥足珍贵的经验。

2. 团队开发：软件工程首先是集成与责任

团队项目给我的冲击比结对项目更大。因为结对项目中，两个人的沟通成本还比较低，很多问题可以随时讨论；但到了团队项目，前端、后端、知识库、问答逻辑、测试、文档和发布都需要协同，任何一个模块的变化都可能影响其他人。

我们的交付成果作为一款智能知识服务平台，并不是一个单纯展示页面的项目。它背后涉及真实用户需求、知识内容组织、检索与回答逻辑、界面交互、系统稳定性和结果可信度。Alpha 阶段让我认识到，先跑通核心链路非常重要。只有当用户能真正提出问题、获得回答、完成一次完整使用过程时，项目才从功能集合变成了产品雏形；Beta 阶段则让我认识到，项目后期真正消耗时间的往往不是新增功能，而是修复细节、统一体验、补齐测试、完善文档和准备发布。

团队项目也让我更理解责任的含义。一个模块不是写完就结束，而是要能够被集成、被测试、被解释、被维护。团队中的每个成员都不能只关心自己局部代码能不能运行，还要关心它是否符合接口约定，是否会影响整体流程，是否给其他人留下了足够清楚的信息。软件工程的很多流程，比如 Issue、分支管理、代码审查、测试和发布检查，本质上都是为了让团队在多人协作中仍然保持可控。

转会环节也让我意识到，团队不是一开始定下来就永远稳定不变的。团队成员临时有事，任务临时变更都会带来上下文丢失、任务重新分配和沟通成本上升。这个时候，文档、任务记录、接口约定和责任边界就显得非常重要。如果所有信息都只存在于某几个人的脑子里，一旦成员变动，项目就会受到很大影响。好的工程过程，应该能让新人尽快理解项目，也能让成员变化不至于破坏整体进度。

五、课程总结

在学期初，我对软件工程的理解还比较接近于开发软件时需要遵守的一套流程和行业规范。经过一个学期的锤炼之后，我更愿意把软件工程理解为：在有限时间、有限人力和不完整信息下，让软件开发过程尽可能可沟通、可验证、可追踪、可维护的一套方法论。

具体而言，需求分析不是把想法写得更长，而是找到真实用户、真实场景和可验收标准；设计不是追求复杂架构，而是控制模块之间的依赖和变化影响；实现不是单纯堆代码，而是持续保持一个可运行、可集成的主干；测试不是项目末尾才开始找错，而是用证据保护需求和规则；发布不是简单部署，而是达到团队共同认可的出口条件；维护也不是在代码完成之后才开始，而是从第一次命名、第一次划分模块、第一次写测试时就已经出现。

这个学期最大的收获，是我开始用工程的眼光看待开发问题。以前我可能更关心一些面上的东西，比如 “这个功能能不能做出来” 这类问题；而现在我会下意识地去考虑，一个模块被设计出来，“它解决了什么用户问题？它的成本是多少？它会影响哪些模块？有什么证据证明它是正确的？以后谁来维护它”，这种思考方式，比单纯掌握某个框架或写出某段代码更重要。

一路走来，我逐渐明白，软件工程并不是束缚创造力的流程，而是在复杂协作和不确定需求中保护项目的一种能力。它让个人开发不只依赖直觉，让结对协作不只依赖默契，让团队项目不只依赖热情。经过这一学期，我对软件工程的认识从遥远的抽象理论概念，变成了自己亲身经历过的开发、沟通、取舍和复盘体验，这就是我在这门课中最重要的收获。

---