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

阅读与提问

项目	内容
这个作业属于哪个课程	2026年春季软件工程 - 北京航空航天大学
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	参与一次完整的团队开发工作，熟悉项目协作的全部流程，积累有关软件开发、维护、运营、测试相关的经验，为实习与就业做准备
这个作业在哪个具体方面帮助我实现目标	了解软件工程开发的常见思想，明确软件工程开发的基本概念和业界通识

一、在 AI 辅助编程越来越普及的今天，“刻意练习”的重点是不是应该变了？

作者在《技能的反面》一节中提到：

意识到“基础技能很重要”，“我要学好编程”只是第一步，但是这个和 “我已经会用这个技术” 还是有很大的差距的。怎么达到呢？ 还是要说服自己不断刻意练习，直到脱掉那层“低效的茧子”，形成肌肉记忆。

这里作者大致是想说明：一个程序员如果总在低层次的问题上消耗太多注意力，比如基础语法、工具配置、低级错误、编译环境之类的问题，那他真正的能力就很难发挥出来。作者用 “低效的茧子” 这个比喻，强调了一件事：要靠反复练习，把底层技能练成近乎本能的动作，这样才有余力处理更高层的问题。

这个逻辑应用在许多基础学科（比如记忆高中理科公式）的学习上，我是非常认同的，然而随着时代进步和 AI 技术的发展，如今的软件工程开发环境和作者提出这段话时相比，已经发生了天翻地覆的变化。

现在很多重复性的代码工作，已经越来越容易交给 AI 工具去完成。很多以前需要自己极尽细致完成的接口封装、基础测试、样板代码、数据转换逻辑，现在往往只需要比较清楚地描述需求，就能很快生成一个初稿，至少在我自己以往的开发经验来看，最近最容易卡住我的，往往不是一些底层的 Bug 修不出来，或者是因为一些语法错误导致代码无法运行，而是下面这些问题：

• 需求分析到底有没有讲清楚；
• 每个模块边界划分是否合理，能否做到高内聚低耦合的开发；
• 如何快速判断当 AI 生成代码较长时，在能运行的基础上，是否很好的遵循了我们的要求，实现了相关的底层逻辑；
• 当前的这种设计是否为了眼前的一时简便，透支了未来的可维护性。

所以对于这一节，我的疑问是：在 AI 时代，软件工程师的 “刻意练习” 是否应该从熟练地手写代码，逐渐转向学会高效与 AI 沟通？

当然，我并不否定基本功，毕竟如果没学过 Python 语法的人，连 AI 生成的代码都看不懂，更别说检查 AI 对任务的完成度，但我确实有必要质疑，今天再把 “刻意练习” 的重点主要放在底层代码熟练书写上，或许不仅仅是浪费时间、投入产出比的问题，更有可能会让程序员跟不上时代，试想可能程序员 A 自身的代码实现能力强于 B，但是在实际工作中 B 能更好地借助 AI 的辅助，那这种偏向于应试 / 闭卷考试中禁止使用 AI，只凭个人掌握的模式是否还真正适用于未来的求值与工作？也许更值得被反复训练的，是更高层的工程判断能力。

二、现代软件开发是不是正在走向一种“没有明显阶段边界”的模型？

作者在《团队和流程》一节中提到：

尽管狭隘定义的瀑布模型有这样那样的问题, 我个人认为这个瀑布模型还是反映了人类解决问题的一个常用的模型。它在软件工程中的局限性在于：

· 各步骤之间是分离的，（但是软件的生产过程中的各个步骤不能这样严格分离出来。）

· 回溯修改很困难甚至不可能, (但是软件生产的过程需要时时回溯)

· 最终产品直到最后才出现，（但是软件的客户, 甚至软件工程师本人都需要尽早知道产品的原型, 试用）

在讲瀑布模型局限性时，作者连续指出了几个问题：步骤之间被切得过于分离，软件开发过程却并不能真的这样严格分开；回溯修改很困难，但软件开发偏偏又经常需要不断回溯；最终产品要到最后才出现，可软件客户和开发者其实都需要尽早看到原型、尽早试用。作者这里用了一个 “造车以后才发现还需要倒车灯” 的例子，来说明需求和真实使用场景往往是在过程中才逐渐暴露出来的。

结合我个人的一些开发经历，我非常认同作者此观念，但在此基础上，我还想进一步追问：今天的软件开发，是不是已经不只是“修补瀑布模型”，而是在走向一种阶段边界越来越模糊的模型？

因为随着各方面技术的提升，现在很多软件开发完全不再像过去一样 “先分析后设计，设计后再写代码，编码后进行测试，测试完再发布” 的串行过程了，比如由于 AI 构造数据的能力，很多时候数据采集还没完成时，我们就可以先试用 AI 构造的数据跑通模型的 Pipeline，同时，在我平时接触的大部分软件形态来看，现今的软件更像是一直在线、一直迭代、一直演化的服务，而不是一次性交付的产品。

那在这种背景下，我们还应不应该把软件工程理解成一个阶段非常分明的过程？

• 书里讲的“分析、设计、实现、测试、发布”，到底是现实中必须严格切开的阶段，
• 还是只是帮助我们理解问题的一种分析框架？

如果未来的软件工程越来越像一个持续反馈系统，那么我们真正该学会的，也许不是把阶段背熟，也不是 ”八股“ 地按照先什么后什么，机械地完成工作，而是需要理解软件开发的阶段之间如何高速循环和相互嵌套，以及根据具体的开发需求做灵活的调整和一定程度的并行。

三、面对大量用户反馈，软件团队到底应该“听用户的话”，还是“读懂用户真正想要的东西”？

作者在《用户调研》一节中提到：

找到一群目标用户的代表来讨论用户想要什么, 用户对软件的评价等等。 焦点小组是很常用的调研方法，它也有一些弱点:

• 一群人在一起，往往大家会出于讨好其他人的心理来发表意见，避免不一致的意见或冲突。
• 讨论者对于他们不熟悉的事物 (例如颠覆式的创新) 不能表达有价值的想法 - 在汽车出现之前, 我们找一帮马车夫来畅想 “未来的交通工具”, 他们未必会贡献很有价值的想法。
• 讨论的人群容易受到主持人有意或无意的影响。
• 研究者往往从不同意见中挑选最符合自己想法的哪些，然后号称这就是大家的共识。

在这一讲里，作者列举了很多理解用户的方法，比如焦点小组、深入面谈、卡片分类、问卷调查等。同时，他也没有把这些方法神化，而是明确指出它们各自都有弱点：比如焦点小组容易受主持人影响，参与者也可能为了避免冲突而给出 “安全答案”；深入面谈虽然能挖得很深，但很费时间和人力。也就是说，作者其实已经在提醒我们：用户调研并不是 “只要去问，就能得到真相”。因为很多时候，非专业领域的用户给出的建议非但不能正确指导我们开发的方向，还有可能起到误导 / 反向的作用。

因此这里会自然而然产生一个问题：收集完用户反馈以后，到底应该怎么鉴别、筛选、处理？

如作者所言，现实中的用户反馈往往非常混杂。有些是情绪发泄，有些是局部偏好，有些是短期诉求，有些才是真正值得长期投入解决的核心问题。如果一个团队只是不断收集声音，而没有能力去解释、筛选和转化这些声音，那最后很可能会陷入“用户意见很多，但产品方向越来越乱”的局面。

这一点我自己在日常使用软件和游戏时特别有感觉。很多时候，用户说出来的是一种表层诉求，但真正的问题并不在那句话本身。比如用户会说一款游戏机制 “太复杂” 玩不明白，表面上是在要求简化；但深层问题可能是这个游戏本身的世界观或者设定结构混乱、引导不清楚、反馈不及时。再比如用户常常要求 “更多福利、更少限制、去掉广告”，这些话当然是真实情绪和切实问题，但如果完全照字面去做，产品真的砍掉了相关的广告和限制，反而很有可能失去平衡性或者降低后期发展潜力。

所以的问题是：软件工程里说的“以用户为中心”，到底该怎么精准定位用户原话背后的实际问题，以及如何判断一个用户需求是否有价值被满足或改进？

四、AI 工具越来越强之后，书里这些经典团队模式还会长期成立吗？

作者在《团队和流程》一节中提到：

软件团队有各种形式, 适用于不同的人员和需求。第一感好用的形式未必是最适合的。例如幼儿园大班小朋友的刚开始踢足球的时候, 大家都一窝蜂地去抢球, 球在哪里, 一堆人就跟到哪里, 这是一个好的团队形式么？或者我们完全凭大家的兴趣？

在讨论团队模式时，作者并没有一概而论地判定哪种模式最好，而是强调：软件团队有多种不同的组织方式，它们分别适用于不同的人员条件和不同类型的需求。这一点我其实很赞同，因为软件团队的组织方式本身也是一种需要 “因地制宜” 的工程决策，而不是照着一种模板生搬硬套。

但也正因为作者这样说，即团队的组织方式是需要适配当前团队所处环境和时代，那么如果团队所使用的工具本身发生了巨大变化，团队模式会不会也被改写？

过去一个项目之所以需要很多角色共同完成，是因为很多事情确实必须由不同的人分别承担，但随着 AI 辅助编码、自动化测试、自动文档整理、代码解释与重构建议越来越成熟，一部分原本高度依赖人力的辅助性工作，已经开始被显著压缩。虽然它离 “完全替代工程师”还 很远，但至少已经在改变 “哪些事必须靠人堆出来” 这件事。比如对于曾经需要花费大量人力物力的软件测试环节，现在可以通过 AI + 自动化脚本的方式迅速实现。

这不禁令人思考：未来的软件团队，会不会整体朝着更小型、更灵活、更动态的方向收缩？换句话说，书里那些主治医师式、功能团队式、交响乐团式、社区式等经典模式，未来会不会越来越像一种按任务动态切换的协作编组，而不是长期固定不变的组织形态？

我之所以会这样想，也和我最近对自己所在的团队开发效率变化的感受有关。很多时候团队真正被拖慢的，未必只是技术本身，而常常是沟通成本、协调成本、等待成本。如果以后人与工具的协作越来越高效，那么人与人之间的协作成本，反而可能成为更突出的瓶颈。

所以我真正困惑的是就不该只是记住有哪些模式，而应该学会判断：在什么样的技术条件、项目规模和工具能力下，什么样的组织方式才更合理。

五、在现实团队里，怎么才能避免“承担很少风险的人，却拥有很大的决策权”？

作者《软件工程之动物世界》一节在中提到：

在一个流程漫长, 合作者众多的项目中, 项目的管理者要把每一个环节的RASCI 角色都列出来, 每个环节有且只有一个R.

在 “猪、鸡、鹦鹉” 和 RASCI 模型相关内容里，作者非常强调责任边界。谁负责执行，谁承担全责，谁提供支持，谁被咨询，谁被告知，都应该在复杂协作中被明确区分。尤其是作者提到，在流程漫长、参与者很多的项目里，管理者应该把每个环节的 RASCI 角色都列出来，而且每个环节有且只有一个 R。作者还顺带提到现实中常见的 “影评家” 式角色，也就是那些不真正参与拍电影、却非常喜欢评价电影的人。这个提醒其实非常有现实感。

但我读到这里时，却有了这样一个疑问：现实团队里，真的只要把角色写清楚，就能避免“责任和权力错位”吗？

因为我在以往的课程项目、小组协作、大作业的开发中，经常感觉到一种很尴尬的现象：真正熬夜写代码、修 Bug、扛 deadline 的人，反而未必拥有足够的决策权；而一些不直接承担结果的人，却可以不断提出要求、增加约束，甚至拥有事实上的否决权。

这就会出现一种非常别扭的局面：

• 决定方向的人，不一定承担后果；
• 承担后果的人，却不一定能决定方向。

在这种情况下，就算纸面上把 R、A、S、C、I 都写清楚了，实际运行起来也可能完全不是那么回事。因为现实里还会掺杂很多模型之外的因素：层级、资历、表达能力、资源掌握、谁更会开会、谁更会汇报，等等。

所以我真正想问的是：软件工程中的责任划分，到底为了沟通和效率，还是应该进一步和参与者决策权、考核方式等绑定起来？

如果不绑定，我认为很多角色分工最后都会流于形式。书里讲 “谁负责” 当然没问题，但很多时候也仅限于理论或者理想团队，现实里的难点恰恰在于：怎么让真正负责的人，拥有与责任相匹配的话语权。

这也是我读完这一部分之后，觉得最现实，也和我们当前组内沟通与作业协作开发最相关的一个问题。

---