# HomeVista PWA 产品 PRD 与 CRM 原型生成指令

> 用途：将本文档交给 Codex，用于生成 **HomeVista PWA 产品需求文档 PRD** 以及 **CRM / Notification 管理后台原型方案**。  
> 产品方向：HomeVista 采用 **自研 CRM / Notification Service + 第三方 Push 通道** 的方式实现 PWA 通知能力。

---

# 一、任务目标

请你基于以下背景，为 **HomeVista 产品升级 PWA** 输出一份完整的产品需求文档 PRD，并进一步设计一套可用于开发参考的 **CRM / 通知管理后台原型方案**。

需要输出两部分内容：

1. **HomeVista PWA 产品需求文档 PRD**
2. **HomeVista CRM / Notification 管理后台原型设计**

文档需要适合交给产品、设计、前端、后端、测试共同评审。

---

# 二、产品背景

HomeVista 是一个面向房地产 / 项目销售场景的定制类 SaaS 工具。

产品特点：

1. HomeVista 服务多个客户。
2. 每个客户可以拥有一个或多个独立项目。
3. 每个项目有自己的成员、角色、客户线索、房源资料、预约、报价、销售跟进记录等数据。
4. 不同客户之间的数据必须严格隔离。
5. 不同项目之间的数据也需要隔离，避免出现消息、客户、报价、房源等信息混用。
6. HomeVista 希望升级为 PWA，让用户可以把 Web 应用添加到手机桌面，并接收 Push 通知。

当前技术方向已经确定：

> 采用 **HomeVista 自研 CRM / Notification Service + 第三方 Push 通道** 的方式实现。

其中：

HomeVista 自己负责：

- 租户 tenant 隔离
- 项目 project 隔离
- 用户 user 权限
- 角色 role 权限
- 通知偏好
- 订阅 subscription 管理
- 推送内容生成
- 推送内容脱敏
- 推送日志
- 审计记录
- 通知触发规则

第三方 Push 服务只负责：

- 将通知投递到用户设备
- 返回发送成功 / 失败状态

第三方 Push 不能决定“谁应该收到消息”，只能作为投递通道。

---

# 三、第一部分：PWA 产品 PRD 要求

请按照以下结构输出 PRD。

---

## 1. 项目概述

说明：

- 为什么 HomeVista 需要升级 PWA
- PWA 对 HomeVista 用户的价值
- 添加到手机桌面的价值
- Push 通知的价值
- 对房地产销售 / 项目管理场景的意义

请重点说明：

> HomeVista 的场景不是普通网页通知，而是多租户、多项目、强隔离的 SaaS 通知系统。

---

## 2. 产品目标

请拆成 **业务目标** 和 **技术目标**。

### 2.1 业务目标

业务目标包括但不限于：

- 提升销售人员访问 HomeVista 的便捷性
- 让客户 / 销售 / 管理员可以及时收到项目消息
- 降低消息遗漏
- 提高客户咨询、预约、报价更新的响应效率
- 支持不同客户 / 项目独立配置通知规则

### 2.2 技术目标

技术目标包括但不限于：

- 支持 PWA 安装
- 支持 Android 添加到桌面
- 支持 iOS 添加到主屏幕
- 支持 Service Worker
- 支持 Web Push
- 支持 Push subscription 管理
- 支持 tenant / project 级别数据隔离
- 支持通知日志和审计

---

## 3. 用户角色

请定义 HomeVista PWA / CRM 中的用户角色。

至少包括：

- 平台超级管理员 Super Admin
- 客户管理员 Tenant Admin
- 项目管理员 Project Admin
- 销售人员 Sales
- 客服 / 跟进人员 Support
- 普通查看用户 Viewer

每个角色需要说明：

- 角色说明
- 可以访问哪些项目
- 可以管理哪些通知
- 是否可以配置通知规则
- 是否可以查看推送日志
- 是否可以发送项目通知

建议输出表格格式：

| 角色 | 角色说明 | 项目访问范围 | 通知管理权限 | 日志查看权限 | 是否可发送通知 |
|---|---|---|---|---|---|

---

## 4. 核心使用场景

请至少覆盖以下场景：

1. 用户首次访问 HomeVista，并添加到手机桌面
2. 用户从桌面图标打开 HomeVista
3. 用户开启通知权限
4. 用户进入某个项目后订阅该项目通知
5. 项目有新客户咨询时，项目销售收到通知
6. 项目预约看房前，相关人员收到提醒
7. 项目报价更新后，相关人员收到通知
8. 项目管理员发送项目公告
9. 用户点击通知后跳转到对应项目页面
10. 用户关闭某个项目的通知
11. 用户同时属于多个项目时，通知不能串项目
12. 用户没有项目权限时，即使点击旧通知，也不能查看对应数据

每个场景请输出：

- 场景描述
- 参与角色
- 前置条件
- 用户操作流程
- 系统处理流程
- 异常情况
- 验收标准

建议输出格式：

```txt
场景名称：

场景描述：

参与角色：

前置条件：

用户操作流程：
1.
2.
3.

系统处理流程：
1.
2.
3.

异常情况：

验收标准：
```

---

## 5. PWA 安装需求

请分别说明 Android、iOS、桌面浏览器的 PWA 安装需求。

---

### 5.1 Android

要求：

- Chrome Android 支持添加到桌面
- 可通过 beforeinstallprompt 触发安装提示
- 可以显示 HomeVista 自定义安装按钮
- 安装后从桌面启动，进入 standalone 模式

请输出：

- 功能说明
- 页面入口
- 交互流程
- 状态判断
- 异常提示
- 验收标准

---

### 5.2 iOS

要求：

- iOS Safari 需要用户手动添加到主屏幕
- 系统需要提供“添加到主屏幕”引导
- 用户从主屏幕打开后才进入类 App 模式
- iOS Push 需要考虑系统版本和浏览器限制

请输出：

- 功能说明
- 页面入口
- 交互流程
- 状态判断
- 异常提示
- 验收标准

---

### 5.3 桌面浏览器

要求：

- Chrome / Edge 桌面端可安装
- 安装后可以作为桌面应用打开

请输出：

- 功能说明
- 页面入口
- 交互流程
- 状态判断
- 异常提示
- 验收标准

---

## 6. Push 通知需求

请设计 HomeVista 的 Push 通知体系。

---

### 6.1 通知类型

至少包括：

- 新客户咨询通知
- 客户留言通知
- 预约看房提醒
- 报价更新通知
- 房源状态变更通知
- 项目公告通知
- 系统通知
- 任务跟进提醒
- VR / 3D 看房访问提醒

每种通知请说明：

- 触发条件
- 接收角色
- 是否支持项目级开关
- 是否支持用户级开关
- 通知标题
- 通知正文
- 点击跳转地址
- 是否需要脱敏
- 是否需要记录日志

建议输出表格：

| 通知类型 | 触发条件 | 默认接收角色 | 项目级开关 | 用户级开关 | 标题 | 正文 | 跳转地址 | 是否脱敏 | 是否记录日志 |
|---|---|---|---|---|---|---|---|---|---|

---

## 7. 多租户 / 多项目隔离规则

这是重点，请详细设计。

要求明确：

1. 所有通知必须归属于 tenant_id。
2. 所有项目通知必须归属于 project_id。
3. subscription 不能只绑定 user_id。
4. subscription 必须绑定 tenant_id + project_id + user_id + device_id。
5. 发送通知时必须先校验用户是否仍然属于该 tenant / project。
6. 用户退出项目后，不应继续收到该项目通知。
7. 用户没有项目权限时，即使点击旧通知，也不能访问项目数据。
8. 客户 A 的通知不能被客户 B 看到。
9. 项目 A 的通知不能发给项目 B 的成员。
10. 第三方 Push 服务不能作为权限判断依据。

请输出：

- 隔离原则
- 数据边界
- 权限校验规则
- subscription 绑定规则
- 通知发送前校验规则
- 通知点击后校验规则
- 异常场景处理

请明确以下原则：

> HomeVista 决定“谁应该收到通知”，第三方 Push 服务只负责“把通知送达”。

---

## 8. 通知权限与用户偏好

请设计用户通知设置。

包括：

- 当前设备通知状态
- 当前浏览器通知权限
- 当前项目订阅状态
- 开启通知
- 关闭通知
- 按通知类型设置开关
- 按项目设置开关
- 重新订阅
- 当前设备解绑

请说明：

- 设置入口
- 页面字段
- 操作流程
- 保存逻辑
- 异常提示

---

## 9. 通知内容脱敏规则

请设计通知内容规范。

原则：

> Push 通知不应直接展示敏感客户信息、报价金额、房源详细地址、电话号码、客户预算等内容。

推荐通知示例：

- 你有一条新的客户咨询
- 项目报价信息已更新
- 你有一个即将开始的预约
- 项目有新的销售跟进任务

不推荐通知示例：

- 山田太郎咨询了港区 3LDK 1.2 亿日元房源
- 客户手机号 090-xxxx-xxxx
- 报价更新为 88,000,000 日元

请输出：

- 脱敏原则
- 可出现在 Push 中的信息
- 不允许出现在 Push 中的信息
- 各通知类型推荐文案

---

## 10. 通知点击跳转规则

请设计通知点击后的跳转逻辑。

要求：

1. 通知点击后打开 HomeVista PWA。
2. 跳转到对应 tenant / project / business 页面。
3. 如果用户未登录，先进入登录页。
4. 登录后继续跳转目标页面。
5. 如果用户无权限，显示无权限页面。
6. 如果项目已删除或数据不存在，显示数据不存在页面。
7. 如果通知已过期，显示通知已失效提示。

请输出：

- 跳转 URL 结构建议
- 登录态处理
- 权限校验
- 异常页面
- 验收标准

建议 URL 结构示例：

```txt
/app/tenants/{tenantId}/projects/{projectId}/notifications/{messageId}
/app/tenants/{tenantId}/projects/{projectId}/leads/{leadId}
/app/tenants/{tenantId}/projects/{projectId}/appointments/{appointmentId}
```

---

## 11. 通知日志与审计

请设计日志体系。

需要记录：

- tenant_id
- project_id
- message_id
- user_id
- device_id
- subscription_id
- provider
- 通知类型
- 通知标题
- 发送时间
- 发送状态
- 失败原因
- 点击时间
- 操作人

请输出：

- 日志字段
- 日志页面
- 查询条件
- 权限规则
- 审计价值

---

## 12. 非功能需求

请覆盖：

- 安全
- 隐私
- 性能
- 兼容性
- 可用性
- 可扩展性
- 可维护性
- 多语言
- 时区
- 错误处理
- 监控告警

其中兼容性请至少覆盖：

- Android Chrome
- iOS Safari
- Desktop Chrome
- Desktop Edge
- Desktop Safari

---

## 13. MVP 范围

请明确哪些功能进入第一期。

建议 MVP 包括：

1. PWA manifest
2. Service Worker
3. 添加到桌面
4. iOS 添加到主屏幕引导
5. 通知权限申请
6. subscription 保存
7. tenant_id + project_id + user_id + device_id 绑定
8. 新客户咨询通知
9. 项目公告通知
10. 通知点击跳转
11. 用户关闭通知
12. 基础发送日志

请同时列出暂不做的功能：

- 复杂营销推送
- A/B 测试
- 定时群发
- 完整运营统计
- 多语言通知模板管理
- 高级自动化规则

---

## 14. 验收标准

请按模块输出验收标准：

- PWA 安装验收
- Push 权限验收
- subscription 管理验收
- 多租户隔离验收
- 通知发送验收
- 通知点击跳转验收
- 通知设置验收
- 日志审计验收
- 兼容性验收
- 安全验收

每个模块请输出明确的 Given / When / Then 或可测试标准。

---

# 四、第二部分：CRM / Notification 管理后台原型要求

请输出一套后台原型说明，作为 UI / 前端开发参考。

---

## 1. 后台模块结构

请设计 HomeVista CRM 中的通知管理模块。

建议菜单结构：

```txt
HomeVista CRM
├── 项目管理
├── 成员管理
├── 客户线索
├── 销售跟进
├── 预约管理
├── 报价管理
├── 通知中心
│   ├── 通知概览
│   ├── 通知规则
│   ├── 通知模板
│   ├── 用户订阅
│   ├── 设备管理
│   ├── 发送记录
│   └── 系统设置
└── 审计日志
```

请说明每个菜单的功能。

---

## 2. 通知概览页面

请设计字段和布局。

需要展示：

- 今日发送数量
- 发送成功数量
- 发送失败数量
- 点击数量
- 当前活跃订阅设备数
- 各项目通知量
- 各通知类型分布
- 最近发送记录

请输出：

- 页面目标
- 页面布局
- 数据卡片
- 图表
- 表格字段
- 筛选条件
- 操作按钮

低保真原型格式示例：

```txt
页面名称：通知概览

顶部区域：
[项目选择器] [时间范围] [刷新按钮]

数据卡片：
[今日发送] [成功率] [失败数] [点击数] [活跃设备数]

图表区域：
左侧：通知类型分布
右侧：项目发送趋势

表格区域：
| 时间 | 项目 | 类型 | 标题 | 接收人 | 状态 | 操作 |
```

---

## 3. 通知规则页面

用于配置不同项目的通知触发规则。

需要支持：

- 按项目配置
- 按通知类型配置
- 按角色配置接收人
- 是否启用
- 是否必须脱敏
- 是否允许用户关闭

字段建议：

- 规则名称
- tenant
- project
- 通知类型
- 触发事件
- 接收角色
- 是否启用
- 是否允许用户关闭
- 创建人
- 更新时间

请输出：

- 页面说明
- 列表字段
- 新增规则弹窗
- 编辑规则弹窗
- 启用 / 禁用操作
- 权限限制

---

## 4. 通知模板页面

用于管理 Push 文案模板。

需要支持：

- 模板名称
- 通知类型
- 标题模板
- 正文模板
- 跳转 URL 模板
- 是否脱敏
- 可用变量
- 预览

要求：

> 敏感变量默认不允许直接用于 Push 文案。

请输出：

- 页面说明
- 模板字段
- 可用变量设计
- 禁用变量设计
- 预览效果
- 保存校验规则

---

## 5. 用户订阅页面

用于查看某个项目下用户的订阅状态。

字段包括：

- 用户姓名
- 角色
- tenant
- project
- 通知权限状态
- 项目订阅状态
- 开启的通知类型
- 最后订阅时间
- 最后活跃时间
- 设备数量

操作包括：

- 查看设备
- 关闭项目订阅
- 重新发送授权引导
- 查看发送记录

请输出：

- 页面说明
- 列表字段
- 筛选条件
- 操作按钮
- 权限规则

---

## 6. 设备管理页面

用于管理 subscription。

字段包括：

- 设备 ID
- 用户
- tenant
- project
- 浏览器
- 系统
- provider
- endpoint / token 脱敏展示
- 是否有效
- 最后成功发送时间
- 最后失败时间
- 创建时间

操作包括：

- 禁用设备
- 删除失效 subscription
- 查看发送记录

请输出：

- 页面说明
- 字段
- 状态
- 操作
- 安全注意事项

---

## 7. 发送记录页面

需要支持查询和审计。

字段包括：

- 发送时间
- tenant
- project
- 通知类型
- 通知标题
- 接收用户
- 设备
- provider
- 发送状态
- 失败原因
- 是否点击
- 点击时间

筛选条件：

- 时间范围
- tenant
- project
- 通知类型
- 发送状态
- 用户
- provider

请输出：

- 页面说明
- 表格字段
- 筛选区
- 详情页
- 导出规则
- 权限限制

---

## 8. 系统设置页面

用于配置 Push Provider。

字段包括：

- 当前 Provider
- Provider 名称
- API Key
- App ID
- VAPID Public Key
- VAPID Private Key
- 是否启用
- 测试发送

要求：

- Secret 信息必须脱敏显示
- 只有平台超级管理员可配置
- 支持 provider adapter，未来可切换

请输出：

- 页面说明
- 字段
- 操作流程
- 权限限制
- 安全规则

---

## 9. 用户端通知设置页面

除了 CRM 后台，也需要设计普通用户在 HomeVista 前台的通知设置页。

页面包含：

- 当前设备通知权限
- 当前项目订阅状态
- 开启 / 关闭当前项目通知
- 通知类型开关
- 当前设备信息
- 解绑当前设备
- 添加到桌面引导

请输出：

- 页面布局
- 字段
- 按钮
- 状态文案
- 异常提示

---

## 10. 原型输出格式要求

请用文字方式输出低保真原型。

格式示例：

```txt
页面名称：通知概览

顶部区域：
[项目选择器] [时间范围] [刷新按钮]

数据卡片：
[今日发送] [成功率] [失败数] [点击数] [活跃设备数]

图表区域：
左侧：通知类型分布
右侧：项目发送趋势

表格区域：
| 时间 | 项目 | 类型 | 标题 | 接收人 | 状态 | 操作 |
```

每个页面都请按这种结构输出。

---

# 五、第三部分：技术边界和接口建议

请在文档最后补充技术建议。

---

## 1. 核心数据表建议

至少包括：

- push_subscriptions
- notification_preferences
- notification_rules
- notification_templates
- notification_messages
- notification_deliveries
- notification_clicks
- provider_configs
- audit_logs

请输出每张表的核心字段。

---

## 2. 核心 API 建议

至少包括：

- POST /api/push/subscribe
- POST /api/push/unsubscribe
- GET /api/notification/preferences
- PUT /api/notification/preferences
- GET /api/admin/notification/rules
- POST /api/admin/notification/rules
- PUT /api/admin/notification/rules/:id
- GET /api/admin/notification/deliveries
- POST /api/admin/notification/test-send
- POST /api/internal/notification/events

每个 API 请说明：

- 用途
- 请求参数
- 返回结果
- 权限要求
- 是否需要 tenant_id / project_id

---

## 3. 业务事件建议

请定义事件驱动模型。

至少包括：

- lead.created
- message.created
- appointment.created
- appointment.reminder
- quote.updated
- property.status_changed
- project.announcement_created
- task.due_soon
- vr_view.opened

每个事件说明：

- 触发来源
- payload 字段
- 默认接收角色
- 默认通知模板
- 是否 MVP

---

# 六、输出要求

请使用中文输出。

文档风格要求：

- 结构清晰
- 适合产品和研发评审
- 不要只写概念，要写可执行需求
- 多租户、多项目隔离是重点
- 第三方 Push 只作为通道，不承担权限判断
- 所有涉及通知发送的流程都必须包含 tenant_id 和 project_id
- Push 内容必须默认脱敏
- PRD 和 CRM 原型都要覆盖

最终请输出：

1. 完整 PRD
2. CRM / Notification 管理后台低保真原型
3. 用户端通知设置页低保真原型
4. 数据表建议
5. API 建议
6. MVP 范围
7. 验收标准

不要只给大纲，请尽量写成可直接评审的产品需求文档。