北航2026软件工程作业 - I.1 阅读与提问
北航2026软件工程作业 - I.1 阅读与提问
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 北航2026年春季软件工程 |
| 这个作业的要求在哪里 | [I.1] 个人作业：阅读和提问 |
| 我在这个课程的目标是 | 接触理解应用现代软件工程常用的开发方式，锻炼自己编写代码以及团队协作的能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 初步接触到软件工程中常用的开发模式与团队协作方法，对现代软件工程的应用和实践场景有了初步的了解 |
问题一
一、内容
在大模型和AI辅助编程普及的今天，教材中提到的“通过刻意练习底层代码形成肌肉记忆以脱掉低效的茧子”，其核心定义是否需要被重构？在未来的软件工程实践中，传统手写底层代码的肌肉记忆，是否反而会限制开发者向系统架构师与AI协同者转型？
二、 支持我提问的事例与资料
- AI编程工具的大规模应用数据：
根据 GitHub 发布的研究报告显示，使用 GitHub Copilot 的开发者中，有大约 46% 的代码是由 AI 自动生成的，且开发速度提升了 55%。这意味着，传统意义上需要通过肌肉记忆来快速盲打的固定模式代码（如正则表达、数据转换、标准CRUD接口等），已经被自动化工具替代。 - AI 软件工程师的出现：
2024年，全球首个AI软件工程师 Devin 问世，它能够根据自然语言指令，自主完成环境配置、代码编写、Bug修复甚至自动部署。在这种技术背景下，人类工程师如果把精力依然放在刻意练习写具体代码上，其竞争力将远不如能够做好上层架构设计和业务需求拆解的工程师。 - 软件工程发展史的间接经验：
回顾软件工程历史，技术的每一次跃迁都在消灭底层的肌肉记忆。C语言消灭了汇编语言中手动分配寄存器的肌肉记忆；Java/Python等高级语言消灭了手动管理内存的肌肉记忆。如今的 Generative AI，正在消灭手写基础逻辑代码的肌肉记忆。
三、 我提出该问题的原因
我之所以提出这个问题，主要是因为教材中的描述与我的经验产生了矛盾，并且我认为教材立论的底层假设与当今时代背景产生了冲突。
- 与我的实际经验相矛盾：
在我的编程实践中以及观察行业大佬的开发模式中，我发现真正导致“低效”的，往往不是键盘敲得慢或底层语法不熟练，而是前期需求没拆解清楚、架构设计存在缺陷，或者对业务逻辑的理解出现偏差。现在遇到底层代码的实现，我完全可以通过精准的 Prompt让 AI 瞬间完成，我只需进行代码审查。因此，我觉得花大量时间对底层代码进行“肌肉记忆的刻意练习”，投入产出比在当今时代有所降低。 - 底层假设的不同：
- 教材的假设： 软件开发的瓶颈在于把逻辑转化为代码的熟练度，因此需要通过刻意练习形成肌肉记忆，来提高这部分的吞吐量。
- 我的假设： 随着AI时代的到来，逻辑到代码的转化已经不再是瓶颈，变成了廉价的计算力。现代软件开发的真正瓶颈在于模糊需求的精准定义、复杂系统的架构设计以及对AI生成代码的鉴别与质量控制”。
因此，我认同需要刻意练习，但我不认同刻意练习的对象依然是底层代码。我认为我们应该刻意练习的，是系统设计和与AI协作的能力。
问题二
一、 内容
在抛弃了单向不可逆的狭隘瀑布模型后，现代工业界已经全面转向了敏捷与 DevOps。我想探讨的是：在当今云计算、持续集成甚至 AI 自动化测试普及的背景下，软件工程开发是否正在走向一种无明显阶段边界的模型？面对未来，我们要追求的理想模型，是不是一个模糊了设计、开发、测试、运维界限的模型？
二、 支持我提问的事例与资料
- “最小可行性产品”：
当今如微信、抖音等超级应用，甚至 OpenAI 的 ChatGPT，其最初版本都是极其简陋的 MVP。现代工业界不再追求一次性交付完美产品，而是通过“构建 - 测量 - 学习”的极速循环，让产品在第一周就面世，随后根据真实用户数据进行高频迭代。 - DevOps 与 CI/CD 的普及：
根据业界调查，像亚马逊、谷歌这样的顶尖科技公司，每天的生产环境部署次数多达数千次甚至上万次。开发人员提交一段代码，几分钟内就会经过自动化测试并部署到全球用户的手机上。写代码和发版不再是两个孤立的阶段。 - 软件形态的转变：
过去软件像建筑一样，卖出去（如 Windows 95 光盘）就无法轻易修改，所以需要瀑布模型。现在的软件大多是 SaaS，运行在云端。修改一个 Bug 的成本从召回数百万张光盘变成了刷新一下服务器。
三、 我提出该问题的原因
我提出这个问题，是因为书中描述的生产模型，与我目前观察到的现代软件开发经验存在矛盾，瀑布模型中的高昂修改成本与当今软件产品要求的低修改成本不吻合，这源于行业底层假设的改变：
- 旧假设被颠覆： 瀑布模型从建筑工程借用经验，其隐含的底层假设是：后期的修改成本极其高昂，因此前期设计必须绝对完美。但在如今的软件工程中，有了 Git、Docker、云原生微服务平台以及 AI 辅助，修改代码和回退版本的成本已经降低。
- 对未来模型演进的推演： 既然修改成本极低，那么我们追求的理想模型，不应再纠结于如何通过完美的计划来防范错误，而是应该追求如何建立一套能够最快发现错误并修复的系统。
- 与 AI 时代的共鸣： 结合我之前提出的第一个问题，在未来的开发模型中，人类或许只需要在分析需求和查看反馈数据两端工作，中间的“设计 -> 实现 -> 测试 -> 部署”流程，将由 AI 代理在几秒钟内形成一个黑盒自动完成。
问题三
一、 内容
讲义中列举了10种获取用户反馈的方法，其隐含前提似乎是“只要我们准确听到了用户的声音，就能做出好产品”。但我对此存疑。我想探讨的是：
- 在海量的反馈中，我们应如何建立一套机制，以区分高价值的核心诉求与低价值的情绪发泄？
- 当用户的诉求（如游戏玩家要求提高免费福利、降低难度）与产品的商业目标（如维持盈利、保证生命周期）发生冲突时，软件工程实践中应当采用什么样的决策模型来平衡这种取舍，而不是盲目陷入用户至上的教条主义？
二、 支持我提问的事例与资料
- “福特造车”悖论与用户认知的局限性：
汽车大王亨利·福特曾有一句名言：“如果我当年去问顾客想要什么，他们肯定会告诉我，想要一匹更快的马。” 这说明用户往往只能基于现有认知提出表面解决方案，而不是真正的需求。在游戏体验中，玩家抱怨“某个Boss太难，要求削弱Boss”，但其实高价值的反馈可能是 Boss战缺乏合理的正反馈机制或视觉引导。 - 《魔兽世界》“疲劳系统”的心理学博弈：
暴雪在开发《魔兽世界》早期，为了防止玩家沉迷，设计了疲劳系统——玩的时间越长，扣除的经验值越多。这遭到了玩家的抵制。后来暴雪没有改变任何数值平衡，仅仅换了一种说法：“正常经验值定为原本的50%，玩家休息后上线会获得200%的‘双倍经验奖励’”。玩家立刻对这个“福利”赞不绝口。这证明，用户的直接反馈有时不仅不能字面采纳，还需要通过心理学和产品包装去“欺骗”或“引导”。 - 福利通货膨胀导致游戏死亡：
在现代手游运营中，如果完全听从玩家“增加抽卡福利、提高爆率”的反馈，短期内玩家会很开心，但几个月后就会因为数值膨胀、失去追求目标而迅速流失，同时公司的营收也会崩盘。这证明了用户短期诉求与产品长期生态之间存在天然矛盾。
三、 我提出该问题的原因
我之所以提出这个问题，是因为书中的方法论假设与我在实际游戏体验中观察到的现象存在差异。
- 书中的局限性：
书里列举的焦点小组、问卷调查等方法，都在教我们如何听用户说话。这容易给初学者一种错觉：只要听话，就是好工程师/好产品经理。 - 我的实际经验与思考：
我发现真正的难点根本不在于收集反馈，现代软件有无数种探针和埋点技术可以收集海量数据。真正的难点在于转化与过滤。很多时候，用户是“贪婪且短视”的（例如要求全部免费、去广告），而开发团队是背负着生存压力的。 - 我渴望找到的答案：
我提出这个问题，希望在《软件工程》这门课中探讨：我们是否需要一套需求过滤模型？比如，不看用户“怎么说”，只看用户“怎么做”；或者探讨在遇到商业目标冲突时，如何寻找双赢的替代方案，在不损害商业利益的前提下，用最低的成本提供最大的情绪价值，这才是现代软件工程中最具挑战的艺术。
问题四
一、 内容
教材中列举了从“主治医师”到“功能团队”、“交响乐团”等十几种团队模式。我想探讨的是：
- 在复杂多变的现代软件工业中，我们是不是更应该采取多变的团队协作方式？
- 结合前沿趋势，随着 AI Agent能够承担越来越多原本辅助开发、测试、运维的工作，未来的软件团队是否会变成单纯的vibe coding？
二、 支持我提问的事例与资料
- 康威定律对“通配法”的否定：
软件工程界著名的康威定律指出：“设计系统的组织，其产生的设计等同于该组织内部沟通结构的副本。”- 如果你要开发底层操作系统（如Linux），你就需要“社区模式/开源模式”。
- 如果你要开发紧密耦合的航天飞机控制系统，你就需要强控制的“交响乐团/官僚模式”。
- 如果你要做快速试错的互联网 SaaS 业务，你就需要“功能团队”。
- 现代大厂的“动态混合通配”方案：Spotify 模型与亚马逊双披萨团队：
虽然没有绝对的通配模型，但现代大厂找到了一种接近通配的元模型。比如亚马逊的“两张披萨团队”（团队人数不超过吃掉两张披萨的规模），以及 Spotify 的“小队、部落、行会”模型。这些模型本质上都是“功能团队”与“爵士乐队”的结合体——平时是跨职能的功能团队，遇到技术攻坚时又能在内部按专业行会交流。 - AI 时代的组织结构坍缩：
根据目前 Cursor、Devin 等 AI 开发工具的展现出的能力，现在的创业公司不再需要组建包含前端、后端、测试、DBA 的庞大“交响乐团”。一个具备强架构能力的人，带着几个 AI Agent，就能完成一个复杂 App 的开发。团队形式正在被技术重塑。
三、 我提出该问题的原因
- 底层假设的探讨：
教科书假设“人”是组成不同团队的唯一变量，因此分工极度细化。但我假设，一旦工具极其强大，人与人之间的协作成本将远大于人与机器的协作成本。因此我怀疑，未来并没有那么多复杂的团队模式，最终最有效的只有一种：“超级个体 + 智能工具”构成的微型战斗小组。
问题五
一、 内容
教材中生动地用“猪、鸡、鹦鹉”的比喻和 RASCI 模型刻画了团队中不同的投入级别与责任界限。我想进一步探讨的是：
- 在复杂的矩阵式组织或跨部门协作中，我们如何从制度和工程文化的层面，防止“鹦鹉”获得“猪”的决策权与否决权？
- 既然一个健康的软件生态同时需要这三种角色，作为现代软件工程师，我们应该如何建立一种“角色切换机制”，让自己在核心项目中做一头“猪”，在边缘项目中做一只“鸡”，同时在技术布道时做一只有价值的“鹦鹉”，而不是在所有项目中都盲目透支精力？
二、 支持我提问的事例与资料
- 风险共担理论：
著名学者纳西姆·塔勒布在其著作《非对称风险》中提出，系统的崩溃往往源于决策者不承担决策带来的后果。在软件工程中，这就是典型的“鹦鹉治国”——高管、架构评审委员会或外部顾问强制推行某种技术栈或流程，但当项目延期或出现重大 Bug 时，加班熬夜甚至背锅被裁的却是第一线的开发人员。 - 大型开源项目的健康生态：
在成功的开源社区（比如 Linux）中，角色的划分极其明确且运转良好。- 猪： 拥有代码合并权，对项目成败负全责。
- 鸡： 业余时间提交几个 PR 修复Bug，不承担项目长远规划的压力。
- 鹦鹉： 虽然不写代码，但负责写教程、做宣讲，吸引更多人使用。
- 大厂的“大公司病”与 RASCI 模型的失真：
在很多大型企业中，一个需求落地往往要拉几十人的大群。由于流程繁琐，RASCI 模型中的 R 只有几个底层程序员，而 A 和 C 却有一大堆。很多项目并非死于技术难度，而是死于需要向无数只鹦鹉汇报并获取批准。
三、 我提出该问题的原因
- 与理想化假设的矛盾：
书中假设大家只要明确了“谁是猪、谁是鸡”，就能各司其职，“重大决定由猪来定夺”。但我认为这违背了职场的人性规律。在现实中，人性往往驱使人们去追求“鹦鹉的权力”，同时规避“猪的风险”。因此，光靠说清楚角色是不够的，必须探讨背后的强制约束机制。 - 对个人职业发展的困惑与思考：
现在的软件工程教育往往鼓励学生在事情上都做到 100% 的投入。但我认识到人的精力是有限的。如果不学会在某些非核心事务上“做一只按时下班的鸡”，或者在需要扩大影响力的场合“做一只擅长PPT和演讲的鹦鹉”，工程师就会陷入过度劳累。所以我希望探讨这三种角色的合理取舍。
浙公网安备 33010602011771号