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

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

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标	学习专业团队的软件开发流程，提升团队协作能力和项目管理能力；锻炼软件开发技术，为职业发展打下坚实基础；培养解决复杂工程问题的能力，提高技术壁垒和专业性。
这个作业在哪个具体方面帮助我实现目标	这个作业迫使我回头检查一学期前提出的问题：哪些观点被实践验证了，哪些判断过于绝对，哪些问题仍然没有解决。通过这种回顾，我把零散的个人项目、结对编程和团队项目经历重新整理为对软件工程方法的理解。

---

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

在学期初的 I.1 阅读与提问 作业中，我围绕《构建之法》提出了五个问题。经过一个学期的个人项目、结对项目和团队项目实践后，我对这些问题有了新的理解。

问题一：在 vibe coding 时代，软件开发的工作量和质量的衡量标准是否还与书中的四个因素一致？

我现在的回答是：四个因素仍然有效，但它们的度量对象需要重新解释。

学期初我认为，AI 能快速生成大量代码，所以“项目大小、花费时间、质量、是否按时交付”这些标准的基础已经被动摇。经过实际开发后，我发现这个判断有些过于依赖“写代码”这一环节。AI 确实压缩了从想法到代码初稿的时间，但它没有消除软件开发的全部成本。需求澄清、接口设计、代码阅读、调试、测试、集成、发布和维护仍然需要人负责。

因此，“项目/任务有多大”不应该再简单等同于代码行数，而更应该看问题复杂度、依赖关系、边界条件和验证成本。“花了多少时间”也不能只统计敲代码的时间，还要统计理解 AI 生成代码、修改提示词、调试异常、编写测试、做 Code Review 和集成发布的时间。“质量如何”更不能只看代码能不能跑，而要看它是否可维护、可测试、可扩展，是否符合团队规范。至于“是否按时交付”，在 AI 时代反而更重要，因为更快的代码生成会让人低估后续集成和验证的时间。

这个问题主要是通过个人项目和团队项目中的实践弄清楚的。个人项目中，我能明显感受到工具可以加速实现，但如果没有自己理解算法、边界条件和测试数据，生成的代码很容易停留在“看起来完成”的状态。团队项目中，AI 生成的代码还要和他人的模块对接，接口约定、代码风格和异常处理都需要人工把关。所以 PSP 的核心价值没有消失，它只是从“记录我写了多少代码”转向“记录我为一个可靠交付付出了哪些工程成本”。

问题二：AI 辅助编程提供了成倍的生产力提升，是否还需要进行功能分析？

我现在的回答是：更需要进行功能分析。

学期初我认为，AI 降低了编码成本，所以团队可以“全都要”，不再需要像书中那样做取舍。经过项目实践后，我发现这个想法忽略了软件产品的真实成本。一个功能从“代码能生成”到“用户愿意使用”，中间还有需求解释、交互设计、数据结构、权限边界、异常处理、测试用例、文档说明、发布验证和后续维护。AI 降低的是局部实现成本，不是完整产品成本。

在团队项目中，功能如果没有经过优先级分析，很容易变成范围膨胀。看起来每个功能都可以做，但每个功能都会带来新的 Bug、新的测试场景和新的沟通成本。尤其是多个成员并行开发时，一个边缘功能也可能占用接口、影响数据结构，甚至拖慢主流程。因此，功能分析的意义不是为了“少写代码”，而是为了回答“什么功能真正创造价值，什么功能只是制造复杂度”。

这个问题是通过需求讨论、任务排期和版本发布逐渐弄清楚的。AI 让我们能更快地做出原型，但它不能替代对目标用户、核心场景和产品定位的判断。功能分析依然有现代价值，而且在 AI 编程环境下更像是一种防止项目失控的工程纪律。

问题三：在企业普遍压榨 PUA 员工的今日，如何识别并避免假团队的出现？

我现在的回答是：假团队可以通过“目标是否共享、信息是否透明、责任是否可追踪、成员是否互相信任”来识别，也可以通过过程设计来尽量避免。

学期初我更关注职场中的压榨、表演式加班和形式主义汇报，所以把“假团队”看得比较悲观。经过课程项目后，我认为假团队并不是一个抽象的道德标签，而是可以从日常协作中观察出来的状态。一个团队如果只在会议上说合作，实际任务却互相甩锅；如果每个人只关心个人评分，没人关心产品质量；如果信息只在少数人手里流转，其他人只能被动等待；如果成员遇到问题不敢暴露风险，只能用好看的汇报掩盖进度，那么这个团队就已经在向假团队滑落。

避免假团队不能只靠喊口号。更有效的方法是把协作变成可观察的过程：用 Issue 或任务板记录每个任务的负责人、截止时间和验收标准；用 Pull Request 和 Code Review 让代码变化可追踪；用例会同步真实阻塞，而不是只报喜；用阶段性 Demo 和测试结果评价进展，而不是只看口头描述。团队内部也需要形成一种共识：暴露问题不是丢脸，隐藏问题才会伤害团队。

这个问题主要是通过团队项目和转会环节体会到的。成员变化会放大信息断层，如果没有文档、任务板、代码规范和沟通记录，新成员很难接上已有工作。真正的团队不是每个人都很忙，而是每个人都知道共同目标是什么，也知道自己的工作如何影响别人。

问题四：在 RASCI 模型中，为什么每个环节有且只有一个 R？

我现在的回答是：我对“有且只有一个 R”的理解发生了变化。它的重点不是否认多人协作，而是避免“人人负责等于无人负责”。

学期初我觉得这个说法和结对编程、多人协作有冲突。比如前后端共同开发一个功能，或者两个人结对完成一个模块，似乎都在承担 Responsible 的角色。后来我在项目中发现，RASCI 的关键不是把所有参与者硬分成高低等级，而是让每个具体环节都有明确的完成责任。

如果任务粒度太粗，“开发某个系统”当然可能有多个 R。但把它拆细后，就可以更清楚地分配责任：接口文档由谁最终维护，后端接口由谁保证可用，前端页面由谁负责验收，测试用例由谁补齐，发布前检查由谁确认。其他人可以提供支持、咨询或评审，但必须有人对这个环节的关闭负责。

结对编程也不是对 RASCI 的反例。驾驶员和领航员共同参与实现，但在一个具体时段内，通常仍然可以明确谁正在修改代码、谁负责即时审查、谁负责合并提交。实际项目中，也可以允许“双人负责”，但前提是团队明确这不是互相稀释责任，而是共同承担同一个交付结果。我的困惑不完全是笔误问题，而是我原来把“共同协作”和“责任闭环”混在了一起。

问题五：在团队中，该如何管理才能防止 P2、P3、P4、P5 这类人的出现？

我现在的回答是：不能指望完全消灭这类现象，但可以通过透明的任务机制和以价值为导向的评价方式减少它们出现的空间。

学期初我把这个问题和职场绩效压力联系在一起，担心形式主义会让真正做事的人吃亏。经过团队项目后，我更具体地理解了 P2 到 P5 的出现条件。P2 不做事，往往发生在任务边界模糊、无人追踪进展的时候；P3 不让别人做事，往往发生在关键资源或关键信息被少数人占有的时候；P4 做假的事和 P5 假装做事，则常常发生在评价只看汇报材料、不看实际产出的时候。

因此，管理上最重要的是让真实贡献可见。任务要有明确验收标准，代码要通过提交记录和评审记录体现，测试要有可复现结果，需求变更要有讨论过程。这样一来，“谁真正推动了项目”会更容易被看见，“谁只是在汇报里包装自己”也更难长期隐藏。

对个人来说，坚持做 P1 也不是简单地埋头苦干。更现实的做法是把自己的工作沉淀成可验证的产物：代码提交、设计文档、测试报告、问题记录、复盘总结。这样既保护自己的劳动成果，也能让团队围绕事实讨论，而不是围绕表演讨论。这个问题仍然有现实复杂性，但至少我不再只把它看作道德问题，而是看作激励机制、流程透明度和工程文化共同作用的结果。

二、原来仍不明白的问题

经过一个学期的实践，我原来的五个问题大多已经有了阶段性答案，但仍有两个地方没有完全想清楚。

第一，AI 编程时代的工程度量还需要更成熟的方法。现在我能确认代码行数和纯编码时间不再可靠，但还没有形成一套足够清晰的替代指标。也许可以统计需求复杂度、测试覆盖、缺陷密度、返工次数、评审意见数量、发布后问题数量等，但这些指标之间如何权衡，仍然需要更多项目经验。

第二，假团队和 P2/P3/P4/P5 的问题，在课程项目中可以靠较透明的过程缓解，但在真实企业里会受到绩效制度、上下级权力关系和组织文化影响。工程流程可以减少问题，却不一定能从根本上消除问题。如何在复杂组织中既保护自己，又推动团队保持真实产出，是我还需要继续观察和学习的问题。

三、新产生的问题

经过这学期的项目实践，我又产生了几个新的问题：

1. 在 AI 参与开发越来越深的情况下，代码责任应如何划分？如果一个模块的大部分代码由 AI 生成，但由人提交并发布，那么质量问题、版权问题和安全问题究竟应该由谁承担？
2. 团队项目中如果发生人员流动或转会，怎样的文档和交接机制才算足够？写太少会造成信息断层，写太多又会消耗开发时间，这个平衡点如何判断？
3. Code Review 中如何区分“风格偏好”和“质量问题”？如果评审意见过细，会拖慢开发；如果评审过松，又可能埋下维护成本。团队应该如何建立一致的评审标准？

四、各阶段学到的知识点

软件工程覆盖需求、设计、实现、测试、发布、维护六个阶段。这个学期最大的体会是，每个阶段都有自己的核心知识点，而且任何一个阶段偷懒，都会在后面以更高成本返还。

需求阶段：需求不是愿望清单，而是价值排序

在需求阶段，我学到最重要的知识点是功能优先级分析。用户、开发者和管理者都会提出很多想法，但不是所有想法都应该进入当前版本。真正有效的需求分析要回答三个问题：目标用户是谁，核心痛点是什么，当前版本最小可交付价值是什么。

以前我容易把“能做”理解为“应该做”。现在我意识到，需求阶段必须主动做取舍。NABCD、功能象限、用户故事和验收标准的价值都在于帮助团队把模糊想法转化为可讨论、可排序、可验收的任务。

设计阶段：好的设计是让协作边界清楚

在设计阶段，我学到的知识点是接口契约和模块边界。设计不是画一张好看的图，而是让团队成员知道彼此如何协作：数据结构是什么，接口输入输出是什么，异常如何处理，模块之间依赖关系如何控制。

团队项目中，如果设计阶段没有把边界说清楚，实现阶段就会不断返工。尤其是多人并行开发时，接口文档、UML 图、数据库结构和 API 约定都不是形式主义，它们是降低沟通成本的工具。

实现阶段：版本控制和小步提交比一次性完成更可靠

在实现阶段，我学到的知识点是小步迭代和版本控制。个人写代码时，可以靠记忆维护上下文；团队开发时，必须靠 Git、分支、提交信息、PR 和 Code Review 来维护上下文。

我以前更关注“功能最后能不能跑”，现在更关注“代码是怎样一步一步变成现在这个样子的”。清晰的提交记录和较小的变更范围能让 Bug 更容易定位，也能让队友更容易评审。实现阶段的工程质量，很多时候就体现在这些看似细小的过程里。

测试阶段：测试不是证明没问题，而是尽早暴露问题

在测试阶段，我学到的知识点是测试分层。单元测试适合验证核心逻辑，集成测试适合验证模块协作，场景测试适合验证用户流程，回归测试适合防止旧功能被新改动破坏。

这学期的实践让我认识到，测试不是项目后期才开始的补救工作。越早引入测试，越容易发现需求和设计中的模糊点。很多 Bug 表面上是代码问题，本质上是需求边界、接口约定或异常场景没有提前说清楚。

发布阶段：发布需要检查清单和预演

在发布阶段，我学到的知识点是 Release Checklist。发布不是把代码合到主分支就结束，而是要检查构建环境、配置文件、依赖版本、数据迁移、资源路径、部署脚本、回滚方案和用户可见说明。

Alpha 或 Beta 发布前，哪怕功能已经开发完成，如果没有完整走一遍构建、部署和验收流程，仍然可能在最后时刻暴露问题。发布检查清单的价值就在于把“我以为没问题”变成“我已经逐项确认”。

维护阶段：维护不是修 Bug，而是持续响应真实反馈

在维护阶段，我学到的知识点是用户反馈驱动的迭代。产品发布后，真实用户会用出许多开发者没有想到的路径。维护阶段不仅要修复缺陷，还要判断哪些反馈代表真实需求，哪些问题应该进入后续迭代。

维护也要求团队保留清楚的 Issue 记录和决策记录。否则一段时间后，团队很难判断某个设计为什么这样做，也很难评估一个修改会影响哪些模块。维护阶段考验的不是短期冲刺能力，而是项目能否长期保持可理解和可演进。

五、个人项目、结对编程、团队项目的心得体会

个人项目

个人项目让我体会到独立解决问题的重要性。没有队友可以依赖时，需求理解、代码实现、测试验证和调试都要自己负责。这个过程训练了我对问题的完整闭环能力，也让我意识到 PSP 记录的价值：估计时间、实际时间、缺陷记录和复盘并不是为了填表，而是为了让自己看见真实的开发习惯。

个人项目也让我认识到，工具只能提高效率，不能替代理解。无论是使用 AI 辅助，还是查阅资料，最后仍然需要我自己判断代码是否正确、边界是否覆盖、结果是否可信。

结对编程

结对编程让我重新理解了“沟通”在软件开发中的价值。两个人一起写代码，并不是把一个人的效率简单乘以二，而是通过实时讨论减少盲点。驾驶员关注当下代码，领航员关注整体方向、边界条件和潜在风险，这种分工能让问题更早暴露。

当然，结对也会产生分歧。我的体会是，分歧本身不是坏事，只要讨论围绕事实和目标展开，就能变成改进方案的机会。好的结对不是一个人指挥另一个人，也不是两个人各写各的，而是在共同上下文中快速试错、快速校正。

团队项目

团队项目是这门课里最接近真实软件工程的部分。个人能力很重要，但团队项目的成败更多取决于协作机制：任务是否拆得清楚，接口是否约定明确，进度是否透明，风险是否及时暴露，代码是否有人评审，发布前是否有人负责检查。

我尤其体会到项目管理不是“催进度”，而是持续维护团队的共同认知。任务板、例会、PR、文档和复盘的作用，都是让信息不只停留在某个人脑子里。转会环节也让我看到，人员变化对团队上下文是一种压力测试。如果一个项目只能靠口头记忆维持，新成员加入时就会非常痛苦；如果项目有清晰的文档和记录，交接成本就会低很多。

团队项目还让我对“做好”和“做完”的差别有了更深理解。Alpha 阶段把核心功能做出来，只是证明方向可行；Beta 阶段继续打磨体验、修复问题、补齐文档和完善发布流程，才更接近一个可交付的软件产品。软件工程的价值就在于让团队不只靠热情冲刺，而是靠方法把产品稳定地推向完成。

六、总结

一个学期下来，我对软件工程的理解从“写代码的方法”逐渐转向“组织复杂工作的方式”。这门课让我看到，需求分析、设计、实现、测试、发布、维护并不是课本上的顺序名词，而是一个项目真实运转时不断互相影响的环节。

我最明显的变化是，不再把工程流程看成额外负担。PSP、功能分析、RASCI、Issue、Code Review、测试、发布检查清单、复盘，这些工具的目的都不是制造形式，而是降低不确定性，让团队在复杂环境中仍然能做出可靠的软件。

回头看学期初提出的五个问题，我当时的语气更接近质疑：AI 是否会让传统软件工程失效，功能分析是否还需要，团队管理是否会被现实职场吞没。现在我的答案更谨慎：新工具会改变局部工作方式，但不会消除工程问题本身；现实组织会带来很多复杂性，但透明的流程和真实的产出仍然有价值。软件工程不是一套僵硬的教条，而是一种经过实践检验的思维方式，它教会我在不确定性中拆解问题、验证假设、协作交付，并持续改进。