[T.19] 团队项目：Beta 阶段项目总结

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

HexaVigil Beta 阶段事后分析报告

一、设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

HexaVigil 要解决的问题，是做出一个以“白天探索经营 + 夜晚塔防战斗 + 长期肉鸽构筑”为核心循环的策略游戏。玩家每天在迷雾地图上探索、采集资源、建造防线、招募并部署干员；夜晚则根据敌情预告和出怪口信息防守核心；每晚结束后通过遗物、盟约、事件和商店选择逐步形成构筑。

从 Beta 结束时的实现看，这个问题定义已经比 Alpha 清楚很多。当前项目文档把单局循环收束为九天三幕：第 1-3 天、第 4-6 天、第 7-9 天逐步加压，第 3/6/9 晚为幕末 Boss 战。数据表与代码也支持这个目标：wave_templates.json 提供 21 套夜晚模板，night_affixes.json 提供 7 条夜晚词缀，events.json 提供地图事件，buffs.json 提供遗物，map_generation.json 与地图生成脚本提供 terrain-first 的随机地图。

典型用户也比 Alpha 阶段更明确：他们不是只想看一个塔防原型，而是希望在一局游戏里反复做策略判断的玩家。典型场景包括：

• 白天看到今晚敌情后，决定优先探索、补资源、封出怪口，还是强化阵容。
• 在地形、天然高台、人工高台、木墙、资源点之间安排防线。
• 根据夜晚词缀、Boss、敌人类型和活跃出怪口调整部署与技能节奏。
• 通过遗物、盟约 tag、随机事件和商店选择形成不同构筑路线。

不过，典型用户画像仍然不够量化。我们没有明确区分“第一次接触游戏的新玩家”“熟悉塔防机制的策略玩家”“只测试作业成果的评审用户”三类人，也没有提前写出每类用户的关键验收路径。这导致 Beta 后期教程、剧情、敌情预览、UI 可读性、性能和发布包体同时成为风险点。

2. 我们达到目标了吗？原计划的功能做到了几个？是否按原计划交付？原计划达到的用户数量达到了吗？

从功能目标看，Beta 的主要目标基本达到，并且范围比最初计划更大。当前 GitHub 中 Beta 相关 issue 共 46 个，已经全部关闭；估点合计 223 points。按 issue 标题和合并 PR 看，主要功能包括：

• 新手引导与通用剧情对话框架。
• 随机事件地图化与事件大面板。
• 干员阵营 tag、盟约机制和盟约 Buff。
• 遗物池、规则型遗物、开局遗物选择、祝福三选一。
• 更具策略深度的敌人与 Boss，包括奶龙、爱国者、凑凑企鹅等多阶段 Boss。
• 九天三幕夜晚机制、多波刷怪、命名夜晚模板、白天敌情预告。
• 动态出怪口、封口、出怪口预览与覆盖面显示。
• 商店锁定槽、盟约权重漂移、定向升星、数值经济和后期难度曲线。
• 新手教程、开场剧情、剧情播放期间 BGM 与说话反馈。
• UI 视觉规范、HUD、部署栏、详情栏、遗物界面、事件/对话/结算界面、设置面板、图标与分层资产接入。
• 战斗音效、Boss BGM/语音、事件选项音效、结算与夜晚转场反馈。
• 导出资源、发布页资产、包体压缩、性能优化。

从交付时间看，我们没有完全按原计划在 2026-06-08 前自然收束。beta-burndown 在 6 月 8 日附近仍显示大量 issue 未完成，而实际大量功能在 6 月 13-15 日密集合并：仅 6 月 14 日就关闭 27 个 Beta issue，约 105 points；6 月 15 日又关闭 8 个 Beta issue，约 45 points。最终完成了 Beta，但完成方式偏“后期集中冲刺”，不是理想的平滑燃尽。

从用户数量看，仓库没有接入真实用户统计，也没有外部用户量目标，所以无法回答“达到多少用户”这个问题。我们只能用内部验收、issue 关闭、PR 合并、发布包和可运行版本作为替代指标。这个替代指标能说明工程交付情况，但不能说明真实玩家是否喜欢、是否理解、是否愿意反复游玩。

3. 和上一个阶段相比，团队软件工程的质量提高了吗？在哪里提高，具体提高了多少，如何衡量？

提高了，而且提高主要体现在四个方面。

第一，项目从“功能堆叠”转向“主循环整合”。Alpha 阶段更多是在实现单个模块，Beta 阶段则把白天、夜晚、地图、敌人、UI、事件、遗物、音频和发布流程串成一局完整体验。docs/玩法循环与模块分工、docs/ARCHITECTURE.md、docs/INTERFACE.md、docs/DATA_SCHEMA.md 都反映了这种结构化收束。

第二，数据驱动程度明显提高。敌人、干员、建筑、遗物、事件、夜晚模板、夜晚词缀、UI 图标等内容都主要通过 JSON 配置与资源注册表接入。新增内容不再必须改大量业务代码，这提升了迭代速度，也降低了硬编码风险。

第三，工具和验证意识增强。Beta 中出现了 headless 测试、地图生成测试、遗物抽取测试、战斗覆盖、UI 截图工具、overflow lint、音频资产检查脚本、UI 派生资源生成脚本、Godot CI 和导出流程更新。虽然测试覆盖还不全面，但已经不再只依赖人工点一点。

第四，文档跟随实现更新。Beta 后期有多次 docs 提交，例如同步玩法循环、数据 schema、接口、UI 系统、Boss 特效、生图 prompt、地图与夜晚设计。这说明团队开始把“代码里发生的事实”转成可共享知识。

可衡量数据包括：

• Beta 相关 issue：46/46 已关闭。
• 2026-05-25 以来 PR：62 个，58 个合并。
• 2026-05-25 以来提交：239 条。
• 文档提交：约 35 条 docs 类型提交。
• 测试提交：约 5 条 test 类型提交。
• 性能提交：2 条 perf 类型提交，集中解决终战索敌 O(N²)、前期全图重绘和拖动重绘问题。

不足是，软件工程质量提升主要在 Beta 后半段集中发生，而不是从一开始就稳定执行。比如性能和发布问题发现偏晚，issue 燃尽也不是持续平滑下降。

4. 用户量、用户对重要功能的接受程度和事先预想一致吗？我们离目标更近了吗？

用户量无法判断，因为本阶段没有真实埋点、日活、周活、留存或公开试玩反馈统计。这一点和模板中要求的“用户量”还有距离。我们目前只能用团队内部体验、PR 合并、issue 关闭和发布包完成情况作为间接指标。

对重要功能的接受程度，也只能从内部迭代痕迹间接判断。可以看出团队对以下功能的接受程度较高，并不断追加完善：

• 敌情预告和出怪口预览：从右上角预览，到路线显示，再到覆盖面预览、出怪口编号、颜色联动和悬停高亮，说明这是核心体验之一。
• 九天三幕夜晚结构：从多波与词缀，到 Boss 晚，再到第九天三 Boss 连战，说明团队认可长流程和幕末压力设计。
• 地图生成：从 skeleton_v2 到 terrain-first，再到核心浮动选址、天然高台、资源分布和河流地貌，说明随机地图成为游戏辨识度的重要部分。
• 肉鸽构筑：遗物、盟约、事件、商店权重漂移、定向升星等功能都被持续扩展，说明构筑层已经成为 Beta 的主轴。
• UI 资产化：从纯样式到分层资产、图标、九宫格、派生资源和视觉 QA，说明团队已经意识到“可读性”就是玩法的一部分。

我们确实离目标更近了。Beta 结束时，HexaVigil 已经不是几个孤立系统，而是有九天流程、地图差异、敌情预告、战斗压力、构筑奖励、剧情和音频反馈的一局游戏。

但是我们还没有证明“目标用户真的接受”。下一阶段应该至少组织一次外部试玩，记录以下数据：

• 第一次游玩能否在无讲解情况下完成第一天白天和第一晚。
• 玩家是否能理解敌情预览、出怪口颜色、封口和夜晚词缀。
• 玩家是否知道为什么获得遗物、盟约、事件奖励，以及它们如何改变构筑。
• 玩家在哪些 UI 面板停留过久或误操作最多。
• 玩家是否愿意重新开一局。

本章经验教训

Beta 阶段最大的正向经验是：当我们把目标从“实现若干功能”改成“完成一局体验”后，许多设计选择自然变清楚了。比如地图生成、夜晚模板、敌情预览、遗物和事件，本来可以各自独立扩展，但最终都服务于“玩家每天做决策，晚上验证决策”的核心体验。

最大的问题是：我们对“可发布版本”的定义太晚才具体化。功能目标基本明确，但用户目标、验收目标、发布目标和性能目标没有同等清楚。于是最后阶段出现了大量集中修复和 final PR。

如果历史重来一遍，本章对应改进

如果重新做 Beta，我们会在第一周就写出三份清单：

• 核心体验清单：玩家必须能完整经历哪些场景，哪些场景不完整就不能叫 Beta。
• 用户验收清单：新玩家必须理解哪些概念，哪些 UI 必须无需讲解就能读懂。
• 发布出口清单：包体、性能、教程、剧情、音效、主流程、失败/胜利结算分别达到什么标准。

同时，我们会把“用户数量和用户反馈”纳入计划，而不是只在最后用 issue 关闭数替代。哪怕只有 3-5 名外部试玩者，也比完全没有真实反馈更接近模板要求。

二、计划

1. 是否有充足的时间来做计划？

从时间长度看，Beta 阶段有计划时间。origin/beta-burndown 分支明确记录 Beta 迭代周期为 2026-05-25 至 2026-06-08，并且为了燃尽图维护了 beta_burndown.py、每日快照和 beta_burndown_issues.json。这说明团队不是完全没有计划，而是建立了 milestone、estimate 标签和燃尽图机制。

但从计划质量看，时间使用得不够充分。6 月 8 日燃尽快照中，Beta 计划内 38 个 issue 只关闭了 6 个，剩余 32 个；而当前 GitHub 中 Beta 相关 issue 扩展到 46 个，并最终全部关闭。这说明 Beta 初期计划没有充分识别后续会涌入的工作，尤其是美术资产、UI 精修、音效、性能、导出发布和最终验收这些“非纯代码功能”。

我们有计划时间，但没有把计划时间足够多地花在拆解交付件和定义出口条件上。很多任务在标题上看起来是一个 issue，例如“补齐 UI 美术”“重构夜晚机制”“增加剧情与教程”，实际却包含数据、脚本、场景、资源、导入、测试、文案和视觉验收等多个子任务。结果就是燃尽图看似管理了估点，但估点颗粒度太粗，不能指导每天的稳定推进。

如果只看最终交付，Beta 是完成的；如果看计划执行，Beta 是后期集中补完的。这两者都是真实情况。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

从仓库记录能看到，计划分歧主要通过 issue、PR、设计文档和后续提交修正来解决，而不是一次性在计划阶段完全达成共识。比如：

• 夜晚机制先经历命名夜晚模板、敌情预览、多波刷怪、动态出怪口、九天三幕、夜晚词缀、Boss 晚等多轮演进。
• 地图机制从早期生成器推进到 skeleton_v2，再切到 terrain-first，并在高台、河流、核心选址、资源投放和连通性上持续修正。
• UI 方向从样式脚本和占位面板，发展为 assets/ui/generated/、UiFrameSpec、UiArtRegistry、分层资产和派生资源管线。
• 随机事件从简单事件表，改为地图事件点、事件面板、契约事件和事件插图资产。

这种解决方式的好处是执行速度快：当团队发现某个方向不够好时，可以通过 PR 快速落地新方案。坏处是分歧常常在实现中被解决，而不是在计划中被提前收敛。实现中解决分歧会带来返工，例如路径预览从线预览调整到覆盖面预览，敌人移动从 A* 改为 flow field，UI 层级和资产接入也经历多次修正。

计划阶段的讨论如果能更早产出“不可变约束”，后期会少一些方向性返工。例如：

• 夜晚预览必须和实际刷怪共用同一份数据。
• 出怪口必须有稳定编号、颜色和地图/右栏联动。
• UI 资源必须分层，不允许把文字和动态内容烘进背景图。
• 地图生成必须保证核心、出怪口、资源和初始可见区域共同服务白天决策。

这些原则后来都逐渐形成了，但不是 Beta 一开始就明确写下来的。

3. 原计划的工作是否最后都做完了？如果有没做完的，为什么？

从 GitHub 当前状态看，Beta 相关 issue 已经全部关闭，说明原计划和后续追加的 Beta 工作在 issue 层面已经完成。具体包括：

• #172 新手引导与通用剧情对话框架。
• #173 随机事件地图悬浮气泡与大事件面板。
• #174 阵营 tag 与盟约 Buff。
• #175 遗物内容与构筑策略空间。
• #176 更具策略深度的怪物与 Boss。
• #177 更好的夜晚关卡机制。
• #178 可体验或跳过的新手教程。
• #179 剧情与 NPC 对话。
• #180 至 #201 一系列 Beta 美工/UI/特效任务。
• #202 至 #204 音效规范和关键音效。
• #210 至 #215 夜晚模板、敌情预览、遗物、经济曲线、自动释放和更长流程。
• #219 肉鸽构筑层重构。
• #244、#251、#266、#268 等后续音频与事件音效补充。

但如果按“原定 2026-06-08 完成”的计划看，并没有按时做完。6 月 8 日以后仍有大量功能和修复进入主干：6 月 10 日合并夜晚多波、遗物池、契约事件、教程关、商店锁定、定向升星和动态出怪口；6 月 13 日合并 terrain-first 地图、九天三幕、第三 Boss、音效和多项战斗修复；6 月 14 日集中合并 UI 资产、剧情系统、作弊面板、数值调优、路径预览、随机事件插画；6 月 15 日继续合并 Boss 音乐、事件音效、发布资源、随机事件触发链路和最终质量改进；6 月 16 日还做了性能优化和终战调整。

没能按计划期完成的主要原因有三点。

第一，任务低估了跨模块集成成本。比如“夜晚机制”不是只改 WaveManager，还要改 RunState、GameController、NightTemplateResolver、UI 敌情面板、数据表、地图出怪口、封口逻辑、Boss 安排和文案展示。

第二，美术和 UI 不是独立收尾项。UI 资产接入会反过来暴露布局、层级、文本溢出、交互语义和图标缺失问题。大量 fix(ui) 提交说明 UI 不是“最后贴图”，而是系统体验的一部分。

第三，发布条件被定义得太晚。包体大小、性能、Boss 音频长音效、终战三 Boss 连战、堵路拆墙、导出资源等问题都在后期集中出现，说明我们直到接近发布才真正按发布版本标准审视项目。

4. 有没有发现做了一些事后看来没必要或没多大价值的事？

有，但这些“没必要”的工作很多不是完全浪费，而是探索成本。比较典型的有：

第一，部分中间态路径与预览方案后来被替换。路线预览从线条形式，到完整线条和迷雾遮挡，再到覆盖面预览与右栏颜色联动；敌人寻路也从每怪 A*、候选走法策略、软避让补丁，演进到共享距离场和单调下行。早期方案帮助团队看清问题，但如果计划阶段更早定义“敌人推进要呈现为一面，而不是一条线”，可以少走弯路。

第二，一些 UI 临时样式和兜底方案在正式资产接入后价值下降。Beta 后期建立了派生资产管线和 UiArtRegistry 后，许多组件层面的临时样式、重复路径和占位处理都需要清理。它们曾经让功能先跑起来，但也带来了后续统一成本。

第三，文档中有部分设计稿和 TODO 在实现快速变化后变成过时内容。团队后来做了 docs: 清理已交付/已废弃功能的开发文档、docs: 现状权威文档对齐到当前代码 等工作，说明早期文档没有始终和实现同步。文档不是越多越好，过时文档会增加判断成本。

第四，有些发布 PR 标题和流程偏临时，例如多次 final/final final 的收尾 PR。这类 PR 本身不是没价值，但暴露了发布节奏不够稳定。真正有价值的不是“最后再来一个 final PR”，而是可重复执行的 release checklist。

如果重来一次，我们仍会保留探索，但会把探索任务和正式任务分开。探索任务可以接受丢弃；正式任务必须有清晰交付件、验收标准和清理要求。

5. 是否每一项任务都有清楚定义和衡量的交付件？

没有。Beta issue 都有标题和估点，大多数能看出方向，但并不是每一项都有足够清楚的交付件。

比较清楚的任务包括：

• “实现干员自动合成进阶与出售”：交付件明确，功能边界相对清楚。
• “实现干员操作子弹时间”：可以通过战斗交互验证。
• “在设置面板中增加技能自动释放开关”：UI 入口、设置状态和技能行为都能验收。
• “建立命名夜晚出怪模板与白天敌情预告”：虽然跨模块，但可以通过模板数据和白天预览验证。
• “补齐战斗命中、弹道与技能释放音效”：可以通过音效 key、资源路径和战斗触发点验证。

不够清楚的任务主要集中在美术和体验类：

• “顶部 HUD 与设置面板场景精修”
• “事件、对话、地图弹窗与设置弹窗精修”
• “通用战斗反馈特效补齐”
• “昼夜环境调色与转场控制”
• “全 UI 目视 QA、截图对比、残边扫描、验收记录”

这些任务很重要，但如果没有截图基线、具体场景、目标分辨率、验收清单和资源路径，很容易变成“感觉还要再修一修”。Beta 后期大量 UI 修复和视觉调整，说明交付件定义需要更具体。

下阶段每个任务至少应该包含：

• 影响模块：代码、场景、数据、资源、文档分别涉及哪些目录。
• 玩家可见结果：玩家在哪个界面或流程能看到变化。
• 验收方式：运行哪个场景、点击哪些路径、预期看到什么。
• 不做范围：明确哪些内容本 issue 不负责，避免顺手扩张。
• 截图或录屏要求：UI/美术/特效类任务必须保留验收截图。

6. 项目的整个过程是否都按照计划进行？出了什么意外？有什么风险当时没有估计到，为什么没有估计到？

项目整体没有完全按照原计划平滑推进。更准确地说，Beta 的方向是按计划推进的，但节奏和范围发生了明显变化。

主要意外和风险包括：

第一，夜晚机制复杂度上升。最初如果只是“增加夜晚关卡机制”，看起来像波次表和敌人配置问题；实际落地时变成九天三幕、多波计划、出怪口激活、夜晚词缀、Boss 晚、敌情预览、波间倒计时、强制开波和胜利判定。它影响的是整局节奏，而不是单个模块。

第二，地图生成成为核心体验风险。terrain-first 让地图更自然，但也带来核心选址、资源分布、连通校验、天然高台、河流、出怪口、迷雾、性能和可读性的综合问题。团队后续增加了大量生成子模块和 debug 测试，说明一开始低估了地图生成的系统性。

第三，敌人移动与预览一致性风险。玩家看到的路线如果和敌人实际走法不一致，会直接破坏策略可信度。Beta 后期专门修复 fix(path): align route preview with enemy movement，并把敌人推进改为 flow field，说明这个风险很关键，但计划早期没有被列为高优先级出口条件。

第四，UI 资产接入风险。UI 美术不是“替换图片”这么简单。正式资产需要分层、九宫格、透明边、裁剪、图标注册、按钮状态、进度条、滚动条、文本布局、输入穿透和 hover tooltip。这个复杂度在计划中被明显低估。

第五，发布包体与性能风险。fix(export): reduce packaged export size 和 6 月 16 日的性能 PR 说明，发布阶段才发现包体和终战性能问题。原因是日常验证更多关注功能是否能跑，而不是发布环境和压力场景。

这些风险没有被充分估计，主要是因为我们在计划时按“模块功能”估计，而不是按“玩家路径”估计。一个玩家路径可能穿过 6-8 个模块，只要其中一个模块没接好，就会变成体验问题。

7. 在计划中有没有留下缓冲区？缓冲区有作用吗？

从结果推断，计划中即使有缓冲，也不够。Beta 计划周期写到 6 月 8 日，但实际核心收尾延续到 6 月 16 日。也就是说，真实缓冲至少用了约一周，而且这段时间并不只是做低风险收尾，而是仍在合并关键功能、资源、修复、性能和发布 PR。

缓冲区确实发挥了作用：如果没有 6 月 13-16 日这段集中收尾，Beta 很可能无法达到当前完成度。许多关键工作都发生在这段时间：

• 6 月 13 日：terrain-first 地图、九天三幕、第三 Boss、难度曲线、战斗音效、地图艺术资源。
• 6 月 14 日：UI 资产管线、剧情系统、作弊面板、数值调优、随机事件插画、路径预览修正。
• 6 月 15 日：Boss 音乐与语音、事件音效、发布资源、随机事件触发链路、最终质量改进。
• 6 月 16 日：性能优化、包体和终战体验收尾。

但是，这种缓冲更像“延期冲刺”，不是健康的风险缓冲。健康缓冲应该用于修 bug、做验收、压发布、写报告，而不是继续完成大块功能。我们最终完成了，但付出的代价是后期风险集中、验证压力变大、PR 密度过高。

8. 将来的计划会做什么修改？例如缓冲区定义、加班等。

下阶段计划需要做以下修改。

第一，把缓冲区写成显式阶段，而不是隐藏在截止日期之后。建议每个里程碑拆成：

• 功能开发期：只做新功能。
• 集成冻结期：不再新增系统，只允许把已合并系统接完整。
• 内容冻结期：不再新增资源，只允许修资源路径、导入和显示问题。
• 发布候选期：只允许 bugfix、性能、打包和验收。

第二，缓冲区不能用来装“还没开始的大功能”。如果某个功能在功能冻结日前没有可运行竖切片，就自动降级或延期。这样可以避免最后几天同时上线新功能和修发布问题。

第三，计划颗粒度要更细，尤其是美术、音频、UI、发布任务。比如“补齐 Boss 音效”应该拆成：资源命名、导入设置、AudioManager key、触发点、音量平衡、长音效完播、实机验证。这样估点才有意义。

第四，每周至少做一次主流程验收，而不是等全部功能完成再跑完整局。验收路径至少包括：新开局、第一天探索、第一晚战斗、遗物选择、Boss 晚、教程、失败结算、胜利结算、导出运行。

第五，不鼓励用加班作为计划手段。后期集中工作不可避免，但计划上应该减少对个人英雄式冲刺的依赖。对于高风险模块，应该提前安排双人 review 或交叉验收，避免知识集中在一个人身上。

本章经验教训

Beta 的计划不是没有，而是“能列任务，不能稳定控制风险”。燃尽图、estimate 标签、issue 和 PR 都存在，这些是很好的工程基础。但计划真正的问题在于：没有足够早地把玩家路径、发布出口、视觉验收、性能压力和资源接入都纳入同一张计划表。

从结果看，我们完成了 Beta；从过程看，我们是在后期靠密集提交完成 Beta。完成值得肯定，但不能把这种节奏当成下阶段常态。

如果历史重来一遍，本章对应改进

如果重新做 Beta，我们会在 2026-05-25 开始时就做三件事：

第一，把 46 个 Beta issue 按玩家路径重排，而不是只按模块重排。比如“白天决策路径”“夜晚战斗路径”“构筑成长路径”“发布验收路径”，每条路径都有自己的完成定义。

第二，为每个大 issue 写交付件清单。没有交付件清单的 issue 不允许进入 sprint，只能先作为调研或设计任务。

第三，在 6 月 8 日之前强制进入冻结期。如果那时某些任务未完成，就明确延期或降级，而不是默默进入最后一周集中补完。

下一阶段我们要保留 Beta 中已有的 issue/PR/CI/文档机制，但把它们从“记录工作”升级为“控制风险”。

三、资源

1. 我们有足够的资源来完成各项任务吗？

如果以最终结果衡量，团队拥有完成 Beta 的基本资源：代码、数据、UI、美术、音频、文档和发布都有人推进，最终 Beta 相关 issue 全部关闭，主干也形成了可发布版本。仓库中可以看到多个方向都被实质推进：

• 代码资源：scripts/ 目录在 Beta 中 churn 约 26534 行，是最大变化区域。
• 资产资源：assets/ 目录 churn 约 22354 行，说明大量视觉和音频资源进入项目。
• UI 资源：assets/ui/generated/ 下有 464 个生成资源文件，data/ui_icons.json 中有 61 个图标 key。
• 音频资源：assets/audio/ 下有 112 个音频文件，覆盖 BGM、战斗音效、Boss 音乐/语音、事件音效和结算反馈。
• 事件插图资源：assets/story/events/ 下有 69 个文件，为随机事件面板提供视觉支持。
• 数据资源：当前有 28 名干员、24 种敌人、9 类建筑、45 件遗物、21 套夜晚模板、7 条夜晚词缀。

但是，如果以计划过程衡量，资源是不够均衡的。尤其是 Beta 后期，很多关键工作集中在少数人身上。git shortlog 显示 2026-05-25 以来主要提交集中在 Xiao Yihan/肖一涵、風船、S7AM1NA、Old-Joy、Z-XUA 等成员，其中玩法主线、地图、敌人、文档和系统整合高度集中。这说明团队总体资源够用，但关键模块存在“单点高负载”。

另一个资源不足是外部用户资源不足。我们没有真实试玩用户统计，也没有形成固定的外部验收流程。结果是很多“玩家是否理解”的问题只能靠团队内部判断，例如敌情预览是否清楚、随机事件选择是否易懂、教程是否足够、新手是否知道如何建造和部署。

因此，本阶段资源结论是：实现资源勉强够，集成资源紧张，测试和外部反馈资源不足，美术/音频/发布资源被低估。

2. 各项任务所需的时间和其他资源是如何估计的，精度如何？

Beta 使用 GitHub issue 的 estimate:N 标签进行估点，并通过 beta-burndown 分支生成燃尽图。当前 Beta 相关 issue 估点合计 223 points，其中 estimate 分布大致为：

• estimate:3 的 issue 最多，共 20 个。
• estimate:5 的 issue 共 15 个。
• estimate:8 以上的中大型 issue 包括新手引导、Boss、夜晚机制、遗物构筑、盟约等。
• 还有少量追加任务缺失或未体现估点，例如部分后续音频补充。

估点方法说明团队已经有量化意识，但精度一般。主要问题是估点更多按“标题规模”估，而不是按“跨模块链路”估。比如：

• “设计并实现更好的夜晚关卡机制”估点为 9，但实际涉及夜晚模板、词缀、波次、多出怪口、UI 预览、Boss 晚、胜利判定、数据表和文档。
• “增加更具策略深度的怪物与 Boss”估点为 10，但实际涉及敌人配置、BossController、多阶段机制、特效、音频、数值、AI、路径、战斗反馈和沙盒验证。
• 大量 Beta 美工任务估点为 3 或 5，但实际需要生图、裁剪、透明处理、九宫格、导入、场景接入、UI 层级、文本适配、截图 QA。

精度偏差最明显的证据，是计划期结束时燃尽仍未完成，而后续一周集中关闭了大量任务。6 月 14 日关闭 27 个 Beta issue，约 105 points；这不是正常估点精度下的平滑燃尽，而是大量任务到后期才形成可关闭状态。

资源估计还忽略了“验证资源”。功能做完后，还需要有人验证主流程、视觉、性能、包体和跨平台导出。Beta 后期出现 fix(export)、perf、音频长音效完播等 PR，说明这部分资源没有提前预算充分。

3. 测试的时间、人力和软硬件资源是否足够？对于美工设计/文案等不需要编程的资源是否低估难度？

测试时间和人力不够充分。团队做了一些自动化和工具化测试，这是进步；但从提交节奏看，测试更多是伴随功能修补出现，而不是从一开始就作为 Beta 计划的固定资源。

已有测试和工具包括：

• scripts/debug/test_map_generation.gd 等地图生成测试。
• 夜晚计划、词缀、遗物抽取、定向升星等 headless 覆盖。
• UI 截图捕获工具和 overflow lint。
• CombatSandbox 和 DialogSandbox 等调试场景。
• 音频资产检查与处理工具。
• Godot 云端 CI 和导出工作流。

这些工具是有效的，尤其对地图、遗物、夜晚机制、UI 溢出和音频资源有帮助。但测试资源仍有不足：

• 没有看到完整九天通关的自动化回归。
• 没有形成固定的“每晚模板 + 每个 Boss + 每个词缀”的组合测试矩阵。
• UI 视觉主要依赖人工目视，没有稳定的截图对比基线。
• 性能测试发现偏晚，终战索敌 O(N²) 和拖动重绘问题直到 6 月 16 日才集中优化。
• 发布包体大小问题到 6 月 15 日才修复。

对于美工、文案和音频资源，Beta 明显低估了难度。

美工方面，UI 不是一批图片生成完就结束。它要求：

• 统一风格和色板。
• 透明背景和残边清理。
• 九宫格安全区。
• 不把文字、数字和动态内容烘进图。
• backplate、frame、overlay、状态层分离。
• 每个资源 key 稳定注册。
• Godot 导入后真实界面不溢出、不遮挡、不抢输入。

文案方面，随机事件、夜晚模板、Boss 名称、关卡预览、教程提示、剧情对话都直接影响玩家理解。当前数据中有 10 个顶层随机事件、21 套夜晚模板和开场剧情；这些内容不仅要能读，还要和机制一致。比如事件选项必须准确说明代价和收益，夜晚描述必须和实际敌人/词缀相符。

音频方面，Boss BGM、语音、长音效、事件选项、夜晚转场、胜利/失败反馈都涉及触发时机和音量平衡。fix(audio): 保证奶龙长音效完播 就说明音频接入不仅是放文件，还要处理播放生命周期。

如果重来一次，美工、文案、音频都应该作为正式资源参与估点，而不是被当成代码完成后的附属收尾。

4. 有没有感到你做的事情可以让别人来做，并且会更有效率？

有。Beta 中有几类工作如果提前拆分，会更适合由不同成员并行完成。

第一，内容填充和机制代码可以拆开。比如遗物、事件、夜晚模板、词缀、敌人配置都属于数据内容；机制稳定后，内容填充可以由熟悉表结构和玩法目标的人批量完成，不一定都由核心代码实现者继续维护。这样核心开发者可以把时间留给系统边界、bug 和性能。

第二，UI 视觉验收可以独立出来。UI 资产接入后，很多问题是“按钮文字是否溢出、面板是否遮挡、图标是否缺失、滚动条是否可见、tooltip 是否被挡住”。这些问题可以由专门的 QA 或美术验收人员按截图清单检查，不必全部压给实现者。

第三，文档同步可以在功能 PR 合并后由对应模块负责人补充，但也可以设一个文档 reviewer。Beta 后期文档有集中同步，这很好；但如果每个大 PR 都要求更新对应接口/数据 schema/玩法文档，最后集中补文档的压力会小很多。

第四，发布和包体检查应该有专人维护。导出 preset、CI、itch/release 页面资源、包体大小、资源排除规则都不是业务逻辑，但发布时非常关键。如果每次都临时处理，就容易出现 final 阶段反复修发布的情况。

第五，音频素材处理可以工具化并交给音频负责人。Beta 已经有 check_audio_assets.py、prepare_audio_assets.ps1 等工具，下一阶段可以把音频裁剪、响度、命名、导入和 key 注册变成流程，减少程序员逐个试错。

这不是说某些人“不该做”某些事，而是说 Beta 后期很多工作由同一批人连续处理，降低了并行效率，也增加了单点风险。

本章经验教训

资源问题的核心不是“人不够”，而是“资源种类识别不够早”。Beta 不是纯代码迭代，它同时是玩法、内容、美术、音频、UI、测试和发布迭代。只给功能写 issue，不给资源接入、视觉验收、文案校对、音频生命周期、性能压力和发布包体预留资源，最后就会在收尾阶段一起爆发。

这次团队能够完成 Beta，说明执行力强；但后期执行强度偏高，也说明计划没有把资源压力提前摊平。

如果历史重来一遍，本章对应改进

如果重新做 Beta，我们会在资源层面做五个调整：

第一，为每个大功能配置“代码 + 数据 + UI + 资源 + 测试 + 文档”的资源表。只要其中任何一项缺人或缺时间，就不能把 issue 估得过低。

第二，为美术、音频、文案、发布分别设置负责人和验收清单。它们不是附属任务，而是玩家体验的一部分。

第三，建立每周试玩和截图验收资源。至少固定一名非实现者跑主流程，记录不理解、不好点、不好看、不流畅的地方。

第四，把性能和包体当作资源预算。终战敌人数、UI 重绘频率、音频文件数量、导出包大小都要有目标值。

第五，减少关键模块的单人依赖。地图生成、夜晚机制、UI 资产、发布流程这类高风险模块，应至少有第二个人能读懂和验收。

四、变更管理

1. 每个相关成员都及时知道了变更的消息吗？

部分做到了，但不够稳定。Beta 阶段的变更主要通过 GitHub issue、PR、commit message、文档更新和团队内部沟通传播。从仓库历史看，比较大的变更通常能在提交标题和文档中留下痕迹，例如：

• feat(night): 九天三幕日程 + 数据驱动胜利判定 + 飞行延后
• feat(map): terrain_first 第三阶段—接入主管线
• refactor(enemy): 寻路改纯单调下行(flow field), 删掉踱步补丁机制
• feat(events): 重构随机事件系统并实装全部插画
• feat(story): 通用剧情演出系统(引擎/数据/控制器) + 开场竖切片
• docs: 现状权威文档对齐到当前代码

这些记录让后来查看仓库的人能够知道“发生了什么”。尤其是 docs/ARCHITECTURE.md、docs/DATA_SCHEMA.md、docs/UI_SYSTEM.md 和玩法循环文档，在 Beta 后期承担了同步现状的作用。

但“知道变更消息”和“及时理解变更影响”是两回事。Beta 中很多变更是跨模块的，单靠 commit title 很难让所有相关成员立刻知道自己需要调整什么。比如：

• 夜晚模板从单晚模板升级为整夜多波计划，会影响 RunState、NightManager、WaveManager、敌情预览 UI、数据表和文案。
• 出怪口从固定少量标记变成 5 个候选口、每日激活集合和封口机制，会影响地图、白天交互、夜晚刷怪、UI 预览、事件和路径服务。
• UI 资产从占位样式变成 UiFrameSpec、UiArtRegistry 和生成资源，会影响所有 UI 脚本和场景。
• 敌人移动改成 flow field 后，路径预览、堵路拆墙、软避让、性能和战斗可读性都要重新校准。

这些变更虽然最后都被接上了，但过程中出现了不少“修正类提交”，说明相关成员并不总是在变更发生时同步知道全部影响。例如 fix(path): align route preview with enemy movement 就说明敌人移动与路线预览一度产生了偏差；fix(ui): restore FloatingLayer visibility so map popup shows 说明 UI 层级变更影响了既有交互。

结论是：团队有变更记录机制，但缺少“变更影响广播机制”。下阶段每个跨模块 PR 应该在描述中写清楚影响范围和需要关注的模块，而不是只靠代码 review 时临时发现。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？

Beta 中判断“必须实现”的主要依据是能否支撑完整 Beta 体验。最终被坚持做完的功能，大多符合以下条件：

• 影响主循环闭环：九天三幕、白天探索、夜晚战斗、遗物结算、胜负结算。
• 影响玩家理解：新手教程、剧情引导、敌情预览、出怪口颜色、UI 图标、事件面板。
• 影响策略深度：盟约、遗物、事件、商店、定向升星、夜晚词缀、Boss。
• 影响发布质量：音效、UI 资产、发布页资源、包体大小、性能优化。
• 影响基础可信度：路径预览和敌人实际移动一致、堵路拆墙玩法可用、Boss 长音效完播。

被推迟或弱化的内容，则多是“更精细但不阻断 Beta”的内容。比如 UI_SYSTEM 文档里仍提到遗物条视觉微调、部分视觉验收和后续资产完善；一些更深入的用户数据、外部试玩统计、完整自动化视觉回归，也没有在 Beta 内完成。

不过，这种取舍更多是后期自然形成的，而不是从计划一开始就明确写成 must/should/could/won't。到 6 月 14-16 日，团队实际上是在用发布压力倒逼取舍：能阻断 Beta 可玩性和可发布性的必须修；只影响锦上添花的部分先放下。

这种方式短期有效，但风险很高。因为当取舍发生在最后几天时，每个人对“必须”的理解可能不同。例如对玩法实现者来说，Boss 与夜晚机制是必须；对 UI 负责人来说，可读性和资源接入是必须；对发布负责人来说，包体和导出是必须；对新玩家来说，教程和提示是必须。缺少统一优先级时，各条线都可能觉得自己在救火。

下阶段建议使用明确的优先级：

• P0：不做就无法发布或无法完整游玩。
• P1：显著影响核心体验，但可以用降级方案发布。
• P2：改善体验或内容丰富度，可延期。
• P3：探索性、风格性或锦上添花。

并且每周更新一次 P0/P1 列表，避免最后几天才做取舍。

3. 项目的出口条件（Exit Criteria，什么叫“做好了”）有清晰定义吗？

没有足够清晰。Beta 最终能发布，是因为团队在后期不断修到“可以接受”，但这个“可以接受”更多依赖团队判断，而不是提前写好的出口条件。

从实际结果看，Beta 的隐性出口条件大概包括：

• 能从主菜单开始新游戏。
• 能完成白天探索、建造、招募、部署准备。
• 能进入夜晚并正常刷怪。
• 敌人能沿路径或 flow field 到达核心，不出现明显卡死。
• 玩家能看懂今晚敌情和出怪口预览。
• Boss 战可运行，阶段转换、特效、音频和奖励不崩。
• 夜晚结束后能进入遗物选择或结算。
• UI 不出现严重遮挡、缺图、滚动条异常或按钮不可点。
• 音效和 BGM 能基本反馈关键动作。
• 导出包可生成，包体不过大，终战性能可接受。

这些条件都很合理，但它们是在实现过程中逐渐浮现的，而不是 Beta 开始时写在 issue 或 release checklist 中。因此有些出口条件发现得偏晚：

• 终战性能问题直到 6 月 16 日通过 perf PR 解决。
• 导出包体大小到 6 月 15 日才修。
• Boss 长音效完播到 6 月 15 日才修。
• 路径预览和敌人移动一致性到 6 月 14 日才有专门修复。
• UI 美术接入和布局精修在 6 月 13-15 日高度集中。

这说明“做好了”的定义不只是功能列表，还应该包括性能、资源、UI 可读性、发布包和主流程验收。Beta 阶段我们有最终标准，但没有足够早地把它文档化。

下阶段出口条件应该写成 checklist，例如：

• 主流程：新开局到第 9 晚胜利至少完整跑通一次。
• 教程：新玩家可以完成教程并理解探索、建造、部署、朝向和入夜。
• 战斗：所有 Boss 至少在 CombatSandbox 和主流程中各验证一次。
• UI：1920x1080 下无关键文本溢出、无面板互相遮挡、无缺失图标。
• 资源：新增 PNG 和 import 文件齐全，音频 key 可检查，无失效路径。
• 性能：终战三 Boss 连战不卡到不可玩，拖动地图不触发全图高频重绘。
• 发布：导出包生成成功，包体大小在阈值内，主菜单/结算/重开可用。

4. 对于可能的变更是否能制定应急计划？

Beta 中部分变更有事实上的应急方案，但多数不是提前制定的。

已有的应急能力包括：

• 地图生成有 retry 和 fallback 思路，保证生成失败时不直接阻断游戏。
• 路径服务在正常路径和拆墙路径之间有模式切换，避免玩家堵路后敌人完全失效。
• UI 资源解析有 UiArtRegistry、旧 icon_key 兼容和部分缺图兜底，降低资源缺失导致崩溃的风险。
• CombatSandbox、DialogSandbox、作弊面板提供了快速验证和跳关能力。
• 音频资产检查工具能发现部分资源问题。
• CI 和导出流程能帮助发现构建层面的错误。

这些都是很有价值的应急能力。但很多应急是问题发生后才补的，而不是计划前就写好的预案。比如：

• 当敌人寻路与路线预览不一致时，后续才集中修复和重构。
• 当 UI 资产层级影响弹窗可见性时，后续才修复 FloatingLayer、ModalLayer 等。
• 当发布包体过大时，后续才减少 packaged export size。
• 当终战性能不足时，后续才优化索敌和重绘。

更理想的做法，是对高风险模块提前写“如果失败怎么办”：

• 如果 terrain-first 地图生成稳定性不足，是否保留旧生成器作为发布 fallback？
• 如果 UI 新资产来不及接完，哪些面板必须资产化，哪些可以保留简化样式？
• 如果 Boss 音频过大或播放异常，是否先降级为短音效或只保留 BGM？
• 如果九天三幕完整流程调不平，是否允许第 9 晚降低波数或先移除三 Boss 连战？
• 如果教程来不及完整引导，是否提供跳过和简化说明？

Beta 最终能完成，靠的是团队快速响应；但快速响应不能完全替代应急计划。

5. 成员是否能够有效处理意料之外的工作请求？

总体能处理，而且执行力很强。Beta 后期出现了许多意料之外或临近发布才暴露的问题，团队都通过 PR 解决了，例如：

• 修复导出包体大小。
• 修复 Boss 长音效完播。
• 追加 Boss 音乐与语音。
• 增加粉色奶龙事件选项音效。
• 修复路径预览与敌人移动不一致。
• 恢复用墙/高台堵路逼普通怪拆墙的玩法。
• 消除终战 O(N²) 索敌和前期每帧全图重绘。
• 追加作弊面板“获得全部正常遗物”按钮，方便最终验收。
• 调整夜晚词缀行布局、遗物事件资产和 overlay 层级。

这些说明成员面对突发问题时并没有停在讨论，而是能迅速定位、修改、合并。

但也有代价。意外请求过多，会让成员不断切上下文，尤其是核心实现者同时处理地图、敌人、数据、UI 预览、性能和文档时，很容易出现疲劳和遗漏。后期 PR 密度很高，短时间内大量合并也会提高回归风险。

下阶段要保留“快速处理意外”的能力，但减少意外数量。具体方式是：

• 每个高风险模块在进入发布候选前先做一次专项验收。
• 发布前冻结新需求，让意外请求只来自 bug 和验收失败。
• 为意外请求设置入口，由负责人判断优先级，不让每个人同时被打断。
• 对每个意外请求要求写清影响范围和验证结果，避免修一个问题引入另一个问题。

本章经验教训

Beta 的变更管理有两个特点：记录比较完整，控制不够提前。GitHub issue、PR、commit 和文档让我们能追溯变更，但很多重要取舍是在实现和发布压力中临时完成的。

这次最重要的经验是：跨模块变更不能只用“代码合并”来管理。它必须同时管理数据、UI、资源、测试、文档和发布影响。否则每个模块都觉得自己改完了，但玩家路径仍可能断在模块之间。

如果历史重来一遍，本章对应改进

如果重新做 Beta，我们会在变更管理上做四个调整：

第一，每个跨模块 PR 必须写“影响范围”。至少列出代码模块、数据表、场景、资源、UI、文档和验证方式。

第二，建立 release checklist，并在 Beta 开始时就维护，而不是发布前临时总结。Checklist 中每一项都要有负责人和验证状态。

第三，用 P0/P1/P2/P3 管理取舍。P0 必须完成，P1 可以降级，P2/P3 默认不进入发布候选期。

第四，对高风险变更写降级预案。地图生成、夜晚机制、Boss、UI 资产、音频和导出都要提前知道“做不完时怎么发布”。

如果做到这些，Beta 后期仍然会忙，但不会像这次一样把许多风险集中压到最后几天。

五、设计 / 实现

1. 设计工作在什么时候、由谁完成？是合适的时间、合适的人吗？

Beta 的设计工作不是一次性完成的，而是在多个关键系统推进过程中逐步完成。可以把它分为几类：

第一类是总体架构和玩法循环设计。当前项目已经明确 Game.tscn 内部的 World / Managers / UI 三层结构，核心运行状态归 RunState，静态配置归 DataRepo，跨模块广播归 EventBus，主场景切换归 SceneRouter。这些设计主要体现在 docs/ARCHITECTURE.md、docs/INTERFACE.md 和玩法循环文档中。它们在 Beta 后期被同步到当前实现，说明设计和实现逐渐对齐。

第二类是玩法系统设计。夜晚机制、地图生成、敌人寻路、遗物/盟约、随机事件、商店、定向升星等，都在 Beta 中经历了从设计到实现的闭环。比如夜晚机制最终形成九天三幕、多波模板、动态出怪口、夜晚词缀和幕末 Boss；地图生成最终形成 terrain-first、浮动核心、天然高台、河流、资源投放和连通校验；肉鸽构筑最终形成遗物池、盟约 tag、契约事件和定向升星。

第三类是 UI 与资源设计。docs/UI_SYSTEM.md 在 Beta 中承担了较完整的 UI 设计约束：顶部状态栏、左侧建筑/商店、底部部署栏、右侧敌情/详情、遗物面板、设置面板、事件/对话/结算面板，以及 UI 资产分层规范。与 Alpha 相比，Beta 的 UI 不再只是“能显示”，而是开始要求玩家能扫描、理解和操作。

第四类是内容和表现设计。随机事件、夜晚模板、Boss 特效、地图/角色/UI 生图 prompt、音效 key 和资源路径，都逐渐形成文档和数据表。这类设计不是传统 UML，而是“数据 schema + 资源规范 + prompt 文档 + 场景约束”的组合。

从人员匹配看，大体是合适的。熟悉玩法架构的人推进地图、夜晚、敌人、遗物和文档；熟悉 UI/资产的人推进界面、美术接入和导出；音频负责人推进 BGM、Boss 语音和关键音效；教程和调试工具也由对应成员补齐。这种分工让系统最终能合上。

但从时间点看，有些设计发生得偏晚。比如 UI 资产分层、发布出口、性能指标、路径预览与敌人移动一致性，都是在实现过程中逐渐明确的。如果这些设计约束在 Beta 初期就写清楚，后续返工会少一些。

2. 设计工作有没有碰到模棱两可的情况？团队是如何解决的？

有，而且 Beta 中很多重要进展都是从模棱两可到逐渐定型。

第一个模棱两可点是“夜晚到底怎么玩”。如果只说“增加更好的夜晚关卡机制”，可以有很多解释：增加敌人、增加 Boss、增加波次、增加词缀、增加预告、增加路线变化。最终团队把它收束成九天三幕、多波、动态出怪口、词缀、幕末 Boss、白天敌情预告和右侧 UI 预览。这是一个从“更多内容”变成“有节奏的整局结构”的过程。

第二个模棱两可点是“地图随机性和可控性如何平衡”。早期地图生成可以只保证连通，但 Beta 需要让地图产生策略差异：天然高台、河流、水域、山岳、资源点、核心位置、出怪口、迷雾前沿都要有意义。团队最终通过 terrain-first 生成器、核心浮动选址、资源近探索圈保底、出怪口安全半径和连通校验来解决。这个方案不是一开始完全确定的，而是通过多轮生成器提交和测试逐步收敛。

第三个模棱两可点是“敌人路线应该怎么被玩家理解”。线预览可以告诉玩家一条路径，但当多个出怪口、开阔地、绕行、拆墙和 flow field 同时存在时，线预览不够表达实际威胁。团队后来把预览改成每个出怪口异色覆盖面，并与右侧敌情编号联动。这个变化说明我们从“显示路径”转向“显示威胁区域”。

第四个模棱两可点是“UI 美术资源应该怎么接入”。如果把大图直接贴进面板，短期看起来快，但后续文字、进度条、按钮状态、滚动和动态列表都会受限。团队最终选择分层资产、九宫格、UiFrameSpec、UiArtRegistry 和 generated/source/styles/templates 分层，这让 UI 更可维护。

第五个模棱两可点是“随机事件是剧情，还是机制”。Beta 最终把随机事件做成契约系统：事件不是只讲故事，还会改变资源、遗物、盟约、出怪口和夜晚风险。这使事件成为构筑层的一部分，而不是纯文本弹窗。

这些模糊问题主要通过三种方式解决：

• 写设计文档或同步文档，例如夜晚机制、UI 系统、地图 prompt、Boss 特效文档。
• 做竖切片实现，用 PR 验证方向，再根据运行结果修正。
• 用数据表把分歧外置，让同一套机制能支持多种内容，例如 wave_templates.json、events.json、buffs.json、night_affixes.json。

这种方式有实践优势，但成本是返工较多。下阶段最好在高风险点先写“设计约束”，再进入大规模实现。

3. 团队是否运用单元测试、TDD、UML 或其他工具帮助设计和实现？这些工具有效吗？项目开始的 UML 文档和现在有什么区别？是否要更新 UML 文档？

团队没有严格采用 TDD，也没有看到传统 UML 作为主设计工具。更准确地说，Beta 使用的是 Godot 项目中更实用的一组工具：

• 架构文档：docs/ARCHITECTURE.md 描述项目骨架、节点结构、模块职责和数据归属。
• 接口文档：docs/INTERFACE.md 描述公开方法、EventBus 信号和模块协作链路。
• 数据文档：docs/DATA_SCHEMA.md 描述 JSON 表结构和字段含义。
• UI 文档：docs/UI_SYSTEM.md 描述 UI 分层、场景节点、资产规范和验收标准。
• 调试场景：CombatSandbox.tscn、DialogSandbox.tscn、UiAssetDerivedPreview.tscn。
• 自动化/半自动化测试：地图生成、夜晚计划、遗物抽取、定向升星、UI overflow lint 等。
• 资源工具：UI 派生资源生成、截图捕获、音频资产检查、音频处理脚本。
• GitHub 流程：issue、PR、CI、review、导出工作流。

这些工具是有效的。它们没有完全替代单元测试，但让复杂系统能被拆开验证。例如地图生成测试能帮助发现连通性和地形规则问题；遗物和夜晚 headless 覆盖能验证数据解析；UI screenshot/overflow 工具能发现视觉问题；音频检查工具能避免资源路径或格式问题；CombatSandbox 让战斗、Boss 和部署问题不用每次从主流程跑起。

不过，工具使用还不够系统。TDD 没有成为主要开发方式，原因可以理解：Godot 场景、UI、资源和玩法组合很难完全测试先行。但至少对纯逻辑模块，比如夜晚模板解析、词缀抽取、遗物过滤、地图生成校验、战斗数值计算，可以更接近 TDD 或先写测试夹具。

关于 UML，项目并没有维护传统 UML 图，因此不存在“项目开始 UML 与现在 UML 的差异”。但如果把架构文档当作 UML 的替代品，那么差异非常大：Beta 结束时的系统比早期更复杂，新增了 TutorialManager、RandomEventManager 的地图事件职责、AudioManager 的多类音频、PathService / flow field、NightTemplateResolver、NightAffixService、BossController、UI 资产管线和多个 UI 组件。

是否要更新 UML？如果课程要求 UML，那么应该补一份轻量图，而不是试图画完整类图。建议补三类图：

• 模块协作图：RunState、DataRepo、GameController、DayManager、NightManager、WaveManager、MapManager、PathService、UI 的关系。
• 主流程时序图：新开局、白天探索、进入夜晚、刷怪、夜战结束、遗物选择。
• 数据流图：JSON 配置如何进入 DataRepo，再被 Manager、Actor 和 UI 使用。

这些图可以从当前文档生成，不必过度追求 UML 形式。重点是帮助团队和评审快速理解当前架构。

4. 什么功能产生的 Bug 最多？为什么？发布之后发现了什么重要 bug？为什么开发时没有想到？

从提交历史看，Bug 和修复最集中的区域主要有五类。

第一类是 UI 和视觉层级。相关提交包括恢复 FloatingLayer、ModalLayer、ResultPanelSlot 可见性，修复 HUD 滚动条、部署筛选条、对话说话人标签、遗物界面、UI 资产层级、按钮语义、夜晚词缀行布局、overlay 层等。UI bug 多的原因是 UI 同时依赖场景树、脚本、资源、样式、输入和文字内容；任何一个层级变化都可能让面板不可见、按钮不可点或文本溢出。

第二类是路径、寻路和预览一致性。相关提交包括路线预览改完整线条、迷雾遮挡、出怪口覆盖面、flow field、软避让、堵路拆墙、路径预览与敌人移动一致等。Bug 多的原因是敌人移动不是纯算法问题，它直接影响 UI 预览和玩家策略。如果预览和实际不一致，玩家就会觉得规则不可信。

第三类是地图生成。terrain-first、skeleton_v2、高台、河流、核心选址、资源分布、出怪口、连通性和性能都在 Beta 中快速变化。地图生成 bug 多，是因为它同时要满足自然性、连通性、可玩性、资源公平、视觉可读和性能。

第四类是 Boss、敌人和战斗反馈。凑凑企鹅的二阶段、反伤、AOE、特效文件、帧居中、近战阻挡、攻击范围、Boss 音频和终战三 Boss 连战都经历了修正。Boss 是高风险功能，因为它把数值、AI、阶段、特效、音频、UI 和奖励集中在一起。

第五类是发布和性能。发布包体压缩、终战索敌 O(N²)、前期每帧全图重绘、拖动地图 8Hz 全图重绘等问题在最后阶段被修复。原因是平时测试更多关注“能不能玩”，而发布版本需要关注“是否流畅、是否包体合理、是否在压力场景仍可玩”。

“发布之后”的严格外部 bug 数据目前没有，因为没有真实用户反馈记录；但从最后几天的 release PR 看，发布候选阶段发现的重要问题包括：

• 终战性能不足。
• 导出包体过大。
• Boss 长音效被截断。
• 堵路拆墙玩法被路径逻辑影响。
• UI 夜晚词缀布局需要打磨。

为什么开发时没有想到？主要原因是测试场景和压力场景不足。许多问题在单功能测试中不会出现，只有完整主流程、终战、多 Boss、多 UI 层、真实导出包、长音频播放时才会暴露。下阶段需要把这些场景提前纳入验收，而不是等发布候选才集中发现。

5. 代码复审是如何进行的，是否严格执行了代码规范？

代码复审主要通过 GitHub PR 进行。仓库 README 规定所有改动必须通过 PR 合并到 dev，合入前通过 Godot 云端 CI 测试，PR 必须关联 issue。Beta 数据显示 2026-05-25 以来共有 62 个 PR，其中 58 个合并、4 个关闭未合并。这说明团队整体遵守了 PR 流程，不是直接在 dev 上随意提交。

代码规范方面，团队总体有意识遵守项目规范：

• Commit message 多数使用 feat(scope): ...、fix(scope): ...、docs(scope): ...、chore(scope): ... 等形式。
• 新逻辑多数放在既有职责边界内，例如 Manager、DataRepo、EventBus、UI 控制器、Actor、数据表。
• 数据表继续使用 JSON 保存静态配置，不把运行时状态写入数据。
• 场景路径多数通过 scene_key 和 DataRepo 维护，而不是到处硬编码。
• UI 逐步收敛到 game_ui_style.gd、ui_tokens.gd、ui_frame_spec.gd、ui_art_registry.gd 等工具。
• GDScript warning 被当成风险处理，例如有提交专门消除 mouse_filter 枚举告警和未用参数告警。

但复审严格程度不完全稳定。Beta 后期 PR 密度很高，6 月 14 日合并 17 个 PR，6 月 15 日合并 11 个 PR。这样的节奏下，review 很容易偏向“能不能合、CI 过不过、是否阻断发布”，而不是充分审查架构、命名、边界、测试和文档。大量 fix 提交也说明一些问题是在合并后通过实测才发现。

另外，部分 commit message 出现中英混合、格式不完全统一、PR 标题如 “final pr / Final Final Final PR” 等，说明发布后期流程压力已经影响了规范性。这不影响功能完成，但对后续追溯不友好。

下阶段 Code Review 应该更明确地分层：

• 功能 review：功能是否满足 issue。
• 架构 review：是否破坏 Manager/DataRepo/EventBus/UI 边界。
• 数据 review：JSON 字段、schema、命名和兼容性是否正确。
• UI review：节点层级、输入穿透、文本溢出、资源路径是否正确。
• 测试 review：是否有对应 headless 测试、沙盒验证或人工验收说明。
• 发布 review：是否影响包体、导出、性能或资源 import。

这样 review 才能从“看过代码”变成“控制风险”。

本章经验教训

Beta 的设计与实现有一个非常明显的进步：系统边界逐渐清晰，玩法主循环真正闭合，数据驱动和资源管线也开始成熟。团队没有只靠堆代码，而是在不断把实现沉淀为架构文档、数据 schema、UI 规范和工具脚本。

但问题也很清楚：许多关键设计是在实现中才被迫明确的。夜晚机制、地图生成、敌人移动、UI 资产、Boss 反馈和发布性能都经历了“先做出来，再发现系统性约束”的过程。这个过程能跑通 Beta，但会带来返工和后期风险集中。

如果历史重来一遍，本章对应改进

如果重新做 Beta，我们会在设计 / 实现上做六个调整：

第一，对高风险系统先写一页设计约束，再写代码。夜晚、地图、敌人、UI 资产、Boss、发布都属于高风险系统。

第二，所有跨模块功能都要先做竖切片。比如动态出怪口应先打通“数据 -> 地图 -> UI -> 夜晚刷怪 -> 验证”，再扩展内容。

第三，纯逻辑模块尽量先写测试。夜晚计划、词缀抽取、遗物筛选、地图连通、战斗数值等都适合更强的自动化覆盖。

第四，UI 资产先定分层规则，再批量接图。不要先贴大图再反复拆。

第五，Boss 和终战场景提前进入性能测试。只在普通夜晚验证是不够的。

第六，Code Review checklist 化。每个 PR 至少回答：改了什么、影响哪些模块、怎么验证、是否更新数据/文档/资源、有没有发布风险。

这样做不会减少所有 bug，但会让 bug 更早暴露，也会让设计更少依赖最后几天的集中补救。

六、测试 / 发布

1. 团队是否有一个测试计划？为什么没有？

Beta 阶段有测试意识，也有测试工具，但没有形成足够完整、提前写好的测试计划。更准确地说，我们有“局部测试计划”和“问题驱动测试”，但缺少贯穿整个 Beta 的“主流程验收计划”。

已经存在的测试和验证方式包括：

• GitHub PR 与 Godot CI：保证合入 dev 前至少能通过基础构建/检查。
• Godot headless 测试：部分夜晚计划、遗物抽取、战斗能力和地图生成逻辑有脚本覆盖。
• Debug 场景：CombatSandbox.tscn 用于战斗、部署、敌人和 Boss 验证；DialogSandbox.tscn 用于剧情对话验证；UiAssetDerivedPreview.tscn 用于 UI 派生资产预览。
• 工具脚本：UI 派生资产生成、截图捕获、UI 溢出检查、音频资产检查、音频处理脚本。
• 人工验证：团队在后期通过主场景、沙盒和发布包进行大量手动检查。

这些测试方式说明团队不是没有测试。但是，测试计划没有在 Beta 开始时明确写成 checklist。我们没有一份从 5 月 25 日就维护的表格来记录：

• 每天主流程是否能从新开局跑到入夜。
• 每个 Boss 是否在主场景和沙盒中都验证过。
• 每个夜晚词缀是否至少触发过一次。
• 每个随机事件是否能打开、选择、结算、关闭。
• 每种 UI 面板是否在 1920x1080 下无遮挡和溢出。
• 导出包是否能运行，包体大小是否达标。
• 终战压力场景是否保持可接受性能。

为什么没有形成完整测试计划？主要原因是 Beta 的功能范围持续变化。夜晚机制、地图生成、UI 资产、随机事件、Boss、音频、教程和发布都在后期持续追加；当功能边界还在变时，团队更容易先写功能、再靠问题驱动修复，而不是先维护完整测试矩阵。

另一个原因是 Godot 项目测试门槛较高。很多问题依赖场景树、资源导入、UI 层级、音频播放和真实帧循环，不能像纯函数一样容易单测。于是团队更依赖沙盒和人工验收。

结论是：Beta 的测试不是空白，但测试计划不够前置、不够系统、不够覆盖主流程。

2. 是否进行了正式的验收测试？

没有看到严格意义上的正式验收测试记录。Beta 最终通过 issue 全部关闭、PR 合并、发布 PR、导出修复和性能修复形成了事实验收，但缺少一份明确的验收报告来说明每个出口条件是否通过。

实际发生的验收更像“发布前集中验收”。从 PR 和提交历史看，6 月 13-16 日团队集中处理了大量接近验收阶段的问题：

• UI 与资源：接入派生 UI 资产、修复遗物界面、调整夜晚词缀行布局、补齐滚动条纹理、修复 overlay 层级。
• 路径与敌人：修复路径预览和敌人移动一致性，恢复堵路拆墙玩法，优化 flow field 和覆盖面预览。
• 剧情与教程：接入通用剧情系统，调整教程流程与内容。
• 音频：补齐战斗音效、夜晚转场、胜利/失败反馈、Boss 音乐与语音、事件选项音效，并修复长音效完播。
• 发布：添加 release page assets，更新 distribution exports，减少 packaged export size。
• 性能：优化终战索敌 O(N²)、前期全图重绘和拖动地图重绘。

这些工作说明团队确实做了验收，只是验收结果散落在 PR 和提交里。正式验收应该把这些检查项汇总成表，例如：

验收项	结果	证据
新开局到第一晚	通过/未通过	截图、录屏或测试记录
第 3/6/9 晚 Boss	通过/未通过	沙盒 + 主流程验证
出怪口封堵	通过/未通过	手动步骤
随机事件	通过/未通过	事件列表抽样
遗物三选一	通过/未通过	headless + 主流程
UI 1920x1080	通过/未通过	截图
导出包	通过/未通过	CI 或本地命令
性能压力	通过/未通过	帧率/耗时记录

下阶段发布前应把正式验收测试作为 release PR 的附件，而不是只靠“大家都试过”。

3. 团队是否有测试工具帮助测试？有哪些改进计划？

有，而且这是 Beta 相比 Alpha 的明显进步。主要测试工具和辅助工具包括：

• scripts/debug/test_map_generation.gd：用于地图生成规则、连通性和边界检查。
• scripts/debug/test_relic_draw.gd：用于遗物抽取、稀有度和里程碑保底等逻辑。
• scripts/debug/test_highland_platform.gd：用于高台地形、部署门控和人工高台行为回归。
• scripts/debug/test_wall_art.gd：用于墙体美术和透明度等检查。
• CombatSandbox.tscn：用于部署、战斗、敌人、Boss、技能、路径等快速验证。
• DialogSandbox.tscn：用于剧情和对话系统验证。
• UiAssetDerivedPreview.tscn：用于 UI 派生资产预览。
• scripts/tools/generate_ui_derived_assets.gd：用于生成 UI 派生资产。
• scripts/tools/scan_ui_actual_sizes.gd：用于扫描 UI 实际尺寸。
• scripts/dev/check_audio_assets.py：用于音频资产检查。
• scripts/dev/prepare_audio_assets.ps1：用于音频素材处理。
• CI 与导出工作流：用于基础构建和发布包生成。

这些工具有效地降低了部分风险。比如地图生成如果完全靠手动玩，很难覆盖大量种子；UI 派生资产如果全靠手工裁切，很容易路径和尺寸不一致；音频资源如果没有检查，很容易出现缺文件、命名不一致或格式问题。

但测试工具还需要升级。改进计划如下：

第一，建立主流程自动烟测。至少能在 headless 环境中启动游戏、创建一局、进入白天、解析夜晚计划、进入夜晚、模拟波次结束、进入遗物选择和结算。哪怕不能完全模拟玩家操作，也应验证主状态机不崩。

第二，建立九天流程回归。可以用作弊/调试接口快速推进天数，验证第 1-9 天的模板解析、词缀数量、活跃出怪口数量、Boss 晚和胜利判定。

第三，建立 UI 截图基线。对主菜单、白天 HUD、夜晚 HUD、敌情预览、单位详情、建筑/商店、事件面板、遗物面板、剧情面板、结算面板各截一张图，至少人工对比是否有明显遮挡、缺图、溢出。

第四，建立资源完整性检查。检查 data 中引用的图标、音效、场景 key、事件插图、Boss 特效是否存在，避免发布包中出现失效路径。

第五，建立性能基准脚本。记录典型场景和终战场景下的重绘次数、敌人数量、索敌耗时和帧率区间。Beta 已经修了 O(N²) 问题，下一阶段应防止回归。

第六，自动生成验收报告。CI 不只显示成功/失败，还应输出测试项、覆盖场景和失败原因，方便 PR review。

4. 团队如何测量并跟踪软件效能？压力测试呢？实际运行结果说明这些测试有用吗？应该如何改进？

Beta 中性能问题被发现并修复，但性能测量还不够前置和量化。最明显的性能工作发生在 6 月 16 日：

• perf(combat): 消除终战 O(N²) 索敌与前期每帧全图重绘
• perf(map): 拖动地图跳过重绘，消除敌情预览的 8Hz 全图重绘

这些提交说明团队在实际运行中发现了性能瓶颈，并且能够定位到复杂度和重绘频率。具体问题包括：

• 终战敌人数量、单位数量和 Boss 机制叠加后，索敌复杂度过高。
• 前期地图或 HUD 在不需要时仍然全图重绘。
• 拖动地图时敌情预览导致高频全图重绘。

修复这些问题很有价值，也证明性能测试是有用的。但问题是，性能压力发现得偏晚。终战三 Boss 连战和大量敌人本来就是 Beta 的关键卖点，应当更早进入压力测试，而不是最后一天才集中优化。

目前缺失的性能跟踪包括：

• 没有固定记录平均帧率、最低帧率、最大敌人数下的耗时。
• 没有记录地图重绘次数、寻路重建次数、UI 刷新次数。
• 没有自动比较性能优化前后的数据。
• 没有把发布包运行性能和编辑器运行性能区分记录。

下阶段性能改进计划：

第一，为 CombatSandbox 增加压力预设，例如 50/100/200 敌人、多 Boss、多飞行单位、多建筑阻挡、多投射物场景。

第二，在关键系统加轻量统计开关，例如每秒索敌次数、路径重建次数、地图 redraw 次数、UI refresh 次数、活动 enemy/unit/projectile 数量。

第三，发布前固定跑终战压力场景，并记录结果。不是只看“能不能过”，还要看是否卡顿到影响操作。

第四，性能 PR 要写优化对象和效果。例如从 O(N²) 降到什么策略，重绘频率从多少降到多少，哪些场景收益最大。

第五，避免 UI 定时刷新过度。敌情预览、资源条、波次倒计时、遗物条等 UI 应该事件驱动或低频刷新，不能默认每帧重算。

Beta 的性能修复说明团队有能力处理问题；下一阶段要把这种能力前移到开发中期。

5. 发布过程中发现了哪些意外问题？

发布过程中的意外问题主要有五类。

第一，发布包体问题。fix(export): reduce packaged export size 表明导出包在接入大量 UI、音频、事件插图和资源后体积超出预期。Beta 中新增了 464 个 UI 生成资源、112 个音频文件、69 个事件插图资源，如果没有资源筛选和导出规则，很容易把 raw、source、临时文件或不必要资源打进包里。

第二，性能问题。终战三 Boss 连战和复杂敌人/单位场景暴露了索敌复杂度和重绘问题。发布时玩家最容易遇到的不是单个功能 bug，而是“后期卡顿导致无法操作”。这类问题必须在发布前压力测试中发现。

第三，音频生命周期问题。奶龙 Boss 长音效被截断，需要专门修复保证长音效完播。Boss BGM、语音、事件音效和结算音效都不是简单播放一次，还涉及切场景、切阶段、长短音效叠加和音量设置。

第四，路径玩法回归问题。fix(pathfind): 恢复用墙/高台堵路逼正常怪拆墙的玩法 说明寻路优化或重构后，原本设计的堵路拆墙玩法受到影响。发布前才发现这类问题，说明回归测试没有覆盖“玩家会怎样利用建筑改变路径”。

第五，UI 细节和布局问题。夜晚词缀行、遗物事件资产、overlay 层级、滚动条、对话标签、部署筛选条等都在发布前后被修复。UI 问题很容易被认为是小问题，但它们直接影响玩家是否能看懂和点击。

这些意外问题共同说明：发布不是最后“打一个包”，而是一套独立工程。发布要检查资源、性能、导出、主流程、回归玩法、视觉和音频。Beta 结束时团队处理了这些问题，但下阶段应该更早设置 release candidate。

本章经验教训

Beta 测试和发布的最大经验是：工具越早进入流程，后期越少靠人肉救火。地图、遗物、UI、音频和性能都有工具化苗头，这是好事；但工具覆盖还不够系统，很多问题仍然在发布前集中暴露。

另一个经验是：完整主流程测试比单功能测试更重要。一个功能单独能跑，不代表它在九天三幕、真实 UI、真实资源、真实导出包、终战压力和新手路径中仍然好用。

如果历史重来一遍，本章对应改进

如果重新做 Beta，我们会在测试 / 发布上做六个调整：

第一，从 Beta 第一天建立验收 checklist，每周更新，不等发布前再补。

第二，把主流程烟测加入 CI 或固定手动流程。至少每周跑一次从新开局到夜晚结算的路径。

第三，把终战压力测试提前到中期。Boss 和性能不是最后才测。

第四，把 UI 截图验收变成固定产物。每个 UI PR 至少附关键界面截图。

第五，把资源完整性检查放进发布流程。data 引用、UI 图标、事件插图、音频 key、import 文件都要检查。

第六，发布候选期只修 bug、性能和导出，不再接新系统。这样发布问题能被稳定处理，而不是和新功能一起互相干扰。

下一阶段的目标不是“测试更多”，而是“测试更早、更固定、更贴近玩家实际路径”。

七、团队角色、管理与合作

1. 团队的每个角色是如何确定的？是不是人尽其才？

Beta 阶段的角色分工主要是从 Alpha 以来的模块熟悉度自然延续出来的，而不是完全重新分配。也就是说，谁对某一块系统最熟，谁就继续承担该块的主要推进和收尾。这样做的好处是效率高、上下文少丢失；坏处是关键模块容易形成单点压力。

从提交、PR 和 issue 记录看，Beta 阶段主要角色大致如下：

• Xiao Yihan / 肖一涵：主要承担玩法主链路、地图生成、夜晚机制、敌人/Boss、寻路、数据表、文档同步和最终性能收尾。相关工作包括 terrain-first 地图、动态出怪口、九天三幕、夜晚词缀、第三 Boss 凑凑企鹅、flow field 敌人推进、路径预览和终战性能优化。
• 風船：主要承担 UI 美术接入、HUD 精修、UI 资产管线、发布资源和导出相关工作。相关工作包括 UI 派生资产、遗物界面、对话面板拆分、部署筛选、快捷键、夜晚词缀行布局、release page assets 和 packaged export size 修复。
• S7AM1NA：主要承担音频方向，包括战斗音效、夜晚转场、胜利/失败反馈、剧情说话反馈、Boss BGM 与语音、事件选项音效，以及音频资产检查工具。
• Old-Joy：主要参与数值、路径和体验修复，包括 starting economy、combat values、late-day prestige rewards、bonus relic choice 可见性和路径预览与敌人移动一致性。
• Z-XUA：主要参与新手教程和调试工具，包括教程形式与流程修改，以及作弊面板创建，帮助后期调试和跳关验收。

总体上，这个分工是“人尽其才”的。熟悉系统的人推进系统，熟悉 UI/资源的人推进表现，熟悉音频的人推进听觉反馈，熟悉教程和调试的人补齐上手和验收入口。这使 Beta 能在后期高强度收口。

但这也暴露出三个问题。

第一，角色边界比较自然，但不够制度化。某些工作是“谁会谁做”，不是“计划中明确谁负责、谁验收、谁备份”。这在赶进度时很有效，但当负责人忙不过来时，其他人很难立刻接手。

第二，模块负责人和验收负责人没有明显分离。比如某个系统的实现者往往也是第一个验收者，这会导致一些“自己知道怎么用”的设计，对新玩家不一定友好。

第三，关键模块知识集中。地图生成、夜晚机制、UI 资产管线、发布流程等都需要至少两个人能解释和维护，否则后续迭代风险较高。

下阶段角色分工应从“谁熟谁做”升级为“负责人 + 备份人 + 验收人”的结构。

2. 团队成员之间有互相帮助吗？

有，而且 Beta 能完成很大程度上依赖跨模块互相补位。

最明显的互助体现在“功能链路补齐”上。比如夜晚机制不只是玩法代码，必须有人补敌情 UI、出怪口预览、数据表、Boss、音效和性能；随机事件不只是事件逻辑，还需要事件插图、事件面板、事件音效和事件奖励；剧情系统不只是对话脚本，还需要 UI 面板、头像裁剪、背景音乐、说话反馈和教程流程。

具体例子包括：

• 夜晚机制与 UI 协作：九天三幕、多波、出怪口、词缀等功能需要右侧敌情预览、地图覆盖面预览和颜色联动支撑。玩法和 UI 的协作让玩家能理解夜晚变化。
• UI 与美术/工具协作：正式 UI 资产不是单个成员手工替换，而是通过派生资产、frame spec、art registry、截图和实际场景精修共同完成。
• 音频与玩法协作：Boss 音乐、语音、事件选项音效和夜晚转场都需要玩法触发点接好，音频资源才能真正变成体验的一部分。
• 调试工具与主流程协作：作弊面板、CombatSandbox、DialogSandbox 降低了后期验证成本，让其他成员可以更快定位问题。
• 文档与实现协作：玩法循环、架构、接口、数据 schema 和 UI 系统文档在后期同步，减少了“只有实现者知道”的隐性知识。

团队互助也体现在后期大量 fix 提交上。一个系统的改动引出另一个系统的问题后，成员没有停在互相甩锅，而是通过 PR 快速补齐。例如路径预览和敌人移动一致性、UI 层级和弹窗可见性、音频长音效完播、导出包体和终战性能，都在最后阶段得到修复。

不足是，互助很多发生在“问题已经出现之后”。更理想的互助应该更前置：设计阶段就让相关成员参与评审，避免实现后才发现资源、UI、文案、音频或发布跟不上。

3. 当出现项目管理、合作方面的问题时，团队成员如何解决？

Beta 中的项目管理和合作问题主要有四类：范围扩大、后期集中收尾、跨模块变更影响、发布前意外问题。

第一，范围扩大时，团队主要通过 issue 和 PR 继续拆解，而不是停止迭代。比如 Beta 原计划中的夜晚、UI、美术、音频、事件和教程，在后期不断增加细分任务。这样保证了最终体验完整，但也导致燃尽图在计划期内不够好看。

第二，后期集中收尾时，团队采用高频 PR 和快速修复方式。6 月 13-15 日合并了大量功能和修复，6 月 16 日又继续做性能优化。这说明团队在紧急阶段执行力强，但也说明项目管理上没有足够早进入冻结。

第三，跨模块变更影响通过“修复 PR + 文档同步”解决。比如敌人移动改动后修路径预览，UI 层级改动后修弹窗可见性，数据表调整后同步 schema 和玩法循环文档。这种方式最终有效，但它是补救式协作。

第四，发布前意外问题通过专门 PR 解决，例如包体、性能、Boss 音频、堵路拆墙和 final release PR。团队没有因为临近结束就放弃这些问题，而是继续修到可发布。

合作中比较好的地方是：大家围绕“Beta 能不能成为完整体验”这个共同目标做取舍。即使模块边界不同，最后都服务于主流程。

合作中需要改进的是：缺少明确的变更入口和冻结规则。后期如果每个人都能提出“这个也要修”，就容易让发布候选期变成新一轮开发期。下阶段需要由 PM 或 release owner 统一判断：这个问题是 P0 bug、P1 体验、还是可以延期。

4. 明确感谢团队成员的帮助

按照模板要求，这里列出团队成员之间具体的感谢。由于本报告基于仓库记录整理，以下感谢尽量对应可见的工作事实。

我感谢 Xiao Yihan / 肖一涵 对团队的帮助，因为他承担了 Beta 中最复杂的玩法主链路整合：地图生成、夜晚机制、敌人寻路、Boss、数据表、文档和性能收尾。没有这些系统被打通，Beta 很难成为完整的一局游戏。

我感谢 風船 对团队的帮助，因为他持续推进 UI 美术接入、界面精修、资产管线和发布资源，让游戏从“功能可用”变得更接近“玩家能读懂、能操作、能发布”。

我感谢 S7AM1NA 对团队的帮助，因为他补齐了战斗、剧情、夜晚、结算、Boss 和事件音效，让 Beta 不只是静态界面和逻辑，也有了关键反馈和氛围。

我感谢 Old-Joy 对团队的帮助，因为他在数值调优、路径体验、奖励曲线和遗物可见性等方面做了修正，帮助游戏从“系统能跑”走向“体验更顺”。

我感谢 Z-XUA 对团队的帮助，因为他推进了新手教程和作弊面板，让新玩家入口和后期调试验收都有了更明确的支撑。

也感谢所有在 issue、PR、测试、文档和发布过程中补位的成员。Beta 的完成不是单个模块胜利，而是多个模块最终接上的结果。

本章经验教训

Beta 阶段团队合作的最大优点是执行力强、补位快、目标一致。遇到问题时，团队倾向于继续把事情做完，而不是停在讨论。

最大的问题是角色和备份机制不够清晰。很多工作依赖自然分工和个人熟悉度，短期效率高，长期风险大。后期集中收尾也说明团队需要更明确的 PM/release owner 角色来控制范围和冻结。

如果历史重来一遍，本章对应改进

如果重新做 Beta，我们会在团队协作上做五个调整：

第一，每个大模块设负责人、备份人和验收人。负责人实现，备份人理解，验收人从玩家角度检查。

第二，每周做一次跨模块同步，只讨论会影响别人工作的变更，例如数据结构、UI 入口、资源路径、发布规则和主流程变化。

第三，发布前设 release owner，统一判断哪些请求能进发布候选，哪些延期。

第四，鼓励成员在 PR 描述中写“需要谁关注”。例如 UI PR 标记玩法负责人看交互，玩法 PR 标记 UI 负责人看展示，音频 PR 标记触发点负责人看生命周期。

第五，减少单点知识。地图生成、夜晚机制、UI 资产管线、音频 key、发布导出都要有文档和至少一名备份成员能接手。

这样团队仍然可以保持 Beta 阶段的速度，但不会把风险过度压在少数成员身上。

八、总结与改进计划

1. 团队目前属于 CMM/CMMI 中的哪个档次？

如果用 CMM/CMMI 的思想粗略对照，我们认为团队目前处于 2 级到 3 级之间：已经不再是完全依赖个人的混乱开发，但距离组织级、可重复、可量化优化的成熟过程还有差距。

接近 2 级的证据是：

• 团队使用 GitHub issue、PR、estimate 标签、milestone 和燃尽图管理任务。
• README 和 AGENTS.md 中有分支、commit、PR、CI、数据表、Godot/GDScript、UI 和资产规范。
• 大多数改动通过 PR 合并到 dev，不是直接改主干。
• Beta 相关 issue 最终全部关闭，说明任务能被跟踪到完成。
• CI、导出流程、headless 测试和调试场景已经进入工作流。

接近 3 级的证据是：

• 架构文档、接口文档、数据 schema、UI 系统文档和生图 prompt 文档已经比较系统。
• 模块职责逐渐清晰：RunState、DataRepo、EventBus、各 Manager、Actor、UI Controller 的边界被反复强调。
• UI 资产、音频、数据表、地图生成和夜晚机制不只是临时实现，而是形成了一定规范和工具链。

仍未达到稳定 3 级的原因是：

• 计划执行不够可预测，Beta 后期集中关闭大量任务。
• 变更影响没有总是提前广播，很多跨模块问题靠后续修复解决。
• 正式验收和发布 checklist 不够前置。
• 性能、用户反馈和视觉验收缺少稳定量化指标。
• 关键模块仍有单点知识风险。

因此，最准确的判断是：团队已经具备“可管理”的基础，正在向“已定义过程”过渡，但还没有形成稳定、可重复、可度量的完整工程体系。

2. 团队目前处于萌芽、磨合、规范、创造阶段中的哪一个？

团队当前处于“规范阶段”，并开始向“创造阶段”过渡。

说它是规范阶段，是因为团队已经有比较明确的仓库结构、Git 流程、数据规范、UI 规范、文档体系和合并流程。Beta 中的大量工作不是随意堆在一起，而是基本沿着 Manager、DataRepo、EventBus、UI 工具类、JSON 配置和资源目录推进。

说它开始向创造阶段过渡，是因为 Beta 阶段已经出现了许多不是照搬模板的系统设计：

• terrain-first 地图生成，用高度/湿度、河流、天然高台、浮动核心和资源保底形成策略地图。
• 九天三幕夜晚结构，把多波、词缀、Boss、活跃出怪口和敌情预览组合成完整节奏。
• flow field 敌人推进和覆盖面预览，让敌人移动表现更像“战线”而不是单怪走线。
• 遗物、盟约、事件、商店权重漂移、定向升星共同构成肉鸽构筑层。
• UI 资产分层和派生管线，让 Godot UI 能接入更完整的美术表现。

但创造阶段要求团队不仅能做出有想法的系统，还能稳定地把想法转化为可维护、可测试、可发布的产品。Beta 说明团队有创造力，但工程节奏还需要继续规范化。

3. 团队在这个里程碑相比前一个里程碑有什么改进？

相比 Alpha，Beta 最大的改进是从“模块原型”变成“完整体验”。

具体改进包括：

• 玩法结构从零散功能收束为九天三幕主循环。
• 地图从基础随机生成升级为 terrain-first 自然地貌和浮动核心。
• 夜晚从简单刷怪升级为多波、词缀、动态出怪口、Boss 晚和敌情预告。
• 敌人从单一路径推进升级为共享距离场、单调下行、软避让和拆墙逻辑。
• 肉鸽层从基础 Buff 扩展为 45 件遗物、盟约 tag、事件交易、商店权重漂移和定向升星。
• UI 从可用面板升级为更完整的 HUD、详情栏、敌情预览、遗物界面、设置面板和事件/剧情/结算面板。
• 资源从占位向正式 UI 资产、事件插图、音效、Boss 音乐与语音推进。
• 工程从只关注功能实现，发展到包含 CI、导出、资源检查、性能优化、文档同步和调试场景。

可量化地看，Beta 相关 46 个 issue 已全部关闭；2026-05-25 以来合并 58 个 PR；主干有 239 条提交；代码和资源变更覆盖 1762 个文件。这些数据说明 Beta 不是小修小补，而是一次完整的系统升级。

4. 目前最需要改进的一个方面是什么？

最需要改进的是“发布前的可预测性”，也就是从计划、开发、测试到发布的节奏控制。

Beta 的最终成果是好的，但过程偏后期集中。6 月 8 日计划期结束时燃尽并不理想，6 月 13-16 日集中合并大量功能、修复、资源、性能和发布内容。团队执行力很强，但如果下一阶段继续依赖最后一周冲刺，会遇到更大风险：

• 功能越多，最后几天回归越困难。
• 资源越多，导出和包体越容易出问题。
• 系统越复杂，性能和跨模块 bug 越难临时修。
• 个人负载越集中，单点失败风险越高。

因此最重要的改进不是“多写一点代码”或“多做一点内容”，而是建立更稳定的 release 节奏：

• 功能冻结。
• 内容冻结。
• 发布候选。
• 验收 checklist。
• 性能和包体基线。
• 外部试玩反馈。

如果这个节奏建立起来，团队的创造力才能稳定转化为可发布质量。

5. 对照敏捷开发原则，我们做得最好的是哪些？请列出具体事例。

我们做得较好的敏捷原则有以下几个。

第一，持续交付可工作的软件。Beta 阶段通过大量 PR 持续把功能合入 dev，而不是长期在孤立分支上闭门开发。5 月 25 日以来 58 个 PR 合并到主线，说明团队一直在把可运行增量并入主干。

第二，欢迎需求变化。Beta 中很多系统都在实践中变化，例如夜晚机制从命名模板发展到九天三幕，地图生成从 skeleton_v2 演进到 terrain-first，敌人移动从路径线转向 flow field 和覆盖面预览。团队没有因为早期设计而拒绝更合适的方案。

第三，业务人员和开发者共同协作。这里的“业务”可以理解为玩法、UI、美术、音频和发布目标。Beta 中玩法实现、UI 表现、资源接入、音频反馈和发布质量相互配合，最终形成完整体验。

第四，关注技术卓越和良好设计。团队没有只堆功能，还重构了 UI 资产管线、路径服务、夜晚解析器、BossController、数据 schema、文档和性能热点。perf、refactor、docs 和 test 提交都说明团队在关注工程质量。

第五，工作的软件是进度的首要度量。最终团队不是只说“设计完成”，而是通过 issue 关闭、PR 合并、主流程运行、资源接入和发布包来判断 Beta 是否完成。

做得不足的敏捷原则也要承认：

• 可持续开发节奏不足，后期冲刺过重。
• 面对面或高质量同步的记录不足，很多协作信息散在 PR 和 commit 中。
• 用户反馈不足，没有真实玩家数据闭环。
• 简洁性还可以更好，部分中间方案和临时修复后续需要清理。

6. 下一阶段如何提高代码管理的质量？代码复审和代码规范如何提高？

代码管理下一阶段重点是让 PR 从“合并入口”升级为“质量控制入口”。

具体改进：

• PR 模板增加固定字段：关联 issue、改动范围、影响模块、验证命令、截图/录屏、风险和回滚方案。
• 跨模块 PR 必须列出影响数据表、场景、资源、文档和发布的地方。
• 大 PR 拆小。比如“夜晚机制重构”应该拆成解析器、数据表、UI 预览、波次执行、测试和文档几个 PR。
• 后期禁止含糊 PR 标题，例如 final pr。发布 PR 应写清楚合入范围和验证结果。
• Code Review 增加 checklist：架构边界、数据 schema、UI 输入和层级、资源路径、测试覆盖、性能影响。
• 对 GDScript warning 保持敏感，继续避免 Variant 推断、无用参数和 Godot warning 变 error。
• 对未合并 PR 和关闭未合并 PR 定期复盘，判断是方向错误、重复工作还是计划变化。

最终目标是：任何人半年后看 PR，都能知道为什么改、改了什么、怎么验证、有什么风险。

7. 整个程序的架构如何具体提高？如何通过重构提高质量，如何衡量？

架构下一阶段应该围绕“降低跨模块耦合、提高可验证性”改进。

具体方向：

• 继续坚持 RunState 只保存全局运行状态，DataRepo 只管理静态配置，Manager 管生命周期和协调，Actor 管自身行为，UI 只展示和发请求。
• 把夜晚计划、词缀、Boss、事件、遗物等纯逻辑尽量保持数据驱动，并增加测试夹具。
• 对 UI 层继续减少脚本定位和硬编码资源路径，统一走 Slot、UiFrameSpec、UiArtRegistry 和 UiDisplayText。
• 对敌人寻路、路径预览和建筑阻挡建立更清晰的契约：玩家看到的预览必须和敌人实际可达逻辑一致。
• 对 Boss 特殊行为建立扩展点，避免未来 Boss 直接在 EnemyActor 或 BossController 中堆大量 enemy_id 分支。
• 对音频建立 key -> 资源 -> 触发点 -> 音量策略的注册表，减少散落调用。
• 对调试/作弊能力保留，但避免进入正式玩法路径。

衡量架构提高可以用这些指标：

• 新增一个夜晚模板是否只需要改数据表。
• 新增一个遗物是否不需要改 UI 组件。
• 新增一个 Boss 是否不需要破坏通用 BossController。
• UI 缺一张图是否能在检查工具中发现。
• 路径逻辑修改后是否有测试覆盖预览一致性。
• 主流程烟测是否能稳定通过。
• PR 中跨模块修改文件数是否逐渐下降。

8. 其他软件工具的应用应该如何提高？

工具改进可以分为四类。

第一，测试工具。把现有 headless 测试扩展为固定测试套件，覆盖夜晚计划、地图生成、遗物、事件、商店、Boss 阶段和主流程烟测。

第二，视觉工具。保留并完善截图捕获和 UI overflow lint，为主要界面建立截图基线。UI PR 附截图，发布前对比截图。

第三，资源工具。扩展音频检查和 UI 资源检查，增加 data 引用资源完整性扫描，包括图标、事件插图、Boss 特效、音效 key、scene_key 和 import 文件。

第四，发布工具。导出流程应自动输出包体大小、包含资源统计、平台构建结果和启动烟测结果。发布 PR 应自动附这些信息。

此外，可以考虑增加 changelog 生成工具，从 PR 标题和 issue 自动生成阶段总结初稿，减少每次复盘都靠人工追溯。

9. 项目管理有哪些具体提高？

项目管理下一阶段要提高三件事。

第一，计划颗粒度。大 issue 必须拆出交付件；美术、音频、文案、发布和测试都要估点。

第二，节奏控制。明确功能冻结、内容冻结、发布候选和正式发布四个时间点。冻结后不再接新系统。

第三，风险管理。每周维护 P0/P1 风险列表，标明负责人、影响、应急方案和当前状态。

此外，燃尽图要继续保留，但不能只看 issue 是否关闭，还要看主流程是否可运行、验收项是否通过、风险是否下降。

10. 项目跟踪用户数据方面计划提高什么？

这是 Beta 最薄弱的地方之一。当前没有真实用户量、日活、周活、留存、关卡通过率、失败点、误操作和功能使用率数据。

下一阶段建议从轻量开始，不需要一上来做复杂埋点平台。可以先做三类记录：

• 外部试玩记录：试玩者身份、游玩时长、是否完成教程、卡在哪里、主观评价。
• 本地匿名指标：开始游戏次数、进入第几天、失败天数、是否完成第 9 天、常用建筑、常用职业、遗物选择。
• UI/教程观察：玩家是否理解探索、建造、部署朝向、敌情预览、封口、遗物和事件。

如果不方便做线上数据，也可以先通过表格记录 5-10 名试玩者的观察结果。关键是不能继续完全用开发者自己的感觉替代用户反馈。

11. 项目文档的质量如何提高？

Beta 的文档比 Alpha 有明显进步，但下一阶段需要提高“现状准确性”和“使用价值”。

具体改进：

• 文档开头标明“当前事实”还是“未来设计”，避免过时设计误导实现。
• 每个大 PR 如果修改数据结构、架构边界或 UI 约定，必须同步对应文档。
• DATA_SCHEMA.md 应和 JSON 字段保持一致，新增字段必须同 PR 更新。
• INTERFACE.md 应记录公开方法和 EventBus 信号，不记录已经废弃的接口。
• UI_SYSTEM.md 应保留当前节点结构、资产 key、验收标准，过时 TODO 要定期清理。
• 生图 prompt 文档应区分已入库资源和待生成资源。
• Postmortem、验收报告和 release checklist 应作为 docs 的固定产物，而不是临时聊天记录。

文档质量的衡量标准是：新成员能否靠文档搭起项目模型，旧成员能否靠文档避免问重复问题，评审能否靠文档理解当前实现。

12. 对于人的领导和管理，有什么具体可以改进？

人的管理重点不是增加控制，而是减少不必要的压力和单点风险。

具体改进：

• 每个模块明确负责人、备份人、验收人。
• 后期收尾时由 release owner 统一排优先级，避免所有成员同时被多个紧急请求打断。
• 对高负载成员提前减压，把内容填充、文档、截图验收、资源检查拆给其他成员。
• 每周同步不只问“做了什么”，还要问“卡在哪里、需要谁帮忙、哪些变更会影响别人”。
• 对贡献做具体感谢和记录，避免只有最后提交最多的人被看见。
• 保持任务透明，让每个人知道当前最重要的 P0/P1 是什么。

Beta 的经验说明，团队成员愿意补位，也能高强度完成任务。管理改进的目标，是让这种执行力更可持续。

13. 对软件工程的理论和规律有什么心得体会或不同意见？

Beta 阶段最大的体会是：软件工程不是和写代码相对立的“额外负担”，而是让复杂系统能继续写下去的基础。

如果没有 issue、PR、CI、文档、数据 schema、资源规范和调试工具，Beta 也许能靠个人能力做出一些功能，但很难把地图、夜晚、敌人、UI、事件、遗物、音频和发布接成一局完整游戏。越到后期，越能感受到“程序质量 + 工程质量”才是软件质量。

另一个体会是，游戏项目的软件工程不能只围绕代码。美术、音频、文案、UI、数值、教程和发布都要进入工程流程。否则它们会在最后阶段变成不可控风险。

我们也有一点自己的理解：对学生团队来说，过早追求形式完整的流程可能会拖慢探索；但完全不做流程又会在 Beta 后期付出代价。比较适合我们的方式，是“轻量流程 + 强制关键出口”。平时保持迭代速度，到关键节点必须有 checklist、测试、验收和冻结。

14. 下一阶段最高优先级改进清单

如果只能投三票，我们会把票投给以下三项：

第一票：建立发布候选 checklist 和冻结节奏。原因：这是 Beta 最大痛点，能直接减少最后一周集中风险。

第二票：建立主流程烟测和终战压力测试。原因：主流程和终战是玩家体验核心，也是最容易跨模块出问题的地方。

第三票：建立外部试玩反馈机制。原因：没有真实用户反馈，就无法判断教程、UI、敌情预览和构筑系统是否真的被理解。

其他也重要，但可以排在下一层：

• PR 模板和 review checklist。
• UI 截图基线。
• 资源完整性扫描。
• 文档“当前事实/未来设计”分层。
• 模块负责人、备份人、验收人制度。

15. 总结

Beta 阶段对 HexaVigil 来说，是从原型走向完整游戏的一次关键跃迁。我们完成了九天三幕、terrain-first 地图、动态出怪口、flow field 敌人推进、夜晚词缀、Boss、遗物、盟约、随机事件、剧情教程、UI 资产、音频和发布优化。最终 Beta issue 全部关闭，主干形成了可发布版本。

但这次复盘也说明，我们还不能只满足于“最后做出来了”。更好的团队应该能更早知道风险在哪里，更稳定地推进计划，更清楚地定义出口，更早地测试主流程，更真实地收集用户反馈。

如果用一句话概括 Beta 的经验，就是：

我们已经证明团队能把复杂系统做出来；下一阶段要证明团队能稳定、可预测、可验证地把复杂系统做好。

这也是下一阶段最重要的软件工程目标。