《构建之法》课程期末回顾：从提问到再提问
第一篇博客链接：
《现代软件工程课程 个人博客第一次作业》
链接
本学期伊始，我在快速阅读《构建之法·现代软件工程》后，围绕软件工程的真实复杂性、需求分析、工程创新、伦理设计以及 AI 测试等问题提出了五个较为"偏问题导向"的思考。随着大半个学期的课程实践、项目协作和不断试错，现在回过头来看，这些问题本身已经发生了变化------有些得到了阶段性的回答，有些则变得更加复杂，甚至引出了新的问题。
以下从五个方面，对当初的问题、现在的理解以及新的困惑进行系统性回顾。
一、当初提出的问题，我是否已经能自己回答？
结论是：大多数问题不再是"有没有答案"，而是"答案不再唯一"。
-
关于"模拟上线问题"的疑问
学期初我认为：没有真实线上环境，就无法理解维护与运维的复杂性。
现在回看，通过：
- API 驱动开发中的接口失配；
- 团队协作中因为权限、依赖、分支管理产生的真实冲突；
- UX 测试中"功能没错但体验失败"的反复修改；
我意识到：
所谓"假的上线问题"，本质并不假 。只要问题足够真实、责任足够清晰、代价足够明确，它就能迫使人进入"工程状态"。
真实生产事故当然不可替代，但课程已经成功构造了一个"低风险但高还原度"的工程环境。
-
关于"没有客户如何做需求分析"
我现在更倾向于承认：
对研究生或个人开发者而言，"需求分析"往往是从"问题建模"开始，而不是从"客户访谈"开始。
在本学期的项目中，我逐渐学会用使用场景、失败路径、被放弃的方案来反向验证需求是否成立。这在形式上不像传统需求分析，但在逻辑上是成立的。
-
关于工程创新是否只能发生在"框架级别"
现在我会明确回答：
工程创新更多发生在流程、接口、协作和约束设计中，而非功能本身。本课程中的 API 驱动开发、阶段性交付、强制团队调整，本身就是一种工程范式实验。
-
关于商业化设计与用户体验的冲突
我不再简单地将其理解为"背离用户中心"，而是理解为：
这是工程中多目标博弈的结果，而不是单一价值观的失败。但工程师是否意识到这种博弈、是否有能力提出反向方案，本身就是工程素养的一部分。
-
关于 AI 是否会取代测试工程师
现在我更认可一个中间态结论：
AI 正在快速吞噬"可形式化的测试工作"，而人类测试正在向"问题设定者"和"风险假设者"迁移。
二、哪些问题反而变得更困惑了？
如果说学期初的困惑是"我不懂工程"，那么现在的困惑更像是：
我开始理解工程了，但工程的复杂性比我预期的更大。
尤其是在 AI 深度介入开发后，我感受到一种明显的张力：
- 工具越强，能探索的解空间越大；
- 搜索空间越大，对决策与取舍的要求越高；
- 能力越强，野心越容易膨胀。
所谓 vibe coding 的吸引力正在于：
它让"想法 → 实现"的距离被极大压缩。
但我越来越清晰地意识到：
压缩实现成本，并不会同步压缩责任成本。
当代码生成、测试生成、架构草图都可以被 AI 快速给出时，人真正需要承担的，是：
- 为什么要做这件事？
- 为什么是这个结构？
- 如果失败，失败代价由谁承担？
这类问题，并不会因为 AI 更强而消失，反而更加集中地压在人身上。
三、AI 时代的软件开发：我产生了哪些新问题？
本学期后半段，我开始反复思考一个问题：
在 AI 深度参与开发的情况下，责任究竟如何划分？
我逐渐形成了一个类似"自动驾驶分级"的直觉模型：
-
L1--L2：AI 辅助开发
人对每一行代码负责，AI 只是工具。
-
L3：AI 主导实现，人类审查
人负责目标与验收，但不完全掌控过程。
-
L4：AI 自主生成并自测
人类只在事故或异常时介入。
-
L5：全自动工程系统
此时"工程责任"可能已不再是个人层面的概念。
这带来一个极其现实的问题：
当 AI 写的代码通过了 AI 写的测试，而系统依然失败时，谁该为结果负责？
在这个意义上，我开始认为：
未来的软件工程教育，必须显式讨论"AI 参与下的责任边界"，否则所有效率提升都可能是不可持续的。
四、从 NCL 视角，回看本学期的教学方式
如果以 Natural · Critical · Learning 作为评价框架，我对本学期的体验总结如下：
-
公开博客 + 千帆竞发图
强烈的 Natural 与 Learning 属性。
但对个人而言，时间分配与持续输出仍然是明显短板。
-
结对编程 + API 驱动开发
工程真实，但交流深度有限。
某些时候更像是一种"妥协式协作"，而非真正的共创。
-
pq 问答、课堂测试、UX 现场评估
非常符合 Critical Learning 的初衷，是我认为最"工程化"的教学设计之一。
-
学生自行组队与选题
自由度高，但仍不可避免地存在路径依赖和现实妥协。
-
Alpha 后的强制人员流动
非常有价值的一项设计。
它迫使人面对真实工程中的"不连续性"和"非个人最优"。
-
业界工程师与专家讲课 + Demo
价值极高。
不仅是技术输入，更是"工程思维方式"的示范。
整体来看，这门课确实构建了一个并不舒适、但高度真实的 NCL 环境。
五、基于 2025 AI-Native 能力表的自我评估（重点提升项）
结合课程前后变化，我认为自己提升最明显的维度是：
-
第五维：智能开发与人机协同
我已经能更清楚地把 AI 当作"思维放大器"，而不是"答案生成器"。
-
第二维：AI 原生架构与沟通设计
对"如何把模糊想法转化为可讨论结构"有了更清晰的实践认知。
-
第一维：AI 模型与系统权衡意识（初级）
虽然尚未达到成熟阶段，但已经开始主动考虑"代价、约束与收益"的关系。
相对而言，工程领导与多约束决策仍是我认为最需要继续补足的能力，这也正是我未来最希望在真实工程环境中继续锻炼的方向。
结语
回头看，第一篇博客里的五个问题，并没有被"彻底解答"。
但它们确实完成了一个重要使命：
它们把我带进了一个需要持续提问、持续修正、持续承担责任的工程世界。
而这，或许正是《构建之法》和本课程真正想传递的东西。