现代软件工程课个人博客三：半学期后，我能回答哪些问题了？

申鹏（252403050）

个人博客链接

• 第一次博客：https://shenpeng.work/index.php/2025/10/11/software/
• 结对编程博客：https://shenpeng.work/index.php/2025/10/25/elevator_work/

回头看：学期初我问了什么？

在第一次博客里，我主要在纠结三件事：

1. “工程这东西到底怎么学”——靠看书/听课，还是必须靠一堆真实任务把人拽进坑里爬出来。
2. AI 写代码到底是“加速器”还是“债务制造机”——尤其当项目开始变大、开始重构时。
3. 在 AI 时代，脚手架、测试、规范是不是比“写得快”更重要？我当时甚至把“技术债是不是可以被结构化管理”当成一个大问号。

现在我怎么回答这些问题？

（1）能不能自己回答？可以回答，但是不会再纠结具体“是或者否”的答案，而是应该以工程的角度去看待问题，对很多问题有了更多实感

• 以前我会问“这个需求怎么写得漂亮”；现在更常问“怎么让需求变成可验收的东西（DoD/测试/演示路径）”。
• 结对编程做电梯调度时，AI 确实让“框架搭起来”更快，但后期调试和重构会被细节错误拖到怀疑人生——甚至“让它给每个模块写单测也不一定能避免”。这让我对“先把可回归的验证链路搭起来”有了实感。

（2）AI 是加速器还是债务制造机？取决于你有没有“护栏”。
我现在更倾向把 AI 当成“能快速出手但不背锅的实习生”：

• 让它产出：样板代码、接口草案、文档初稿、测试用例候选。
• 但要用护栏兜住：清晰接口契约、最小可复现用例、CI/回归、日志与监控。
  否则就会出现在期中反馈里说的那种“假借 AI 之手的虚假繁荣”，看似代码很多，维护起来很痛。

还有没完全想明白的困惑

• “技术债”在 AI 生成代码里的度量：哪些债是“先欠着能跑”，哪些债会在迭代/重构时指数爆炸？目前我更多靠经验直觉，还缺一套更可量化的做法。
• 团队协作里的“最后一公里”：打包、部署、联调、验收这些环节依然最容易在 ddl 前集中爆雷（期中反馈里看到很多这种情况），这种情况可以彻底避免吗？

AI 时代我冒出来的新问题

• 怎么把“接口契约 + 测试 + 文档”变成 AI 协作的默认产物，而不是额外负担？（否则永远是“快写—难改—再重写”循环）
• 当项目开始引入智能体/自动化流程时，怎么做可观测、可回滚、可追责的治理？（比如幻觉检测、越权熔断、质量闭环）
• 前端/UI 在 AI 时代的价值怎么体现？ 我现在更相信：UI 不是“画页面”，而是“把反馈做成系统的一部分”（比如减少 paper-cuts、提高可信度、提高参与度）。

课程方法 vs NCL：哪些对我有用？

老师提的 NCL 理想环境，本质是“自然的、有批判精神的学习环境”，靠真实问题驱动，大家一起提问、尝试、反馈、总结。

对我最有价值的几件事：

• 公开博客交作业 + 千帆竞发图跟踪：逼着我把过程写出来，起到“持续复盘”的硬约束。千帆图的阶段轴也把“课程到底在逼你练什么”讲得很直白。
• 结对编程（API 驱动）：把“接口契约/信息隐藏/松耦合”从概念变成了会影响生死的工程选择（不然就会死锁/不显示/返工）。
• PQ 问答 + UX 现场测试：我第一次把“微小挫败（paper-cuts）”“防错设计”“同理心”当成工程问题来写改进方案，而不是当成“审美问题”。

差距/吐槽：

• 强制团队人员变动（alpha 后）：对“跨团队迁移能力”很有价值，但成本也真实存在——上下文切换、技术栈切换、信任关系重建。我作为 UI 前端转到量化投资团队，就是一次典型的“现实世界式重组”。

自我评价：课前/课后提升最大的部分

参考 软件工程师能力自我评价表：