个人博客作业 3：回答博客1 提出的问题，提出新问题，并总结收获

最新推荐文章于 2025-12-22 02:04:16 发布

原创最新推荐文章于 2025-12-22 02:04:16 发布 · 247 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#软件工程 #人工智能 #团队开发

回答博客 1 中提出的问题、提出新的问题、总结个人收获，并对课程采用的多种教学方法与 NCL理想教学环境进行反思与评价。

课程：现代软件工程
学期：2025 年秋季
学生：彭怀玉
项目：MyMind思维导图

博客 1：https://blog.youkuaiyun.com/m0_62051253/article/details/153105743?fromshare=blogdetail&sharetype=blogdetail&sharerId=153105743&sharerefer=PC&sharesource=m0_62051253&sharefrom=from_link

一、学期初提出的问题，现在能回答了吗？

回顾博客 1 中阅读《构建之法》提出的五个问题，经过大半个学期的课程实践、团队项目和反复试错，其中部分问题已经有了相对清晰的答案，部分问题则变得更加复杂，但也更具体了。

问题一：用户体验与质量是否只能二选一？

当前理解：

在本学期的项目实践中，我逐渐意识到，用户体验与质量并不是一个非此即彼的选择题，而更像是一个系统工程问题。所谓“质量”，并不是抽象意义上越高越好，而是是否服务于用户在特定使用场景下的目标需求。很多看似是用户体验与质量之间的冲突，实际上源于对真实用户理解得不够深入，导致问题被错误地建模。通过重新审视需求本身，而不是在既定方案中做取舍，往往可以找到所谓的“第三条路”，就像在博客一中我举到的医用眼罩案例一样，并非牺牲成像质量，而是通过需求重构缓解用户的不适体验，解决了问题。

我的观点：

这是一个假对立的问题，解决的关键在于能否从真实的用户体验出发，重新找准需求和问题。

问题二：创新是否具有时代局限？如何评价失败的创新？

当前理解：

通过老师在博客一评论区中的回复以及课程上的讨论，我逐渐意识到，创新不能脱离具体的时代背景来评价。技术是否先进只是其中一个方面，更关键的是要将创新放在技术成熟度、市场窗口和成本结构共同构成的背景中来看。以博客一的铱星计划为例，其目标市场规模不足以支撑长期商业运作，从而导致产品价值与现实回报之间出现明显落差，最终只能宣布破产。

我的观点：
创新并非非黑即白，而是是否在合适的时间，以合适的规模，服务合适的人。

问题三：大众对新技术的接受曲线是否已经过时？

当前理解：

本课程中 AI 工具的高频使用让我对这一问题有了更加深刻且具体的认识。不可否认的是，AI 显著降低了新技术的理解成本，使得普通人能够更快“看懂”甚至“用上”前沿工具，老师也在课堂上发出了“AI时代，人人都是乔布斯”的感慨。但信任成本、迁移成本以及使用习惯的改变成本依然是真实存在。很多新的技术在短期内能够引发快速的尝鲜热潮，却很难转化为长期、稳定的使用行为。

我的观点：
大众对新技术的接受曲线并未消失，而是被压缩并呈现出分层特征。这里的鸿沟，已经从“是否理解新技术”转变为“是否值得为其长期改变行为方式”。

问题四：持续讨论 vs 每周例会，哪种更高效？

当前理解：

我在团队项目中担任项目组长，我切身体会到这两种方式各自可能走向低效的极端。缺乏充分准备的“持续讨论”往往会演变为漫无边际的拉扯，而缺少明确产出的例会则很容易形式化，成为例行公事。问题并不在于会议形式本身，而在于是否具备清晰的决策目标，以及是否有人真正对讨论结果负责。

我的观点：

会议效率并不取决于采用哪种形式，而取决于目标是否明确、责任是否清晰，以及是否对会后继续推进决策与执行有帮助。

问题五：远程异步协作能否替代结对编程？

当前理解：

在本学期大量使用 AI 辅助开发和远程协作工具后，我逐渐形成了一种更细分的认识。异步协作在方案设计、代码审查以及复杂问题的独立思考阶段具有明显优势，而结对编程在面对高复杂度问题、需要快速建立认知共识时，依然具有不可替代的价值。在一定程度上，AI 已经承担了部分“虚拟结对者”的角色，帮助开发者进行即时反馈和思路校正，但它并不能完全取代人与人之间的协作互动。

我的观点：

远程异步协作与结对编程并非替代关系，而是在不同阶段各自更优的选择。但是结对编程的特殊性需要强调，异步协作在团队项目中往往变成了多个AI的协作，成员获得的成长有多少我真的说不清楚，而结对编程是一次实实在在与人协作的体验。

二、AI 时代的软件开发：我产生的新问题

在《现代软件工程》这门课中，我感受到 AI 工具已经逐渐成为编程和软件开发中无法忽视的一部分。无论是在代码编写、问题排查，还是在理解新技术、新框架的过程中，AI 都能提供快速而直接的帮助。随着使用频率的增加，AI 不再只是一个效率工具，更参与到了软件工程的多个关键环节中。这也使我产生了以下几个问题：

问题一：AI 参与开发后，软件工程中的质量和个人能力应如何评价？

在传统的软件开发中，代码质量往往被视为衡量工程水平和个人能力的重要指标。然而，当大量代码可以由 AI 生成时，代码本身是否仍然能够真实反映工程师的能力，成为一个值得讨论的问题。如果不同工程师在相同需求下都能借助 AI 生成结构相似、风格接近的代码，那么“谁写得更好”似乎不再那么容易区分。

在我看来，
代码质量本身并不会消失其价值，但它正在从“个人编码能力的直接体现”转变为“工程判断能力的结果”。在 AI 参与下，真正拉开差距的，可能不再是能否写出一段代码，而是能否提出正确的问题、判断 AI 输出是否可靠，并在复杂约束条件下对方案进行取舍。

问题二：当编码成本显著降低时，工程师的核心竞争力正在向哪里转移？

随着 AI 大幅降低编码门槛，越来越多的时间和精力被释放出来，用于需求分析、系统设计和方案权衡。这也引发了一个现实问题：当“把代码写出来”不再是最难的部分时，工程师的核心竞争力究竟体现在哪里？

在我看来，
工程师的价值正在逐步从“实现能力”转向“建模能力”和“决策能力”。是否能够准确理解需求本质、在多种技术方案中做出合理选择、并清楚地向他人（包括 AI）表达自己的设计意图，正在成为比单纯编码更重要的能力。

问题三：软件工程是否正在从“写程序”转向“设计人–AI 协作系统”？

在项目实践中，我逐渐意识到，软件工程不再只是人与计算机之间的关系，而是变成了“人—AI—系统”共同参与的复杂协作过程。工程师不仅要设计系统功能，还需要设计人与 AI 之间的协作方式。

在我看来，
软件工程的重心正在发生微妙但深刻的变化。未来的工程问题，可能不只是“系统如何实现”，而是“哪些工作由人完成、哪些工作交给 AI、两者如何协同”。这意味着工程师需要具备从系统层面思考协作结构的能力，而不仅仅是关注代码本身。

问题四：在 AI 辅助开发的团队中，如何避免“假协作、真单点依赖”？

AI 的引入在一定程度上降低了个人完成任务的门槛，但也可能掩盖团队协作中的结构性问题。例如，表面上看每个人都在使用 AI 编码，项目进展顺利，但实际上关键逻辑、部署流程或系统理解仍然集中在少数人甚至单一成员手中。

在我看来，
AI 并不会自动解决协作问题，反而可能放大已有的组织风险。如何通过明确的分工、代码审查和知识共享机制，确保团队成员对系统有真实理解可能是很重要的，而不是依赖某个掌握全局的人或某个最会用 AI 的人。

三、对 NCL 理想教学环境与本课程的评价

在学期初，老师向我们介绍了 NCL 所提出的理想教学环境，其核心强调真实情境下的实践驱动、学生的主动参与，以及持续反馈与反思。在课程接近尾声时回顾《现代软件工程》的整体教学安排，我认为本课程在理念层面与 NCL 的设想高度一致，并在一定程度上打破了我以往对“软件工程课”的刻板印象。

1. 本课程与 NCL 的契合点

Natural：
课程通过真实项目、开放问题和不可预期的团队协作过程，让我第一次感受到失败、本身就是工程的一部分，而不是围绕考试结果进行优化。

Critical：
无论是公开博客、课堂讨论，还是项目复盘，都不断促使学生解释为什么这样做，而不是寻找唯一正确答案。

Learning：
课程并未以某一次提交或阶段性成果作为终点，而是通过 Alpha、Beta 等阶段设计，让问题在推进中不断暴露不断建模不断解决。

2. 对本学期教学方式的反思与评价

公开博客 + 千帆竞发图：以公开博客作为主要作业提交方式，使我在整个学期中形成了持续输出和阶段性反思的习惯。相比一次性交作业，这种形式更强调过程本身，也更容易暴露思考中的漏洞。但在实际执行中，我也感受到一定的形式化风险：当输出本身成为目标时，反思的深度可能会被弱化。如果能在评价中更强调内容质量而非完成度，这一方式的价值会更加充分。
结对编程 & API 驱动开发：结对编程和 API 驱动的开发方式，让我第一次切身感受到协作成本的存在。很多问题并非源于技术难度，而是来自接口定义不清、任务边界模糊以及沟通不充分。这种体验让我意识到，软件工程中代码能不能跑只是最低要求，更重要的是系统是否具备可协作性和可扩展性。
pq 问答与 UX 现场测试：在课堂上，老师通过 PQ 系统出题，我们在手机小程序上即时作答，这种方式让我必须随时理解和应用知识，而不是事后才复盘。UX 现场测试则是在真实操作中观察用户使用系统，并提出批评和改进建议。这让我开始从使用者的角度审视软件设计，不仅要关注功能是否实现，更要考虑用户的理解成本、操作便利性和整体体验。通过这两个环节，我才真正体会到，软件工程不仅是对机器负责，更是对人的行为和体验负责。
学生自主组队 + alpha 后人员流动：学生自主组队并在 Alpha 阶段后引入人员流动机制，在心理层面带来了不小冲击。它迫使我们正视沟通效率、责任分配以及组织结构的问题，而不是默认大家都会积极参与。这种不稳定性虽然增加了不确定性，但也更贴近真实工程环境中人员变动和角色调整的常态。
业界专家分享 + Demo：业界专家的分享和现场 Demo，在我看来是本课程中非常重要的一环。它有效拉开了学生项目与真实工程之间的距离，让我意识到能做出来和能长期使用之间存在巨大差异。这些案例帮助我重新校准了对系统可用性、可靠性和工程成熟度的判断标准。
天使投资式评选：以天使投资的方式评选团队项目，使我第一次从资源投入和价值回报的角度审视自己的项目。这种评价方式明确区分了技术上的正确性与项目整体成功之间的差异，也让我意识到，在真实世界中，工程决策往往需要在不完美条件下权衡风险与收益。
补充建议：在团队项目中，我发现一个长期存在的问题是，部分组员缺乏主动性，只想着混个分数，难以真正参与任务的深度讨论和实际开发。这种情况下，团队整体效率和创新能力都会受到影响。我在想，如果在团队成立之初，就能设计一定的激励与约束机制，比如提供适度的资金或酬劳，明确“聘用与开除”规则，让每个成员对自己的贡献和责任有清晰认知。可能会更有活力，也更接近真实工程环境。这不仅可以调动大家的积极性，还能在实践中锻炼我们面对真实组织问题的能力，让课程项目更贴近未来工作的体验。

四、基于能力评价表的自我快速评估

提升最明显的方面：

第五维：智能开发与人机协同：在团队项目中，我逐渐学会如何将模糊的想法清晰地传达给 AI 工具，并将其输出转化为可执行方案。人-AI-人的协作链条中，我能够发挥主导作用，优化团队的协作流程，这让我在需求理解和方案落地上效率明显提升。
第二维：AI 原生架构与沟通设计：本学期的项目实践让我深刻体会到，将业务需求转化为清晰架构并推动团队达成共识，是工程设计中至关重要的一环。我逐渐提高了进行跨角色沟通的能力，确保团队对架构方案的理解一致。
第六维：工程领导与系统权衡：本学期，我担任了项目组长这一角色。需要协调组员任务分配、兼顾各模块开发进度和资源使用，使我对多维约束下的系统决策和团队领导能力有了更直观的感受。