关于邹欣老师《现代软件工程》课程的五问
ZGCA《现代软件工程》课程 个人博客作业 #1
1. 引言：对课程的期望
作为一名人工智能领域的博士生，我的日常工作聚焦于算法模型的探索与实现。在追求模型性能的极致（SOTA）的过程中，我们常常采用“快糙猛”的开发方式——在Jupyter Notebook中快速验证想法，用拼凑的脚本处理数据，代码版本管理也时常在混乱中挣扎。这种研究模式虽然能保证我们以最快的速度进行学术探索，但当项目需要协作、复现、或从研究原型走向实际应用时，其“软件工程”属性的缺失便会成为巨大的阻碍，导致项目脆弱、难以维护和扩展。
我期望通过《现代软件工程》这门课程，系统性地学习将工程的严谨性、规范性和可协作性引入到AI研究与开发中。我希望能掌握如何为充满不确定性的AI项目（尤其是大模型应用和具身智能的开发）建立高效、敏捷且可靠的开发流程。我期待学习到的不仅仅是具体的工具或方法，更是一种能将学术研究的灵活性与工业级软件的鲁棒性相结合的“思维框架”，从而提升我的研究质量、团队协作效率以及未来将科研成果转化为现实影响力的能力。
2. 五个核心问题
-
问题一：在“AI原生”时代，软件工程的边界与核心实践应如何演进？ 在由大型语言模型驱动的“AI原生”应用中，软件的核心逻辑正从确定性的代码，转变为由自然语言引导的、行为具有不确定性的模型。这一范式转变为软件工程带来了新的挑战。它要求我们探索针对模型和提示词优化版本控制、协同编辑和自动化测试方法。同时，面对模型可能出现的“幻觉”或偏见，传统的单元与集成测试显得力不从心，亟需建立一套新型的“AI测试”体系来保障系统的可靠性。更进一步，经典的持续集成/持续部署流程是否也需要演进，形成更为复杂的“持续学习与部署”的闭环。
-
问题二：敏捷开发方法如何适应目标不明确、高度探索性的AI科研项目？ 敏捷开发强调在短周期内交付明确的“用户价值”，这与AI科研项目的特性——目标模糊、结果不可预测、甚至没有传统意义上的“用户”——形成了鲜明对比。在这种背景下，直接套用敏捷框架会遇到诸多挑战。例如，当一个失败的实验（证明某条路走不通）也是有价值的产出时，我们需要重新定义“Sprint”的目标和“Done”的标准。同样，“User Story”的写法也需变通，因为这里的“用户”常常是研究者自己，而“需求”则是“验证一个科学假设”。因此，核心的挑战可能是在于如何灵活地应用敏捷思想，使其成为科研探索的助推器，而非形式化的束缚。
-
问题三：人类-AI结对编程的最佳实践是什么？ 随着以GitHub Copilot为代表的AI编程助手成为日常开发的“新伙伴”，传统的“人-人结对”或许正在演变为“人-AI结对”。这种新型协作关系引发了一系列值得探讨的工程问题。我们需要明确界定人与AI在开发流程中的角色与职责，以最大化协同效应，避免开发者沦为简单的“代码验收员”。同时，我们必须审慎评估AI生成代码的可信度，并深入思考这种新模式对代码所有权、软件质量以及初级开发者成长曲线的深远影响，最终目的是探索并建立一套与AI高效、安全协作的最佳实践。
-
问题四：具身智能软件的测试难题与质量保证策略？ 与纯软件系统不同，具身智能的“输出”是与物理世界发生的直接交互，这使得测试的复杂性呈指数级增长。这首先对传统的测试模型提出了挑战，其是否依然适用值得怀疑。其次，为了实现大规模、可复现的自动化测试，我们可能还需要构建高保真的物理仿真环境，并解决仿真结果如何有效迁移到真实世界这一核心难题，并需要一种适应这种模式的测试方法。
-
问题五：如何将AI研究原型（Prototype）优雅地工程化为产品（Production）？ 大量的AI创新诞生于研究人员的Jupyter Notebook或零散脚本中，这些原型普遍缺乏良好的软件工程实践。将这样的研究原型转化为稳定、可扩展、服务大众的在线产品，是一项巨大的工程挑战。这个“从研究到生产”的转化过程，充满了关键的软件架构决策点。对于身处研究阶段的我们而言，我们该如何提前规划并采纳某些关键的软件工程实践，从而能极大地降低未来产品化过程中的技术债务。
3. 总结
上述五个问题，根植于我作为一名AI研究者的日常困惑，同时也触及了现代软件工程与前沿AI技术交叉口的核心挑战。我相信，传统的软件工程原则为我们提供了宝贵的“确定性”工具，但在面对AI带来的“不确定性”时，这些原则需要被重新审视、调整和创新。我热切地期望能在本课程的深入学习和探讨中，为这些问题找到答案的线索，构建起一套能驾驭未来AI软件开发复杂性的知识体系。
