跳转至

现代软件工程课程个人总结（期末）

ZGCA《现代软件工程》课程 个人博客作业 #3

1. 学期初的问题，现在能自己回答了吗？

结论：大部分问题在实践中找到了答案，但答案比预期更加"工程化"和"务实"。

1.1 Q1：在"AI原生"时代，软件工程的边界与核心实践应如何演进？

现在的理解： 经过一学期的实践，我认识到AI原生时代的软件工程核心并没有被颠覆，而是被**延展**了。

在 pet-focus 项目中，我们大量使用 GitHub Copilot 进行代码生成，但发现传统软件工程的核心原则——模块化、接口设计、版本控制、CI/CD——依然是项目可维护性的基石。AI 改变的是"实现速度"，而非"架构质量"的要求。

对于 Prompt 和 AI 行为的版本控制，目前我们的实践是将关键的系统提示词作为配置文件纳入版本管理。至于"AI测试"体系，我认为当前更务实的做法是：自动化烟雾测试 + 真实用户反馈闭环，而非追求完美的AI行为测试覆盖。

1.2 Q2：敏捷开发方法如何适应目标不明确、高度探索性的AI科研项目？

现在的理解： 敏捷的**精神**比**形式**更重要。

在团队项目中，我们经历了从 Alpha 到 Beta 的迭代。最大的收获是：Sprint 的目标可以是"验证一个假设"或"探索一条技术路径"，而不必是传统意义上的"交付功能"。关键是保持**短周期反馈**和**持续复盘**的节奏。

对于"失败的实验也是有价值的产出"这一点，我们在项目中确实遇到过——某些技术方案被验证不可行后，及时调整方向反而加速了整体进度。这让我理解到，敏捷的核心是**快速学习和适应**，而非机械地完成预定功能。

1.3 Q3：人类-AI结对编程的最佳实践是什么？

现在的理解： 这是我这学期体会最深的一点。

在项目开发中，我逐渐摸索出一套与 AI 协作的模式： - 人负责架构和设计决策，AI 负责实现细节 - 人负责代码审查和质量把控，AI 负责快速原型 - 人负责 context 管理，确保 AI 理解项目的整体结构

最关键的教训是：不能沦为"代码验收员"。AI 生成的代码需要**主动理解和重构**，否则技术债务会快速累积。在 pet-focus 项目中，我们在 Alpha 阶段进行了一次大规模重构（alpha-refactor 分支），正是因为早期过于依赖 AI 生成而缺乏统一的架构设计。

1.4 Q4：具身智能软件的测试难题与质量保证策略？

现在的理解： 这个问题在本学期的项目中没有直接涉及，因为 pet-focus 是一个桌面/移动应用而非具身智能系统。

但通过课程学习，我理解到仿真环境的重要性，以及"Sim-to-Real"迁移的核心挑战。这个问题仍需在未来的研究中继续探索。

1.5 Q5：如何将AI研究原型优雅地工程化为产品？

现在的理解： 这学期的项目经历给了我非常具体的答案。

从 git log 可以看到，我在项目中主导了多次重构和功能迭代：从 CalDav 同步支持、Pomodoro 番茄钟功能的层次化设计、到 Tag 标签系统和拖拽排序功能的实现。这个过程让我深刻体会到：

  1. 提前设计好数据模型和接口，是降低后期重构成本的关键
  2. 模块化和关注点分离，让功能迭代更加顺滑
  3. CI/CD 流水线，是保障代码质量的自动化防线

关键洞察：研究原型到产品的转化，不是"重写一遍"，而是**在原型阶段就埋入工程化的种子**——清晰的模块边界、可测试的接口、版本化的配置。

2. 仍未解决或更困惑的问题

  • 如何量化 AI 生成代码的长期维护成本？ 目前缺乏系统性的度量指标。
  • 如何在交付压力下保持"高速度 + 高质量"的平衡？ 在 Beta 阶段我们曾面临功能堆叠的诱惑。
  • Prompt/Context 的工程化管理如何标准化？ 目前的实践仍较为零散。

3. 对 AI 时代软件开发的新问题

经过一学期的实践，我产生了一些新的思考：

  1. Context 管理的工程化： 如何像管理代码一样管理 AI 的上下文？项目规模增大后，如何确保 AI 理解正确的项目背景？

  2. AI 生成模块的责任边界： 当 AI 生成的代码出现问题时，责任归属如何界定？这对代码审查流程有何影响？

  3. 工程知识的沉淀： 如何确保团队的工程经验真正沉淀为可复用的资产，而不是只存在于 AI 的对话历史中？

4. 项目贡献与工程实践证据

我的主要贡献包括：

  • 架构重构（Alpha Refactor）： 对前后端进行了全面重构，建立了清晰的模块结构
  • 核心功能开发： CalDav 同步、Pomodoro 番茄钟（含 Session/Record 层次化设计）、子任务功能、标签系统、拖拽排序
  • CI/CD 建设： 搭建了 GitHub Actions 流水线，包括格式检查和自动化测试
  • UI/UX 迭代： 多次优化界面设计和交互体验

这些实践印证了"工程化"不是一次性的工作，而是贯穿整个开发周期的持续努力。

5. 对 NCL 理想教学环境与课程方法的评价

NCL 理想教学环境： https://www.cnblogs.com/xinz/archive/2011/12/29/2306652.html#5-ncl

5.1 对本学期各教学方法的价值评估

教学方法 价值与收获
公开博客作业 + 千帆竞发追踪 强迫表达与反思，形成了有效的学习闭环。写博客的过程本身就是一种知识梳理。
结对编程（API 驱动） 深化了对"接口即契约"的理解，也体会到了协作中沟通的重要性。
PQ 问答 / UX 现场测试 真实暴露了"开发者理解 ≠ 用户理解"的鸿沟，这是非常宝贵的体验。
学生自行组队并选择项目 逼迫工程管理能力成长，也让我们为自己的选择负责。
Alpha 阶段后强制团队人员变动 虽然痛苦，但非常真实地模拟了实际工作中的团队变动，提升了适应能力。
业界专家讲座 + Demo 提供了现实世界的参照系，让我们看到课堂之外的工程实践。
"天使投资"方法评选团队项目 引入了市场和价值的视角，但可能需要更多后续的复盘和反馈。

5.2 与理想教学环境的差距

  • 真实用户反馈仍有限：用户面相对较窄，持续反馈机制不够完善
  • 工程过程标准化：主要依赖学生自觉，缺乏强制性的过程规范
  • 过程质量的可度量性：评价体系更侧重结果，对过程质量的量化评估有待加强

6. 补充感想

回顾整个学期，最大的收获是：被"逼迫"表达和复盘。

如果没有博客作业和阶段总结的要求，我很可能不会系统性地反思团队在各个阶段的问题和成长。这种"强制输出"的机制，确实帮助我将隐性的工程经验转化为显性的知识。

同时，团队协作中的摩擦和磨合，虽然过程中有时令人沮丧，但回头看都是宝贵的学习经历。Alpha 后的人员变动尤其让我体会到：好的软件架构和文档，是应对团队变化的最好保障。

7. 结语

AI 时代的软件工程，本质上仍然是关于**"协作、质量与可持续性"**的学问。

LLM 让我们能更快地写出"能跑"的代码，但真正的挑战在于：如何让系统在 6 个月后仍然可维护、可演进。这学期的课程和项目实践让我意识到：

  • 工程能力不等于功能数量，而是"可持续交付能力"
  • 课程的最大价值不是作业本身，而是逼迫我们把"工程经验"表达出来、沉淀下来
  • AI 是强大的工具，但人的判断力、架构能力和责任心依然是不可替代的

我在第一次博客中提出的五个问题，大部分在实践中找到了初步的答案。但正如软件工程本身是一个不断演进的领域，这些答案也会随着技术和实践的发展而持续更新。

未来的方向是：将这些经验进一步固化为可复用的方法论，并在更大规模、更复杂的项目中验证和迭代。

cc-by-nc-sa 4.0

评论