《构建之法》：初读和提问

[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又是否会赋能系统学习？这也很值得思考。

​ 总之，邹欣老师对“习而学”很有好感的同时，我对两种学习方式都抱有平等的好感。如何能平衡做和学，如何选择恰到好处的学习方式，对于老师抑或是学生，仍是一门学问。