心晴屿 Moodisle Alpha 冲刺总结随笔

作业基本信息

这个作业属于哪个课程	2601_FZU_SE
这个作业要求在哪里	团队第四次作业-站立式会议+α冲刺
团队名称	心绪气象局
这个作业的目标	Alpha 冲刺总结

目录

一、项目预期计划与现实进展

华为云代码仓库： 心晴屿 Moodisle 项目仓库

1.1 项目简介

心晴屿 Moodisle 是一款面向学生及初入职场用户的情绪陪伴式待办与专注应用。我们希望把现实任务管理与轻量养成结合起来，让用户在记录和完成任务的过程中获得陪伴与反馈。产品强调低压力、零惩罚和隐私优先，采用本地单用户模式，核心功能包括待办管理、天气精灵、陪伴专注、岛屿天气、精灵图鉴和本地存档。

用户录入待办时，可以选择面对这项任务的情绪，系统据此关联相应的天气精灵；完成任务后，用户能够收服精灵，并推动岛屿状态和成长资源变化。专注功能提供另一条成长路径，用户与精灵共同专注，积累陪伴与成长进度。待办和专注共同影响岛屿体验，但不要求用户必须先完成一次专注才能完成待办。我们希望这些反馈能够帮助用户看到自己的行动成果，同时避免中断操作带来的额外压力。

1.2 Alpha 阶段预期计划

本次 Alpha 冲刺计划用七天完成心晴屿 Web 端的一个可演示版本。团队希望在阶段结束时，用户能够从录入待办开始，选择面对任务时的情绪，召唤对应的天气精灵；完成现实任务后收服精灵，并在主岛和图鉴中看到相应变化。用户还可以选择伙伴进行陪伴专注，应用通过本地存档保存进度，并用背景音乐和音效补充反馈。

（1）功能计划

模块	预期完成的工作	希望达到的效果
待办管理	定义任务、日期和情绪类型，建设任务录入、展示及操作页面。	用户能够创建待办，选择情绪和难度，并在任务完成后得到清楚的状态反馈。
专注计时	建设专注状态机和页面，处理开始、暂停、恢复及结束。	用户能够进入陪伴专注；切换页面或返回时，计时和状态能够按规则处理。
天气精灵	建设精灵实体、资源和动画，将完成待办与精灵收服连接。	用户完成任务后能够看到收服反馈，精灵状态与任务结果对应。
主岛与天气	建设岛屿页面、季节地图和天气模型，接入天气遮罩等视觉效果。	主岛能够展示场景，业务状态变化可以与天气和岛屿表现衔接。
精灵图鉴	建设精灵卡片及收藏展示。	用户能够查看不同精灵，并区分已获得与未获得状态。
数据存档	建设数据库、仓储及 Web 存储适配，推进 JSON 存档导入导出。	应用能够保存和恢复本地进度，并对存储异常和格式兼容问题进行处理。
音频系统	接入背景音乐、按钮音效及收服等业务音效，处理浏览器播放限制。	用户操作和场景变化时能获得相应声音反馈，并可管理播放状态。
测试与交付	逐步编写领域、存档和业务流程测试，准备运行展示和项目文档。	团队能够检查核心规则、发现模块衔接问题，并提供可查看的阶段成果。

（2）七天安排

时间	预期安排
Day1	建立工程基线和代码规范，梳理情绪、专注、界面、数据及测试等基础设计。
Day2	建设领域内核、待办和精灵模型、专注状态机，以及页面容器、存储和音频接口。
Day3	接入全局控制器、游戏状态与事件，推进主岛页面、天气模型、数据仓储和基础音效。
Day4	把待办完成与精灵收服串联起来，同时推进专注生命周期、天气效果、精灵动画和 Web 存储适配。
Day5	完善图鉴、待办交互、气候与专注联动、场景音频和存档测试，开始检查模块之间的配合。
Day6	集中处理移动端布局、后台计时、浏览器存储和音频等适配问题，补充必要的工具和测试。
Day7	检查输入边界、资源和构建配置，整理文档，开展业务流程回归，并准备 Demo 展示。

（3）分工、会议与验收安排

团队按照架构与控制器、待办、专注与天气、UI 与主岛、精灵与美术、数据存储、音频、测试八个方向分工。各成员负责自己模块的开发或检查；涉及待办收服、数据保存和页面反馈等跨模块流程时，由相关成员共同对接。

冲刺期间计划每天举行站立式会议，每位成员说明前一天完成的工作、遇到的问题以及下一步安排。会议记录中汇总代码提交、对应 Issue 或测试等非开发工作的成果，配合会议照片、燃尽图和项目运行展示。各成员也根据任务需要使用相应的 AI 技术员辅助分析问题，但代码和方案仍由成员检查、集成和验证。

验收时，我们计划按用户操作顺序演示：录入待办并选择情绪，进行专注，完成任务并查看精灵收服反馈，再返回主岛、打开图鉴，最后刷新页面检查数据恢复。除演示外，还要结合自动化测试和人工操作检查异常输入、页面切换、存储与音频等情况。

1.3 七天冲刺进展

时间	计划重点	实际进展	成果
Day1	工程基础与规范	建立 Flutter Web 工程基线、代码检查规则、情绪枚举、专注配置、视觉 Token 和数据库草案，准备字体裁剪及测试工具。	pubspec.yaml、emotion.dart、tokens.dart、database.dart 和工具脚本等。
Day2	领域模型与状态机	推进 GameCore、待办和精灵实体、专注状态机、通用页面容器与存储接口，接入基础音效。	game_core.dart、task.dart、pet.dart、focus_engine.dart、page_frame.dart 等文件。
Day3	控制器与页面初版	建立全局控制器、状态与事件，建设天气模型和主岛春季昼夜场景，推进仓储、存档编码和背景音乐。	game_controller.dart、game_state.dart、island_page.dart，以及专注和天气测试文件。
Day4	核心交互联动	推进待办完成与精灵收服事件链、待办操作、前后台生命周期监听、夏秋地图、精灵动画与 Web 存储适配。	Issue #125—#132，包含待办页、精灵动画组件、Web 存储适配器和收服测试。
Day5	主要模块完善	完善异常保护、待办删除与置顶、专注和天气联动、冬季场景、图鉴、存储降级及音乐切换。	运行展示描述涉及冬季岛屿、精灵图鉴和 IndexedDB；存档往返与存储测试。
Day6	多端适配与稳定性	优化软键盘避让、时间戳校准和响应式布局，推进漫游卡片、资源台账、存档导入导出及 Safari 音频恢复。	运行展示描述涉及待办录入、主岛和宽屏布局；一致性检查、覆盖率工具及音频测试替身。
Day7	回归与交付准备	整理生产入口和交付文档，完善输入边界、算法参数、视觉资源、数据库访问与最终音效，推进业务流程和回归测试。	应用演示和测试结果说明， app_flow_test.dart、regression_test.dart 等。

1.4 计划与现实进展对比

从七天记录来看，开发内容总体覆盖了 Alpha 计划中的主要模块。前两天的工程基线和领域模型为后续开发提供基础，第三至第五天逐步形成页面及业务联动，第六、七天则转向兼容性、边界处理和交付准备。实际开发中，我们投入了较多精力处理浏览器环境带来的问题，包括后台定时器挂起、软键盘遮挡、存储能力受限和音频恢复。这说明 Web Demo 的完成不仅依赖功能数量，也依赖具体运行环境中的可靠性。

仍需持续完善的工作主要集中在真实设备测试、异常场景和跨模块一致性。例如，静态截图可以呈现页面，却无法单独证明后台恢复后的计时正确；存储适配代码能够说明处理路径，但降级及恢复效果仍需实测；精灵漫游的地形约束方案也需要结合实际动画验证。

1.5 项目运行展示

项目安卓端运行视频

项目运行视频二

以下是 Web 界面，展示了新手引导、主岛与各功能页面的初始状态。

新手引导与情绪选择：首次进入时，欢迎页面介绍待办与天气精灵之间的关系；引导页面提示用户选择情绪属性。

主岛与待办页面：主岛显示秋季地图、放晴度和装扮商店。待办页面展示任务输入框、情绪选项与难度设置。

图鉴、心绪回廊与专注页面：图鉴显示尚未收服的伙伴，回廊页面列出区域及解锁条件。专注页面在没有伙伴时给出提示，并展示伙伴云游区域。

二、团队分工、协作与成员收获

2.1 团队分工

成员	学号	主要职责	代表性工作	七天工作内容
连一帆	102400317	架构与全局控制器	建立工程基线、GameCore 与 GameController，推进待办收服事件链、异常保护、多端检查及交付文档。	Day1：建立 Web 工程和代码检查基线。 Day2：建设领域内核 game_core.dart。 Day3：接入 game_controller.dart 和 Web 入口配置。 Day4：推进待办完成与精灵收服的事件管道。 Day5：处理全局异常保护和版权规范检查。 Day6：建设多端配置一致性检查并调优控制器。 Day7：整理应用入口、README 和发布文档。
徐宇扬	102400330	待办管理与领域状态	定义情绪、待办、游戏状态与事件，完善待办操作、撤销、软键盘适配和输入边界。	Day1：定义情绪类型和天气映射。 Day2：建设任务实体及本地日期抽象。 Day3：整理游戏状态快照和业务事件。 Day4：建设可交互待办页面并接入操作图标。 Day5：完善删除和置顶功能。 Day6：处理移动端软键盘遮挡并接入撤销操作。 Day7：加强输入长度和列表展示的边界处理。
邱宇翔	102400326	专注计时与天气算法	建设专注状态机、生命周期通道和气候引擎，推进时间戳校准及结算参数调优。	Day1：定义专注常量和游戏配置。 Day2：建设专注状态机与漫游相关配置。 Day3：推进天气循环与气候模型。 Day4：建设应用生命周期监听并调整状态转换。 Day5：推进气候综合引擎和专注页面接入。 Day6：处理页面挂起、恢复后的时间戳同步。 Day7：调整专注结算与气候参数。
苏涵棋	102400327	UI/UX 与主岛场景	建设设计 Token、页面容器和主岛页面，接入季节地图、天气效果及响应式布局。	Day1：建立设计 Token 和配色。 Day2：建设通用页面容器与导航图标。 Day3：搭建主岛页面并接入春季昼夜地图。 Day4：推进夏秋地图和天气遮罩。 Day5：接入冬季昼夜地图与天气粒子效果。 Day6：调整响应式断点和宽屏容器。 Day7：检查主岛视觉并整理美术资产说明。
李燕玲	102400404	精灵与美术资源	建设精灵实体、动画、图鉴和漫游卡片，整理资源台账、应用图标及资源清单。	Day1：准备美术资源提示词和资产接入工具。 Day2：建设精灵实体并接入焦焦二阶资源。 Day3：建立图标注册组件并补充精灵资源。 Day4：建设精灵序列帧组件并接入三阶图片。 Day5：推进图鉴页面及收藏品目录。 Day6：建设漫游卡片和逐资产台账工具。 Day7：整理应用图标、资源清单并收尾图鉴。
王馨怡	102400108	数据持久化与存档	建设数据库、仓储与存档编码，推进 Web 适配、存储降级、导入导出和数据访问优化。	Day1：设计数据库结构草案。 Day2：生成数据库辅助类并建立存储接口。 Day3：建设游戏仓储和 JSON 编解码。 Day4：推进 Web 存储适配器与跨平台桩文件。 Day5：处理内存降级和写入协调。 Day6：推进存档导入、导出和格式迁移。 Day7：调整数据库索引和仓储访问。
林子璇	102400105	音频与资源优化	优化字体资源，建设音频服务，接入背景音乐和交互音效，处理切换与播放恢复。	Day1：编写中文字体子集化工具。 Day2：建立音频服务接口并接入点击、添加音效。 Day3：接入晴天背景音乐和任务完成音效。 Day4：建设音频依赖注入，接入收服音效与迷雾背景音乐。 Day5：推进背景音乐平滑切换及升级音效。 Day6：处理 Safari 音频解锁和页面恢复，补充提示音。 Day7：整理音效生成工具并接入成长相关音效。
谢思晨	102400306	自动化测试与质量保障	建设测试基础设施，补充领域、存档、音频替身与业务流程测试，推进覆盖率统计及回归。	Day1：建立测试配置和资源扫描工具。 Day2：完善临时目录清理与测试指南。 Day3：编写专注和天气相关单元测试。 Day4：补充精灵收服与状态测试。 Day5：编写存档序列化往返和存储测试。 Day6：建设音频平台测试替身及覆盖率统计工具。 Day7：推进核心业务流程和回归测试。

2.2 组员协作情况

我们按照既定模块认领任务，并通过每日站立式会议同步完成情况、困难和下一步安排。成员在记录中列出负责的文件及对应 Issue，使其他成员能够了解模块推进到了哪一阶段。遇到影响其他模块的问题时，需要先明确状态与接口，再调整各自实现。随着开发从单模块建设转向联调，我们更加重视提前反馈依赖问题。前台操作、异步事件、动画和存档不能各自假定其他环节已经完成。测试工作也随着模块推进逐步展开，从领域逻辑到存档，再到业务流程，帮助团队检查组合后的行为。

团队的协作逐步展开：Day1—Day2 先由各成员建立工程基线、领域实体、页面容器、存储接口和测试环境，这些基础需要先约定名称和职责，后面的模块才能接入。Day3—Day4 转向模块之间的连接：连一帆的控制器需要接收徐宇扬的任务状态和事件，再协调李燕玲负责的精灵展示与王馨怡负责的存档；邱宇翔的专注状态则需要通过生命周期通道与页面同步。谢思晨围绕已形成的规则补充相应测试。Day5—Day6 的协作重点转向运行环境和使用细节。苏涵棋调整页面和主岛布局，徐宇扬处理待办输入及键盘遮挡；邱宇翔检查页面挂起后的专注时间，林子璇处理切换或恢复页面后的音频状态；王馨怡处理 Web 存储与导入导出，谢思晨则补充存档和音频相关测试工具。Day7 的任务集中在收尾：连一帆整理入口与交付文档，其他成员分别处理待办边界、计时与天气参数、页面和资源、仓储、音效以及回归测试。

2.3 各成员的收获和心得

连一帆

这七天我主要负责项目的应用层架构和全局控制器。从一开始搭建工程配置、整理多端依赖，到后来把待办完成、精灵收服和数据保存串起来，再到检查各平台配置、整理启动入口和交付文档，我对整个项目的运行流程有了更清楚的认识。

过程中最让我费心的是异步操作的顺序。任务完成后，动画、状态更新和数据保存都要接上，如果调用关系没理清，就可能互相等待或出现异常。我反复梳理了事件流程，也补充了异常处理。到了最后打包时，还要注意 Release 模式下入口被裁剪等问题。以前我觉得架构更多是划分文件和接口，这次才体会到，它还要考虑各模块怎样配合，以及出错时程序能不能继续运行。后面做项目，我会更早和负责各模块的同学沟通接口，也会提前验证打包结果，避免问题都堆到最后。

这次冲刺也让我感受到沟通的重要性。控制器要连接多个模块，一个接口的变化可能影响待办、精灵和存档等好几个地方。自己考虑清楚还不够，还要及时和其他成员对齐数据和调用方式。每天梳理进度的过程，也让我更清楚哪些任务可以先做，哪些问题需要尽早提出来一起解决。

徐宇扬

这次冲刺我主要负责待办和情绪映射。从定义情绪类型、设计天气映射，到完善待办实体和页面交互，我逐渐把最初比较抽象的想法变成了用户可以实际操作的功能。做情绪映射时，如何划分不同情绪对应的数值范围让我想了不少，也让我意识到规则如果一开始说不清，后面联调就容易产生分歧。

做页面时，我还遇到过滑动列表容易误触删除、手机键盘遮住输入框、长文本影响布局等问题。这些情况单看都不大，但真正用起来很影响体验。调整手势、页面布局和文本显示后，我对“功能做出来”和“功能用起来顺手”之间的区别有了更直观的感受。以后除了检查正常流程，我也会多站在使用者的角度试一试，看看误操作和特殊输入会带来什么问题。

在情绪和天气映射的设计中，我学会了先把规则和边界写清楚，再去实现具体逻辑。不同情绪如何区分、状态变化怎样反映到天气上，都需要考虑前后是否一致，也需要和负责天气及界面的同学沟通。

邱宇翔

七天里我主要负责专注计时和天气演变相关的逻辑。刚开始以为计时只要让定时器按秒累加就够了，实际开发后才发现，浏览器切到后台时可能暂停或限制定时器，回来后显示的时间就会不准确。我改用时间戳计算实际经过的时间，并处理页面恢复和计时状态衔接的问题。

后面把专注行为和天气变化联系起来时，还要考虑频繁开始、取消短时任务会不会让天气数值反复波动。通过设置变化阈值，我对状态转换和边界条件有了更深入的理解。这次最大的收获是，写算法不能只看理想情况下的结果，还得考虑程序所处的运行环境和用户的实际操作。今后我会更早把后台切换、超时和频繁操作这些情况加入验证。

在和其他模块联调时，我也更加理解了状态设计的重要性。计时的开始、暂停、结束和页面恢复并不是孤立的，状态一旦不清楚，就会影响页面显示和后续天气变化。把每种情况下该发生什么先梳理出来，解决问题时就更容易找到原因。七天的工作让我积累了处理浏览器生命周期和时间计算的经验，也让我学会把一个看似简单的问题拆开分析。

苏涵棋

我这次主要负责界面设计和主岛场景。前期整理颜色、间距等设计规范，后面逐步接入地图、天气遮罩和环境效果，也调整了不同屏幕尺寸下的页面布局。看着原本静态的页面慢慢有了天气和场景变化，我很有成就感。

开发中也发现，画面好看并不代表在所有设备上都流畅。地图和天气效果叠加时可能出现掉帧，我尝试把静态背景和动态区域分开，减少重复绘制；适配不同屏幕时，还遇到了地图边缘黑边和裁剪问题。最后检查动画时，也需要考虑不同屏幕刷新率带来的速度差异。这些经历让我明白，做界面不能只看一张设计图，还要在不同尺寸和设备上实际查看，兼顾可读性、流畅度和整体风格。

在统一设计规范的过程中，我也意识到，颜色和间距并不是凭感觉分别调整就可以的。多个页面由不同成员开发，如果缺少共同的样式依据，很容易出现按钮、文字和布局不一致的情况。把常用样式整理起来以后，讨论和修改都有了更清楚的依据。这次让我在视觉设计之外，也学到了性能和适配方面的知识。

李燕玲

这七天我主要负责精灵素材、展示组件和资源管理。从整理素材规格、检查图片尺寸，到接入精灵不同形态、制作动画和完善图鉴，我对美术资源进入项目后的流程有了更完整的认识。

精灵动画曾经出现过动作切换时位置抖动的问题，后来统一了各帧的脚底定位基准，效果才自然一些。处理精灵活动范围时，也要注意不能让它走进建筑等不合理的区域。到冲刺后期，资源数量多了，清单和实际文件的核对也变得重要，因此借助脚本检查资源台账。以前我更关注图片本身好不好看，这次发现命名、尺寸、位置和来源记录同样重要。今后制作素材时，我会从一开始就注意统一规格，减少接入时的反复修改。

素材接入的过程让我更加重视和程序同学的配合。一张图片在本地看起来合适，放进界面后还要考虑大小、透明区域和动画位置；图鉴展示也需要与精灵状态对应。提前了解这些要求，再整理和检查素材，可以减少来回调整的次数。这次我不仅练习了资源处理，也学会了用清单记录素材，关注文件是否齐全、来源是否清楚。七天时间比较紧，我有时会先关注眼前的展示效果，后来才发现整理工作也需要同步进行。

王馨怡

我主要负责数据持久化和 Web 端存储。前期设计数据库结构、处理 Web 平台的配置，后面逐步完善存档读写、异常降级以及数据导出等功能。做这些工作时，我一直在想：用户关闭页面再回来，之前的数据能不能正常找回。

比较棘手的是不同浏览器的存储环境并不完全一样，有些情况下本地存储可能无法使用。因此需要考虑存储异常时的处理；频繁更新数据时，也要注意减少重复写入。做 JSON 导出时，我又接触了浏览器下载文件的方式，以及导入数据时需要考虑的格式兼容问题。通过这次冲刺，我认识到数据保存不是写入成功就结束了，还要考虑读取、异常和后续恢复。以后我会更仔细地检查各种存储条件，并和测试同学一起验证数据是否完整。

在处理存储问题的过程中，我对数据结构、平台差异和异常处理有了更具体的认识。同一个功能在正常浏览器环境下可以使用，并不代表换一种环境也一定没有问题。尤其是存储不可用时，程序如何继续运行、用户的数据会受到什么影响，都需要认真考虑。

林子璇

这次我负责字体资源优化和音频功能。最开始通过字体子集化减少 Web 端加载的资源大小，之后逐步接入背景音乐和操作音效，处理不同场景下的音乐切换和播放状态。这七天让我对 Web 端多媒体开发有了更实际的了解，也让我学会在遇到问题时先区分是资源本身、播放状态还是浏览器环境造成的。

音频开发比我预想的复杂。直接切换音乐会显得突兀，频繁切换页面又可能出现多个背景音乐同时播放；在移动浏览器中，自动播放限制和页面切换也会影响声音恢复。我通过调整淡入淡出、管理播放状态和处理页面可见性变化来改善这些问题。这次让我学到，多媒体功能不仅要有素材，还要关注加载、播放时机和浏览器的限制。后续我希望能在更多实际设备上检查音量、切换和恢复效果，让听感更自然。

做字体优化时，我认识到资源体积和显示效果需要一起考虑。压缩后虽然有利于加载，但也要检查项目需要的文字是否仍然能够正常显示。音频工作同样如此，资源能够播放只是第一步，还要考虑音量、切换时机和用户是否希望静音。

谢思晨

我主要负责自动化测试和质量检查。从搭建测试环境、检查资源和代码来源，到编写精灵收服、成长状态以及存档读写相关的测试，我逐渐熟悉了项目中各模块的运行方式，也体会到测试需要尽早参与开发。

测试随机收服逻辑时，同一段代码可能因为随机结果不同而偶尔失败，后来通过固定随机数种子让测试条件更稳定。检查存档时，我也发现不能只看能否保存和读取，还要留意嵌套数据的字段和类型是否发生变化。另外，在没有音频设备的环境中运行测试时，需要用测试替身隔离底层平台依赖。这七天让我明白，好的测试既要能发现问题，也要能稳定重复运行。以后我会更早和开发同学沟通边界情况，让测试跟着功能一起完善。

测试过程中，我也逐渐理解了各模块之间的联系。例如，精灵收服不只是一个随机结果，还会影响状态变化和后续保存；存档测试也不能只看一个字段。为了写出有用的测试，我需要先和负责功能的同学确认预期，再思考正常流程和容易出错的边界。这次冲刺让我知道发现问题只是测试的一部分，把复现条件和现象描述清楚同样重要，这样大家才能更快定位原因。

2.4 Alpha 阶段工作量比例

成员	工作内容	工作量比例
连一帆	架构与控制器，完成每日冲刺随笔，代码规范、冲刺任务与计划随笔	13.0%
徐宇扬	待办与领域状态，项目总体把控，功能实现	13.0%
邱宇翔	专注与天气算法，完成测试随笔，制作评审表	12.0%
苏涵棋	界面与主岛场景，完成测试随笔	12.5%
李燕玲	精灵与美术资源，完成冲刺总结随笔	12.5%
王馨怡	数据持久化，完成冲刺总结随笔	12.5%
林子璇	音频与资源，制作课堂答辩PPT	12.0%
谢思晨	测试与质量保障，制作课堂答辩PPT	12.5%
合计	八个模块方向	100%

三、AI 技术员的表现与贡献

3.1 AI 技术员配置与协作方式

负责成员	AI 技术员角色	主要协助方向
连一帆	AI 系统架构师	分层接口、异步流程、异常保护和平台配置
徐宇扬	AI 领域程序员	待办实体、状态转换、交互和输入边界
邱宇翔	AI 状态机与算法技术员	专注计时、生命周期和天气算法
苏涵棋	AI 视觉设计师	视觉规范、响应式布局和天气渲染
李燕玲	AI 概念美术与交互员	精灵资源、动画定位和资源管理
王馨怡	AI 数据库专家	存储适配、降级、存档兼容和数据一致性
林子璇	AI 多媒体工程师	音频状态、音乐切换和浏览器兼容
谢思晨	AI 测试技术员	测试用例、随机性控制、测试替身和回归

整个冲刺中，成员先说明当前功能、异常表现和项目约束，再请相应角色的 AI 分析原因、提出方案。成员结合现有代码判断建议是否适用，完成修改与集成，再通过运行或测试验证。AI 的角色随着任务变化从基础设计和实现辅助，逐步转向复杂问题排查与边界测试。

七天冲刺中的 AI 协作情况

时间	当天协作重点	AI 技术员的主要帮助
Day1	工程基础与规范	协助梳理 Flutter Web 工程分层、代码规范、情绪与天气映射、专注计时思路、视觉 Token、数据库结构和测试基础设施；同时帮助分析字体裁剪、图片尺寸统一及资源扫描。
Day2	领域模型与状态机	围绕领域内核、任务和精灵实体、专注状态机、页面容器、存储接口及音频服务，协助成员明确模块职责、数据结构和接口边界。
Day3	控制器与页面初版	协助梳理全局控制器和游戏状态，分析天气状态转移、精灵图片渲染及存档编解码问题；测试方面帮助设计虚拟时间方案，减少专注测试中的实际等待。
Day4	核心交互联动	重点分析待办完成、精灵收服动画和存档写入的异步顺序，以及浏览器后台计时、天气图层重绘、精灵动画定位、Web 存储降级、音频切换和随机测试等问题。
Day5	功能完善与异常处理	协助处理全局异常、待办列表排序、跨自然日专注统计、天气粒子渲染、图鉴灰度展示、高频存储写入、音频实例管理及存档往返测试。
Day6	Web 适配与稳定性	围绕多端配置一致性、软键盘遮挡、后台计时恢复、宽屏布局、精灵漫游、Web 存档导出、Safari 音频恢复和音频测试替身提供建议。
Day7	回归与交付准备	协助检查 Release 构建、长文本边界、专注与天气参数、主岛动画、资源清单、数据库查询、音频格式及端到端回归测试。

3.2 冲刺过程中的具体贡献

七天里，AI 技术员协助的工作随着冲刺进度发生了变化。前两天主要围绕工程结构、实体、状态机和测试基础展开；第三、四天开始处理控制器、页面和模块之间的连接；第五至第七天更多是在排查浏览器适配、异常处理和回归测试中的问题。

3.2.1 架构与应用控制器

冲刺初期，连一帆借助 AI 系统架构师梳理 Flutter Web 工程目录、分层职责和代码检查规则。Day2 建设领域内核时，AI 协助明确领域逻辑与平台相关代码之间的边界，为后续全局控制器的接入提供思路。Day3 开始，项目需要通过 GameController 协调页面、领域状态和数据存储。到了 Day4，完成待办后需要依次处理状态变化、精灵收服反馈和数据保存，几个环节都可能涉及异步操作。AI 协助梳理事件触发、动画执行和数据写入之间的关系，帮助成员明确各步骤的处理顺序。

后期，AI 又协助分析 Web 运行中可能出现的未处理异常，以及不同平台的应用名称、图标和版本号可能不一致的问题。Day6 列出了跨平台配置检查脚本；Day7 则协助检查 Release 构建中可能出现的裁剪问题，并整理应用入口和项目文档。这部分协作帮助我们把复杂问题拆成可以逐项检查的任务。

3.2.2 待办管理与领域逻辑

徐宇扬在前期负责情绪类型、天气映射、任务实体和日期抽象。AI 领域程序员协助梳理任务需要保存的属性，以及情绪、任务状态和业务事件之间的关系。

页面开始接入操作后，AI 协作逐渐转向具体的使用问题。Day4 成员发现快速滑动列表时可能误触删除，AI 协助分析手势触发条件，并提出调整操作阈值和增加视觉反馈的思路。Day5 又围绕置顶和普通任务排序时可能出现的列表重排问题，协助检查排序逻辑。Day6 的重点是移动端输入体验。手机浏览器弹出软键盘后，页面底部可能被遮挡，AI 协助分析视口变化，并提出使用 MediaQuery.viewInsets.bottom 获取遮挡区域，再调整页面布局。Day7 则继续检查空输入、长文本和列表显示边界。

这些建议帮助成员更早想到不同操作场景，但滑动手感、键盘遮挡和长文本布局是否符合预期，仍需要在实际设备上验证。

3.2.3 专注计时与天气算法

邱宇翔在前期建设专注状态机和天气模型时，AI 状态机技术员协助梳理开始、暂停、恢复和结束之间的转换关系，并分析天气状态之间的变化规则。随着专注功能接入 Web 页面，浏览器生命周期问题变得明显：用户切换标签页或锁屏后，定时器可能被暂停或延迟。如果只依靠定时器每次触发时累加时间，重新回到页面时就可能出现计时偏差。

AI 协助分析页面生命周期、系统时间和专注状态之间的关系，提出使用时间戳计算实际经过时间的思路，并讨论页面恢复、超时结算及保护性状态重置。Day5 提到跨自然日专注统计的问题，AI 协助分析如何按自然日边界拆分时间。Day7 则围绕短时间内的频繁专注操作，讨论天气数值的小幅波动和参数调整。

3.2.4 界面、主岛与美术资源

苏涵棋在冲刺前期借助 AI 视觉设计师整理颜色、间距和页面容器等设计 Token，使不同页面能够沿用相近的视觉规范。主岛接入四季地图后，静态底图、天气遮罩和粒子效果需要同时显示，AI 协助分析不同图层的重绘范围，并提出使用 RepaintBoundary 隔离静态与动态内容的思路。Day5 中，团队关注雪花等粒子频繁创建对性能的影响，AI 提出复用粒子对象的方案。Day6 又针对宽屏环境下地图边缘可能出现黑边的问题，协助分析图片比例、容器尺寸和裁剪方式，提出调整图片覆盖及视口适配策略。

李燕玲负责的精灵资源也有不少细节需要处理。不同序列帧的图片尺寸和角色位置可能略有差异，直接切换时精灵容易出现抖动。AI 概念美术与交互员协助分析定位方式，提出统一精灵脚底锚点并调整帧偏移。图鉴方面，AI 协助讨论未收服精灵的灰度展示方式，减少为不同状态重复准备图片的工作。Day6 还提出使用可通行区域掩码，限制精灵进入湖泊或山川等不合适的位置。这是记录中提出的处理方案，具体实现程度和实际漫游效果仍需查看代码和运行结果。

3.2.5 数据持久化与存档

王馨怡在前期建设数据库结构和存储接口时，AI 数据库专家协助梳理需要保存的数据、仓储职责和不同平台的存储方式。Day4 记录了 Web 存储环境受限的问题：在部分浏览器设置下，底层存储可能不可用。AI 协助分析异常处理路径，提出回退到内存缓存的方案，使应用在存储受限时仍有继续运行的方式。内存缓存不等同于持久保存，页面关闭后的数据表现仍需单独检查。

Day5，AI 协助分析短时间内频繁操作可能带来的重复写入，提出合并写入的思路。Day6，围绕 Web 端缺少原生文件保存对话框的问题，协助分析浏览器下载机制，提出通过 JSON、Blob 和下载链接实现存档导出，并讨论导入和旧格式迁移时的兼容性。Day7 又协助检查历史任务数据增长后可能出现的查询效率问题。

3.2.6 音频与资源优化

林子璇在 Day1 围绕 Web 资源体积开展工作时，AI 多媒体工程师协助分析中文字体子集化流程，为减少字体文件体积提供思路。随着音频服务和场景音乐接入，团队开始处理播放状态问题。Day4 AI 协助分析不同天气背景音乐切换时可能出现的声音突然中断，提出通过淡入淡出调整音量的方案。Day5 又协助梳理频繁切换页面时的音频实例和播放状态管理。

Day6 重点处理 iOS Safari 的音频恢复。用户锁屏或切换页面后，浏览器可能暂停音频上下文；AI 协助分析页面可见性变化，并提出在页面恢复时检查和尝试恢复音频状态。Day7 则协助整理音效生成与音频资源格式。音频相关问题很难只靠静态截图判断，AI 可以帮助分析浏览器限制和状态变化。

3.2.7 自动化测试与质量保障

谢思晨在前期建立测试配置和辅助工具时，AI 测试技术员协助梳理测试环境、临时文件清理和资源扫描的思路。Day3 的专注测试涉及较长时间的倒计时。如果测试真的等待计时结束，会增加执行时间。AI 协助提出使用 fake_async 模拟时间推进，让测试能够检查状态转换，而不必实际等待完整时长。

Day4 的精灵收服测试带有随机性，同一个测试可能因为随机结果不同而偶发失败。AI 建议使用确定性伪随机数，让相同条件下的测试结果可以重复。Day5 又协助梳理存档序列化、保存、读取和反序列化的往返测试，检查字段和嵌套数据是否保持一致。Day6，团队考虑到持续集成环境可能没有真实音频设备，AI 协助设计纯内存的音频平台测试替身，减少测试对底层硬件的依赖，并推进代码覆盖率统计工具。Day7 继续协助整理业务流程和回归测试。自动化测试能够帮助团队反复检查规则，也能让问题更容易复现。

3.3 AI 协作的效果与局限

AI 的实际帮助主要体现在问题分析和方案细化。例如，面对后台计时偏差，AI 将注意力引向时间戳与状态机；面对动画抖动，引导成员检查锚点与图片偏移；面对测试环境缺少音频设备的问题，提出使用可控替身。这样的建议使排查方向更具体，也帮助我们理解问题背后的工程机制。

但是，AI 的建议可能忽略项目已有接口、平台差异或边界条件。我们需要审查生成代码是否符合当前架构，检查资源来源与使用规范，并通过测试确认行为。最终的产品取舍、集成结果和交付质量由团队承担，不能以 AI 给出解释作为验收依据。

3.4 下一阶段如何更好地利用 AI

下一阶段，我们将为 AI 任务提供更完整的上下文，包括需求背景、相关接口、复现步骤、运行环境和验收条件。例如，处理专注恢复时，明确进入后台前后的时间、状态及期望结算方式，使建议能够针对具体问题。在测试方面，可以请 AI 协助补充空输入、重复操作、页面切换、异常存档和存储不可用等边界场景，再由成员判断哪些用例有必要、是否符合业务规则。对跨模块修改，也可以先让 AI 帮助梳理可能影响的页面、状态和数据，再由相关负责人共同检查。

我们也会更早利用 AI 辅助设计边界用例和审查清单，将空输入、重复操作、异常存档、存储不可用及音频恢复等场景纳入开发过程。对于跨模块改动，要求先分析影响范围，再提出最小修改，并配合回归测试检查已有行为。代码与素材仍由成员复核，兼容性和交互效果通过真实环境检查。

我们团队还会记录问题、AI 建议、实际采用的内容、人工修改和测试结果。这样在后续复盘时，能够看清 AI 在哪些问题上提供了帮助，哪些建议需要较多调整，也能避免只记录“使用了 AI”，却说不清它具体做了什么。

四、下一阶段展望

4.1 核心功能与业务联调

Alpha 冲刺阶段，团队初步完成了待办管理、陪伴专注、天气精灵、主岛场景、精灵图鉴和本地存档等主要模块的开发，并逐步推进了模块之间的业务联动。下一阶段，我们将优先完善现有功能，进一步检查各模块之间的状态同步与数据一致性，确保用户操作能够得到符合预期的反馈。

具体而言，我们将继续验证待办完成、精灵收服、图鉴更新和数据保存之间的衔接，重点检查存档导入导出、页面刷新后的数据恢复等场景。同时，针对专注计时、天气变化和精灵展示等功能，进一步检查不同操作顺序及异常情况下的处理逻辑，及时修复联调过程中发现的问题，逐步提升核心业务流程的完整性与稳定性。

4.2 测试与用户体验

经过 Alpha 阶段的自动化测试和手工检查，团队对现有功能的运行情况有了初步认识，但部分测试场景仍有待进一步验证。下一阶段，我们将继续完善测试体系，补充跨页面业务流程测试，评估将代码覆盖率纳入持续集成流程的可行性，并针对已有测试中尚未单独覆盖的边界条件补充相应断言或人工检查。

在兼容性方面，我们将进一步检查 Web 端在不同屏幕尺寸和浏览器环境下的表现，并根据设备条件逐步补充 iOS 真机交互等验证。对于专注过程中页面切换、锁屏及应用进程被系统终止等特殊情况，也需要进一步明确预期行为并开展针对性测试。

除功能正确性外，团队还将关注实际使用体验，结合试用反馈持续优化移动端布局、软键盘避让、动画表现和音频播放等细节。通过自动化测试与人工验收相结合，逐步减少现有功能中的体验问题，并提高测试结论的完整性和可追溯性。

4.3 后续功能与交付

在核心功能和质量验证逐步完善的基础上，团队将根据项目需求、用户反馈和实际开发资源，评估心绪回廊、周报及轻量分享等后续功能的实现优先级，合理安排开发工作，避免在现有功能尚未充分验证时过早扩展需求。

与此同时，我们将持续维护项目说明文档、测试记录和代码提交记录，补充必要的运行展示与验收证据，并进一步整理项目部署、构建和演示流程，为后续开发、项目评审及最终交付做好准备。

通过下一阶段的持续迭代，我们希望在现有 Alpha 成果的基础上，进一步提高心晴屿 Moodisle 的功能完整性、运行稳定性和使用体验，使项目从能够展示主要功能逐步迈向经过更充分验证、更加可靠的应用版本。

五、答辩 PPT

• 答辩 PPT 文件 ：点击查看答辩 PPT