心绪气象局——团队展示

作业基本信息

这个作业属于哪个课程	2601_FZU_SE
这个作业要求在哪里	软件工程实践团队作业——种子队选拔、团队展示及选题
这个作业的目标	1.组建强劲队伍 2.敲定选题，选择大家都感兴趣的方向 3.在作业中运用团队绩效考核、NABCD模型分析等软件工程方法 4.展现团队风采与愿景
其他参考文献	《构建之法》第四版 你参加团队有什么样的投入 绩效管理

目录

1.团队介绍

1.1团队名称

心绪气象局

1.2 团队logo

1.3队员风采

1.队长：连一帆

学号	102400317
姓名	连一帆
csdn地址	102400317连一帆-CSDN博客
性格	上进且负责
擅长的技术	python后端
兴趣爱好	音乐、球鞋
希望的软工角色	团队管理/开发
slogan	当大人，做大嘢
精神面貌

2.队员：徐宇扬

学号	102400330
成员姓名	徐宇扬
成员csdn地址	102400330徐宇扬-CSDN博客
成员性格	乐观向上，很有梦想
擅长的技术	Java，TypeScript，python
兴趣爱好	不知道啊
希望的软工角色	PM（Product Manager & Project Manager）& 全栈开发 & 美术
一句slogan	大家加油吧
精神面貌

3.队员：邱宇翔

学号	102400326
姓名	邱宇翔
csdn地址	102400326邱宇翔-CSDN博客
性格	执行力强
擅长的技术	Unity程序
兴趣爱好	游戏、音乐
希望的软工角色	程序
slogan	哇！金色传说！
精神面貌

4.队员：苏涵棋

学号	102400327
姓名	苏涵棋
csdn地址	102400327苏涵棋-CSDN博客
性格	耐心且执行力强
擅长的技术	测试开发
兴趣爱好	音乐、中长跑
希望的软工角色	测试/开发
slogan	保持迭代，行胜于言
精神面貌

5.队员：李燕玲

学号	102400404
姓名	李燕玲
csdn地址	102400404李燕玲-CSDN博客
性格	内敛、耐心、认真
擅长的技术	Java后端
兴趣爱好	听歌、绘画、羽毛球
希望的软工角色	后端/前端
slogan	我要实实在在的增长，不要模糊的幻想
精神面貌

6.队员：王馨怡

学号	102400108
姓名	王馨怡
CSDN地址	102400108王馨怡-CSDN博客
性格	认真负责，做事比较有耐心
擅长的技术	Python、Java及项目开发
兴趣爱好	排球、音乐、钢琴
希望的软工角色	前端开发 / 后端开发
slogan	先做，再慢慢做好
精神面貌

7.队员：林子璇

字段	内容
学号	102400105
成员姓名	林子璇
成员CSDN地址	102400105林子璇-CSDN博客
成员性格	活泼乐观，肯学肯干
擅长的技术	HTML、CSS、Vue3
兴趣爱好	游戏、旅游、音乐
希望的软工角色	前端开发
一句slogan	我想像诗意绽放的花朵，选择更璀璨的人生
精神面貌

8.队员：谢思晨

学号	102400306
姓名	谢思晨
csdn地址	102400306谢思晨-CSDN博客
性格	认真负责
擅长的技术	python和C
兴趣爱好	绘画、舞蹈
希望的软工角色	后端
slogan	从0到1，从1到∞
精神面貌

2.项目选题

2.1 项目一句话描述

心晴屿：一座会反映你心情天气的小岛。 把真实待办化作情绪天气精灵收服陪伴，用「无愧疚」的陪伴式专注，和它一起等一场放晴。

2.2 项目背景与选题初衷

随着学习和工作节奏不断加快，大学生和初入职场的年轻人往往需要同时处理课程、作业、项目、实习和日常事务。传统待办与专注类应用虽然能够帮助用户记录任务、安排时间，但很多产品更强调效率、打卡和结果反馈，部分产品还采用中断惩罚、连续签到等机制。对于本身就处于焦虑、拖延或高压状态的用户来说，这类“强监督”式体验有时反而会增加心理负担。与此同时，也有一些产品尝试加入宠物陪伴、岛屿养成等元素，但任务管理、情绪表达和陪伴体验之间往往仍然相对独立。

基于这样的背景，我们希望面向18—30岁的大学生和年轻职场人，开发一款兼顾“任务管理”与“情绪陪伴”的治愈系软件——心晴屿 Moodisle。用户可以在应用中记录真实待办，同时为任务赋予当下的情绪；这些情绪会以不同的“天气精灵”出现在小岛上，完成任务的过程也不再只是简单地将待办划掉，而是转化为与精灵互动、让岛屿逐渐“放晴”的过程。项目希望通过轻松、柔和的视觉风格和无惩罚式的陪伴机制，让用户在处理繁忙事务的同时，也能够感受到适度的情绪反馈与陪伴。

我们选择这个题目，是因为我们认为年轻人需要的不只是一个“催着你完成任务”的工具，也可以是一款愿意陪你把事情慢慢做完的软件。即使处于低谷、焦虑或者暂时没有动力的状态，应用也不会通过扣分、断签等方式制造额外压力，而是希望用更加温和的方式陪伴用户面对自己的情绪与任务。

我们希望它既是一款能够认真记录生活事务的效率工具，也是一款能在忙碌生活中给予年轻人情绪陪伴的治愈系应用。

2.3 目标用户

“心晴屿”主要面向 18–30 岁的大学生及初入职场的年轻人。这一群体普遍处于学习、就业和职业发展的重要阶段，日常需要处理课程、作业、考试、实习、项目以及工作任务等多种事务，对任务记录、时间管理和专注效率具有较高需求。

与此同时，快节奏的学习与工作生活也容易带来拖延、焦虑、疲惫等情绪。相比单纯强调效率和任务完成率的传统工具，我们希望为这类用户提供更加轻松、温和的使用体验。通过治愈系的视觉风格、天气精灵陪伴以及情绪与待办相结合的设计，让用户在管理日常事务、完成任务的过程中，也能够获得一定的情绪反馈与陪伴。

因此，我们的核心目标用户可以概括为：有任务管理和专注需求，同时希望获得轻量化情绪陪伴体验的年轻学生与职场新人。

2.4 核心功能概述

“心晴屿”围绕 任务管理、陪伴专注、情绪反馈与轻量养成 展开，将现实中的待办事项、专注过程与虚拟小岛中的天气精灵相结合，形成“任务流 + 专注流”双驱动的核心体验。主要功能包括：

1. 待办任务与情绪记录
   用户可以记录学习、工作和生活中的待办事项，并为任务关联当前的情绪状态。不同情绪会转化为对应的“天气精灵”出现在小岛上，使原本单纯的任务记录具有更加直观、治愈的表达方式。

2. 天气精灵收集与陪伴
   当用户完成现实中的待办任务后，可以收服由该任务情绪产生的天气精灵，并推动小岛逐渐“放晴”。精灵不仅作为任务完成后的反馈，也会成为后续专注过程中的陪伴角色。

3. 陪伴式专注功能
   用户可以选择已经获得的天气精灵陪伴自己进行专注。与传统强调惩罚和防作弊的专注工具不同，“心晴屿”采用无惩罚式设计，即使专注中断，也不会扣除已经获得的成果，希望减少用户因失败而产生的额外压力。

4. 情绪气候可视化
   系统会根据用户近期记录的情绪和任务状态改变岛屿的天气。例如，当焦虑类情绪和待办积压较多时，小岛可能出现“心雾”；随着任务逐渐完成和情绪得到疏导，天气也会逐渐转晴。通过这种方式，让抽象的情绪变化以更加直观的形式呈现出来。

5. 精灵养成与探索玩法
   用户在完成任务和专注后可以积累相应资源，用于提升精灵羁绊、培育精灵和解锁新的形态。同时，项目还设计了“心绪回廊”等探索玩法，在基础效率工具之外增加轻量化的养成与游戏体验，提高长期使用的趣味性。

6. 轻量化分享与社交
   用户可以通过岛屿明信片、漂流瓶等方式分享自己的岛屿和精灵。项目计划采用导入码等形式实现轻量化的异步互动，在降低账号和服务器依赖的同时，尽量减少传统社交功能带来的额外压力。

总体而言，“心晴屿”希望将传统的“记录待办—完成任务”过程，转化为“记录情绪—完成任务—收服精灵—获得陪伴—见证放晴”的完整体验，让任务管理不再只是追求效率，也成为一种更轻松、更有温度的生活陪伴方式。

2.5 项目特色与创新点

“心晴屿”并不是简单地在传统待办或专注工具上加入养成元素，而是尝试将任务管理、情绪表达、陪伴体验与轻量化游戏机制进行结合，形成具有自身世界观和交互逻辑的产品体验。其主要特色与创新点体现在以下几个方面：

1. 将真实待办与情绪天气精灵进行绑定
   用户在录入待办事项时，可以同时记录当前情绪，不同情绪会对应不同类型的“天气精灵”。例如，带有拖延、焦虑等情绪的任务会以相应精灵的形式出现在小岛上，任务完成后则完成精灵的“收服”与状态转变。通过这种方式，原本抽象的情绪与任务被转化为更加直观、具象的视觉反馈，使任务完成不再只是简单地勾选完成。

2. 采用“羁绊式陪伴”替代传统惩罚式专注机制
   在专注过程中，天气精灵会陪伴用户完成学习或工作任务。与部分专注工具通过失败惩罚、连续签到、资源损失等方式约束用户不同，“心晴屿”强调“无愧疚”的陪伴式专注。即使用户中途离开或专注失败，也不会扣除已有成果，而是通过精灵等待、羁绊成长等方式降低失败带来的心理负担，让专注体验更加温和。

3. 利用“情绪气候系统”实现情绪状态可视化
   小岛的天气并非单纯的装饰，而是用户近期情绪结构与任务状态的外在表现。当焦虑情绪或待办积压较多时，岛屿可能出现“心雾”等天气变化；随着任务逐渐完成和情绪状态发生变化，岛屿也会逐步转晴。通过这种动态天气反馈，将用户一段时间内的情绪变化转化为可观察、可感知的环境变化，使“情绪”成为产品体验中的重要组成部分。

4. 设计低压力、轻量化的异步社交方式
   项目计划通过岛屿明信片、漂流瓶和导入码等方式实现好友间的异步互动，减少对实时在线、账号系统和强社交关系的依赖。好友之间可以分享自己的岛屿状态或让招牌精灵进行短期“客住”，在保留互动感的同时，尽可能避免传统社交产品中频繁回复、在线状态和社交比较带来的额外压力。

5. 构建“任务流 + 专注流”双驱动体验
   “心晴屿”并不把所有功能都建立在单一的专注时长之上，而是让任务管理与专注过程分别形成独立但互相关联的成长路径。任务完成推动精灵收服和岛屿生态变化，专注过程则推动羁绊成长和相关资源积累，两条路径可以相互增益，但不会彼此强制绑定。这样既保证了效率工具本身的实用性，也增强了长期使用过程中的陪伴感和趣味性。

总体而言，“心晴屿”的创新并不只体现在某一个单独功能上，而在于将现实待办、情绪记录、陪伴式专注、天气变化和精灵养成组合成一套统一的产品体验。我们希望通过这种设计，让用户在完成日常事务的同时，也能够看到自己的情绪被记录、被回应，并在一次次任务完成和专注过程中逐渐见证属于自己的“小岛放晴”。

2.6 项目选题 PDF

为进一步完整展示“心晴屿 Moodisle”的项目定位、用户需求、解决方案及团队实施思路，我们整理形成了项目选题说明 PDF。

PDF 主要围绕以下内容展开：

• 项目背景与选题初衷
• 目标用户与核心需求
• NABCD 模型分析
  • N —— Need：用户需求
  • A —— Approach：解决方案
  • B —— Benefit：用户收益
  • C —— Competitors：竞争分析
  • D —— Delivery：推广与落地
• 项目特色与创新点
• 团队绩效考核方案
• 团队愿景

项目选题 PDF：

👉 《心晴屿 Moodisle——团队项目选题说明》

3.NABCD 分析

3.1 N —— Need：用户需求

“心晴屿 Moodisle”主要面向18～30岁的大学生与年轻职场人。我们发现，这一群体虽然普遍具有较强的任务管理与专注需求，但真正影响他们开始和持续完成任务的因素，往往并不只是“事情太多”，还包括拖延、焦虑、疲惫、分心等情绪压力。

传统待办和专注工具能够帮助用户记录任务、安排时间，但通常更强调效率、自律和完成结果，对任务背后的情绪状态关注较少。因此，我们希望从“现实任务”和“情绪体验”两个维度出发，寻找一种更加温和、更具陪伴感的解决方式。

3.1.1 目标用户

“心晴屿”的核心目标用户为 18～30岁的大学生与年轻职场人，主要包括以下几类人群：

• 经常需要处理课程作业、考试复习、项目开发、实习、工作任务等多种事务的用户；
• 具有待办记录、时间管理和专注需求的用户；
• 容易受到拖延、焦虑、低落、倦怠、分心、完美主义等情绪影响的用户；
• 使用过番茄钟、待办清单或专注类应用，但难以长期坚持的用户；
• 希望在完成任务的同时获得一定陪伴感、成就感和情绪反馈的用户。

对于这类用户而言，效率工具不仅要能够帮助他们“记住要做什么”，还应该尽可能降低开始任务时的心理压力，并在完成任务的过程中给予持续、温和的正向反馈。

3.1.2 用户痛点

结合目标用户的日常学习、工作与生活场景，我们将主要痛点归纳为以下几个方面。

1. 知道任务存在，却迟迟难以开始

很多用户并不是不知道自己应该做什么，而是在面对任务时容易受到拖延、焦虑、倦怠等情绪影响。例如，明明知道需要完成课程作业、准备考试或者处理工作任务，却因为任务困难、时间紧张或担心完成效果而迟迟无法开始。

传统待办工具通常只记录“做什么”，却很少关注：

“我面对这件事情时是什么感受？”

这使得任务本身被记录下来，但真正阻碍行动的情绪因素没有得到回应。

2. 任务完成后的反馈较弱

传统待办产品通常以“完成 / 未完成”作为主要反馈。完成一项任务后，用户往往只是将任务划掉或看到简单的数据变化，长期使用容易缺乏持续的成就感与成长感。

对于需要长期坚持学习、工作和自我管理的年轻用户来说，仅仅“打勾”并不足以形成稳定的使用动力。

3. 惩罚式专注容易带来额外压力

部分专注工具通过连续签到、中断惩罚、资源损失等方式强化自律。这类机制虽然能够提高约束力，但对于本身就处于焦虑、低落或高压状态的用户而言，一次失败可能进一步产生负罪感和挫败感。

当用户因为一次专注中断而产生“我又失败了”的感受时，工具本身反而可能增加重新开始的心理门槛。

4. 情绪记录与现实任务相互割裂

传统效率工具更多关注任务和时间，而部分情绪记录产品则主要关注心情本身，两者之间通常缺少直接联系。

用户能够看到自己今天完成了多少任务，却不一定能够直观了解：

• 最近为什么总是不想开始任务；
• 哪些情绪出现得更加频繁；
• 一段时间内自己的情绪状态发生了怎样的变化；
• 情绪变化与现实任务之间是否存在一定联系。

5. 纯工具类产品缺少长期陪伴感

待办和专注工具在功能层面十分明确，但往往缺少持续的成长体验；而单纯的宠物养成、岛屿养成类产品虽然具有陪伴感，却可能与用户真实的学习和工作任务脱节。

因此，用户需要一种能够同时连接 现实任务、专注过程、情绪状态和长期成长反馈 的产品体验。

3.1.3 核心需求

基于上述用户痛点，我们认为目标用户的核心需求可以概括为以下几个方面。

1. 清晰、低门槛的任务管理需求

用户首先需要能够快速记录学习、工作和生活中的真实待办，并清楚了解当前需要完成的事项，使产品在基础功能上真正具备实用价值。

2. 更温和的专注体验

用户需要专注功能帮助自己进入任务状态，但不希望因为一次中断、失败或状态不佳而受到额外惩罚。产品应当通过陪伴和正向反馈鼓励用户继续，而不是利用资源损失或连续打卡制造压力。

3. 对任务背后情绪的关注

用户不仅需要记录“我要做什么”，也希望能够表达“我面对这件事情时是什么感受”。因此，产品需要建立任务与情绪之间的联系，让情绪不再只是独立存在的一条记录。

4. 直观的情绪反馈与变化感知

用户希望能够看到一段时间内自己的情绪变化，而不是只能浏览零散的情绪数据。因此，需要通过更加直观、具象的方式呈现近期状态，让用户能够感知自己的变化过程。

5. 持续的陪伴感和成长反馈

用户需要的不只是一次性的任务完成反馈，还希望在长期使用过程中获得持续成长感。通过天气精灵、岛屿天气、羁绊、成长与探索等机制，让每一次现实任务的完成都能够留下可见的积累。

因此，“心晴屿”希望提供的不只是一个“提醒用户做事”的工具，而是一个能够理解任务背后情绪、降低开始任务的心理压力，并通过持续正反馈陪伴用户完成现实事务的产品。

我们希望将传统的：

记录任务 → 完成任务

进一步转化为：

记录待办 → 感知情绪 → 天气精灵出现 → 完成现实任务 → 收服精灵 → 小岛逐渐放晴

让用户在提高效率的同时，也能够感受到自己的情绪被记录、被回应，并在一次次完成现实任务的过程中获得持续的陪伴与成长感。

3.2 A —— Approach：解决方案

针对年轻用户在任务启动、持续专注、情绪反馈和长期坚持等方面存在的问题，“心晴屿 Moodisle”采用“现实任务 + 情绪天气 + 精灵陪伴 + 游戏化成长”的整体解决思路，将现实中的待办事项、用户面对任务时的情绪状态以及后续的专注过程连接起来。

产品并不试图通过更强的惩罚和约束迫使用户完成任务，而是希望利用天气精灵、陪伴式专注、情绪气候和轻量养成等机制，把原本单一的“记录任务——完成任务”过程转化为一个具有情绪表达、成长反馈和陪伴感的完整体验。

其核心体验可以概括为：

记录待办 → 登记情绪 → 天气精灵现身 → 完成现实任务 → 收服精灵 → 陪伴专注 → 小岛逐渐放晴

3.2.1 情绪锚定的天气精灵

“天气精灵”是“心晴屿”连接现实任务与用户情绪的核心机制。

用户在录入待办事项时，不仅记录“需要完成什么”，还可以同时选择自己面对这项任务时的情绪，例如焦虑、低落、拖延、倦怠、内耗、混乱、分心、完美主义、错失焦虑和社交压力等。

不同类型的情绪会对应不同的天气现象，并进一步转化为具有独立形象的“天气精灵”。

例如：

“不想写周报” + “拖延”
→ 对应的天气精灵在小岛上现身
→ 用户完成现实中的周报任务
→ 收服精灵，并获得相应的成长反馈

天气精灵并不是随机生成的普通虚拟宠物，而是直接来源于用户真实待办背后的情绪。我们希望通过这一机制，将“拖延”“焦虑”等原本抽象的心理感受转化为用户可以看见、理解和互动的对象。

在这一过程中，完成任务不仅意味着将一项待办划掉，也意味着用户完成了一次对当前情绪的面对和安放。

在产品世界观中，天气精灵还具有不同的成长状态。用户完成对应任务后，精灵可以由初始的“阴态”转变为“晴态”，并在后续陪伴、培育与探索过程中进一步形成长期成长体验。

因此，传统待办工具中的：

记录任务 → 完成任务

被进一步转化为：

记录待办 → 感知情绪 → 精灵现身 → 完成任务 → 收服精灵 → 获得成长反馈

使现实任务、情绪状态和虚拟陪伴角色真正建立联系。

3.2.2 陪伴式专注

在完成天气精灵的收服后，用户可以选择已经获得的精灵陪伴自己进行专注，并根据实际任务设置15分钟、25分钟、50分钟等不同专注时长。

与部分通过失败惩罚、资源损失或连续打卡强化约束的专注产品不同，“心晴屿”采用“无愧疚、零惩罚”的陪伴式专注理念。

在一次专注过程中：

• 用户可以选择一只天气精灵陪伴自己；
• 精灵会进入专注陪伴状态，与用户共同完成这一段时间；
• 当用户短暂离开专注界面时，精灵不会立即消失或受到惩罚，而是停留并等待用户回来；
• 产品设计中设置约2分钟的宽限时间；
• 如果超过宽限时间，本次专注可以判定为未完成，不产生本次对应收益；
• 但用户已经获得的精灵、资源和成长成果不会因此被扣除或清零。

我们希望把传统惩罚式专注中：

“我必须坚持，否则就会失去什么。”

转化为更加温和的：

“它还在等我，我想回来继续完成这件事。”

当用户顺利完成专注后，可以提升与天气精灵之间的“羁绊”，并获得相应的成长资源。

“羁绊”并不是一种单纯用于防作弊的数值，而是用户与精灵长期共同完成现实任务和专注过程的记录。随着羁绊逐渐提高，还可以进一步解锁同行、挂件等陪伴体验。

通过这种方式，“心晴屿”希望在保留专注工具实用性的同时，减少一次中断或失败给用户带来的额外负罪感。

3.2.3 情绪气候系统

除了单个任务对应的天气精灵之外，“心晴屿”还设计了覆盖整个小岛的“情绪气候系统”。

小岛的天气并不是随机变化的背景装饰，而是用户近期情绪结构和任务状态的一种可视化反馈。

系统会综合用户近期约7天的情绪记录和任务情况，对小岛环境产生影响。

例如：

• 当焦虑类情绪较多、相关待办不断积压时，小岛可能逐渐出现“心雾”；
• 当用户开始完成相关任务、逐渐疏导这些情绪时，雾气可以慢慢散去；
• 当一段时间内整体状态逐渐改善时，小岛还可能出现虹光、彩虹、极光等特殊天气表现。

这种设计希望把原本散落在数据中的情绪变化，转化为用户能够直接看到的环境变化。

同时，“心晴屿”并不会把阴天、雾天或者其他负面天气简单理解为“用户表现不好”。

即使处于情绪低谷，小岛仍然会提供一定的互动和正向反馈。例如在雾天状态下，用户仍然可以获得“雾露”等资源。

因此，负面天气不是一种处罚，而是一种状态呈现。

情绪气候系统真正希望表达的是：

天气会变化，人的状态也会变化。阴天并不等于失败。

用户不需要因为某一天状态不好而重新开始，而是可以通过长期记录看到自己的情绪如何变化，以及小岛如何随着现实生活中的一点点行动逐渐放晴。

3.2.4 任务流与专注流双驱动

“心晴屿”采用“任务流 + 专注流”双驱动结构，而不是将全部成长都绑定在单一的专注时长上。

两条核心成长路径分别为：

任务流：

录入待办 → 登记情绪 → 精灵现身 → 完成任务 → 收服精灵 → 改善岛屿生态与天气

任务流主要服务于用户现实中的待办事项。

用户通过完成课程作业、考试复习、项目开发、工作任务以及其他真实事务，推动天气精灵收集、放晴度和岛屿生态发生变化。

专注流：

选择精灵 → 开启陪伴专注 → 完成专注 → 羁绊提升 → 获得成长资源 → 解锁更多陪伴体验

专注流主要服务于用户实际的学习和工作过程。

完成专注后，可以提升精灵羁绊，并获得星屑等成长资源，用于后续的精灵培养和相关玩法。

两条路径各自成立，同时又能够互相增益。

用户即使暂时不使用专注功能，也能够通过完成现实待办继续收服精灵、推动岛屿变化；当某段时间现实待办较少时，也可以通过专注继续培养已经获得的天气精灵。

因此，两条成长路径之间并不存在强制绑定关系。

在此基础上，项目还设计了进一步的轻量成长内容，包括：

• 心绪回廊：使用行动力进行探索，获得晨露、晴晶等成长资源；
• 精灵培育与成长：精灵可以从晴态继续成长至虹态、觉醒态等阶段；
• 天气纪念品与岛屿装饰：记录用户在不同阶段的成长经历；
• 精灵云游：通过不同天气航线获得纪念品；
• 心晴周报：帮助用户回顾一周内的任务与情绪变化；
• 异步分享：通过明信片等形式分享小岛和精灵。

这些机制共同组成长期成长循环，但游戏化始终服务于现实任务和专注过程，而不是为了让用户长时间停留在应用中。

3.2.5 隐私与轻量化设计

由于“心晴屿”记录的不仅包括现实待办，还涉及用户面对任务时的情绪状态，因此隐私保护是产品设计中的重要原则。

在数据设计方面，项目强调 隐私优先、本地存储。用户的情绪记录和核心个人数据以本地保存为主要方式，不强制依赖复杂的账号体系，也不会将用户的情绪状态默认公开给陌生人。

在社交设计方面，“心晴屿”采用低压力的异步互动方式，而不是强调实时在线和高频社交。

计划中的互动方式包括：

• 岛屿明信片；
• 漂流瓶；
• 导入码分享；
• 精灵短期“客住”等形式。

例如，用户可以生成自己的岛屿分享信息或导入码，好友主动导入后，用户的招牌精灵可以在好友岛屿上进行短期“客住”。

这种设计尽量减少对实时聊天、持续在线和强社交关系的依赖，使用户可以自由决定是否进行互动。

与此同时，“心晴屿”坚持以下设计原则：

• 零惩罚：断签、专注中断或探索失败只影响当次收益，不扣除已有成长资产；
• 隐私优先：情绪数据尽量保存在本地，社交行为由用户主动发起；
• 反成瘾：通过久坐提醒、休息演出等方式避免制造“在线时间越长越好”的使用焦虑；
• 轻量社交：降低账号体系、实时互动和社交比较带来的额外压力；
• 游戏化服务现实生活：精灵、岛屿和成长机制的最终目的仍然是帮助用户更轻松地面对现实中的任务。

因此，“心晴屿”的 Approach 并不是简单增加一个番茄钟、一个宠物系统或一个情绪记录功能，而是将它们围绕同一套核心逻辑重新组织：

真实任务是起点，情绪天气是表达，天气精灵是陪伴，专注过程是行动，小岛放晴是反馈。

最终形成：

现实待办 → 情绪天气精灵 → 完成收服 → 陪伴专注 → 情绪气候变化 → 精灵与小岛持续成长

这一完整的产品体验闭环。

3.3 B —— Benefit：用户收益

“心晴屿 Moodisle”希望带给用户的价值，并不只是“帮助完成更多任务”，而是在任务管理、专注执行和情绪反馈之间建立更加温和的正向循环。

通过天气精灵、陪伴式专注、情绪气候和长期成长机制，用户在完成现实任务的同时，也能够获得更加直观的反馈、更低压力的专注体验，以及持续的陪伴感。

3.3.1 降低任务启动压力

对于许多大学生和年轻职场人而言，真正困难的往往不是“不知道应该做什么”，而是明明知道任务存在，却因为焦虑、拖延、倦怠等情绪迟迟难以开始。

传统待办工具通常将任务呈现为一个需要完成的条目，而“心晴屿”会进一步把任务与用户当前的情绪联系起来。

当用户记录一项待办时，可以同时选择自己面对这项任务时的情绪，系统会将这种情绪转化为对应的天气精灵。

这样一来，用户面对的不再只是一个冷冰冰的“未完成任务”，而是一个与自己当前状态相对应、可以被看见和理解的对象。

例如：

“我不想写这份报告，因为觉得很焦虑。”
→ 记录任务与情绪
→ 对应的天气精灵出现
→ 完成任务并收服精灵

通过这种方式，原本抽象的心理压力被转化为更加具体、柔和的互动目标。

用户不再只是想着：

“我必须把这件事情做完。”

而是可以将其理解为：

“我先完成这一件事，让自己的小岛放晴一点。”

我们希望借此降低用户开始任务时的心理门槛，让“开始行动”本身变得更加容易。

3.3.2 增强任务完成反馈

传统待办工具在任务完成后，通常只提供“勾选完成”“任务消失”或简单的数据统计。

这种反馈虽然直接，但随着使用时间增加，用户很容易对单纯的完成标记失去新鲜感。

“心晴屿”希望让现实任务的完成获得更加丰富、持续的反馈。

当用户完成一项真实待办后，可以获得：

• 收服对应的天气精灵；
• 推动精灵由阴态转变为晴态；
• 提升小岛的放晴度；
• 改变岛屿天气状态；
• 获得后续培养和探索所需的资源；
• 推进精灵图鉴、成长和探索内容。

因此，一项现实任务的完成不仅意味着“列表中少了一项任务”，还会在虚拟世界中留下明确的成长痕迹。

例如：

完成现实任务 → 收服精灵 → 小岛天气发生变化 → 获得成长反馈

通过这种可见的变化，用户能够更直观地感受到自己已经完成的事情，从而提高任务完成后的成就感和持续使用动力。

3.3.3 帮助用户观察情绪变化

传统任务管理工具主要记录“做了什么”，而“心晴屿”还希望帮助用户逐渐观察：

“我面对这些事情时，通常是什么感受？”

用户在记录待办的同时，也会留下相应的情绪信息。

随着使用时间增加，这些原本零散的情绪记录会通过天气精灵、岛屿气候以及“心晴周报”等方式进行可视化呈现。

例如：

• 焦虑类情绪和待办积压较多时，小岛可能出现“心雾”；
• 随着相关任务逐渐完成，雾气会慢慢散去；
• 当近期整体状态较为稳定时，岛屿可能出现彩虹、虹光或极光等特殊天气；
• 心晴周报可以帮助用户回顾一周内出现较多的情绪类型及变化趋势。

因此，用户看到的不再只是一些孤立的数字或情绪标签，而是一段能够被直观感知的“情绪天气”。

长期使用后，用户可以逐渐了解：

• 自己最近最常出现哪些情绪；
• 哪些类型的任务更容易带来拖延或焦虑；
• 最近一段时间的状态是否发生变化；
• 自己完成现实任务之后，情绪结构是否逐渐改善。

“心晴屿”并不试图替用户判断情绪是“好”还是“坏”，而是希望帮助用户更清楚地看到自己的状态变化。

3.3.4 减少惩罚式自律压力

部分专注工具会通过连续签到、失败惩罚、资源损失等方式强化用户的自律行为。

这类机制对于部分用户有效，但对于本身就处于高压、焦虑或低落状态的人而言，一次中断可能进一步带来：

• “今天又没有坚持下来”的挫败感；
• 连续记录中断后的负罪感；
• 已有成果被清零后的失落感；
• 因担心再次失败而降低重新开始的意愿。

因此，“心晴屿”坚持“零惩罚”的设计原则。

在专注过程中，即使用户短暂离开，天气精灵也会等待用户回来；超过宽限时间后，本次专注可以不产生对应收益，但不会扣除用户已经获得的精灵、资源和成长成果。

同样，断签、状态不佳或部分探索失败，也只影响当次收益，而不会破坏此前已经积累的成果。

我们希望将传统的：

“如果失败，就会失去什么。”

转化为：

“这一次没有完成也没关系，可以重新开始。”

在“心晴屿”的设计中，负面状态也不是需要被处罚的状态。

即使小岛出现心雾，用户仍然可以获得“雾露”等正向反馈。

项目希望传递的是：

没有完成所有事情，不代表今天毫无价值。

通过这种方式，减少用户因一次中断或失败产生的额外心理压力，让产品真正成为帮助用户继续行动的工具，而不是新的压力来源。

3.3.5 提供长期陪伴与成长感

“心晴屿”中的天气精灵并不是完成一次任务后就结束作用的一次性奖励。

用户收服精灵之后，还可以继续与精灵进行陪伴专注、提升羁绊、培养成长，并参与后续的探索玩法。

随着长期使用，用户能够逐渐看到：

• 自己曾经收服过哪些天气精灵；
• 哪些情绪曾经频繁出现在自己的生活中；
• 与哪些精灵建立了更深的羁绊；
• 精灵从晴态逐渐成长到更高阶段；
• 自己的小岛经历过怎样的天气变化；
• 完成过多少真实的学习、工作和生活任务；
• 自己一段时间内的情绪结构发生了怎样的变化。

与此同时，心绪回廊、精灵培育、云游、天气纪念品、岛屿装饰和心晴周报等机制，也为长期使用提供持续的成长内容。

但这些成长机制并不是为了迫使用户长时间停留在应用中。

“心晴屿”的核心仍然是现实生活中的任务和专注行为，游戏化内容只是对现实行动的陪伴与反馈。

因此，产品希望形成的是一种长期、温和的陪伴关系：

现实中完成一点事情，虚拟的小岛就放晴一点；现实中坚持一段专注，天气精灵就陪用户成长一点。

最终，我们希望用户从“心晴屿”中获得的不只是一次任务完成后的短暂奖励，而是一段能够随着现实生活共同积累的成长记录。

用户最终感受到的，不是：

“今天我又逼自己完成了多少任务。”

而是：

“今天，我又让自己的小岛放晴了一点。”

3.4 C —— Competitors：竞争分析

目前市场上与“心晴屿 Moodisle”定位相近的产品，主要集中在专注计时、无惩罚养成、宠物陪伴、岛屿养成以及社交陪伴等方向。

这些产品各自在时间管理、专注激励、虚拟陪伴或游戏化体验方面已经形成较为明确的产品模式，但“心晴屿”并不希望简单复制其中某一种模式，而是尝试在 情绪、现实任务、专注、陪伴和养成 之间建立更加紧密的联系。

3.4.1 同类产品分析

结合项目现有调研，我们将主要同类产品划分为以下几类：

产品类型	代表产品	常见核心机制	心晴屿的切入方向
专注计时类	Forest、番茄ToDo、潮汐	番茄钟、计时、连续专注	强化陪伴感，并采用零惩罚机制
无惩罚养成类	Flora、Focus Friend	专注与养成、装饰奖励	将伙伴与用户具体的待办情绪直接绑定
宠物陪伴类	Finch、Focus Dog	自我关怀目标、宠物成长	增加现实任务驱动、情绪天气与探索玩法
岛屿养成类	Focus Island、小岛番茄时间	通过专注推动岛屿成长	岛屿不仅展示进度，还反映用户近期情绪结构
社交陪伴类	Focus Traveller	好友陪伴、共同完成目标	采用轻量异步互动，降低强社交压力

1. 专注计时类产品

以 Forest、番茄ToDo、潮汐等产品为代表，这类应用的核心是通过番茄钟、专注计时和连续完成等方式帮助用户减少分心、提高专注效率。

其优势在于功能直接、使用门槛低，用户能够快速进入专注状态。但部分产品会通过中断失败、连续记录或其他约束机制强化用户自律。

“心晴屿”并不否定这种专注方式，而是希望在专注功能之外增加更加明显的陪伴体验，并采用“零惩罚”机制，使一次中断只影响当次收益，而不会扣除用户已经获得的成长成果。

2. 无惩罚养成类产品

Flora、Focus Friend 等产品尝试将专注过程与养成、装饰或虚拟伙伴结合，通过视觉反馈和成长奖励提高专注过程的趣味性。

这类设计已经证明“陪伴 + 养成”可以成为效率工具的重要体验之一。

“心晴屿”的进一步切入点在于：虚拟伙伴并不是与用户现实生活无关的通用角色，而是直接从用户自己的待办情绪中诞生。

用户面对不同任务产生的焦虑、拖延、倦怠等情绪，会对应不同的天气精灵，使“伙伴是谁”与“用户正在面对什么”之间建立直接联系。

3. 宠物陪伴类产品

以 Finch、Focus Dog 等为代表的产品，更加强调自我关怀、虚拟宠物成长和长期陪伴。

这类产品能够通过角色成长增强用户的情感连接，但在“现实待办如何直接影响产品世界”方面，与“心晴屿”的设计重点有所不同。

“心晴屿”希望让天气精灵、岛屿变化和成长过程始终与用户现实中的任务和专注行为相连接，使游戏化机制服务于现实行动，而不是形成一个与现实任务相互独立的养成系统。

4. 岛屿养成类产品

Focus Island、小岛番茄时间等产品将专注行为与岛屿成长结合，通过树木、环境变化和视觉氛围等方式展示用户的长期积累。

相比之下，“心晴屿”中的岛屿并不只是专注进度的视觉化载体。

岛屿天气还会反映用户近期的情绪结构。例如，当焦虑类待办积压较多时可能出现“心雾”，随着相关任务逐渐完成，天气也会随之发生变化。

因此，小岛既承担成长展示功能，也承担情绪可视化功能。

5. 社交陪伴类产品

Focus Traveller 等产品通过好友互动、共同完成目标等形式增强陪伴感和社交动力。

“心晴屿”则更加倾向于弱社交、异步互动。

项目计划通过岛屿明信片、漂流瓶、导入码以及精灵短期“客住”等方式完成用户之间的轻量互动，尽量减少实时在线、复杂账号体系和强社交关系带来的额外压力。

3.4.2 心晴屿的差异化优势

在对上述产品类型进行分析后，我们认为“心晴屿”的竞争优势并不来自某一个完全独立的新功能，而是来自多个机制围绕同一套“情绪天气”世界观形成的整体体验。

其主要差异化优势包括以下几个方面。

1. 情绪与虚拟伙伴直接绑定

天气精灵并不是随机生成的普通宠物，而是从用户具体待办所对应的情绪中诞生。

例如，当用户记录一项带有“拖延”情绪的任务时，对应的天气精灵便会在岛上出现。

因此：

现实任务 → 当前情绪 → 天气精灵

三者之间形成直接联系。

用户完成任务并收服精灵的过程，同时也可以被理解为一次面对和安放当前情绪的过程。

2. 情绪真正影响整个产品世界

在“心晴屿”中，情绪并不只是一条隐藏在统计页面中的数据。

用户近期约7天的情绪结构会影响整座岛屿的气候状态：

• 焦虑类待办积压可能形成“心雾”；
• 相关任务逐渐完成后，雾气可以慢慢散去；
• 状态改善后可能出现虹光、彩虹或极光等天气变化。

因此，用户的情绪会真正参与产品世界的变化，使情绪可视化成为核心体验，而不是附加功能。

3. 采用零惩罚的陪伴式专注

“心晴屿”不希望通过资源损失强化用户的失败感。

在专注过程中，用户短暂离开时，精灵会原地等待；超过约2分钟宽限时间后，本次专注可以不产生收益，但不会扣除已经获得的资源与成长成果。

断签、专注中断或者部分探索失败同样只影响当次收益。

产品希望将：

“失败就会失去什么”

转化为：

“这次没有完成也没关系，还可以重新开始。”

4. 任务流与专注流双驱动

与主要依赖“专注时长”推动成长的模式不同，“心晴屿”设计了两条相对独立的成长路径。

任务流：

完成真实待办 → 收服天气精灵 → 推动岛屿生态与天气变化

专注流：

完成陪伴专注 → 提升精灵羁绊 → 获得成长资源

两条路径能够互相增益，但不会强制绑定。

用户即使暂时不进行专注，也能够通过完成现实任务推动产品进程；当某段时间现实待办较少时，也可以继续通过专注培养已经获得的精灵。

5. 游戏化始终服务于现实任务

“心晴屿”虽然包含天气精灵、心绪回廊、精灵培育、云游、岛屿装饰和天气纪念品等游戏化内容，但这些机制并不是独立于现实生活存在的小游戏。

整个成长体系始终建立在：

现实待办 + 真实专注行为

之上。

用户完成现实中的课程作业、考试复习、工作任务或者生活事务，才能真正推动天气精灵和小岛发生变化。

因此，游戏化的目标并不是增加用户停留时间，而是为现实行动提供更加直观和持续的反馈。

6. 低压力的异步社交与隐私设计

“心晴屿”不强调高频实时社交，而是采用岛屿明信片、漂流瓶、导入码和精灵短期“客住”等轻量化方式进行互动。

同时，情绪数据以本地存储为核心，不强制依赖账号体系，也不会默认将用户的情绪状态公开给陌生人。

这种设计希望在保留分享和陪伴感的同时，尽可能降低社交比较、持续在线和隐私暴露所带来的压力。

综合来看，“心晴屿”的核心差异并不是简单地把待办、番茄钟、宠物和岛屿功能放在一起，而是让这些机制围绕同一个逻辑共同运转：

真实待办产生情绪 → 情绪化为天气精灵 → 完成任务实现收服 → 精灵陪伴用户专注 → 情绪结构改变岛屿天气 → 长期行动沉淀为精灵与小岛的成长。

因此，“心晴屿”希望形成的是一套以 “情绪锚定 + 零惩罚 + 情绪气候 + 双驱动成长 + 低压力异步社交” 为核心的差异化产品体验。

3.5 D —— Delivery：推广与落地

“心晴屿 Moodisle”的推广与落地不会在项目初期追求大规模用户覆盖或一次性完成所有平台，而是采取“真实用户验证 → 核心体验打磨 → 视觉化传播 → 多端逐步扩展”的实施思路。

项目首先从大学生这一与产品目标用户高度契合的群体切入，在真实学习和生活场景中验证“待办 + 情绪 + 天气精灵 + 陪伴专注”的核心体验；在核心闭环稳定之后，再逐步扩展传播方式和多端能力。

3.5.1 校园用户验证

项目早期将以大学生作为主要种子用户。

大学生日常需要处理课程作业、考试复习、项目开发、英语学习、科研任务以及各种生活事务，与“心晴屿”所面向的任务管理、专注和情绪陪伴场景具有较高匹配度，因此适合作为产品早期验证群体。

我们计划重点在以下真实场景中进行体验验证：

• 课程作业：记录课程任务及面对任务时的情绪，并通过完成任务收服对应的天气精灵；
• 考试复习：利用陪伴式专注完成阶段性的复习计划；
• 项目开发：记录开发任务，通过待办和专注功能推进项目进度；
• 日常事务：记录生活中需要完成的零散事项；
• 阅读与运动计划：将长期目标拆分为可以持续完成的小任务。

团队成员本身也将作为项目的第一批真实用户。

在开发过程中，我们会实际使用产品完成自己的课程、学习和项目任务，并观察：

• 待办录入是否足够方便；
• 情绪选择是否自然；
• 天气精灵能否帮助用户建立更加直观的任务反馈；
• 陪伴式专注是否能够降低传统专注工具带来的压力；
• 小岛天气变化是否能够有效表达用户近期的情绪状态；
• 游戏化机制是否真正促进现实任务，而不是喧宾夺主。

通过真实使用和持续反馈，团队可以不断调整产品流程与功能设计，使核心机制更加符合目标用户的实际需求。

3.5.2 产品推广方式

“心晴屿”在推广过程中将重点突出 低门槛体验和视觉化传播 两个方向。

首先，产品需要让用户在较短时间内理解最核心的使用逻辑。

我们希望用户第一次体验产品时，不需要阅读复杂的玩法说明，而是能够直接经历：

写下一件你不想做的事 → 选择此刻的情绪 → 一只天气精灵出现 → 完成任务 → 收服它 → 小岛放晴

这一过程集中展示了“心晴屿”最核心的产品价值，也能够让用户快速理解“现实任务、情绪和天气精灵之间有什么关系”。

其次，“心晴屿”的天气精灵、小岛天气和成长记录本身具有较强的视觉表现力，因此可以成为产品传播的重要内容。

后续可以生成和分享的内容包括：

• 心晴周报：展示用户一周内的任务和情绪天气变化；
• 岛屿明信片：记录当前岛屿状态，并分享给朋友；
• 精灵图鉴卡片：展示已经收服和培养的天气精灵；
• 特殊天气纪念图：记录彩虹、极光等特殊天气；
• 阶段成长记录：展示一段时间内完成的任务和岛屿变化。

用户可以主动将这些视觉化内容分享给朋友或社交平台，使产品通过用户自身的成长记录形成自然传播。

与此同时，产品不会将分享设计成强制任务，也不会依赖高频实时社交。

“心晴屿”更希望通过明信片、漂流瓶、导入码等轻量异步方式形成互动，在保留分享和陪伴感的同时，降低社交压力。

因此，产品推广的核心并不是单纯依靠广告或强制邀请，而是让用户愿意分享：

“这是我的小岛，也是我最近一段时间生活状态的记录。”

3.5.3 多端落地规划

“心晴屿”的产品形态目标包括 Android、iOS 和 Web 轻量版。

在实际落地过程中，团队将优先保证核心功能闭环能够稳定运行，而不是为了追求平台数量而降低产品完成度。

第一阶段重点实现以下核心功能：

1. 待办录入与情绪选择；
2. 天气精灵生成与收服；
3. 岛屿天气变化；
4. 陪伴式专注；
5. 精灵图鉴与成长；
6. 心晴周报；
7. 本地数据保存。

在核心闭环稳定之后，再根据项目开发进度逐步扩展不同平台的体验。

Android 端计划进一步结合：

• 桌面小组件；
• 专注状态常驻通知；
• 本地通知；
• 精灵桌面挂件；
• 触感反馈；
• 本地数据存储与导出。

iOS 端作为后续产品目标，可进一步结合：

• 灵动岛 / Live Activity；
• 锁屏状态展示；
• 本地通知；
• 锁屏组件；
• 触感反馈；
• 本地存储及可选的云端能力。

Web 轻量版则更强调低门槛使用，主要提供：

• 基础待办与情绪记录；
• 标签页专注倒计时；
• 核心数据展示；
• 本地存储等轻量功能。

在核心功能稳定后，还可以逐步增加通知、分享、移动端组件和其他多端适配能力。

因此，“心晴屿”的落地原则并不是：

“一次性把所有平台和功能全部做完。”

而是：

“先把最核心的体验闭环做完整，再根据真实用户反馈逐步扩展。”

即首先保证：

真实待办 → 情绪天气精灵 → 完成收服 → 陪伴专注 → 小岛放晴

这一核心体验能够稳定运行，再逐步完善情绪反馈、养成探索、分享互动和多端体验，从而让项目在课程开发周期内保持明确的实现重点，同时为后续迭代保留足够的扩展空间。

4.产品愿景

4.1 团队愿景

我们希望“心晴屿 Moodisle”是一座能够承接用户真实情绪、陪伴用户完成日常事务的小岛。

当用户面对考试复习或工作事项时，产品不仅帮助其记录“要做什么”，还允许用户记录面对任务时的情绪，并通过天气精灵、小岛天气等方式给予直观、温和的反馈。

我们希望用户在焦虑或疲惫时，不会因为一次中断或失败再次受到惩罚；而当用户完成一件现实中的小事时，也能够从精灵和小岛的变化获得相应的成就感与陪伴感。

“心晴屿”最终希望形成一种低压力的使用体验，让任务管理不仅仅意味着提高效率，也能够成为用户观察自身状态、记录生活变化的一种方式。

4.2 本学期预期实现程度

本学期计划重点完成以下核心功能：

1. 待办任务管理
   支持用户新增、查看、修改和完成学习、工作及生活中的真实待办事项。

2. 任务情绪记录
   用户创建任务时可以选择相应的情绪标签，将现实任务与当前情绪状态建立联系。

3. 天气精灵生成与收服
   根据任务对应的情绪生成不同的天气精灵；完成现实任务后完成精灵收服，并给予相应的视觉反馈。

4. 陪伴式专注
   支持选择天气精灵进行专注计时，并实现“零惩罚”的基本专注逻辑，使专注中断不会造成已有成果损失。

5. 岛屿天气变化
   根据用户近期任务与情绪情况，对小岛天气进行基础变化，使情绪状态能够通过心雾、放晴等方式得到直观呈现。

6. 精灵图鉴与基础成长
   记录用户已经获得的天气精灵，并实现基础的收集、查看和成长反馈。

7. 基础统计与心晴周报
   对用户一段时间内的任务完成情况和情绪记录进行简单汇总，帮助用户观察近期状态变化。

8. 本地数据保存
   保证用户的任务、情绪、精灵及相关成长数据能够稳定保存和读取。

在上述核心功能稳定之后，如果开发进度允许，再逐步加入心绪回廊、精灵进一步培育、岛屿装饰、明信片分享等扩展功能。

对于灵动岛、桌面小组件、复杂云游系统、完整异步社交以及多端完全同步等功能，本学期将其视为后续扩展方向，不作为当前阶段必须全部完成的目标。

因此，本学期最重要的开发目标是完整实现：

记录待办 → 选择情绪 → 天气精灵出现 → 完成任务并收服 → 精灵陪伴专注 → 小岛状态发生变化

这一核心体验闭环，并确保其能够稳定运行。

4.3 未来应用场景

“心晴屿”主要面向18～30岁的大学生和年轻职场人，其核心功能能够自然融入学习、工作和日常生活中的多种场景。

1. 课程学习与作业管理

大学生可以将课程作业、实验报告、课程项目等事项记录为待办任务，并记录自己面对不同任务时的情绪状态。完成任务后获得天气精灵和岛屿变化反馈，使日常学习任务具有更加直观的完成感。

2. 考试复习与集中学习

在期中、期末考试或四六级、考研等复习阶段，用户可以将较大的复习目标拆分为多个具体任务，并通过天气精灵陪伴进行25分钟、50分钟等阶段性专注。

3. 项目开发与科研任务

对于需要持续推进的软件项目、课程设计或科研任务，可以将“阅读资料”“完成某个模块”“整理实验结果”等内容拆分成具体待办，使复杂任务逐步完成，同时记录过程中出现的焦虑、拖延或疲惫等状态。

4. 初入职场的日常事务管理

年轻职场用户可以记录周报、会议准备、资料整理、方案撰写等工作任务，并通过陪伴式专注降低开始复杂任务时的心理压力。

5. 日常生活与个人计划

除学习和工作外，用户还可以记录阅读、运动、整理房间、处理生活事务等个人计划，使“心晴屿”成为一个轻量的日常任务与状态记录工具。

在后续版本中，如果核心功能经过实际用户验证并具有较好的使用体验，再逐步扩展桌面组件、移动端通知、岛屿明信片以及轻量异步互动等能力。

项目不会以“替代所有任务管理软件”为目标，而是希望首先服务好那些既需要管理现实任务，又希望获得更加温和、具有陪伴感体验的年轻用户。

5.团队绩效考核方案

为了保证团队项目开发过程公平、透明、高效，并能够真实反映每位成员在产品设计、前端开发、后端开发、测试、文档、项目管理和汇报等不同工作中的实际贡献，我们制定了统一的团队绩效考核方案。

团队采用“任务贡献为核心、成果质量为重点、过程记录为依据、成员互评为补充”的考核机制，并坚持以下原则：

• 过程可追踪：成员承担的任务和开发过程应有相应记录；
• 结果可验收：所有任务均以实际成果和验收结果作为评价依据；
• 贡献可量化：通过任务、质量、协作、过程规范和互评综合计算绩效；
• 角色不歧视：前端、后端、测试、产品、UI、文档、项目管理和汇报等工作均可计入正式贡献。

团队不会简单以代码行数或 Git Commit 数量衡量成员贡献，而是综合考虑成员所承担任务的工作量、技术难度、实际价值、成果质量和协作情况。

5.1 绩效考核构成

每名成员在每个开发阶段的绩效满分为 100 分，具体由以下五个部分构成：

考核项目	权重	主要考察内容
任务完成与实际贡献	40%	是否按计划完成任务，以及任务的工作量、难度和实际价值
成果质量	25%	功能正确性、代码/设计/文档质量、测试情况及返工情况
团队协作与责任意识	15%	沟通、会议参与、主动协作、任务响应和责任心
软件工程过程规范	10%	Git、Issue、任务记录、测试记录和项目文档是否规范
团队成员互评	10%	队友对成员实际投入、可靠性和合作情况的评价
总计	100%

其中，“任务完成与实际贡献”和“成果质量”作为绩效评价的主要部分，重点反映成员实际完成了多少具有价值的工作，以及最终成果是否达到团队要求；团队协作、过程规范和成员互评则用于评价成员在整个开发过程中的综合表现。

5.2 任务评分与过程依据

每轮开发开始前，由团队共同拆分任务，并根据任务的 预计工作量、技术难度和项目重要程度 对任务进行分级。

任务等级	任务示例	基础分
S级	核心架构、关键算法、重大功能模块	10
A级	完整主要功能、重要页面或测试模块	7
B级	普通功能、页面、接口、文档模块	4
C级	小功能、Bug 修复、素材整理等	2

任务完成并通过团队验收后，才能计入实际任务贡献。

任务贡献得分按照以下方式计算：

任务贡献得分 =（已验收任务价值 ÷ 应完成任务价值）× 40

除任务完成情况外，团队还会综合考察成果是否符合需求、是否存在明显 Bug、代码和文档是否规范、是否产生大量返工，以及成员是否能够按时完成交付。

整个考核过程以实际开发记录作为依据，包括但不限于：

• 任务看板；
• Git Commit；
• Pull Request；
• Issue 或任务卡；
• 原型设计；
• 项目文档；
• 测试记录；
• 会议记录。

这些记录主要用于证明成员实际承担和完成了哪些工作，而不会简单以 Commit 数量或代码行数直接决定个人贡献。

5.3 个人贡献度计算

每个开发阶段结束后，每名成员会根据上述考核项目获得一个阶段绩效分 Pᵢ。

在课程后续需要划分个人贡献度时，根据成员实际绩效计算：

Cᵢ = Pᵢ ÷（P₁ + P₂ + … + Pₙ）× 100%

其中：

• Pᵢ：第 i 名成员的绩效得分；
• Cᵢ：第 i 名成员的个人贡献度；
• n：团队成员人数。

团队所有成员的贡献度之和为：

C₁ + C₂ + … + Cₙ = 100%

通过这种方式，可以使后续贡献度分配建立在整个开发过程中的实际绩效之上，而不是在项目结束后依靠主观印象临时分配。

5.4 特殊情况与复核机制

在实际开发过程中，团队不会对所有延期或未完成情况采取简单的统一扣分，而是结合具体原因和实际影响进行处理。

如果成员因为技术困难、需求调整等合理原因导致任务延期，只要能够提前说明并与团队共同调整计划，原则上不直接扣分；若无合理原因，并且直到截止时间才反馈任务无法完成，则根据实际影响扣除相应的任务完成分和责任意识分。

对于主动承担额外任务、帮助其他成员解决问题、参与紧急补位或发现重大 Bug 的成员，可以将其产生的实际成果计入任务贡献。

如果成员认为自己的绩效评分与实际贡献不符，可以提出复核申请，并提交 Git、PR、Issue、文档、测试结果、原型或会议记录等证据，由团队共同重新核对。

同时，团队坚持不同岗位等价评价原则：

不设置“写代码天然比写文档贡献大”的评价规则。

无论成员承担前端、后端、测试、UI、产品、文档、项目管理还是汇报工作，只要该任务对项目具有实际价值并通过验收，就按照其工作量、难度、重要程度和成果质量进行评价。

5.5 考核流程

团队绩效考核按照开发阶段进行，每轮开发均遵循以下流程：

任务拆分与定级
→ 成员领取或分配任务
→ 开发过程记录
→ 阶段成果验收
→ 完成各项绩效评分
→ 团队成员互评
→ 计算个人绩效
→ 计算个人贡献度
→ 公布结果
→ 如有异议则进行复核

通过这一机制，我们希望尽可能真实地反映每名成员在团队项目中的实际投入，在保证公平性的同时，让成员能够明确自己的责任与目标，并通过规范的软件工程过程共同推进“心晴屿 Moodisle”项目的开发。

6.相关材料

6.1 团队评审表

为了在项目开发过程中更加客观地记录每位成员的阶段性表现，并为后续个人绩效与贡献度计算提供依据，团队根据已经制定的绩效考核方案设计阶段性成员评审表。

评审表以“任务完成与实际贡献、成果质量、团队协作与责任意识、软件工程过程规范、团队成员互评”五个方面作为主要评价维度，同时记录成员在本阶段承担的主要任务和综合评价。每个评价维度均采用 1～10 分制，最终按照既定权重折算为100分制的阶段综合评分。

成员姓名	本阶段主要任务	任务完成与实际贡献（1-10）	成果质量（1-10）	团队协作与责任意识（1-10）	软件工程过程规范（1-10）	团队成员互评（1-10）	综合评价（文字描述）	阶段综合评分（折算100分）
成员1
成员2
成员3
成员4
成员5
成员6
成员7
成员8

评分说明：

• 任务完成与实际贡献：主要考察成员是否按计划完成所承担的任务，以及任务的工作量、技术难度、重要程度和实际价值。
• 成果质量：主要考察功能实现效果、代码/设计/文档质量、测试情况以及是否产生较多返工。
• 团队协作与责任意识：主要考察成员的沟通情况、会议参与、任务响应、主动协作以及责任心。
• 软件工程过程规范：主要考察 Git、Issue、任务看板、文档、测试记录、会议记录等软件工程过程是否规范。
• 团队成员互评：由其他成员根据该成员在本阶段的实际投入、可靠性、合作情况以及任务响应情况进行综合评价。

评分标准（1～10分）：

• 1～2分：表现较差，基本未达到相关要求；
• 3～4分：表现较弱，完成度较低，需要明显改进；
• 5～6分：达到基本要求，能够完成相应工作；
• 7～8分：表现良好，能够较稳定地完成任务并积极参与团队协作；
• 9～10分：表现优秀，在该项中持续具有较高质量表现，并对团队产生明显积极贡献。

阶段综合评分按照团队绩效考核方案中的既定权重计算：

阶段综合评分 =（任务完成与实际贡献 × 0.40 + 成果质量 × 0.25 + 团队协作与责任意识 × 0.15 + 软件工程过程规范 × 0.10 + 团队成员互评 × 0.10）× 10

团队计划在每个主要开发阶段结束后进行一次评审，例如需求与原型设计阶段、功能开发阶段、联调测试阶段以及项目收尾阶段。评审结果将与任务看板、Git 提交、Pull Request、Issue、文档、测试记录等实际过程材料共同保存，为后续个人绩效计算和贡献度划分提供依据。

通过阶段性评审，可以避免项目结束后仅凭印象分配贡献度，使每位成员的实际工作过程和成果更加清晰、透明、可追溯。

6.2 综合评分表

其他小组互评（占0.25权重）	助教评分（占0.35权重）	教师评分（占0.4权重）	综合得分

7.总结

通过本次团队作业，我们完成了“心绪气象局”的团队组建，并围绕学期项目“心晴屿 Moodisle”对项目定位、目标用户、核心需求、解决方案、竞争优势以及后续落地方式进行了较为完整的梳理。

“心晴屿”希望面向18～30岁的大学生与年轻职场人，将真实待办、情绪记录、天气精灵和陪伴式专注结合起来，在满足任务管理与专注需求的同时，为用户提供更加温和、低压力的情绪反馈。通过 NABCD 模型的分析，我们进一步明确了项目需要解决的用户痛点，也明确了“情绪锚定、零惩罚、情绪气候、任务流与专注流双驱动、轻量异步社交”等主要差异化方向。

在项目实现方面，优先保证“记录待办 → 选择情绪 → 天气精灵出现 → 完成任务并收服 → 精灵陪伴专注 → 小岛状态变化”这一核心体验闭环能够稳定实现，再根据开发进度逐步完善统计、养成、探索、分享和多端体验。

与此同时，为了保证后续团队开发过程中的分工公平与贡献可追踪，我们制定了统一的团队绩效考核方案，并设计阶段性成员评审机制，以任务完成情况、成果质量、团队协作、软件工程过程规范和成员互评作为主要评价依据。希望通过明确的分工、规范的开发流程和持续的团队沟通，让每位成员都能够发挥自身优势，共同推进项目落地。

本次作业是“心绪气象局”团队协作的起点。接下来，我们将从目前已经确定的产品定位和核心功能出发，在实际开发过程中不断验证需求、完善设计并根据真实使用反馈进行迭代，努力将“心晴屿”从一个完整的产品设想逐步实现为真正可用、具有自身特色的应用。