[I.3] 个人作业：结课总结

[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	2026年春季软件工程 (北京航空航天大学 - 计算机学院)
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	在真实项目中实践软件工程方法，理解工程化思维，提升团队协作与交付能力
这个作业在哪个具体方面帮助我实现目标	通过回顾一学期的学习与实践，系统梳理知识点，巩固“做中学”的收获

一、回顾与链接

学期初，我在阅读《构建之法》等材料后，在案博客中记录了自己对软件工程的一些疑惑。
🔗 I.2案例分析

如今经历了一个完整的学期，完成了个人项目、结对项目与两个阶段的团队项目，再回头看当初的问题，发现很多困惑已经在实践中得到了解答。

---

二、对自己曾经提出的问题的解答

我在当初的博客中主要提出了以下几个问题，现在尝试一一回答。

问题一：功能“面面俱到”还是“做一件事并把它做好”？

解答：
经过一学期的阅读、实践与讨论，我认为这并非二元对立。Unix 哲学与 Super App 的冲突背后，是产品所处生命周期和核心价值的差异。

• 初创期/垂直工具：应严格遵循“杀手功能优先”，把10X原则做到极致。过多的外围功能不仅稀释核心体验，还会因为希克定律让用户决策瘫痪。
• 平台期/Super App：当产品已经成为一个生态或基础设施时，“大而全”变成一种防御性壁垒和用户停留时长的保证。此时功能增加不是在做“加法”，而是在构建“场景矩阵”，让用户无需离开。

问题二：如何合理奖励末端治理与前期治理？

解答：
目前我认识到，完全依靠机制自动记录防火者功绩依然很难，但可以通过一定的规则来缓解。

• 在团队项目中，我们强制要求所有风险预警、设计评审意见都记录在文档和 issue 中，并在迭代回顾会议上专门设立风险预警表彰。这让早期提建议的人得到可见的认可。
• 救火英雄虽然值得感谢，但必须同时对引发火灾的流程缺失复盘。我们可以做到，不让救火成为晋升的唯一路径。

问题三：先发优势还是后发优势？如何平衡？

解答：
通过读书、查阅资料，以及在团队项目中的决策，我形成了以下判断框架：

• 如果市场有限，用户依赖很高，先发很重要。比如卡拉比丘作为率先进行FPS结合变维的游戏，后来者很难挤占市场。
• 如果技术路线不成熟，或者先发者已经暴露了致命缺陷，那么后发而先至是更聪明的工程策略。
  后发先至的度在于：后用别人验证过的需求，但要在执行力和体验上做到先至。比如谷歌做搜索、苹果做 iPod 都是如此。
  我们团队项目第一阶段选择了紧跟如今AI潮流与论文阅读需求，但通过差异化的智能总结与知识图谱功能获取了测试用户认可，这就是一次小的“后发先至”。前提是团队有快速迭代和精准定位痛点的能力。如果没有这种素质，先发可能会拖死，后发则永远落后。

问题四：AI 时代 “小作坊” 如何保持竞争力？

解答：
经过这学期的实践观察和思考，我的回答是：AI 时代小作坊的竞争力，正从拼技术堆砌转向对细分场景的极致理解 + 快速创新迭代。算力与基础模型已被巨头垄断，但巨头难以覆盖每一个垂直领域里的独特需求——无论是行业知识、用户习惯，还是未被满足的趣味玩法。小团队利用成熟工具链上做创意组合，完全可以在一个狭窄赛道做到 90 分的体验，而巨头只能提供 70 分的通用方案。

• 游戏领域就是最鲜活的例证。小厂没有大厂的资金和美术资源，做不出 3A 级的画面和物理引擎，但玩法创新能瞬间打破壁垒。最近爆火的《Meccha Chameleon》，将“躲猫猫”与“绘画”两个看似不相关的玩法巧妙融合，让玩家在伪装与识破中获得前所未有的社交乐趣——上线短短几周下载量突破 200 万，用户好评如潮。这说明，玩家要的不是堆料，而是“原来还能这么玩”的惊喜。小作坊正是凭借对某一类玩家心理的深度洞察，用轻量级实现快速试错，反而比大厂更敏捷。

所以，小作坊并未退化，前提是必须拥有一位真正懂该领域的匠人，他未必会写最复杂的代码，但一定懂得如何在细节处制造惊喜和创新。这种竞争力恰恰是 AI 时代留给创新者最公平的窗口。

问题五：兼容性是否拥有超越健壮性的权利？

解答：
结合书本和这学期项目实践，我认为这是一个战略取舍问题，没有绝对答案，但有清晰的决策依据：

• To B/平台型产品：兼容性即生存权。企业用户切换成本极高，一旦破坏兼容，会瞬间失去阵地。Windows 的做法符合“生态责任”，即使代码有历史负担。
• To C/初创产品：可以学习 macOS 的优雅斩断，前提是你用极强的创新体验弥补用户迁移成本。
  在我们自己的团队项目中，初期设计数据库 schema 时留下了一点不完美的字段，重构会花两天，保留则永远别扭。最终我们选择在发布前彻底修复，因为用户基数为 0，还没有兼容包袱。什么阶段做什么选择，健壮性是长期资本，兼容性是当下存活，鱼与熊掌在不同阶段权重不同。

---

四、各阶段的知识点总结

阶段	学到的知识点	简要说明
需求	用户故事	我们最初把需求写成“系统要有登录功能”，后来学会用“作为<角色>，我想要<功能>，以便<价值>”的格式，并附上可测试的验收条件。这让需求更聚焦于用户价值，也方便测试用例设计。
设计	依赖倒置原则	在设计中，我们通过定义接口让高层模块不依赖低层模块的具体实现。后期更换数据库访问层时，只需实现同一接口即可，体会到了面向接口设计的威力。
实现	持续集成	团队初期经常出现合并冲突。引入 CI 后，每次提交都会自动构建并运行基本测试，问题被及早发现，提高了代码集成频率和信心。
测试	测试金字塔	知道了单元测试、集成测试、端到端测试的比例应该合理。我们项目中对核心逻辑写了较多单元测试，API 层做集成测试，UI 只做少量端到端冒烟测试，既保证了质量又没有拖慢开发。
发布	可靠发布	虽然课程项目规模不大，但我们建立了简单的 CI/CD 流程，每次提交代码自动运行测试和部署，确保了发布的可靠性。
维护	日志与监控	项目上线后，用户反馈的有些 bug 很难复现。需要靠可靠的日志系统来跟踪。

---

五、经历与心得

个人项目

个人项目中，我第一次独立完成从需求分析到代码实现的全流程，并练习了AI辅助编程、文档编写与测试驱动等实践。实际写起来才发现，让AI生成可用的代码片段需要反复调整提示词、验证输出正确性；文档也不是最后补几句话就能交差，而是要清晰地说明设计决策和使用方式；测试更是得考虑各种边界和异常场景。

结对编程

结对项目是用 WebAssembly 实现“花见小路”桌游的核心逻辑，两人采用经典的领航员-驾驶员模式：一人写代码，另一人实时审查、提示思路并记录待办。同时，WebAssembly 本身涉及类似C++的边界交互，类型转换和内存管理，很容易出错，领航员的角色帮我们避免了很多这方面的问题。我最大的心得是：结对不是一个人干活另一个人看着，而是两个人的实时代码编写和审查，让代码更加健壮。

团队项目

两个阶段的团队项目是整个课程最忙碌的时期。
在项目的Alpha阶段中，我们因为分工模糊，有人忙死有人闲。在Beta阶段后，我们引入了明确的角色和任务认领机制，配合每日例会同步进度，团队运转明显更顺畅。
此外，我也体会到技术栈的选取要与项目规模和团队熟悉度相匹配——一个只有几周开发周期、三五人协作的课程项目，经不起花大量时间学习和调试一个庞大而陌生的框架。我们后来坚持够用就好的原则，优先选用大家已有基础的工具，哪怕它看起来没那么新，但能保证每个人都理解其原理，遇到问题也能快速定位和修复。