[I.1] 个人作业：阅读和提问

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习软件工程相关的基础知识，并在实战中运用这些知识
这个作业在哪个具体方面帮助我实现目标	了解软工、学习软件工程相关的基础知识

一、AI 时代，软件工程师的“智力”是否仍然一成不变？

在阅读 《构建之法》1.2.1 软件的特殊性 时，书中列举了学者总结的软件开发过程中的五点难题：复杂性、不可见性、易变性、服从性、非连续性。其中第一点描述如下：

书中提到，软件的各个模块之间的依赖关系的数量逐年指数增长，而软件工程师的智力、记忆力在过去的几十年都没有大的提高，这导致了软件的复杂性。

我认为此观点在当今乃至未来已经不再适用。如今 AI 高速发展，图像识别模型努力模仿人类视觉，语言模型达到超越常人水平的理解和推理能力，这些由芯片、电流组成的人工智能似乎正逐步发展为“硅基生命”的雏形。倘若未来脑科学取得更多突破，进一步指导人工智能的架构设计和迭代，人类在短期内无法随意对自己进行“更新换代”，但人类亲自塑造的人工智能却能实现这个愿望。软件工程师借助人工智能为“第二大脑”，利用人工智能让软件更易读，不就是扩充了自己的智力和记忆力？将一位熟练运用人工智能工具的工程师和十几年前的他自己相比，不就是发生了“人”本身的变化？

二、Tab 还是 Space？

在阅读 《构建之法》4.2.1 缩进 时，书中描述如下：

书中提到 Tab 键在不同情况下会显示不同的长度，对此我表示赞成。回忆起在大二下学期学习操作系统时，使用课程组提供的跳板机编写代码，缩进是 8 个空格，让习惯了 4 个空格的我非常难受。

但我不赞成使用 4 个空格替代 Tab 键，有以下几点理由：

• Tab 键只需敲一次键盘，空格需要敲 4 次，很麻烦，有时漏敲了变成 3 个空格更麻烦。
• 大多数现代 IDE 例如 vscode 和 idea 都会智能缩进，使用 Tab 更切合这些软件的设置。
• Tab 可以通过设置自定义宽度。

三、AI 编程助手普及的今天，传统的“结对编程”是否还有必要？

在阅读 《构建之法》4.5.2 为什么要结对编程 时，书中对结对编程给予了很高的评价：

书中提到，在结对编程模式下，一对程序员肩并肩、平等地互为“领航员”和“驾驶员”。书中认为这种模式能提供不间断的代码审查，极大提高代码质量，并促进团队知识传递。

但我对这种纯人类之间的结对编程在当下的普适性和效率表示怀疑，尤其是在学生团队中。

• 首先，结对编程对两人的水平差异有严格要求。在实际的软工课组队中，如果两人代码能力悬殊，往往会演变成“一人熬夜写代码，一人想帮忙又帮不上”的“搭便车”现象，不仅没有起到审查作用，反而浪费了人力资源。
• 其次，随着 GitHub Copilot、Cursor 等 AI 编程工具的全面普及，AI 实际上已经完美胜任了“领航员”甚至部分“驾驶员”的角色。AI 可以在我输入代码的瞬间完成逻辑补全、边界条件审查和漏洞检测。既然我们可以实现“Human-AI”的高效结对，且不需要考虑沟通成本和情绪价值，那么传统这种耗时、对性格与能力匹配度要求极高的“Human-Human”结对编程，是否已经成为一种应当被淘汰的低效开发仪式？

四、敏捷流程中的“每日例会”在学生团队中是否容易变成形式主义？

在阅读 《构建之法》6.1 敏捷的流程简介 时，书中介绍了敏捷开发中非常关键的一个环节：

书中强调，团队每天要抽出时间面对面开会，每个人依次汇报：昨天做了什么、今天打算做什么、遇到了什么困难。书中认为这能让团队成员了解彼此进度，及时发现问题。

我认为这个理想化的敏捷仪式在大学生团队（乃至部分采取远程办公的现代企业）中行不通。大学生的时间是高度碎片化的，每个人有不同的课表、实验和活动。强行要求每天凑在一起开会，往往会演变成一种负担。很多时候为了完成软工课的任务，大家只是机械地在群里发几句废话，或者为了应付助教而在例会时摆拍，立会彻底流于形式。

此外，在现代工程协作中，像 GitLab/GitHub 的看板、飞书/钉钉的自动化进度追踪，已经能够实现彻底的“异步协同”。我们完全可以通过看代码仓库的 Commit 记录和 Issue 状态来了解进度。强行遵守这种僵化的流程，是不是反而违背了“个体和互动高于流程和工具”的核心价值观？

五、在软工课中 PM 是否变得无用？

在阅读 《构建之法》9.3 PM 做开发和测试之外的所有事情 时，书中详细定义了微软模式下的 PM 的职责：

书中指出，PM 负责做商业分析、收集需求、制定计划、协调资源以及撰写文档，而把写代码和测试的专业工作留给开发和测试人员。书中的理念是：开发人员应当专注于实现，PM 则是团队的润滑剂和对外的接口。

但在软工课这样的小型学生团队实践中，我对设立“专职 PM”这一角色的合理性存疑。在学生项目中，整个软件的规模通常不需要极为复杂的商业调研，真正的核心难点往往在于技术实现。如果团队中有一名同学完全按照书中所述只做 PM 不写代码，在项目初期画完原型图、写完需求文档后，中期极易陷入“无事可做”的状态；但在最终项目答辩时，PM 往往因为负责制作 PPT 和主讲，在评委面前获得了最多的曝光度。

这会导致一个极大的不公平：写核心架构的程序员可能拿不到最高分，而依靠“沟通和文档”的专职 PM 却能轻松名列前茅。在无法做到像成熟企业那样拥有完善绩效考核机制的学生团队里，如何界定 PM 的真实工作量？在 5 人的小型学生团队里，由核心开发人员兼任 PM，是不是比设立一个不碰代码的纯 PM 更能服众、更符合实际？