[T.14] 团队项目：Alpha 阶段项目总结

HexaVigil Alpha 阶段事后分析报告

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[T.14] 团队项目：Alpha 阶段项目总结
我在这个课程的目标是	接触理解应用现代软件工程常用的开发方式，锻炼自己编写代码以及团队协作的能力
这个作业在哪个具体方面帮助我实现目标	总结 Alpha 阶段团队项目成果

本文档用于复盘 HexaVigil 团队在 Alpha 阶段的开发过程。复盘依据包括 Alpha 展示博客、Beta 讨论记录、仓库文档、GitHub 协作规范、项目数据表与当前 Godot 工程状态。报告按课程 Postmortem 模板组织，重点回答：我们是否达成目标、过程中哪里做得好、哪里暴露了问题，以及如果重来一次会怎样改进。

1. 设想和目标

1.1 我们的软件要解决什么问题

HexaVigil 是一款以“白天探索建设、夜晚塔防作战”为核心循环的策略塔防游戏。我们希望解决的问题不是现实业务问题，而是游戏体验问题：让玩家在一局 15-25 分钟的短流程中，体验到“白天规划会直接改变夜晚战斗结果”的策略反馈。

项目的目标用户主要分为两类：

• 轻度休闲玩家：希望能快速进入游戏，在较短时间内完成一局，不需要长期养成和复杂付费系统。
• 策略塔防玩家：更关注路线规划、单位搭配、技能时机、Boss 处理和局内构筑。

典型场景定义比较清楚：

1. 玩家进入 Web 或 Windows 版本后，从中心核心区域开始探索 30x30 随机地图，发现资源点、事件点和刷怪口。
2. 白天消耗行动力进行探索、采集、建造、修复和招募。
3. 玩家根据当晚敌情与路线预览调整防线，使用墙体、资源建筑、增益建筑和干员部署影响敌人路径。
4. 夜晚敌人从多个刷怪点进攻核心，玩家通过技能释放、单位撤退再部署、路线阻挡和建筑协同守住核心。
5. 夜晚结束后获得遗物，形成肉鸽式局内成长；第 6 天进入 Boss 战并结算胜负。

这个目标在 Alpha 前期已经有较清晰描述，后续通过 docs/玩法循环与模块分工.markdown、docs/ARCHITECTURE.md、docs/DATA_SCHEMA.md 等文档逐步落到模块和数据结构上。不足之处是用户侧的新手路径和剧情包装定义较晚，导致 Alpha 版本可玩闭环完整，但第一次游玩时仍需要额外说明。

1.2 我们达到目标了吗

总体上，Alpha 阶段达到了“可演示、可游玩、可发布”的目标，但没有完全达到“新用户无说明即可顺畅理解”和“平衡性稳定”的目标。

原计划核心功能完成情况：

目标功能	Alpha 完成情况
Godot 项目骨架与主流程	已完成，包含 MainMenu、Game、Result 三个正式入口
昼夜循环	已完成，白天运营、夜晚战斗、祝福/遗物、结算流程可跑通
30x30 随机地图与迷雾	已完成，地图生成、资源点、事件点、刷怪点和迷雾探索已接入
资源采集与基建	已完成，包含 8 类建筑和建造/损毁/修复/拆除逻辑
干员部署与自动战斗	已完成，包含 28 名干员、技能、弹道、阻挡、撤退再部署
敌人与波次	已完成，包含 23 类敌人、6 天波次、Boss 和多种行为类型
遗物与随机事件	已完成基础系统，包含 31 个遗物和 8 个随机事件
UI 与操作面板	已完成主流程所需 HUD、面板和结算，但视觉与信息层级仍需 Beta 打磨
Web/Windows 发布	已完成，Alpha 提供 Web 试玩与 Windows 导出包
自动化测试体系	未充分完成，主要依赖 CI 导出、手工回归和少量校验
新手引导与剧情演出	未充分完成，Alpha 只具备基本流程和部分文案包装

交付时间方面，Alpha 在课程里程碑要求前完成可发布版本。后期由于劳动节、素材接入和 CD 部署问题，团队使用了更紧凑的集成节奏，并在自动部署不稳定时通过手动上传压缩包完成发布兜底。

用户数量方面，Alpha 灰度期统计口径为手工试玩登记与页面访问记录估算：

指标	Alpha 灰度数据
统计周期	2026-05-04 至 2026-05-10
Web 页面访问	326 次
独立试玩人数	87 人
有效问卷	42 份
平均单局时长	18.6 分钟
完成 3 天以上流程	61 人，占试玩人数 70.1%
完成 6 天完整流程	23 人，占试玩人数 26.4%
首日 DAU 峰值	46 人
次日回访人数	19 人，约 21.8%

页面访问达到了首周 300 次左右的短期目标，但 DAU 100-150 的预期没有达到。原因包括传播范围有限、Web 首次加载门槛较高、缺少正式埋点，以及 Alpha 版本仍偏原型。

1.3 和上一个阶段相比软件工程质量是否提高

相比早期构想和原型阶段，Alpha 阶段的软件工程质量有明显提升，主要体现在可维护结构、协作流程、数据驱动、发布自动化和文档留存。

可衡量的提升包括：

指标	Alpha 阶段结果
Commit 数	146 次
已合并 PR	68 个
Alpha Issue	60 个，其中 53 个关闭
GDScript 文件	88 个，约 18592 行
Godot 场景	26 个 .tscn，约 3777 行
JSON 配置	10 个，约 3670 行
Markdown 文档	11 个，约 6360 行
自动化	GitHub Actions 导出 Windows/Web，Web 部署到 gh-pages

工程质量提升点：

• 从“功能脚本堆叠”推进到 World / Managers / UI 三层结构。
• 通过 RunState、DataRepo、EventBus 和 SceneRouter 明确全局职责。
• 单位、敌人、建筑、波次、遗物、事件等内容主要通过 JSON 配置驱动。
• 使用 GitHub Issue 拆任务，用 PR 合入 dev，并要求 Review 和验证说明。
• README.md、架构、接口、数据 Schema、UI 系统和素材 Prompt 文档较完整。
• Web/Windows 导出不再完全依赖个人本地环境。

仍然不足的地方：

• 虽然使用了 Godot 单元测试插件做部分验证，但自动化测试覆盖仍不足，没有形成稳定的覆盖率统计和场景 smoke test 报告。
• 估点粒度偏粗，尤其低估了美工素材、UI 接入、手动回归和数值调平成本。
• 部分 UML/规格文档与最终实现存在偏差，后期没有完全同步更新。
• 用户数据没有正式埋点，DAU、完成率、失败点等指标仍需估算。

1.4 用户量和重要功能接受程度是否符合预想

用户量部分符合预期。访问量达到短期灰度目标，DAU 未达到较高预设。考虑 Alpha 发布周期短、传播渠道有限，这个结果可以接受，但说明 Beta 需要更明确的推广与埋点方案。

重要功能接受程度总体好于预期：

功能反馈	用户表现
建筑改变敌人路线	42 份问卷中 34 人认为这是最有记忆点的设计，占 81.0%
白天规划影响夜晚战斗	29 人选择，占 69.0%
遗物和干员组合	21 人选择，占 50.0%
路线预览是否有帮助	平均分 4.4 / 5
建筑影响路径是否有新意	平均分 4.3 / 5
愿意再次游玩	平均分 4.0 / 5

与预想不完全一致的地方：

• 玩家能感受到核心机制有新意，但第一次玩不一定知道应该先做什么。
• 路线预览被认可，但视觉强调和引导说明还不够。
• 后期难度波动比团队预期更明显，部分局会突然变难。
• UI 信息密度偏高，部分玩家无法快速判断资源、路线、单位状态和技能状态。

结论：我们离“核心玩法成立”的目标更近了，但离“普通玩家自然理解并稳定完成一局”的目标仍有距离。

1.5 经验教训与改进

经验教训：

• 游戏项目必须尽早形成可玩闭环。只有玩家能真正打一局，团队才知道哪些功能重要、哪些只是想象中重要。
• 特色机制不仅要实现，还要被玩家看见、理解和使用。路线预览、建墙改路、新手提示是同一个体验链路。
• 数据驱动能显著降低内容迭代成本，但必须配套 Schema、校验和数值测试。
• AIGC 能加速素材草图和通用逻辑，但不能替代人工验收、风格统一和引擎内接入。

如果重来一次，我们会：

1. Alpha 第 1 周就冻结最小可玩闭环，只保留一张地图、少量单位、少量敌人和 2-3 天流程，先验证核心体验。
2. 更早建立自动化数据校验、路径服务测试和关键场景 smoke test。
3. 把“新手第一局”作为 Alpha 必做功能，而不是 Beta 才补。
4. 对美工和 UI 接入单独估点，不把素材寻找、裁剪、导入、九宫格、场景适配当成附属工作。
5. 早期接入基本埋点或至少建立结构化试玩记录表，减少事后估算。

2. 计划

2.1 是否有充足时间做计划

团队有时间做基础计划，包括 WBS、模块分工、Issue 拆分、架构文档和 Git 协作规范。Alpha 初始任务按模块拆分，总预计开发时长约 111 小时，人均 15-16 小时，并要求子任务尽量控制在 8 小时内。

但计划时间并不充分。Alpha 前期更重视核心系统实现，低估了三个方面：

• 多模块联动后的集成调试。
• UI/美术资产从“能用”到“统一可读”的成本。
• 数值平衡和试玩回归的循环次数。

2.2 计划阶段如何解决不同意见

团队主要通过例会、Issue 讨论和 PR Review 解决不同意见。玩法、架构、地图、AI、战斗和基建之间出现边界争议时，优先回到两个标准：

1. 是否服务 Alpha 可玩闭环。
2. 是否能保持模块职责清晰，减少跨模块硬编码。

例如建筑影响路径牵涉地图、寻路、敌人 AI 和建造合法性，团队最终将地图真相放在 MapManager，路径计算交给 PathService，建筑生命周期由 BuildingManager 管理，敌人只读取路径服务结果，不直接改地图。

2.3 原计划工作是否全部完成

核心玩法工作基本完成，主要包括：

• 昼夜流程。
• 随机地图和迷雾。
• 资源、建筑和修复。
• 干员部署、技能、阻挡、弹道和再部署。
• 敌人、波次、Boss 和 AI。
• 遗物、随机事件、商店和结算。
• Web/Windows 发布。

未完全完成的工作：

• 新手引导。
• 剧情包装与 NPC 对话演出。
• 自动化测试体系。
• 真实用户数据埋点。
• 系统性平衡性验证。
• 美术风格统一和 UI 精修。

未完成原因主要是时间和优先级。Alpha 阶段必须先保证可发布闭环，团队把剧情、引导、完整自动化测试和美术精修推迟到 Beta。

2.4 是否做了事后看来价值不高的事

有一些工作事后看价值低于预期：

• 早期花费较多时间寻找和筛选美工素材，但缺少统一风格、尺寸和接入规范，很多素材后续仍需重做。
• 部分 UI 先用临时方案接入，短期支撑了演示，长期造成安全区、拉伸和视觉统一问题。
• 部分数值调整在缺少批量测试和数据记录的情况下靠试玩手感迭代，效率不高。

这些工作并非完全无用，但如果一开始有更明确的资产规范、UI 分层和测试脚本，投入产出会更高。

2.5 是否每项任务都有清楚交付件

大多数功能任务有较清楚交付件，例如某个脚本、场景、JSON 表、UI 面板或 PR 验证说明。Issue 中也使用 estimate:N 记录估点。

不够清楚的任务主要集中在：

• 美术风格探索。
• 体验打磨。
• 数值平衡。
• 用户测试。
• 文案与世界观包装。

这些任务往往只有“变好看”“更平衡”“体验更顺”这样的目标，缺少截图标准、数值目标、完成率目标或玩家反馈指标。Beta 需要把这类任务拆成可验收交付件。

2.6 项目是否按计划进行，出现了什么意外

项目大方向按计划推进，但过程里出现了几个意外：

• 劳动节假期打断开发节奏，后期集成和测试时间变紧。
• Godot Web/Windows CD 部署遇到问题，最终使用手动上传压缩包兜底。
• 怪物寻路、攻击建筑、核心封闭、飞行怪路径等联动问题比预期复杂。
• UI 与美术资产接入成本高于预期，抠图、裁剪、拉伸、风格统一都需要返工。
• 玩家反馈中新手引导不足和难度波动问题比预期更突出。

当时没有充分估计这些风险，主要因为团队对游戏项目的集成复杂度和素材生产成本经验不足，也因为早期更关注“功能能跑”，没有把“玩家能理解”和“视觉能验收”作为同等重要的计划项。

2.7 缓冲区是否有作用

计划中实际缓冲区不足。后期靠成员额外投入、集中 Review、手工回归和功能降级完成 Alpha 发布。缓冲区起到的作用有限，更多是隐含在“非核心功能推迟到 Beta”里。

2.8 将来计划如何修改

Beta 阶段计划会做以下修改：

1. 为每个大方向设置负责人：玩法、平衡、剧情/引导、美工、测试分别有人统筹。
2. 显式设置缓冲区：每周至少预留 20%-30% 时间给集成、回归、试玩和突发 Bug。
3. 美工和玩法分别建立独立任务规划，避免都挤在最后一周。
4. 每项 Issue 必须写清交付件、验收标准和验证方式。
5. 对数值和平衡任务建立固定测试样本和记录表，而不是只靠主观体验。

2.9 计划经验教训

如果历史重来一遍，我们会把计划从“功能清单”改为“体验闭环清单”。不仅写要做地图、战斗、建筑、UI，还要写玩家第一次进入游戏应该在第 1 分钟、第 5 分钟、第 15 分钟分别理解什么、做什么、看到什么反馈。

3. 资源

3.1 是否有足够资源完成任务

总体资源勉强足够。团队有人负责 PM、架构、地图、战斗、AI、基建、美工和数据，GitHub、Godot、AIGC、CI/CD 和大量 token 支撑了开发。

不足主要出现在：

• 美工和 UI 资源：产量、风格统一、透明化、Godot 接入都比预期难。
• 测试资源：缺少专职测试和自动化脚本，后期主要靠成员试玩回归。
• 用户数据资源：没有正式埋点，只能用手工登记和访问记录估算。

3.2 时间和资源如何估计，精度如何

任务估计主要来自 Issue 的 estimate:N 标签和成员对模块工作量的判断。功能开发估计相对准确，尤其是模块内部清楚的任务；跨模块集成、美术、测试和平衡估计偏乐观。

估计偏差例子：

• 寻路与建筑阻挡本身可估计，但“核心被封死后敌人如何处理”“路径预览如何实时反馈”“拆除型敌人和飞行怪如何共存”更难估。
• UI 面板能先搭出结构，但图片资源、九宫格、安全区、字体、中文显示、缩放和鼠标层级需要额外时间。
• 数值能通过 JSON 快速修改，但要证明一局 15-25 分钟且难度曲线合理，需要多轮试玩样本。

3.3 测试、美工设计和文案资源是否低估

测试时间勉强足够，但测试方式不系统。团队进行了多次手工试玩和 PR 验证，能保证 Alpha 演示稳定，但没有形成足够自动化的回归体系。

美工设计被明显低估。问题包括：

• UI 风格偏古早，高饱和青绿色较重。
• 抠图残边、透明背景污染、九宫格拉伸不协调。
• 角色、特效和页面风格之间存在违和感。
• 白天夜晚的视觉变化不够明显。

文案和剧情也被低估。世界观有雏形，但开场叙事、新手目标、随机事件表达和 NPC 乱入对话没有在 Alpha 中完整交付。

3.4 是否有工作可以让别人来做

团队按模块分工总体合理，但后期暴露出一些可优化点：

• 架构负责人承担了较多集成、Review、文档和 UI 实装工作，可以在 Beta 中分出 UI 接入负责人。
• 玩法负责人和战斗负责人需要更多平衡测试支持，不能只由实现者自己测。
• 美工素材可以拆成风格负责人、资产生产、Godot 接入和 QA 四类角色，避免“找素材的人”和“接入素材的人”之间标准不一致。

3.5 资源经验教训

如果重来一次，我们会：

1. 把测试、文案、美工和 UI 接入都作为正式资源，而不是编程之外的附属任务。
2. 对美术资产建立从 Prompt、源图、裁剪图、导入、StyleBox、场景验收的完整流程。
3. 给自动化测试留出固定人力，至少覆盖 JSON、路径、建造合法性和主流程 smoke test。
4. 用试玩记录表或埋点收集关键数据，包括第几天失败、失败原因、平均局长、遗物选择和干员使用率。

4. 变更管理

4.1 员工是否及时知道变更

总体上，每个相关成员能通过例会、GitHub Issue、PR 和群内沟通及时知道变更。仓库中 README.md 也规定了分支、PR、Issue 和合并流程。

不足之处是体验类和美术类变更有时没有第一时间沉淀到 Issue，导致口头反馈和实际修复之间存在信息损耗。

4.2 如何决定推迟和必须实现的功能

Alpha 阶段判断标准是“是否影响可玩闭环和课程展示”。

必须实现：

• 主流程可从菜单开始并进入结算。
• 昼夜循环可运行。
• 地图、迷雾、资源、建筑、干员、敌人和波次能形成一局。
• 核心失败和 Boss 胜利能正确结算。
• Web/Windows 至少一种发布形式稳定。

推迟到 Beta：

• 完整新手引导。
• 剧情演出和 NPC 乱入对话。
• 更丰富的 Boss、敌人和地图事件。
• 进阶干员、阵营、声望和干员溢出机制。
• 系统性美术重制。
• 自动化玩法测试和数据埋点。

4.3 Exit Criteria 是否清晰

Alpha 的出口条件有基本定义：能完成 6 天流程，核心 HP 归零进入失败，第 6 天 Boss 战胜利进入胜利结算，Web/Windows 可发布。

但出口条件不够细：

• 没有明确 UI 可读性标准。
• 没有明确平衡性标准，例如平均完成率、失败分布、单局时长区间。
• 没有明确自动化测试通过条件。
• 没有明确美术资产验收标准。

Beta 应把出口条件拆得更具体。

4.4 是否为可能变更制定应急计划

部分制定了应急计划，例如 CD 部署失败时手动上传压缩包，非核心 UI 精修延期，部分素材使用占位或文本兜底。

但系统性应急计划不足。比如如果平衡性无法调好、剧情系统来不及做、进阶机制风险过高，应提前定义可降级版本。

4.5 是否能有效处理意料之外的请求

团队能处理多数意料之外的 Bug 和需求，例如核心封闭寻路修复、路线预览、建造时路径反馈、随机事件接入、UI 溢出修复等。处理效率依赖于模块负责人熟悉系统和 PR Review。

后续需要改进的是：把临时请求转成 Issue，标记优先级和影响范围，避免口头插队打乱计划。

4.6 变更管理经验教训

如果重来一次，我们会：

1. 在计划中明确 P0/P1/P2 优先级和降级方案。
2. 为玩法、美工、测试分别定义 Exit Criteria。
3. 将所有变更请求进入 Issue，哪怕只是两行描述。
4. 每次变更都写清“为什么现在做、如果不做会怎样、验收方式是什么”。

5. 设计与实现

5.1 设计工作由谁完成，是否合适

Alpha 初期设计由架构负责人和玩法负责人主导：

• 黎嘉旋负责 Godot 项目骨架、全局状态、昼夜流程、数据驱动结构、接口文档、CI/CD 和集成。
• 刘笑晨、肖一涵等负责玩法、怪物 AI、战斗、塔防、Boss 和数值方向。
• 李延博负责地图、迷雾、路径服务和事件点。
• 赵栩栩负责基建、资源建筑、增益建筑、建造面板和波次预览。

这个安排总体合适。核心技术结构由熟悉 Godot 和全局集成的人把控，具体玩法模块由对应负责人实现。但美术、UI 和新手体验没有在同等层级进行早期设计，是后期暴露问题的主要原因之一。

5.2 是否遇到模棱两可的情况

遇到过，主要集中在：

• 地图和建筑谁拥有格子占用真相。
• 敌人 AI 如何处理被城墙完全封闭的核心。
• UI 是否可以直接修改业务状态。
• 同名干员重复购买后，部署和再部署应该按单位类型还是按槽位结算。
• 遗物是叫 Buff 还是 Relic，数据兼容如何处理。

团队通常通过讨论和文档更新解决。例如干员重复购买最终明确为 operator_key 槽位实例，撤退、死亡和再部署都按槽位结算；UI 只发请求，不直接改业务真相；遗物在用户体验上称为遗物，旧接口沿用 Buff 命名以兼容代码。

5.3 是否运用单元测试、TDD、UML 或其他工具

Alpha 阶段没有系统使用 TDD，也没有形成完整单元测试覆盖率报告，但团队确实使用了 Godot 单元测试插件对部分逻辑做验证。团队使用的工具和方法包括：

• Godot 单元测试插件，用于对部分核心逻辑做单元测试验证。
• GitHub Issues、PR 和 Review。
• GitHub Actions 自动导出 Windows/Web。
• Godot headless 命令检查工程可打开和可导出。
• JSON 校验、场景实例化检查、手工试玩回归。
• 架构文档、接口文档、数据 Schema 和 UI 系统文档。
• 燃尽图和例会记录。

UML/规格文档在项目开始时起到梳理模块的作用，但后期实现演进较快，部分文档没有同步更新。Beta 需要把架构、接口、数据和实际代码重新对齐，尤其是新机制加入前要先更新文档。

5.4 Bug 最多的功能与原因

Bug 最多的区域是怪物寻路、攻击逻辑、建筑阻挡和 UI 状态联动。原因包括：

• 地图、建筑、AI、战斗和 UI 同时参与一个链路，边界复杂。
• 动态地图和动态路线比固定路线塔防更容易出现边界情况。
• 飞行、拆除、绕路、远程攻击、阻挡攻击、Boss 阶段切换等敌人行为差异较多。
• UI 需要在白天、夜晚、暂停、拖拽、选中、冷却和结算之间切换状态。

发布后或试玩中发现的重要问题包括：

• 核心被城墙封闭时普通怪无法寻路。
• 飞行怪路径异常。
• 战斗暂停时地图交互状态不一致。
• 怪物重叠避免算法覆盖范围不足。
• 狙击干员弹道配置缺失。
• 商店显示、波次预览、目标类型错误。
• UI 文本溢出和面板布局冲突。

这些情况在设计阶段没有全部想到，是因为早期更多验证正常路径，异常路径和玩家“非预期操作”覆盖不足。

5.5 Code Review 如何进行

团队使用 PR 做 Code Review。每个成员在自己的功能分支完成任务后发起 PR，说明改动内容、验证方式和关联 Issue，其他成员 Review 后合入 dev。

代码规范执行情况总体较好：

• 约定 Commit Message 类型，例如 feat、fix、test、style、refactor、perf、chore。
• dev 和 main 作为保护分支，不直接推送。
• 配置表主键使用英文小写下划线，不用中文名作为程序主键。
• 模块之间通过直接依赖、EventBus 和 Group 协作，避免跨模块硬编码不稳定节点路径。

不足：

• 部分 PR 后期时间紧，Review 更偏功能可运行，缺少测试覆盖和长期维护性检查。
• 对 UI/美术资产的 Review 标准不如代码明确。

5.6 设计实现经验教训

如果重来一次，我们会：

1. 先写最小架构约束，再做功能，而不是等集成出问题后补约束。
2. 对跨模块链路画出时序图或 Mermaid 图，尤其是建造、寻路、部署和夜战结算。
3. 把异常路径列入设计文档，例如核心封闭、刷怪点无路、飞行怪、建筑损毁、单位死亡、暂停状态。
4. 在 PR 模板里加入“是否影响数据表、UI、存档、导出、测试”的检查项。

6. 测试与发布

6.1 是否有测试计划

Alpha 没有形成严格的测试计划，但已经使用 Godot 单元测试插件覆盖了部分逻辑验证。实际测试方式是：

• Godot 单元测试插件执行部分单元测试。
• 开发者本地试玩。
• PR 中执行 Godot headless 检查、JSON 校验和场景验证。
• 灰度试玩收集反馈。
• 发布前集中手工回归主流程。

没有完整测试计划的原因是时间紧，团队优先把可玩闭环做出来；同时 Godot 项目的自动化测试经验不足。

6.2 是否进行了正式验收测试

没有进行严格意义上的正式验收测试。团队进行了课程展示前的手工验收，重点确认：

• 能从主菜单进入游戏。
• 能完成白天探索、建造、招募。
• 能进入夜晚并正常刷怪。
• 核心扣血、敌人死亡、声望奖励、遗物选择正常。
• 第 6 天 Boss 战和胜负结算能触发。
• Web/Windows 包可打开。

这保证了 Alpha 发布可用，但不能替代正式测试。

6.3 是否有测试工具帮助测试

已有工具：

• Godot 单元测试插件。
• GitHub Actions 自动导出 Windows/Web。
• Godot headless 命令。
• JSON 格式校验。
• CombatSandbox 调试场景。
• PR 验证说明和手工回归记录。

改进计划：

1. 数据表自动化校验：检查 units.json、enemies.json、buildings.json、buffs.json、waves.json 的字段完整性和引用合法性。
2. 路径服务自动化测试：固定随机种子生成地图，验证 3 个刷怪点到核心可达，建造墙体后不会彻底破坏路径约束。
3. 建造合法性测试：覆盖未探索格、资源不足、行动力不足、核心封闭、资源点建筑等情况。
4. 战斗数值测试：覆盖伤害、护盾、治疗、阻挡、技能倍率和再部署。
5. 场景 smoke test：headless 实例化主菜单、主场景、结算场景和关键 UI 场景。
6. 将现有 Godot 单元测试插件纳入 CI，避免测试只停留在本地运行。
7. 测试结果报告：在 CI 中输出 JSON/Markdown 报告，比较前后失败数和关键指标差异。

6.4 性能与压力测试

Alpha 没有进行正式性能或压力测试。原因是当前版本运行负荷不大，主要瓶颈在可玩性、UI 和稳定性，而不是性能。

从实际运行结果看，Alpha 在一般 Web/Windows 环境下可运行，但仍需注意：

• Web 首次加载慢。
• 同屏敌人、投射物、特效和 UI 较多时需要观察帧率。
• 后续 Beta 增加昼夜光照、更多特效和 Boss 技能后，性能风险会上升。

Beta 改进：

• 增加固定压力场景，例如 100 个敌人、30 个投射物、多个范围特效同屏。
• 记录平均 FPS、最低 FPS、加载时间和内存占用。
• 对 Web 版本做资源体积检查和加载提示优化。

6.5 发布过程意外问题

发布中主要意外是 CD 部署不稳定。团队最终通过手动上传压缩包完成发布，保证 Alpha 能按期展示。

这暴露出两个问题：

• 发布流程应更早演练，不能等最后一天才验证。
• 自动化发布要有兜底方案和明确负责人。

6.6 测试发布经验教训

如果重来一次，我们会：

1. 在 Alpha 中期就建立“每日可导出”的要求。
2. 每个 PR 至少提供一条可复现验证命令或手工验证路径。
3. 为核心玩法写自动化测试，不把所有风险留给手工试玩。
4. 发布前 2 天冻结功能，只允许修 Bug、调参数和改文案。
5. Web/Windows 发布各保留一个可回滚版本。

7. 团队角色、管理与合作

7.1 团队角色如何确定，是否人尽其才

团队角色主要按成员兴趣、技术熟悉度和模块需要自愿确定：

成员	Alpha 阶段角色	主要贡献
刘笑晨	PM，怪物与 AI 模块负责人	任务协调、例会推进、怪物寻路/行为、Boss 与 AI、测试、世界观文案和部分数值平衡
黎嘉旋	总架构负责人	Godot 骨架、全局状态、昼夜流程、数据驱动、CI/CD、接口文档、Review、UI 实装与素材适配
肖一涵	游戏策划，战斗与塔防模块负责人	单位、技能、弹道、阻挡、部署、商店、战术 HUD、玩法体验和特效接入
李延博	地图模块负责人	随机地图、迷雾探索、路径服务、资源点、事件点、BGM 和音效
赵栩栩	基建模块负责人	建筑建造/损毁/修复/拆除、资源/增益/防御建筑、建造面板、波次与路径预览
于忠雨	美工	素材收集、风格探索、素材筛选与预览
初浩然	美工	AI 图像模型评估、风格 Prompt、角色序列帧和素材生成流水线

总体上角色匹配较好，核心模块均有负责人。但 Beta 阶段需要把“玩法统筹”和“美工统筹”拆得更清楚，避免美工和玩法优化都散落在各自模块里。

7.2 成员之间是否互相帮助

有。具体体现包括：

• 架构负责人协助各模块对接 EventBus、RunState、数据表和 UI。
• 地图、基建、AI 成员共同处理建筑改变路径和核心封闭问题。
• 战斗与 UI 成员共同处理部署、选中、技能、再部署和 HUD 显示。
• 美工成员提供素材，开发成员负责裁剪、导入和接入。
• 试玩阶段全员参与反馈收集和 Bug 修复。

7.3 出现项目管理或合作问题时如何解决

主要解决方式：

• 例会同步当前进度、阻塞和下一步计划。
• Issue 记录任务和 Bug，避免口头事项丢失。
• PR Review 发现接口、命名、路径、数据和逻辑问题。
• 对争议功能优先判断是否影响 Alpha 闭环。

Beta 可以改进的是：对冲突和延期更早暴露，负责人应主动调整范围，而不是等截止前集中压缩。

8. 总结

8.1 团队目前属于 CMM/CMMI 哪个档次

团队目前大致处于 CMM/CMMI 2 级到 3 级之间：

• 达到 2 级“已管理”的部分：有 Issue、估点、PR、Review、CI、里程碑发布和基本文档。
• 接近 3 级“已定义”的部分：架构、接口、数据 Schema、UI 系统和 Git 流程已经文档化。
• 未完全达到 3 级的原因：自动化测试、度量体系、变更流程和质量出口条件还不够标准化，执行质量也不稳定。

8.2 团队处于萌芽/磨合/规范/创造哪个阶段

团队处于“磨合到规范”的过渡阶段。

Alpha 前半段更多是磨合：明确每个人负责什么、接口怎么接、Godot 工程如何协作。Alpha 后半段逐渐进入规范：PR、文档、数据表、CI 和模块边界开始稳定。距离“创造”阶段还差系统化质量保障、稳定节奏和更主动的玩法创新验证。

8.3 相比前一个里程碑的改进

主要改进：

• 从概念设计变成可发布、可试玩的一局完整游戏。
• 从零散脚本变成分层清晰的 Godot 工程。
• 从口头分工变成 Issue、PR、Review 和文档支撑。
• 从固定玩法想法变成能根据试玩反馈迭代的项目。
• 从纯功能实现推进到初步关注用户反馈、工程质量和发布流程。

8.4 当前最需要改进的方面

最需要改进的是“质量度量与自动化验证”。Alpha 的很多问题不是团队不知道要修，而是缺少早发现、可复现、可比较的机制。Beta 应把数据校验、路径测试、战斗测试、场景 smoke test、用户行为数据和试玩记录建立起来。

9. 对照敏捷开发原则

做得较好的原则：

1. 尽早交付可工作的软件
   团队优先完成最小可玩流程，Alpha 已能从主菜单进入完整一局并发布 Web 试玩。

2. 欢迎变化
   试玩反馈中的路线预览、部署限制、再部署显示、经济调整、UI 修复和怪物路径修复都被转化为 Issue 或 PR。

3. 业务人员和开发者频繁协作
   虽然是课程项目，但玩法、地图、AI、战斗、基建、UI 负责人持续通过例会和 PR 对齐，保证模块能合在一起运行。

4. 以可工作的软件作为进度主要度量
   Alpha 后期团队更关注“能不能完成一局、能不能发布、玩家能不能理解”，而不是单纯看文档或代码量。

5. 持续关注优秀技术和良好设计
   项目形成了 World / Managers / UI 分层、数据驱动、统一事件总线、公开接口文档和数据 Schema。

做得不足的原则：

• 可持续开发节奏不足，后期赶工明显。
• 自动化测试和持续集成质量还不够，只做到自动导出，没有做到完整自动化验收。
• 简洁性有待提高，部分 UI 和美术接入形成了临时复杂度。

10. 下一阶段如何提高软件工程质量

10.1 代码管理质量

改进措施：

• PR 模板增加影响范围、测试方式、数据表变更、截图或录屏、回滚方式。
• 关键模块要求至少一名非作者 Review。
• dev 保持可运行，每周至少一次集成回归。
• 对 GDScript 命名、模块边界、数据字段和资源路径做 Review 清单。
• 禁止临时硬编码资源路径进入组件脚本，统一通过 DataRepo 或 UiArtRegistry 管理。

衡量方式：

• PR 平均 Review 次数。
• 合入后回滚或热修次数。
• dev 构建失败次数。
• 静态检查和测试失败数。

10.2 程序架构质量

改进措施：

• 继续坚持 UI 只显示和发请求，不保存业务真相。
• 将教程、剧情、随机事件、进阶干员和阵营声望做成数据驱动模块。
• 对 Boss 专属机制、敌人行为、遗物效果建立可扩展注册表，避免按 ID 写大量分支。
• 把路径服务、建造合法性、战斗数学和 Buff 结算拆出可测试接口。

衡量方式：

• 新增玩法机制需要修改的文件数。
• 数据新增是否不改代码即可接入。
• 自动化测试覆盖的核心模块数量。
• 循环依赖和跨模块直接节点路径数量。

10.3 软件工具应用

改进措施：

• 增加 JSON Schema 或自定义校验脚本。
• 增加 Godot headless 场景 smoke test。
• 增加固定随机种子的玩法回归测试。
• 建立截图/录屏留档，用于 UI、美术和昼夜光照对比。
• 评估 Godot 插件时采用小范围试点、锁定版本、可拆除原则。

10.4 项目管理

改进措施：

• Beta 拆成玩法和美工两条主线，各有负责人。
• 所有 Issue 必须写清交付件、优先级、估点和验收标准。
• 每周保留缓冲，禁止把全部时间排满。
• 每次例会同步风险清单，不只同步完成事项。
• 功能冻结后只允许修 Bug、调数值和补文案。

10.5 用户数据跟踪

改进目标：

• 记录 DAU/WAU。
• 记录进入游戏、开始夜晚、失败、胜利、退出等关键事件。
• 记录第几天失败、核心剩余 HP、单局时长、遗物选择、干员使用率。
• 记录 Web 首次加载耗时和进入游戏成功率。

如果不能接正式埋点，至少使用结构化试玩记录表，并在每轮灰度测试后输出统计。

10.6 项目文档质量

改进措施：

• Beta 开始前同步 ARCHITECTURE.md、INTERFACE.md、DATA_SCHEMA.md 和 UI 文档。
• 对新玩法机制补充设计文档和数据字段说明。
• 每个大型 PR 更新对应文档，否则不合并。
• 文档中明确“已实现”“计划中”“废弃”三类状态，避免新人误读。

10.7 人的领导和管理

改进措施：

• PM 不只追进度，也要维护风险、范围和验收标准。
• 负责人要有权决定延期、降级和拒绝临时插入需求。
• 对每个成员的贡献评价应包含实现、Review、测试、文档、沟通和救火，不只看代码量。
• 当成员承担过多集成压力时，及时分摊任务，避免单点瓶颈。

10.8 对软件工程理论的体会

Alpha 最大的体会是：软件工程质量不是额外包装，而是项目能否继续迭代的基础。程序质量解决“此刻能不能跑”，工程质量解决“多人继续改时会不会坏、坏了能不能知道、知道后能不能快速修”。游戏项目尤其明显，因为玩法、数值、美术、UI 和发布互相影响，任何一个环节缺少规范都会把成本转嫁给后期集成。

11. 发布博客附图