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

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

项目	内容
这个作业属于哪个课程	首页 - 2026年春季软件工程 - 北京航空航天大学 - 班级博客 - 博客园
这个作业的要求在哪里	[I.3] 个人作业：结课总结 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是	学习软工方法论，和团队一起加以实践并合力完成一个软件，提升自己的团队协作能力
这个作业在哪个具体方面帮助我实现目标	通过回顾一个学期的实践与学习，对照学期初阅读《构建之法》时提出的问题进行反思总结，梳理自己在软件工程各阶段中获得的知识点和成长

---

一、提问回顾

链接到以前提问题的博客：[I.1] 个人作业：阅读和提问 - 07090824 - 博客园

在学期开始时，我阅读了《构建之法》全书，提出了五个问题——这些问题大多围绕"AI时代下，传统软件工程方法论是否依然成立"展开。经历了一个学期的结对项目和两个阶段的团队项目后，我对这些问题有了更切身的理解和回答。

---

问题1：结对编程和AI辅助编程相比有哪些优势？

原始问题：当我们将AI视为一个"超级结对者"时，人与人的结对编程的核心价值，是否从"共同生产代码"转向了"共同培养一种AI难以替代的、关于协作、意图传递和即时批判的'元能力'"？

现在的理解：

在结对项目"花见小路"中，我和搭档深度实践了"AI辅助下的结对编程"。我的体会是：结对编程和AI辅助编程不是替代关系，而是互补关系。

在实现 PIMC + Alpha-Beta 剪枝博弈 AI 的过程中，AI 确实承担了大量"写代码"的工作——处理 Rust 的借用检查器报错、生成 xorshift64 伪随机数生成器、实现 Action 4 不重复组合生成算法等。但AI做不到的是：

• 在两人对算法策略有分歧时，通过讨论达成共识——比如评估函数中各因素的权重分配，两个人需要在白板上画出博弈树，逐层推演后才确定方案；
• 即时发现对方逻辑中的漏洞——当我在设计状态机时遗漏了某个边界状态，搭档能立刻指出，而AI只会在你主动提问时才回答；
• 共同拟定给AI的Prompt约束条件——两个人先对齐"我们要让AI做什么、不给AI什么自由度"，再由一人"驾驶"AI生成代码，另一人审查。

结论：AI辅助编程让结对编程从"两个程序员轮流敲键盘"演变成了"两个架构师共同指挥AI完成工程实现"。结对编程的"元能力"——协作沟通、意图对齐、即时互相批判——不但没有被削弱，反而更加重要，因为这些能力直接决定了你们能否高效地驾驭AI。

---

问题2：用户说不清需求，在AI时代我们应如何重新定义"需求"？

原始问题：在AI可以快速生成多种方案来满足模糊需求的今天，团队真正的挑战是否变成了如何与用户共同探索和锚定那个"值得被解决的本质问题"？

现在的理解：

这个问题在团队项目"植胜僵场"的需求分析阶段得到了充分验证。我们的目标用户是喜欢卡牌策略游戏的玩家，但"做一个好玩的卡牌游戏"本身就是一个极度模糊的需求。

我们的做法是：

• 用竞品分析锚定方向：在 I.2 个人作业中，我深入分析了《杀戮尖塔》，对比了《炉石传说》《月圆之夜》《皇室战争》等竞品。通过分析发现，《杀戮尖塔》的成功源于"Roguelike + DBG"的核心机制创新和极强的数值平衡，而它的弱点是缺乏社交属性和美术表现力不足。这些分析直接影响了我们团队项目的选题——做一款融合 PvZ 主题的 Roguelike 卡牌游戏，在保留《杀戮尖塔》策略深度的同时，用更亲和的 PvZ 美术风格降低入门门槛。
• 用 NABCD 框架将模糊需求转化为可验证的目标：N（玩家需要一款轻量但有策略深度的单机卡牌游戏），A（TypeScript + Phaser 实现数据驱动的卡牌战斗系统），B（PvZ 主题降低认知成本、回合制降低操作压力），C（相比《杀戮尖塔》画面更亲和、相比《炉石传说》无付费压力），D（通过 Windows/macOS 双平台发布 Demo 获取反馈）。
• 用原型快速验证：Alpha 阶段我们优先做出了"可完整玩一局"的 Demo。真实玩家反馈告诉我们：UI 清晰度、卡牌术语统一性、地图 HP 归零判定——这些才是玩家真正在乎的"需求"，而不是我们最初在文档里写的那些"酷炫功能"。

结论：AI 可以快速生成原型，但判断"哪个原型值得继续投入"仍然需要人类——需要你对用户、市场和竞品的深入理解。需求的本质不是"用户说了什么"，而是"用户在什么场景下、遇到了什么问题、期望得到什么结果"。AI 可以帮助你更快地探索方案空间，但不能替代你对"本质问题"的判断。

---

问题3：AI时代，详细文档和规格说明书还重要吗？

原始问题：既然AI能同时充当"快速原型生成器"和"动态文档解释器"，那么前期工作的核心是否从"撰写一份静态的详细规格书"转变为"定义一套精确、可迭代的规则、约束与决策逻辑"？

现在的理解：

经过 Alpha 和 Beta 两个阶段，我对这个问题的回答是：文档的形式可以变，但"精确的约束和契约"永远不能缺失。

在"植胜僵场"项目中，我们最重要的一份"文档"其实是 src/data/ 目录下的卡牌、敌人、事件、商店数据结构。这些 TypeScript 类型定义不是传统意义上的"规格说明书"，但它们是项目中最精确的契约——新增一张卡牌时，你不需要去翻几十页的文档，只需要看 CardData 接口的定义就知道必须提供哪些字段。

Alpha 阶段我们的教训是：没有明确验收标准的"需求"等于没有需求。比如"UI 更好看""战斗更有反馈""数值更平衡"这类描述，如果没有截图标准、帧率指标或通关率指标，执行起来就会变成主观判断，最终交付物和预期差距很大。

Beta 阶段我们做了改进：每个 Issue 都尽量写明验收条件（如"顶部栏需要展示 HP、金币、楼层数三项信息""卡牌效果预览需要在鼠标悬停时显示"），并且把关键的模块约定（如 DamageMath 统一伤害计算、ShopService 管理购买逻辑）以代码接口的形式固定下来。

结论：我完全同意当初自己的判断——在 AI 时代，文档的核心价值从"描述怎么做"转向了"定义约束是什么"。代码即文档、接口即契约、类型即规格，只要这些"活的约束"足够精确，AI 就能在约束范围内高效工作。但如果约束本身模糊，AI 的"快速"只会加速方向的失控。

---

问题4：代码能力（语法、语言特性）还属于技能吗？

原始问题：如果AI接管了"语法记忆"和"样板代码生成"，那么程序员的"代码能力"内涵是否正演变为"精准定义问题的能力"和"批判性评估与整合AI所生成代码方案的能力"？

现在的理解：

这个问题我经历了一个"从怀疑到确信"的过程。

在结对项目中，我首次深度使用 AI 辅助编程。AI 确实帮我处理了大量 Rust 语法层面的问题——借用检查、生命周期标注、xorshift64 实现等。那时我甚至觉得"以后不用学语法了"。

但在团队项目中，我在负责前端开发时发现：当你不理解底层机制时，AI生成的代码会变成"你无法审查的黑盒"。有一次 AI 帮我在 Phaser 中实现了一个卡牌拖拽效果，代码能跑但性能很差——因为它在每帧都在重新创建纹理。如果我不理解 Phaser 的渲染管线，我根本看不出这个问题，更不用说修复了。

另一个例子是：我们用 DamageMath 统一了所有伤害和格挡计算。这个模块的逻辑本身不复杂，但涉及卡牌效果、状态叠加、敌人护甲等多层交互。AI 可以帮你写出单个函数的实现，但无法帮你判断"这个计算应该放在哪个模块里""这个接口应该暴露哪些参数""这个设计在未来新增卡牌时会不会崩溃"——这些判断依赖的是对系统整体架构的理解。

结论："代码能力"的内涵确实在演变——从"熟练写出语法正确的代码"变为"精准定义问题、理解系统架构、批判性评估AI输出"的能力。但不深入理解语言特性和底层机制，反而会削弱这种高级评估能力。就像你不会因为有了计算器就不学数学一样，AI 降低的是"计算"的负担，而不是"理解"的要求。

---

问题5：AI深度参与开发后，个人贡献该如何评价？

原始问题：当AI成为团队中一个强大的、普惠的基础能力放大器时，评价个人贡献的坐标系是否应该从"产出物的直接贡献度"转向"在关键决策、方向校准与创造性整合上的差异化影响度"？

现在的理解：

在 6 人团队中，我负责美术和前端。如果用"写了多少行代码"来评价贡献，我的贡献可能不如负责战斗系统核心逻辑的同学。但实际体验告诉我，团队项目的瓶颈往往不在"谁写了更多代码"，而在"信息是否对齐、方向是否一致、关键决策是否正确"。

举个例子：Alpha 阶段我们遇到了 UI 清晰度不足、卡牌术语不统一的问题。这些问题不是某个模块的代码写错了，而是不同人对"卡牌应该展示什么信息""状态效果应该如何描述"的理解不一致。在 Beta 阶段，我推动了 UI 规范的统一——包括战斗顶部栏的信息布局、卡牌效果预览的格式、状态标签的视觉语言——这些工作不产生大量代码，但显著提升了玩家的理解和体验。

在 AI 深度参与的开发模式下，我认为个人贡献的评价应该包含三个维度：

• 决策质量：在关键节点做出了多少正确的技术/设计判断；
• 信息整合：在多长时间内发现并解决了多少"理解不一致"的问题；
• 创造性贡献：提出了多少"如果没有这个人就不会出现"的想法或方案。

结论：AI 让"执行力"不再是区分个人贡献的核心维度——因为每个人都能借助 AI 变得"更能写代码"。真正拉开差距的是判断力、整合力和创造力。一个更能推动项目成功的人，可能不是写得最多最快的人，而是最能有效驾驭 AI、弥合信息差、并做出更优判断的人。

---

二、未解决的问题

回顾这五个问题，大部分都在项目实践中找到了答案或至少理清了思路。

仍然让我困惑的是问题4中隐含的一个更深层的问题：如果未来的 AI 不仅会写代码，还能理解系统架构、做出设计决策——那么"精准定义问题的能力"和"批判性评估AI输出的能力"是否也会被 AI 替代？当 AI 能够完成从需求理解到架构设计到代码实现的全链路时，人类软件工程师的终极价值到底是什么？

这个问题我在本学期还没有找到满意的答案。但我观察到一点：即使是最先进的 AI，目前也无法真正"理解用户"——它可以根据你的 Prompt 生成代码，但无法主动发现"用户真正需要什么"。也许，与真实用户共情、在模糊和矛盾中做出判断、对产品方向负起责任——这些才是 AI 短期内难以替代的人类特质。

---

三、新的问题

随着项目经验的积累，旧的疑惑被解开，但基于新的开发模式，我又产生了以下思考：

新问题1：游戏开发中，如何平衡"数据驱动"的灵活性和"硬编码"的执行效率？

在"植胜僵场"项目中，我们把卡牌、敌人、事件等设计为数据驱动，这使得新增内容非常方便。但随着卡牌数量和状态效果的增多，数据之间的隐式依赖也越来越多——一张卡牌的效果可能依赖某个状态的存在，某个状态又会影响伤害计算。当数据规模达到一定程度，"纯数据驱动"是否会导致调试困难、行为不可预测？是否需要在数据层之上引入更严格的规则引擎？

新问题2：当AI能够生成游戏美术素材时，游戏美术的价值在哪里？

我在团队中负责美术，深刻体会到"画出一张好看的卡牌"和"设计一套统一的视觉语言"是完全不同层级的工作。AI 可以生成单张精美的图片，但无法保证不同图片之间的风格一致性、无法理解某个视觉元素在游戏机制中的功能含义（比如"这个图标需要让玩家在一秒内理解它代表'中毒'状态"）。但随着 AI 的进步，这种差距是否会缩小？游戏美术的护城河在哪里？

---

四、"做中学"——六个阶段的知识点

1. 需求阶段

知识点：NABCD 分析框架 + 竞品分析

在团队项目的选题和需求分析阶段，我学到了 NABCD（Need、Approach、Benefit、Competitor、Delivery）分析框架。但对我帮助更大的是 I.2 作业中对《杀戮尖塔》的深入竞品分析——通过系统地分析一款成功产品的数据量、界面、功能、准确度、用户体验等维度，我真正理解了"为什么这个游戏好玩"以及"它的弱点在哪里"。这种竞品分析的思维方式，直接指导了我们团队项目的方向选择：用 PvZ 的美术亲和力降低 Roguelike 卡牌的上手门槛，同时保留《杀戮尖塔》的策略深度。

核心感悟：需求分析不是"我觉得用户需要什么"，而是"用户在使用现有产品时遇到了什么挫折，我们能否解决这些挫折"。

---

2. 设计阶段

知识点：数据驱动的游戏设计 + 模块化架构

"植胜僵场"采用数据驱动设计——卡牌、敌人、事件、商店物品等核心内容集中在 src/data/ 目录，通过 TypeScript 接口定义数据格式。这种设计的最大优势是：新增一张卡牌不需要修改任何场景逻辑，只需要在数据文件中添加一条记录。这让策划、开发和测试能围绕同一套数据结构协作。

同时，项目逐步形成了模块化架构：core、card、battle、data、ui 等模块各司其职，DamageMath 统一伤害计算，ShopService 管理商店逻辑。这些设计决策让 Beta 阶段的扩展和维护成本显著低于 Alpha 阶段。

核心感悟：设计的核心产出不是好看的图或酷炫的交互，而是清晰的模块边界和稳定的数据契约。好的设计让后续开发变快，差的设计让后续开发变慢。

---

3. 实现阶段

知识点：TypeScript + Phaser 3 游戏开发技术栈

在实现阶段，我深度使用了 TypeScript + Phaser 3 + Vite + Electron 的技术栈。与最初设想中的 Unity/C# 方案相比，Web 技术栈的优势是开发迭代快、调试方便、跨平台打包路线清晰（Electron 同时支持 Windows 和 macOS）。

我主要负责前端的 UI 组件开发——包括战斗顶部栏、卡包面板、商店界面、地图小地图等。在这个过程中我学到了：

• 组件化思维：将 RunStatusBar、DeckPackPanel、ShopPanel 等 UI 组件独立封装，减少重复实现；
• 关注点分离：UI 组件只负责展示，业务逻辑放在对应的 Service 中；
• AI 辅助但需要审查：AI 能快速生成 UI 代码骨架，但性能优化（如 Phaser 纹理复用）、交互细节（如拖拽反馈）需要人工打磨。

核心感悟：实现阶段最有价值的不是"写出了多少功能"，而是代码结构是否经得起后续迭代。如果每次加功能都要改三个不相关的文件，那说明设计有问题。

---

4. 测试阶段

知识点：场景化测试 + 自动化回归测试

在 Alpha 阶段，测试主要靠"开发者自己完整试玩一局"，这种方式虽然能发现流程问题，但效率低且不可复现。Beta 阶段我们建立了 30 个 Node test runner 测试文件，覆盖了地图生成、商店购买、奖励发放、状态效果、存档恢复等核心规则。

我最大的收获是：对于游戏项目，场景化测试比单元测试更能发现玩家会遇到的真问题。比如"地图 HP 归零后失败判定有缺陷"这个 Bug，单元测试很难覆盖到（因为涉及地图交互、战斗结算、UI 跳转等多个模块的协作），但任何一个开发者完整试玩一局都会立刻发现。因此，我们的策略是：自动化测试保护核心规则不退化，场景化手动测试保障整体体验流畅。

核心感悟：测试不是为了"证明代码是对的"，而是为了"在代码变错的时候第一时间知道"。

---

5. 发布阶段

知识点：持续集成 + 多平台打包发布

在发布方面，我们建立了从 npm run typecheck → npm run test → npm run build → Electron 打包的完整流水线。Beta 阶段还制定了发布前的检查清单：是否能新开局、是否能继续游戏、是否能打到 Boss、失败/胜利结算是否正确、资源是否全部加载成功。

Alpha 阶段的公开发布是我们最重要的成果之一——真实玩家反馈暴露出的问题（UI 清晰度、卡牌术语不统一、新手引导缺失），比内部测试发现的任何问题都更有价值。

核心感悟：发布不是"把代码推上去"，而是一个可复现、可验证的工程流程。每一次发布都应该像按下一个按钮一样确定和可靠。

---

6. 维护阶段

知识点：用户反馈驱动的迭代 + 文档同步

从 Alpha 到 Beta，我们的迭代方向完全由用户反馈和内部复盘驱动。Alpha 暴露的五大问题（UI 不清晰、术语不统一、流程边界 Bug、测试不足、场景文件职责过重）直接转化为 Beta 的改进任务。

维护阶段我学到的一个重要教训是：文档必须跟着代码一起更新。Alpha 阶段的某些技术文档描述的还是早期设想的 Unity/C# 方案，与实际采用的 TypeScript + Phaser 技术栈不一致，导致新成员上手时产生困惑。Beta 阶段我们花了时间同步文档，但"文档落后于代码"的问题在快速迭代中始终存在。

核心感悟：维护的前提是"信息可追溯"——你知道当前系统是什么状态、为什么是这个状态、上一次改了什么。没有这些信息，每次修改都是盲人摸象。

---

五、个人项目/结对编程/团队项目的心得

个人项目：学会"批判性地看一个产品"

个人作业（阅读提问和软件案例分析）让我学会了批判性地审视现有软件产品。在分析《杀戮尖塔》时，我不仅体验了其核心玩法，还从数据量、界面、功能、准确度、用户体验、软件效能、适应性等维度系统评估了它的质量，发现了数值溢出 Bug、缺乏社交功能、美术表现力不足等问题，并从软件工程的角度分析了其成因和改进方向。

更重要的是，这个分析直接影响了我们团队项目"植胜僵场"的方向选择——我们试图用 PvZ 主题弥补《杀戮尖塔》美术风格的不足，用更清晰的 UI 信息展示降低新手门槛，这些都是从竞品分析中获得的洞察。

核心感悟：一个好的软件工程师不仅要会"造"，还要会"看"——看出一个产品好在哪、差在哪、为什么。

---

结对编程：AI 时代的新范式

结对项目"花见小路"是我第一次将 AI 辅助编程深度融入工程实践。最大的收获是发现了一种新的开发范式：人类定框架，AI 写代码。

在实现 PIMC + Alpha-Beta 剪枝博弈 AI 的过程中，我和搭档负责推演算法架构、设计启发式评估函数的权重分配，然后将繁琐的 Rust 实现细节（借用检查报错修复、伪随机数生成、Action 组合生成）交给大模型完成。

但我要强调的是，"人类定框架"这四个字说起来轻巧，做起来极难。你需要对问题有足够深入的理解，才能定出正确的框架；你需要对 AI 的输出有足够的批判能力，才能发现它生成的代码中的隐藏 Bug。在 AI 辅助编程时代，"思考的深度"比"打字的速度"重要一百倍。

---

团队项目：软件工程的真正意义

"植胜僵场"从零开始，历经 Alpha 和 Beta 两个阶段，最终成为一个拥有完整地图探索、战斗、奖励、商店、事件、Boss 系统的 Roguelike 卡牌游戏——约 3.9 万行源码和测试代码、30 个测试文件、42 张植物卡牌、30 种敌人、14 个随机事件。这段经历让我理解了软件工程这门学科存在的真正意义。

第一个感悟是：软件 = 程序 + 软件工程。 功能能跑只是第一步，真正让产品可持续的是清晰的数据契约（src/data/）、稳定的模块边界（core/card/battle/ui）、可复现的构建流程（typecheck → test → build → package）、可验证的测试体系（30 个测试文件 + 场景化手动测试）和真实的用户反馈。

第二个感悟是：计划总是被改变，但计划的过程本身有价值。 Alpha 阶段我们拆分任务排期，Beta 阶段我们按优先级推进。虽然实际执行中总有偏差——比如"战斗表现打磨"超预期耗时——但正是因为有了详细的计划，我们才能清楚地知道"偏差了多少"并及时调整优先级。没有计划的团队，连自己落后了都不知道。

第三个感悟是：团队协作的核心是信息对齐。 在 6 人团队中，最大的挑战不是技术问题，而是信息同步。我们通过 GitHub Issue、飞书共享文档、每周例会等方式持续对齐。当出现"卡牌术语不统一""UI 风格不一致""接口格式不匹配"等问题时，往往不是某个人做错了，而是两个人的"理解"不一致。软件工程的很多工具和流程（Issue、PR、Code Review、文档、例会），本质上都是在解决人与人之间的信息对齐问题。

第四个感悟是：在一个真实的项目中，你的角色边界是模糊的。 我负责的是美术和前端，但在实际项目中，我有时需要和后端同学讨论接口格式，有时需要和策划同学讨论卡牌效果描述，有时需要帮助测试同学理解 UI 交互流程。一个好的团队成员不是"只做自己分内的事"，而是在需要的时候能够跨越角色边界，帮助团队解决最紧迫的问题。

---

结语

一个学期前，我在读完《构建之法》后提出了 5 个问题，那时的我带着"AI 时代，这些方法论还适用吗"的疑问。一个学期后，我发现大部分问题的答案不是"是或否"，而是"在什么场景下、以什么方式适用"。

软件工程不是一套可以机械执行的规则。你不会因为严格按照某个流程走就做出好产品，也不会因为拥抱 AI 就自动成为高效开发者。真正的能力在于——在具体的约束条件下，做出最合适的选择，并对选择的结果负责。

这个学期我最大的收获，不是学会了 Phaser 或 TypeScript，而是建立了一种工程化的思维方式：面对问题时，先分析需求和约束，再设计方案和验证手段，最后在迭代中不断改进。从"写代码的学生"到"初具工程思维的开发者"——这是软件工程这门课给我最宝贵的礼物。

感谢两位老师，感谢"魔法细胞"团队中的每一位成员，感谢这段从零到一、从能玩到更好的旅程。