FocusPet Beta Release 报告

项目地址 https://github.com/YigesMx/pet-focus

如果无法加载视频，请在此打开：FocusPet Beta 演示（Bilibili）

前言

从 Alpha 的”概念验证”到 Beta 的”真实世界检验”，FocusPet 经历了最严峻的考验。本报告从 NABCD 框架验证、高质量工程实践、用户 NPS 反馈 与 架构评估 四个维度，呈现 Beta 阶段的完整画像。

一、NABCD 验证与惊喜发现

N (Need) — 需求验证 ✅ 部分成立

预期：用户渴望在专注时获得”情感陪伴”，让番茄工作法不再冷冰冰。

验证结果：

• ✅ 确认：开发者/学生用户对”可视化专注反馈”确实感兴趣，数据显示 80% 内测用户完成了至少 5 个番茄钟周期。
• ⚠️ 偏差：用户对”宠物情感反馈”的真实需求远低于预期。调研显示用户更关心 “专注成就感” 与 “数据可视化”，而非宠物的拟人化行为。宠物被视为”装饰”而非核心驱动力。
• 🎯 惊喜：用户强烈需要 “长期激励机制” — 商店、成就系统等游戏化元素，这在初始规划中被列为”Could-Have”，但用户反馈显示这是 “Must-Have”。

A (Approach) — 方案可行性 ✅ 总体可行，但存在架构瓶颈

预期：三进程混合架构（Tauri 后端 + React 前端 + Godot 宠物渲染）可以流畅地同步状态。

验证结果：

• ✅ 核心路径可行：待办→番茄→统计→宠物反馈的闭环在正常场景下运行稳定，消息一致性达到 95%+。
• ❌ 集成地狱：当用户快速切换窗口、频繁创建任务或网络波动时，WebSocket 消息出现乱序、丢失、重复，导致宠物与数据不同步。核心问题是 “缺少幂等性保障与消息队列机制”。当宠物需要扩展对话、互动时，例如，接入LLM API进行对话，现有架构的局限性将更加明显。
• 🎯 惊喜：Tauri 的 IPC（进程间通信）模型相对于”嵌入式 Electron”更轻量。

B (Benefit) — 价值主张 ⚠️ 部分兑现

预期：用户通过 FocusPet 的”情感激励”能延长专注时长 30% 以上。

验证结果：

• ✅ 短期激励有效：内测用户首天使用率 85%，第二天保持 60%。
• ⚠️ 长期激励不足：第三天开始，用户留存率下降很多。原因分析：
  • 宠物互动内容有限（目前只有进食、穿衣等基础动作）；
  • 缺少社交或竞争机制，单用户体验容易疲劳；
  • 商店物品数量不足，玩家感受不到真正的”进度感”。
• 🎯 惊喜：基于成就与统计的”自我竞争”（与上周自己的数据对比）激励效果出人意料地强，部分用户主动保持连续专注天数，形成了自发的挑战社区。

C (Competition) — 竞争地位 ⚠️ 差异化不足

预期：动态宠物 + 番茄钟的结合是独有的，竞品缺少”情感陪伴”层面。

验证结果：

• ❌ USP 被削弱：用户反馈显示 Forest、FocusMe 等竞品的 UI 与交互质量相差无几，主要区别仅在视觉风格。宠物延迟、互动简陋被多位用户指出为”看起来像玩具，而非专业工具”。
• ✅ 发现新差异：FocusPet 的 “离线支持” 与 “跨平台无缝同步” 成为意外的竞争优势。对标 Forest（云依赖、功能同步慢）和 Habitica（复杂臃肿），FocusPet 的轻量级设计获得了开发者的青睐。

D (Delivery) — 交付能力 ⚠️ 短期可行，扩展困难

预期：在 2 周内完成 Beta 版本，支持 Windows/macOS 双平台发布。

验证结果：

• ✅ 按时交付：Beta 版本在第 10 天如期发布
• ⚠️ 扩展困难：任何新功能（如对话功能、多账号同步）都需要触及 WebSocket、数据库与 Godot 三个层面，改动一处需调试三处，集成成本极高。
• 🎯 惊喜：自动化测试框架（E2E + CI）在 Beta 阶段成熟，覆盖率达 65%，使得新功能迭代的回归成本从手工的 1 天降至自动化的不到 1 小时。

二、高质量软件工程实践：我们做到了什么

为什么程序员应该加入 FocusPet 团队？

1. 真正的团队协作与知识沉淀

• 每日 Standup 驱动决策：Alpha 与 Beta 两阶段坚持每日 15 分钟站会，”Yesterday/Today/Blockers” 结构使得团队永不迷茫。所有决策都透明记录，新成员能快速上手。
• 代码走查与 Pair Programming：新成员张沈晖加入时，毛一戈 与申鹏 进行了 3 天的 Pair，确保前端交接零信息丢失。这不是”文档交接”，而是实时知识转移。
• 清晰的技术边界：每个模块（后端 / 前端 / Godot）有明确的 OWNER 与接口规范，PR 评审严格但公平，新手与资深开发都能贡献。

2. 工程化工具链与自动化

• CI/CD 管理员级别：GitHub Actions 不仅跑格式检查，还集成了单元测试、E2E 测试、自动构建与发版脚本。每次提交，机器做 80% 的验证工作，人只需审代码逻辑。这释放了大量调试时间用于真正的设计改进。
• 消息版本兼容层：面对 Alpha 到 Beta 的数据结构演进，团队没有选择”重写一遍”，而是在后端实现了中间件，兼容旧 API 同时支持新字段。这是 “向后兼容” 的实践，值得学习。
• 性能剖析文化：定期运行 Lighthouse / Chrome DevTools 分析，WebSocket 内存泄漏问题靠数据驱动发现，而非”感觉卡”。

3. 健康的风险与复杂度管理

• NABCD + Postmortem 闭环：项目不是”完成功能就完事”，而是每个阶段后进行深度复盘。Alpha Postmortem 明确指出过度工程化、打包瓶颈，Beta 则针对这些问题做了 “化繁为简” 的调整（去掉分心检测、宠物进化等高风险特性）。
• 技术债清偿机制：不是”欠债不还”，而是在每个 Sprint 中分配 20% 的精力用于重构、性能优化、测试补充。这样项目不会越来越臃肿。
• 开放的失败文化：集成地狱、NPS 未达预期、竞品差异化不足——这些问题在报告中坦诚呈现，团队不仅不隐瞒，反而作为下一阶段的方向明确指引。

4. 代码质量与设计模式

• Rust + Tauri 的类型安全：后端 API 通过 Serde 自动序列化，前端 TypeScript 与后端数据结构完全同步。类型不匹配在编译阶段就被发现，运行时 Bug 大幅减少。
• React Hooks + 自定义 Hook：前端采用现代 React，逻辑清晰、易测试。自定义 Hook（如 usePomodoro、usePetState）充分复用，减少重复代码。
• Godot GDScript 的事件驱动：宠物动画通过信号（Signal）与后端解耦，新增动作不需要修改通信层。

如果我们开源，你为何加入？

1. 接触前沿工程话题：Tauri vs Electron、自动化测试的 ROI、跨平台打包的痛点——这些都是业界热题。
2. 友善的代码评审与成长机会：团队有 2 位资深工程师（毛一戈、赵昱），代码评审详细但鼓励，新手 PR 会被细心指导，而非直接拒绝。

架构评估：三位大模型的建议

我们请 3 个代码生成大模型（ChatGPT、Claude、Copilot）评审了 FocusPet 的三层架构。以下是核心建议总结：

Tauri + WebSocket + Godot 架构评价

💚 ChatGPT 的评价（9/10）

“相对于 Electron，你们的 Tauri 选择非常睿智。轻量、跨平台、IPC 清晰。唯一建议是在 WebSocket 上引入消息队列（RabbitMQ/Redis），而非直接 TCP 通信，这样可以保证消息顺序与幂等性。”

• 肯定：IPC 架构、类型安全
• 建议：加入消息队列、implement retry logic

🧡 Claude 的评价（7/10）

“架构本身没有问题，但’过度分离’导致了集成复杂度。你们为什么不考虑把 Godot 作为 Tauri 的一个’视图’而非独立进程？这样可以避免 WebSocket 序列化、反序列化的开销；或者考虑使用现代前端UI动画技术，例如Lottie或者Rive。”

• 肯定：类型安全、测试 setup
• 建议：重新考虑进程模型、减少 IPC 调用

💙 Copilot 的评价（6/10）

“WebSocket over TCP + JSON 序列化的组合在高频消息场景下容易出现延迟。考虑迁移到 gRPC（Protocol Buffers）或 QUIC 以获得更好的性能。但实现成本较高，你们目前的时间线内可能无法完成。”

• 肯定：CI/CD 自动化、测试框架
• 建议：性能优化（长期）、减少消息频率（短期）

三个模型的共识：

| 方面 | 评价 | 改进建议 | |—|—|—| | IPC 设计 | 清晰，但过度分离 | 考虑嵌入式 Godot 或 前端动画 | | 网络层 | TCP + JSON 稳定但不高效 | gRPC / QUIC（长期） | | 前端框架 | React + TypeScript 优秀 | 无重大建议 | | 测试 | 自动化覆盖率 65% 很好 | 补充性能测试与压力测试 | | 总体打分 | 7/10（平均） | 稳定可靠但可优化 | —

三、用户 NPS 反馈：6-7 分的启示

NPS 定义与我们的现状

NPS（Net Promoter Score） = （推荐者 % - 贬低者 %）

我们的 NPS：约 6-7 分（10 分制）

• 推荐者（9-10 分）：35%
• 中立者（7-8 分）：40%
• 贬低者（0-6 分）：25%

为什么低于预期（预期 8-9 分）？

贬低者（0-6 分）反馈的三大痛点：

1. “宠物互动很生硬”（提及率 40%）
   • 宠物的 4-5 个动作重复过度，缺少随机性与惊喜。
   • 与 Tamagotchi / 旅蛙等对标产品相比，动画帧数少、流畅度差。
   • 用户期待：”宠物应该有自己的’脾气’，而不是简单的状态机”。
2. “集成故障影响心流”（提及率 55%）
   • 快速操作时 Web 控制器与 Godot 窗口状态不同步。
   • 用户反馈：”开始专注后宠物反应慢半拍，整个沉浸感碎裂”。
   • 时间延迟 >500ms 被用户明确指出为”不可接受”。
3. “功能不够深”，像个”玩具”（提及率 40%）
   • 商店物品只有 8 种，成就 6 个，用户玩 2 周后就见底。
   • 缺少”社交”、”排行榜”、”挑战” 等延续动力的机制。
   • 与 Forest/Habitica 的丰富度对比，FocusPet 显得”做了一半的产品”。

中立者（7-8 分）的反馈：

• “还可以，但还需要时间打磨”：认可核心概念与 UI 设计，但觉得功能不够成熟。
• “对比 Forest，FocusPet 的离线支持更好”：发现了意外优势，但这不足以成为”推荐理由”。
• “期待未来发展”：持观望态度，希望看到后续的”社交”与”云同步”功能。

NPS 6-7 vs 预期 8-9 的根本原因

惊喜发现：6-7 分背后的”隐性NPS”

虽然 NPS 打分不理想，但我们发现了两个 高价值信号：

用户反馈的方向性极强

• 没有”这个产品不适合我”的言论，都是”这个功能应该这样”。
• 这是 “有机会改进” 而非”方向错误”的信号。

我们的反思

• 短期（下个 2 周）：不改架构，聚焦于”消息频率优化”与”前端延迟掩盖”（骨架屏、乐观更新）。
• 中期（RC 阶段）：引入简单的消息队列（Redis）或引入 gRPC 试点。
• 长期（2026 年）：如果产品达到成熟，考虑重构 宠物组件或迁移到更高效的 RPC 框架。

五、总结：从 Beta 到 Release Candidate

成就

• ✅ 核心闭环验证：待办→番茄→宠物→统计 正常工作。
• ✅ 工程质量：CI/CD、自动化测试、代码走查 达到中等偏上水准。
• ✅ 用户信号：虽然 NPS 6-7 低于预期，但用户建议清晰，改进空间明确。

挑战

• ❌ 集成地狱：WebSocket 同步延迟与消息乱序是影响体验的根本问题，需要架构层面的改进。
• ❌ 内容深度：商店、成就等游戏化核心仍不成熟，用户很快看到天花板。
• ❌ 扩展能力：任何新功能都需触及三层，开发成本高、周期长。

RC（Release Candidate）计划

1. 性能与稳定性（1 周）
   • 减少 WebSocket 消息频率（从 100ms 改为 500ms）
   • 前端实现乐观更新与骨架屏，掩盖网络延迟
   • 压力测试：并发 100 个任务，连续 8 小时运行
2. 内容补充（1-2 周）
   • 商店物品从 8 增至 20+（包括季节限定）
   • 成就系统扩展至 15+ 成就，加入”任务链”（完成成就 A 解锁 B）
   • 初步的”朋友排行榜”（本地或 Discord 集成）
3. 社交激励（可选，依时间）
   • Discord 频道集成：分享成就、挑战朋友
   • “周榜单”与”月挑战”机制

最终目标

在 12 月底前，将 FocusPet 推进到 Release Candidate 阶段，争取 NPS 达到 7-8 分，留存率稳定在 40%+。

如果达成，我们就可以考虑 “正式 v1.0 发布” 与可能的 “开源” 路线。