【Code-with-SOLO】SOLO开发【安守】全自动独居安全守护软件

[用户31748]

爱有两种样子：

一种，是提前写好的告别，温柔得不忍惊扰时光。
一种，是随时待命的警觉，决绝得不肯放过危险。

我们把前者，叫做“不留遗憾”；
我们把后者，叫做“我在等你”。

这是一个关于守护的故事。在你最好的时候，它替你存下温柔；在你最坏的时候，它替你喊出声音。

别让来不及说，成为最后的遗憾；别让来不及救，成为最后的悔恨。
——【安守】，守护你生命中每一个重要的瞬间。

1.0 背景

我是一名全栈开发者，需要进行前后端的全栈开发，原本这个项目的制作周期周期起码要几个月，现在希望用 SOLO 提效。

一个悖论：科技越发达，守护越沉默

我们生活在一个被智能设备包围的时代。手机知道我们的位置、步数、睡眠质量，甚至能预测我们的月经周期和情绪波动。但讽刺的是，当我们真正需要被“看见”的时候——无论是情感上的告别，还是生理上的危难——这些设备往往保持沉默。

它们记录，却不回应。它们感知，却不行动。

这不是技术的局限，而是设计的盲区。大多数应用追求的是“让用户更活跃”“让用户停留更久”，却很少有人想过：当用户不再活跃时，是否还有人替他们守护？

1.2 我们的答案：从“被动记录”到“主动守护”

【安守】项目的诞生，正是为了填补这片空白。

我做了两件简单却重要的事

第一件，是让来不及说的话，有机会抵达。
用户可以在任何时候，写下那些“如果有一天我来不及了，希望你知道”的话。这些话被加密封存，只有预设的条件被触发时——比如手机连续数日无任何操作——才会发送给指定的人。它不是遗言，而是一颗提前种下的种子，在合适的时候开花。

第二件，是让无法喊出的求救，有人听见。
我们调用手机的传感器，持续监测用户的运动状态、环境变化与生理特征。当检测到疑似摔倒、长时间静止不动、心率异常等紧急情况时，系统会自动向预设的联系人发送警报与定位信息。它不是监控，而是一双永远不会合上的眼睛。

1.3 更大的图景：一个人人皆可被守护的未来

我们相信，科技最温暖的样子，不是让你刷得更久，而是让你走得更安心。

想象这样一个世界：

• 独居的老人，可以放心地一个人生活，因为手机知道她摔倒时会有人来；

• 深夜加班的白领，可以放心地走在回家的路上，因为有人知道她平安到了；

• 每一个普通人，都可以放心地去爱、去活、去冒险，因为他们知道——有些话，不会来不及说；有些险，不会来不及救。

这不是遥远的未来。它就在你的手机里，只需要一个应用，和一份愿意守护的心。

2.项目简介

“安守”是一款致力于实现“无感化”监测的 Android 智能守护应用。它深度融合了加速度计、陀螺仪及计步器等多维传感器数据，通过自研算法实时分析用户的运动状态、手机使用习惯及睡眠质量。在确保极低功耗与后台稳定保活的前提下，系统能精准识别异常行为（如长时间失联或未签到），并自动触发多级预警机制通知紧急联系人。

此外，应用独创的“时光胶囊”功能提供了一种温情的数字化保障：当检测到用户长期离线且设备仍有电量时，系统将自动把预设的关怀信息发送给指定亲友，为应对生活中的未知与意外提供最后一道温暖防线。

3. 实践过程

3.1 任务拆解与架构设计

在 SOLO 的帮助下，我采用了“功能模块 → 技术实现 → 问题迭代”的三层拆解策略：

第一层：核心功能模块划分

安守应用
├── 签到系统（CheckinService）
│ ├── 每日安全检查逻辑
│ ├── 警报触发机制
│ └── 防重复报警设计
├── 睡眠监测系统（SleepMonitorService）
│ ├── 入睡检测算法
│ ├── 醒来判定逻辑
│ └── 跨天数据处理
├── 通知系统
│ ├── 邮件发送
│ ├── 短信降级
│ └── 确认通知交互
└── 数据持久化
├── SharedPreferences 管理
├── 日志系统
└── 历史记录存储

第二层：技术难点识别

• 状态管理：如何避免服务重启后状态丢失

• 时间处理：跨天睡眠的时长计算

• 防重复机制：每天只报警一次的设计

• 可观测性：后台服务的日志追踪

第三层：迭代优化路径

V1.0 基础功能 → V1.1 传感器问题修复 → V1.2 ui优化 → V1.3 界面svg图标重新设计 → V1.4 修复睡眠监测逻辑→ V1.5 修复后台被杀问题 → V1.6 日志系统优化 → V1.7 跨天数据逻辑修复

3.2 用了 SOLO 哪些能力

代码生成与重构

• 生成了完整的 Service 生命周期管理代码

• 重构了邮件配置界面的 UI 布局

• 实现了复杂的睡眠检测算法

智能调试与问题诊断

• 通过分析日志定位"重复报警"问题

• 诊断"1970-1-1"时间戳错误的根本原因

• 识别 Log.d() 不写入文件的陷阱

架构设计建议

• 建议使用 AppLogger 统一日志接口

• 推荐添加防重复调度标志（isScheduleInitialized）

• 提出状态恢复机制（restoreServiceState()）

代码审查与优化

• 发现并修复了 4 处缺少有效性检查的 recordSleepData() 调用

• 优化了邮件发送的频率限制处理

• 改进了稍后提醒功能的闹钟调度逻辑

文档生成

• 自动生成流程图和时序图

• 创建问题修复报告

• 生成测试用例说明

3. 3 关键 Prompt 示例（设计部分）：

“请帮我设计一个 Android 睡眠监测服务的架构，要求使用加速度计和计步器数据，并能区分‘躺下’和‘起床’状态，同时需要考虑 Android 10+ 的后台限制。
整个睡眠监测功能可以选择是否开启，关闭后，加速度传感器和陀螺仪传感器也同时关闭。
决定将陀螺仪作为"可选增强"，默认开启开启加速度计
帮我入睡判定标准，阈值默认为屏幕熄灭 + 无步数增长 + (加速度计大无变化) 持续30分钟 → 判定为入睡
屏幕点亮 或 步数增长 > 10步 或 加速度计变化 > 阈值 → 判定为醒来
加速度计大无变化时间（默认30分），加速度阈值，步数（10步）都可以修改，
充电只是一个辅助的判定标准，帮助区分“人睡了”和“手机静置”——插电通常意味着用户进入了长时间不使用手机的状态
排除大量干扰场景——如手机忘带、白天静置等
提供行为模式的上下文——结合时间，可以强化对用户睡眠规律的识别
不使用Google Sleep API ”

“现在对守护界面进行修改，对右上角的设置按钮进行修改，当点击设置按钮时，弹出一个设置界面，该界面其中有如下按钮：添加守护对象，守护对象管理，接收配置，点击添加守护对象后可以添加新的守护对象，点击守护对象管理，会显示当前所有的对象，每个对象末尾都有编辑 删除 禁用 小按钮，点击可以直接进行相关操作。点击接收配置按钮后，弹出输入本机邮箱地址和授权码的界面，如果紧急联系人设置界面设置了该数据，则直接同步紧急联系人设置中的数据。”
“把选择对象的按钮的容器颜色改为纯色。
刷新按钮以下的 警报记录部分好像是不可滑动界面，把它改为可滑动的。警报记录部分的“下拉刷新或添加守护对象”文本，有一部分溢出到导航栏下面了，被导航栏遮挡了，把警报记录部分的文本和守护的svg图标统一向上移动一些”

3.4 关键 Prompt（测试调试部分）

Prompt 1：增强可观测性

多加一些睡眠监测的log，我需要观察睡眠监测的后台运行情况，
观察什么时候在进行入睡相关的逻辑判断，还有入睡醒来的逻辑判断过程

效果：

• SOLO 自动在关键节点添加了详细日志

• 使用 AppLogger 同时输出到 Logcat 和文件

• 生成了完整的入睡/醒来检测流程日志

---

Prompt 2：基于真实数据的 Bug 报告

现在经过一天的测试，现在出现了一些问题。我昨晚测试的时候，
自动报警时间设置的是凌晨00：57，在00：57是成功的发送了警报，
日志界面也有相关的报警逻辑，可是1：41又报警了，然后就是1：56，
2：11，2：26，2：41发送了警报邮件。中间没有报警，然后到了早上
7：50报了一次报警，然后8：17继续每隔15分钟报一次警直到10：47
步数达到了阈值后，报警才结束。这是什么问题

效果：

• SOLO 精准定位到"缺少今日已报警状态记录"

• 提供了完整的修复方案（添加日期检查逻辑）

• 同时修复了自动报警模式的相同问题

设计亮点：提供了精确的时间线数据，让 AI 能快速复现问题场景。

---

Prompt 3：数据准确性验证

现在早上八点检测到没起床，但是报警发送失败。
显示持续睡眠540分钟，可是我是在凌晨一点后睡觉的，
这个持续失眠时间也不太对。

效果：

• 识别出 confirmedSleepStartTime 可能为 0 的问题

• 添加了详细的诊断日志（入睡时间、醒来时间、时长计算）

• 在所有调用点添加了有效性检查

设计亮点：通过对比预期值和实际值，快速定位数据计算错误。

---

Prompt 4：排除法定位问题

邮件配置是完整的，网络连接也没有问题，毕竟7：50还发送了签到警报

效果：

• SOLO 推断出可能是 SMTP 频率限制

• 添加了时间间隔检测日志

• 提供了延迟发送和合并邮件的解决方案

设计亮点：通过排除已知正常项，缩小问题范围。

---

Prompt 5：日志完整性检查

日志上只有睡眠监测服务已启动和已发送睡眠超时警报：540分钟，
其他的所有入睡检测之类的还有醒来检测之类的log都没有显示。
这会是什么问题

效果：

• 发现 Log.d() 不写入文件的陷阱

• 批量替换为 AppLogger.d() / AppLogger.i()

• 确保所有关键日志都能被应用内查看

设计亮点：关注端到端的可见性，而非仅仅代码层面的日志输出。

---

Prompt 6：数据质量验证

现在的睡眠快照日志还是没有记录，同时睡眠监测设置界面的睡眠记录
历史界面的中，今天的睡眠记录还是1970-1-1 8：00-9：00

效果：

• 识别出 timestamp = 0 导致显示 1970 年的问题

• 在所有保存点添加了 if (confirmedSleepStartTime > 0) 检查

• 添加了防御性日志记录

设计亮点：质疑异常数据的合理性，推动系统增加数据验证。

3.5 中间踩过什么坑

1：日志分级陷阱

现象：代码中有大量 Log.d()，但应用内日志查看界面看不到

原因：

• Log.d() 只输出到 Logcat，不会写入文件

• 应用的日志查看功能是从 app_logs.txt 读取的

教训：

关键业务日志必须使用统一的日志工具（如 AppLogger），确保既能调试又能持久化。

修复：批量替换为 com.livewell.untils.AppLogger.d/i/w/e()

---

2：状态管理缺失

现象：每天重复报警多次（00:57, 1:41, 1:56, 2:11…）

原因：

• 没有在 SharedPreferences 中记录"今日已报警"状态

• 每次 CheckinService 启动都会执行完整检查

---

3：时间戳初始化问题

现象：睡眠历史记录显示 “1970-1-1 8:00-9:00”

原因：

• confirmedSleepStartTime 为 0 时仍调用了 recordSleepData()

• Unix 时间戳 0 对应 1970-1-1 08:00（UTC+8）

教训：

所有时间戳字段在使用前必须验证有效性（> 0），避免无效数据污染历史记录。

修复：在 4 个调用点都添加了 if (confirmedSleepStartTime > 0) 检查

---

4：跨天数据处理复杂性

现象：睡眠时长计算错误（显示 540 分钟，实际约 420 分钟）

原因：

• 入睡时间在昨天（23:00），醒来在今天（08:00）

• 如果 confirmedSleepStartTime 记录的是昨天的错误时间，会导致计算偏差

教训：

跨天场景需要特别小心，建议在入睡时立即保存快照，而不是依赖实时计算。

修复：

• 添加 recordPreSleepDataSnapshot() 方法

• 在确认入睡时立即保存步数和使用时长

• 添加详细的诊断日志帮助排查

---

5：外部依赖的频率限制

现象：7:50 签到警报成功，8:00 起床警报失败

原因：

• SMTP 服务器有短时间内的发送频率限制

• 10 分钟内连续发送 2 封邮件可能被拒绝

教训：

调用外部服务时必须考虑限流策略，添加重试机制和退避算法。

修复：

• 添加时间间隔检测日志

• 实现 5 分钟后自动重试机制

• 最多重试 3 次

---

6：服务重启状态丢失

现象：服务被系统杀死后重启，睡眠状态丢失

原因：

• confirmedSleepStartTime 等状态只保存在内存中

• 没有在 onCreate() 中从 SharedPreferences 恢复

教训：

长期运行的 Service 必须在 onCreate 中恢复持久化状态，防止系统杀进程后数据丢失。

修复：

private fun restoreServiceState() {
    val lastConfirmedSleepStart = prefsManager.getLong("confirmed_sleep_start_time", 0)
    if (lastConfirmedSleepStart > 0) {
        confirmedSleepStartTime = lastConfirmedSleepStart
        Log.i(tag, " 恢复之前的入睡状态")
    }
}

---

7：稍后提醒功能不完整

现象：用户点击"稍后提醒"后，30 分钟后没有再次提醒

原因：

• 只设置了 snoozeTime，但没有设置闹钟

• 系统不知道要在 30 分钟后重新检查

教训：

任何"延迟执行"的功能，都必须有对应的定时任务调度。

修复：

• 在 AlertConfirmReceiver.handleSnooze() 中添加 scheduleSnoozeAlarm()

• 30 分钟后启动 CheckinService 并执行 performSafetyCheck()

3.5 核心功能实现

A. 基于多传感器融合的睡眠监测算法

传统的睡眠应用往往依赖手动点击或单一计步器，而“安守”通过 TRAE SOLO 辅助我实现了更精准的加速度计 + 计步器融合算法：

• 动态阈值判定：利用 SOLO 提供的数学逻辑，我编写了低通滤波器来消除传感器噪点。当检测到手机加速度方差低于特定阈值且计步器读数长时间无变化时，系统自动判定为“入睡”。

• 智能起床识别：为了区分“翻身”和“起床”，算法会监测连续的运动时长。只有当运动持续超过 5 分钟且幅度较大时，才标记为“起床”并生成报告。

• 代码亮点：SOLO 帮我优化了 SleepMonitorService 的电量管理，通过动态调整采样频率（静止时降低频率），将夜间耗电量控制在 5% 以内。

B. 闭环式自动报警与邮件反馈机制

这是本项目最具特色的功能，实现了从“发现异常”到“确认安全”的全自动化闭环：

1. 多级预警触发：当用户错过签到时间，后端 Scheduled Task 会立即触发一级预警，向监护人发送邮件。

2. IMAP 自动回读：我在 Android 端集成了 JavaMail API，实现了 EmailReceiverService。当监护人回复邮件（如回复“已知晓”或“平安”）时，App 会自动解析邮件内容。

3. 状态自动同步：一旦识别到关键词，App 会自动取消本地的警报状态并记录日志。这种双向交互设计有效避免了误报带来的恐慌。

4. 技术攻关：在处理 IMAP 协议时，SOLO 帮我解决了 SSL 证书校验和后台线程阻塞的问题，确保了邮件接收的实时性。

C. 跨厂商后台保活体系

针对 Android 系统严格的后台限制，我利用 SOLO 构建了一套组合拳式的保活方案：

• 前台服务提升优先级：通过 Foreground Service 配合常驻通知栏，确保核心监测进程不被系统轻易回收。

• JobScheduler 智能重启：利用系统级的任务调度器，在检测到服务意外停止后，于合适的时机（如充电或连接 Wi-Fi 时）自动重启服务。

• 厂商适配策略：SOLO 提供了针对小米、华为等主流厂商的省电策略白名单引导逻辑，指导用户在系统设置中开启“允许后台活动”，从而大幅提升守护功能的稳定性。

D. 离线优先的数据同步架构

考虑到用户可能在地下室或信号不佳的环境中使用，我设计了**离线优先（Offline-First）**架构：

• 本地持久化：所有的签到记录和睡眠数据首先存入 Room 数据库。

• 增量同步：SyncWorker 会在网络恢复时，对比本地与服务器的时间戳，仅上传未同步的数据。

• 冲突处理：利用 SOLO 生成的版本控制逻辑，解决了多设备登录时的数据覆盖问题，确保数据的最终一致性。

4. 成果展示

4.1 应用界面

应用采用 Material Design 3 设计规范，采用stitch+aistudio辅助设计，界面简洁直观。

图 1：应用首页，支持进行模式选择，查看报警历史记录以及时光胶囊

图 2：守护模式界面，支持添加紧急联系人并查看历史预警

图 3：设置界面

图 4：报警历史记录部分（900步数是测试用例，不是实际逻辑）

图 5：密码书部分（当别人拿到你的手机，可以进行输入密码来解锁查看）

图 6：设置界面

图 7：开发者测试界面

图 8：用户接受到邮件的界面

4.2 技术栈

• 前端：Kotlin, Jetpack Components, Material Design 3

• 后端：Spring Boot (Kotlin), MySQL, JWT

• 管理端：Vue 3, TypeScript, Vite

5.0 总结

5.1 提效了多少？

代码编写速度原先估计要50-100 行/小时，但使用了solo，预估达到了300-500 行/小时

一个Bug 定位时间原先估计要30-60 分钟，但使用了solo，预估只要5-10 分钟

重构一个功能和界面耗时 原先估计要2-4 小时但使用了solo，预估只要20-30 分钟

整体开发周期 预估小几周才能完成，实际开发不算测试的时间只需要几天左右

5.2 SOLO 在我流程中做了什么？

角色 1：智能结对程序员（Pair Programmer）

场景：实现睡眠监测算法

我：需要一个基于步数、屏幕状态、加速度计的入睡检测算法
SOLO：提供了完整的三重判定逻辑，包括：
  - 步数阈值判断
  - 屏幕关闭时长验证
  - 加速度计体动检测
  - 连续检查机制（防止误判）
  - 均衡模式 vs 省电模式切换

价值：

• 提供了行业最佳实践（连续 2 次检查确认）

• 考虑了边界情况（传感器误差、跨天场景）

• 生成了可立即运行的代码

角色 2：高级调试助手（Debug Assistant）

场景：每天重复报警问题

我：提供了完整的时间线数据（00:57, 1:41, 1:56...）
SOLO：
  1. 分析问题根因：缺少"今日已报警"状态记录
  2. 定位代码位置：CheckinService.performSafetyCheck()
  3. 提供修复方案：添加日期检查逻辑
  4. 扩展到相关模块：同时修复自动报警模式
  5. 验证修复：编译成功，逻辑正确

价值：

• 精准定位：从现象到根因的推理链条清晰

• 全面修复：不仅解决当前问题，还预防类似问题

• 即时验证：确保修复不会引入新问题

角色 3：架构顾问（Architecture Advisor）

场景：日志系统设计

我：日志看不到，只有部分信息显示
SOLO：
  1. 诊断问题：Log.d() 不写入文件
  2. 分析原因：应用内日志查看从文件读取
  3. 设计方案：使用 AppLogger 统一接口
  4. 批量修复：替换所有关键日志点
  5. 验证效果：确保端到端可见性

角色 4：代码审查员（Code Reviewer）

场景：睡眠记录保存逻辑

SOLO 主动发现：
  ❌ recordSleepData() 在 4 个地方被调用
  ❌ 其中 1 处缺少 confirmedSleepStartTime > 0 检查
  ❌ 可能导致保存 timestamp=0 的记录（显示 1970-1-1）
  
修复：
  ✅ 在所有调用点添加有效性检查
  ✅ 添加防御性日志
  ✅ 确保数据质量

价值：

• 主动发现问题：在我意识到之前就已经指出潜在风险

• 全面覆盖：检查所有相关代码路径

• 预防胜于治疗：避免未来出现难以追踪的 Bug

5.3 有没有可复用的方法？

1.分层拆解法

核心原则：将复杂问题分解为功能层 → 技术层 → 实现层

示例：睡眠监测系统

第一层：功能需求

• 检测用户何时入睡
• 检测用户何时醒来
• 计算睡眠时长
• 异常时发送警报

第二层：技术方案

• 使用 SensorManager 获取步数和加速度
• 使用 PowerManager 监听屏幕状态
• 使用 AlarmManager 定时检查
• 使用 SharedPreferences 持久化状态

第三层：具体实现

• checkSleepCandidate() 方法
• checkWakeUp() 方法
• confirmSleep() 方法
• recordSleepData() 方法

复用技巧：

1. 先明确功能：不要一上来就写代码

2. 再选择技术：评估多种方案的优劣

3. 最后实现细节：让 AI 生成具体代码

适用场景：新功能开发、系统重构、架构设计

2.迭代验证循环

核心原则：小步快跑，快速验证

流程：

1. 提出需求 → 2. AI 生成代码 → 3. 编译验证
   ↓ ↑
2. 部署测试 ← 5. 修复问题 ← 4. 发现问题

示例：

第 1 轮：实现基础入睡检测 → 编译通过
第 2 轮：添加详细日志 → 编译通过
第 3 轮：发现日志不显示 → 修复 Log.d() 问题
第 4 轮：发现数据错误 → 添加有效性检查
第 5 轮：发现重复报警 → 添加防重复机制

复用技巧：

1. 每次只改一件事：便于定位问题

2. 立即编译验证：避免累积错误

3. 保留中间版本：方便回滚

适用场景：所有开发任务，特别是复杂功能

3.排除法定位法

核心原则：通过排除已知正常项，缩小问题范围

示例：邮件发送失败问题

问题：起床异常警报邮件发送失败

排除步骤：

1. 邮件配置是否完整？→ 是（7:50 签到警报成功）
2. 网络连接是否正常？→ 是（7:50 能发送邮件）
3. SMTP 服务器是否可用？→ 是（7:50 能连接）
4. 是否是频率限制？→ 可能（10 分钟内 2 封邮件）

结论：SMTP 服务器短时间内的频率限制

复用技巧：

1. 列出所有可能原因

2. 逐一排除已知正常的项

3. 聚焦剩余的可能性

4. 针对性添加诊断日志

4.日志驱动开发

核心原则：先设计日志，再实现逻辑

流程：

1. 定义关键事件点（入睡、醒来、报警）

2. 设计日志格式（包含哪些字段）

3. 实现业务逻辑（同时输出日志）

4. 通过日志验证逻辑正确性

5. 根据日志优化算法

   复用技巧：

   1. 日志要包含业务语义（不只是技术参数）

   2. 日志要有关联性（能串联成完整流程）

   3. 日志要有分级（Debug/Info/Warn/Error）

   4. 日志要持久化（便于事后分析）

5.状态机思维

核心原则：明确系统的状态和状态转换

示例：睡眠监测系统状态机

状态：

• IDLE（空闲）
• MONITORING（监测中）
• SLEEP_CANDIDATE（疑似入睡）
• CONFIRMED_SLEEP（确认入睡）
• AWAKE（醒来）

转换：
IDLE → MONITORING：启动服务
MONITORING → SLEEP_CANDIDATE：步数无增长 + 屏幕关闭
SLEEP_CANDIDATE → CONFIRMED_SLEEP：连续 2 次检查通过
CONFIRMED_SLEEP → AWAKE：检测到步数/屏幕/体动
AWAKE → IDLE：记录数据，重置状态

复用技巧：

1. 画出状态转换图

2. 为每个状态定义进入/退出条件

3. 为每个转换添加日志

4. 验证所有状态都能正确恢复

5.4 AI 辅助开发的最佳实践总结

应该做的

1. 提供充分的上下文：代码片段、错误信息、预期行为

2. 分步验证：每步都编译运行，不要一次性改太多

3. 质疑 AI 的输出：理解每一行代码的作用，不要盲目复制

4. 保留历史记录：方便回溯和对比

5. 建立知识库：记录常见问题的解决方案

不应该做的

1. 不要完全依赖 AI：关键逻辑要自己理解和验证

2. 不要跳过测试：AI 生成的代码也可能有 Bug

3. 不要忽视警告：编译器警告往往是潜在问题的信号

4. 不要过度优化：先保证正确性，再考虑性能

5. 不要忘记文档：AI 可以生成，但你要审核

6.0 测试版下载链接

https://wwbez.lanzouw.com/i3GY23ngrskd

密码:i7cw

7.0 Github仓库（暂时未开放公开）

这个项目看起来实现原理不难，但是测试起来很花费时间。目前还有很多功能没有完善以及测试完成，待所以功能界面开发优化完成后，将会开源代码。

（目前版本仍然为测试debug版本，虽然功能基本完善，但对于对机型的适配性可能有所出入，实际使用时一定要把权限全部给到，包括关闭电池优化和无障碍服务，此应用为完完全全的本地运行的应用，不涉及隐私信息的上传）

“让每一次沉默，都被听见。让每一次告别，都不留遗憾。”