[I.1] 《构建之法》：初读和提问
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2026春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | [I.1] 个人作业：阅读和提问 |
| 我在这个课程的目标是 | 获得软件工程师应有的初步能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 初步认识软件工程，并简单理解开发相关的知识 |
写在前面
收到这份作业之后，我只是懒散地打开了博客园网站，眼球在邹欣老师的主页漫无目的地游走。但是略读几篇讲义与文章之后，我个人认为邹欣老师不仅有深厚的专业功底，而且擅于讲明、缕清他的每一个想法。他的文笔下充盈着他对这些“知识”的理解，我作为一个大三的本科生我很难不肃然起敬。（这里我先姑且为“知识”打上双引号
我带着这份敬意逐行逐字阅读博客，也许应该用AI读用AI写，对于现如今的大模型来说不是难事，但我坚信只有如此才能找到我想要的答案————哪怕现在已经是讲义上传15年后的2026年了。
有些遗憾又有些庆幸，也许读得太迟，也许也不算晚。
问题壹：AI时代洪流下的个人开发流程（PSP）中，敲代码作为最基础的技能是否还被需要？
那怎么提高技能呢? 答案很简单, 通过不断的练习, 把那些低层次的问题都解决了, 变成不用经过大脑的自动操作, 然后才有时间和脑力来解决较高层次的问题。
———— 个人开发技术：技能的反面
以上是邹欣老师在讲义PSP节中分享的对技能的看法与思考。虽然老师没有明确指出中高层次的问题的大致划分或者具体代表，但是明确指出低层次问题其中包括了对编程语言语法的了解等等，并且这些内容需要大量的机械重复训练，把它变成不用经过大脑的自动操作，我们才认为是“精通”。
那么现在问题来了，AI大人的时代降临了。
截止到2026年，我认为无论是什么专业、什么学历的人，只要有清晰的表达能力，只要能将起始和迭代需求表达清楚完整，就都可以实现一行代码不碰，甚至一行代码不看，就完成简单功能的开发。精通低层次问题貌似没有那么重要了，AI做了这部分的工作，它比你更洞悉每一条语法规则，你只比它更擅长在每个角落写点bug。尽管如此我认为（应该也是主流观点），我可以不亲自写每一行，但是我要看懂每一行，我要对我的项目、我的文件、我的代码都了如指掌，避免AI创造的屎山在我看不到的地方肆意生长。但是话又说回来，亲自编码和看懂代码二者断然不在同一个境界，我想这有点类似于P≠NP的道理，创造从理论上永远比验证更难。
那既然不需要亲自编码，那我们的学习貌似不需要像从前一样，上机、刷题，达到能独立编程获得AC的境界了？理论上完全没有问题，但是问题在于邹欣老师博客中的形似金字塔的图，它无可争辩地告诉我们：低层次问题是中上层的固不可少的基础。那如果我们没有亲自编码的能力，真的能理解中上层问题的核心吗？这个问题我表示怀疑。
“站在巨人的肩膀上”可以说是人类科学技术的车轮滚滚向前的核心动力。这次的肩膀，不是前辈的、不是专家的，是硅基巨人的肩膀，我们是否能放心将两只脚都踩上去呢？
问题贰：软件工程的学习更多是学知识还是更多是学方法？
这个问题其实源于别的课堂（所以有点带着问题找答案的感觉），是必修的计算机科学方法论的王老师分享的思考，我不确定是否为老师自己的思考，但是确实是首次听说并且给予我启发的说法。
老师讲到其实学习会大致有两种内容，一种是knowledge（知识），一种是method（方法），承接上一个问题来说，我认为知识更多属于低层次问题，而方法更多属于中高层次问题，就拿我们的培养方案举例，程设和数据结构毫无疑问属于knowledge，COOOOS已经有一定体系架构或者开发架构的学习，可能更倾向于knowledge和method的结合体，那么软件工程属于怎样的课程呢？邹欣老师的说法让人很有启发：
软件 = 程序 + 软件工程
程序是基本功，但是除了程序之外，软件工程决定了软件的命运。
————软件工程概述
这个公式直白地把软件工程和我们之前学过的先导课解耦开了，我们这门课最终要做的软件，就是由程序与软件工程构成，那我觉得软件工程本质上学习的是method，或者至少绝大多数是method。但是进一步深入阅读，我发现软件工程中method仍然不是全部，博客中继续提到：
软件工程是把系统的, 有序的, 可量化的方法应用到软件的开发, 运营, 和维护上的过程。
软件工程包括下列领域: 软件需求分析, 软件设计, 软件构建, 软件测试, 和软件维护.
软件工程和下列的学科相关: 计算机科学, 计算机工程, 管理学, 数学, 项目管理学, 质量管理, 软件人体工学, 系统工程, 工业设计, 和用户界面设计.
我们在开发，运营, 维护软件的过程中有很多技术, 做法, 习惯, 和思想体系。 软件工程把这些相关的技术和过程统一到一个体系中, 叫 “软件开发流程”，软件开发流程的目的是为了提高软件开发, 运营, 维护的效率；以及用户满意度, 可靠性，和软件的可维护性。
我们对第一句话进行缩句，得到的结果是“软件工程是过程”。第一眼看上去像是语病，但仔细掂量这句话，感觉说的十分准确。一门包含理论与实践的课程，理论一定是工具，也就是老师说的“系统的, 有序的, 可量化的方法”，实践————“开发, 运营, 和维护”————才是目的。
在罗杰老师的课程介绍当中，也能略知一二，这是一次周期很长、规模较大、人数更多的软件开发流程。method固然需要学习，但更多的收获理应在路上。
问题叁：AI时代的敏捷开发，“快速交付”和“技术债”是否不再冲突？
在讲义中，邹欣老师提到了敏捷思潮的价值观：
Individuals and interactions over processes and tools
个人和交互 重于 过程和工具 Working software over comprehensive documentation
可用的软件 重于 完备的文档 Customer collaboration over contract negotiation
和客户协作重于 合同谈判 Responding to change over following a plan
响应变化 重于 遵循计划
———— 酒后的敏捷
其中第二对是我想要着重讨论的点，我认为在AI时代可用的软件和完备的文档完全不冲突了。对我个人而言，用AI写总结文档或者接口文档是百利而无一害的事情，我在项目实践中会经常调用多个AI一起工作，如同我雇佣的程序员一般，我会要求他们之间通过文档的形式沟通问题或者交付进度。我认为这有些类似于公司分不同的部分，把一个很宏大的项目按照一定的逻辑解耦开交给不同的人，文档是必需品。对于“古法编程”的过去，写文档必然是费时费力的事情，既要尽可能写的滴水不漏，也要尽可能写的通俗易懂。但是时代变了，AI在拥有自己工作的上下文的前提下，能以极快的速度生成一篇满足条件的文档。“快速交付”和“技术债”应该不再冲突了。
这一点对于开发者应该不难接受，也不会因为AI写得又快又好抢了谁的饭碗，因为并没有专门写文档的人，开发者也能更全身心投入到开发当中。这样一来，也算是AI为敏捷开发大大提升了完备性吧。
问题肆：结对编程的定义范围是否应当拓宽？
先来看讲义中对结对编程传统的定义：
在结对编程模式下，一对程序员肩并肩地、平等地、互补地进行开发工作。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起单元测试，一起集成测试，一起写文档等。
————结对编程
对于我们这一代计算机专业的大部分同学而言，这种场景应该是未尝一试的。和另一个人平等地共享一切软件硬件————还有两个人的脑子，只为进行快速地、疯狂地编程。
随着时代的变化，我更倾向于认为人机结对编程也算是一种新型的结对编程，当然这是不符合严格定义的，但是我觉得人机结对编程有着类似的形式，并且和传统结对编程各有利弊，未尝不算是一种定义的延拓。首先从效率的角度上来看，AI能够完全胜任，甚至更适合做领航员和驾驶员中任意一个角色，完全满足结对编程的初心。其次，传统的结对编程会因为各种原因受阻，如程序员不愿与人高强度沟通、程序员在结对中倍感压力，AI在这个方面也是解决了很大一部分人的问题。因此，人机结对编程不只是对结对编程定义的拓宽，更是对应用条件的拓宽，对应用场景的拓宽。我们也应逐渐接纳并熟练与AI的编程交互。
问题伍：“做中学”可以替代系统学习吗？
从我个人的学习和教学经历来看, 我认为给学生具体的, 能实践的, 能马上看到因果关系的教材和练习, 是激发学生兴趣和求知欲的好方法。 我就是这样学习编程和软件开发的 (见下面的注解 三文鱼模型)。 所以我对 “习而学”的方法很有好感。软件工程有理论的部分, 有工程的部分; 有艺术的部分，还有手艺的部分; 在同学们达到理论/艺术的阶段之前, 大量的练习是必须的。
————习而学的软件工程教育
“做中学”也就是邹欣老师讲义中提倡的“习而学”，就是给学生提供一个学习场景，或者开发需求，让学生以更高的兴趣与求知欲学习新知识。我理解为给学生一个切入点，让实践带动理论的学习。感觉2026年的今天，“做中学”是一个很常见的事情，本科生科研已经遍布所有高校，谁敢说自己本科生科研不是“做中学”呢？在和身边朋友讨论的时候，大家都觉得是很有收获的一种学习方式。相比之下，有的课程仍然保持学完知识点再实践巩固的方式，通常给人更死板的感觉。但是我个人感觉这两种学习方式不能一棒子打死一个，这仍然取决于这个课的“成分”。对于有的课而言，它的实践过程是核心，“做中学”是一个很好的学习方式，不可能在软件工程这门课中只讲理论，就像不能在露营课中只学各种帐篷的模样，更重要的还是体验这个过程，遇到了怎样的问题，提出了怎样的方案，事后怎样总结经验等等。对于另外的一些课，知识体系架构如参天大树，从一个细枝末节学习是不合乎道理的，比如数学分析。所以二者仍然要因地制宜地使用，不存在替代关系。
最后的思绪还是绕不开AI（原谅我通篇都在反复点AI，但AI确实给我带来了许多迷思），AI对“做中学”的直接影响就是“做”的门槛变低，我的猜想是“学”的效果也会随之变差，说到底“做”应该比“学”要简单一些，好比使用工具易于了解原理。另一方面，AI又是否会赋能系统学习？这也很值得思考。
总之，邹欣老师对“习而学”很有好感的同时，我对两种学习方式都抱有平等的好感。如何能平衡“做”和“学”，如何选择恰到好处的学习方式，对于老师抑或是学生，仍是一门学问。
If you like this blog or find it useful for you, you are welcome to comment on it. You are also welcome to share this blog, so that more people can participate in it. If the images used in the blog infringe your copyright, please contact the author to delete them. Thank you !