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

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	I.1 个人作业：阅读和提问
我在这个课程的目标是	建立系统的软件工程思维，将个人零散的代码能力转化为构建复杂、可维护软件产品的工程能力。
这个作业在哪个具体方面帮助我实现目标	通过阅读讲义并结合自身实践提出疑问，帮助我在正式开发前发现自己对“敏捷开发”、“需求分析”及“质量控制”等环节的思维盲区，为后续团队协作打下理论基础。

---

问题 1：个人开发流程（PSP）中，“编码”任务的度量价值是否已让位于“提示词工程”与“代码评审”？

在关于个人开发流程（PSP）的部分，教材强调开发者需要记录不同任务阶段所花费的时间，例如需求分析、编码、测试等，并通过这些数据分析自己的效率，如“工程师在实际开发中要记录各项任务所花的时间……通过这些数据，我们可以看到自己在哪些方面可以改进。”

在传统的软件开发环境中，编写代码往往是最耗时的工作，因此“编码时间”自然成为衡量效率的重要指标。通过统计不同阶段的时间分布，可以发现开发者在哪些环节效率较低，从而调整开发方式。

但在当前的软件开发环境中，这种情况正在发生变化。随着 GitHub Copilot、Cursor 等 AI 辅助工具的普及，很多函数或模块的实现已经可以在很短时间内生成。开发者越来越多地通过描述需求、调整提示词来获得代码，再对生成结果进行检查和修改。相比过去，从零编写代码的时间明显减少，而理解需求、设计结构以及审查代码的时间反而变得更加重要。

当开发流程发生这种变化时，PSP 中以“编码时间”为核心的度量方式是否还能准确反映工程师的能力结构就值得思考。如果大量代码可以快速生成，那么真正决定系统质量的可能是提示词设计、架构决策以及对生成代码的判断能力。因此，在 AI 辅助开发逐渐普及的背景下，软件工程对个人效率的度量或许需要从代码产出速度逐渐转向对系统理解能力和工程判断能力的评价。

---

问题 2：如果向进度落后的项目中增加的是 AI 资源，布鲁克斯法则是否仍然成立？

在讨论项目进度管理时，教材引用了著名的布鲁克斯法则：“向进度落后的软件项目中增加人手，只会使项目进度更加落后。”其原因在于，新成员加入团队后需要时间熟悉项目背景，同时团队规模扩大也会带来更多沟通和协调成本，因此新增人力在短期内往往无法真正提高效率。

这一结论主要基于传统的软件开发团队：当项目进度落后时，增加资源通常意味着增加新的开发人员，而这些成员在产生有效贡献之前需要经历培训、代码熟悉和团队磨合等过程。

但在当前的软件开发实践中，团队增加的“资源”有时并不是新的工程师，而是各种 AI 辅助工具。各种自动生成代码、生成测试用例或解释代码结构的工具，正在逐渐承担过去由初级开发者完成的一部分工作。与人类成员不同，这些工具几乎不需要培训，也不会显著增加团队内部的沟通成本。

在这种情况下，一个新的问题就出现了： 如果向进度落后的软件项目中增加的是 AI 工具或算力资源，而不是新的团队成员，项目进度是否仍然会像布鲁克斯法则所描述的那样变慢？ 换句话说，布鲁克斯法则讨论的是增加人手的情况，而在 AI 辅助开发逐渐普及的背景下，是否也需要重新思考它在这种新情境中的适用范围？

---

问题 3：在大量使用开源框架和组件的情况下，软件工程中对“理解原理”的要求应达到什么程度？

教材在讨论工程能力时提到：“程序员不仅要会使用工具，还要理解工具背后的原理。”这一观点强调的是开发者不应只停留在“会用”的层面，而应对系统内部机制有基本理解，这样在出现问题时才能进行分析和改进。

然而在现代软件开发实践中，大量系统都是建立在成熟框架和开源组件之上的。例如 Web 应用通常依赖成熟框架，分布式系统往往基于现成的中间件，机器学习项目则大量使用已有算法库。在很多情况下，开发者并不会深入阅读所有依赖组件的源码，而是通过文档和接口来完成系统开发。

这种方式大大提高了开发效率，也让团队可以把精力集中在业务逻辑和系统设计上，而不必重复实现已经成熟的技术方案。但与此同时，系统对外部组件的依赖也越来越多。如果对这些组件的原理完全不了解，一旦出现性能问题、兼容性问题或复杂 Bug，排查难度就会明显增加。

在现代软件开发环境中，“理解工具原理”更像是一种能力边界的问题，开发者既不可能也没有必要深入掌握所有依赖组件的实现细节，但又需要对关键技术的工作机制有足够理解。如何在“高效使用组件”和“理解系统原理”之间取得平衡？

---

问题 4：当软件开发技术门槛不断降低时，NABCD 模型中的“竞争优势（C）”应如何理解？

在介绍创新方法时，教材提出可以通过 NABCD 模型分析软件项目，其中 C（Competition）表示竞争，即回答“你的产品有什么竞争优势？为什么用户会选择你的产品而不是竞争对手的产品？”

在过去的软件行业中，技术能力本身往往就是重要的竞争优势。例如某些团队能够开发出更高性能的系统、实现复杂算法，或者在稳定性和扩展性方面明显优于其他产品，这些技术能力往往会形成一定的技术壁垒。

然而随着开发框架、开源组件以及 AI 编程工具的发展，许多软件功能的实现门槛正在明显降低。构建一个 Web 服务、实现数据处理流程甚至开发完整应用原型，都可以借助成熟工具在较短时间内完成。单纯依靠实现某个功能本身，已经越来越难形成长期优势。

在这种变化之下，NABCD 模型中所强调的“竞争优势”应当如何理解？当功能实现越来越容易复制时，软件产品的核心竞争力是否正在发生转移，我们学生又应该如何理解这种新的竞争结构？

---

问题 5：在 AI 可以辅助生成文档的情况下，软件工程中“文档”的价值是否需要重新定位？

教材在多个章节中强调文档的重要性，如“文档不仅是给别人看的，也是给未来的自己看的。没有文档的代码是难以维护的。”在团队开发中，文档通常用于记录系统结构、接口设计以及开发过程中的各种决策。

而在当前的软件开发环境中，一些 AI 工具已经能够根据代码自动生成 README、接口说明甚至系统结构图。这类工具可以快速整理已有代码中的信息，使开发者在阅读项目时更容易理解系统的基本结构。

不过，软件工程中的文档并不仅仅是代码说明。很多关键内容，例如系统架构设计的理由、技术选型时的权衡、开发过程中不同方案之间的比较，往往需要开发者在设计阶段主动记录。这些信息通常无法仅从代码中推导出来，却对系统的长期维护和演进具有重要意义。

如果开发者越来越依赖工具生成文档，那么哪些内容仍然必须由人主动记录？在自动化工具不断发展的背景下，软件工程中的文档实践是否也需要重新划分重点，从而既保证效率，又不丢失系统设计中的关键知识？