| 项目 | 内容 |
|---|---|
| 文档名称 | 房屋租赁 SaaS 平台产品需求文档 |
| 版本 | V1.0 |
| 状态 | 待评审 |
| 日期 | 2026-10-18 |
| 适用范围 | 全平台（房源/合同/收租/物业/工单/IoT/AR/Agent/商城） |
| 读者 | 甲方与业务方、产品、研发、测试、运营 |
| 配套文档 | 《阿里云分布式架构》《数据库设计》《部署与不停机升级》 |
面向租赁运营企业的多租户 SaaS 平台，覆盖从房源获取、招租签约、收租履约、物业服务到租客生活的全生命周期管理，并通过智能硬件（数字家庭）、AR 看房与 AI Agent 能力提升运营效率与租客体验。
一句话定位：让租赁运营商用一套系统管好房源、租客、钱和房子里的设备。
| 用户类型 | 典型画像 | 核心诉求 |
|---|---|---|
| 租赁运营公司（主要付费方） | 集中式公寓、分散式包租、二房东 | 提高出租率、降低空置、规范收租、减少人力 |
| 物业公司 | 承接小区物业服务 | 工单闭环、报修响应、巡检留痕 |
| 房东/业主 | 个人或多套房持有者 | 看清收益、透明账单、少操心 |
| 租客（C 端） | 城市白领、学生、企业员工 | 找房快、线上签约、报修方便、缴费省事 |
| 平台运营方 | 我方团队 | 多租户管理、计费、数据看板、风控 |
| 价值点 | 量化目标 |
|---|---|
| 提升出租率 | 通过短租/长租一体化 + OTA 渠道分发，空置率降低 10%+ |
| 降低收租成本 | 线上支付 + Agent 自动催缴，人工催收工作量降低 60% |
| 缩短招租周期 | AR 看房 + 多渠道同步，看房转化提升，招租周期缩短 30% |
| 减少现场人力 | 智能门锁临时密码 + 远程抄表，管家现场跑动减少 50% |
| 提升续租率 | 工单闭环 + 服务响应 SLA，租客满意度提升 |
| 指标 | 目标值 | 说明 |
|---|---|---|
| 房源规模 | 100 万间 | 支撑百万级 |
| 租客规模 | 1000 万人 | 千万级 |
| 账单量 | 1 亿/年 | 需分区 |
| 支持租户数 | 5000+ 家 | 多租户共享集群 |
| 系统可用性 | 99.95% | 年停机 ≤ 4.4 小时 |
| 停机维护 | 不允许 | 灰度发布，滚动升级 |
| 接口响应 | P99 < 500ms | 核心查询 |
| 收租成功率 | > 99.5% | 含第三方支付 |
| 不做 | 原因 |
|---|---|
| 自建电子签章平台 | 法律效力风险，接第三方 |
| 自研 AR 拍摄/建模算法 | 重资产、专业门槛高，接第三方拍摄能力 |
| 自建支付通道 | 需金融牌照，接第三方支付 |
| 自研智能硬件 | 接第三方设备厂商，我方做接入与管理 |
| 房产中介的二手房交易撮合 | 非租赁业务范围 |
平台方（我方）
└── 平台运营 / 平台管理员 / 平台客服
│
└── 租户（运营公司/物业公司）
├── 租户管理员（企业主）
├── 区域经理 / 店长
├── 管家（房源运营）
├── 维修工 / 保洁（服务人员）
├── 财务（收租/对账/开票）
├── 房东（业主，只读+收益）
└── 租客（C 端）权限维度：查看(R) / 新建(C) / 修改(U) / 删除(D) / 审批(A) / 导出(E)
| 功能域 | 平台运营 | 平台管理员 | 平台客服 |
|---|---|---|---|
| 租户开通/停用 | R,U,A | R,C,U,D,A | R |
| 套餐与计费 | R,U | R,C,U,D,A | — |
| 全平台数据看板 | R,E | R,E | R |
| 租户数据访问（代客排查） | R（需审计） | R（需审计） | R（需审计） |
| 风控黑名单 | R,U | R,C,U,D | R |
| 系统配置与灰度开关 | R | R,U,A | — |
⚠️ 平台方访问租户数据必须留审计日志，且需要租户授权或工单凭据。
| 功能域 | 租户管理员 | 区域经理/店长 | 管家 | 财务 | 房东 |
|---|---|---|---|---|---|
| 房源管理（楼盘/房间） | R,C,U,D | R,C,U | R,U | R | R（仅自己房产） |
| 房源状态变更 | R,U | R,U | R,U | — | — |
| 租客档案 | R,C,U,D | R,C,U | R,C,U | R | — |
| 合同签约/续租/退租 | R,A | R,C,U,A | R,C,U | R | R（仅自己房产） |
| 账单生成 | R,U | R | R | R,U | R（仅收益） |
| 收款与核销 | R | R | R | R,C,U | — |
| 退款审批 | R,A | R,A | — | R,C | — |
| 发票管理 | R | R | — | R,C,U | — |
| 工单处理 | R | R,U,A | R,U | R | R（仅自己房产） |
| 设备管理 | R,C,U,D | R,U | R,U | — | — |
| 门锁密码下发 | R,A | R,A | R,C,U | — | — |
| 报表导出 | R,E | R,E | — | R,E | R,E（仅自己） |
| 员工与权限 | R,C,U,D | R（仅下属） | — | — | — |
| 功能 | 维修工 | 保洁 |
|---|---|---|
| 查看指派给自己的工单 | R | R |
| 更新工单状态（接单/处理/完成） | U | U |
| 上传现场照片 | C | C |
| 申请门锁临时权限 | C | C |
| 查看租客联系方式 | 仅处理中工单内 | 仅处理中工单内 |
数据权限原则：服务人员只能看到"与当前任务相关"的信息，工单完成后即失去访问权。
| 功能 | 说明 |
|---|---|
| 找房/看房 | 地图选房、条件筛选、AR 看房、在线预约 |
| 在线签约 | 实名认证、电子签章、在线支付押金租金 |
| 账单缴费 | 查看账单、在线支付、电子发票 |
| 报修 | 提交工单、上传照片、查看进度、评价 |
| 智能家居 | 门锁开锁、查看水电用量 |
| 我的租约 | 合同查看、续租申请、退租申请 |
| 规则 | 说明 |
|---|---|
| 租户隔离 | 租户之间数据完全不可见（数据库层强制） |
| 楼盘级授权 | 可将员工限定到指定楼盘/楼栋 |
| 房源级授权 | 管家可限定到具体房间 |
| 房东只读 | 房东仅可见自己名下房产及其收益，不可见其他 |
| 租客自助 | 租客仅可见自己的合同、账单、工单 |
| 跨租户租客身份 | ⚠️ 租客的信用与黑名单信息跨租户共享（风控需要），但合同与账单严格隔离 |
跨租户租客身份共享需在合同中明确告知并获得授权，这是合规红线。
房源获取 → 房源上架 → 招租（多渠道） → 看房（线上/AR/线下）
→ 签约（实名+签章+押金） → 入住交割（抄表+交钥匙+门锁授权）
→ 居住期（缴费/报修/智能家居/续租） → 退租交割 → 押金结算 → 房源再上架| 模块 | 范围 |
|---|---|
| 平台与租户 | 租户开通、套餐、账号、角色权限、数据权限 |
| 房源管理 | 楼盘/楼栋/单元/楼层/房间、状态机、图片、价格 |
| 租客与合同 | 租客档案、实名认证、合同签约/续租/退租、电子签章 |
| 收租 | 账单生成、在线支付、核销、催缴、押金管理、发票 |
| 物业工单 | 报修、派单、处理、评价、SLA |
| 报表 | 出租率、收入、逾期、工单 |
V1.0 不包含：AR 看房、智能家居、Agent、OTA、商城直播团购（但预留接口与数据结构）
| 模块 | 范围 |
|---|---|
| AR 看房 | 全景漫游、热点、在线带看 |
| 数字家庭 IoT | 智能门锁、水电表、设备影子、场景联动 |
| OTA 渠道 | 携程/美团/飞猪库存同步、订单接收 |
| 短租 | 间夜库存、日历房态、动态定价 |
| 移动端 | 管家 App、租客小程序 |
| 模块 | 范围 |
|---|---|
| AI Agent | 智能客服、自动催收、报修受理、智能推荐 |
| 商城 | 生活服务商品、订单 |
| 直播/团购 | 直播看房、团购券 |
| 开放平台 | 对外 API、第三方开发者接入 |
| 阶段 | 周期 | 交付物 |
|---|---|---|
| M1 需求与设计 | 3 周 | PRD、架构设计、数据库设计、UI 原型 |
| M2 核心开发 | 8 周 | 房源/合同/收租主流程 |
| M3 联调与集成 | 4 周 | 支付、签章、短信对接完成 |
| M4 试点 | 4 周 | 1~2 个楼盘真实跑通 |
| M5 上线 | 2 周 | 正式上线 V1.0 |
编号规则：
模块缩写-序号，如RM-001（Room Management）。
优先级：P0 = 必须（V1.0 上线阻塞）；P1 = 重要（V1.0 尽量）；P2 = 一般（可延后）
描述：平台方为一家运营公司开通租户账号。
字段需求：
| 字段 | 必填 | 说明 |
|---|---|---|
| 企业名称 | 是 | |
| 统一社会信用代码 | 是 | 用于校验企业真实性 |
| 租户编码 | 是 | 全局唯一，系统生成或自定义 |
| 联系人/电话 | 是 | |
| 套餐类型 | 是 | 基础版/专业版/旗舰版 |
| 有效期 | 是 | 到期自动提醒，超期冻结 |
| 房源数量上限 | 是 | 按套餐限制 |
业务规则：
验收标准：
描述：租户管理员为本企业员工分配账号与角色。
业务规则：
描述：平台按房源数量或功能模块向租户收费。
业务规则：
描述：记录所有关键操作，支持追溯。
必须记录的操作：
字段：操作人、时间、IP、操作类型、操作对象、变更前后值
验收标准：
描述：建立房源的物理层级结构。
层级：楼盘 → 楼栋 → 单元 → 楼层 → 房间
字段需求（楼盘）：
| 字段 | 必填 | 说明 |
|---|---|---|
| 楼盘名称 | 是 | |
| 楼盘编码 | 是 | 租户内唯一 |
| 省/市/区/详细地址 | 是 | |
| 经纬度 | 是 | 地图选房必需，支持地址解析获取 |
| 租赁形态 | 是 | 长租/短租/混合 |
| 总房间数 | 自动 | 由房间汇总 |
| 配套设施 | 否 | 健身房、泳池、停车位等 |
| 封面图 | 是 |
业务规则：
描述：房间是可出租的最小单元。
字段需求：
| 字段 | 必填 | 说明 |
|---|---|---|
| 房号 | 是 | 楼盘内唯一 |
| 房间类型 | 是 | 整租/合租 |
| 租赁形态 | 是 | 长租/短租 |
| 建筑面积 / 使用面积 | 是 | ㎡ |
| 户型 | 是 | 如一室一厅 |
| 朝向 | 否 | |
| 装修档次 | 否 | 毛坯/简装/精装/豪装 |
| 挂牌价 | 是 | 长租为月租，短租为日租 |
| 床位数 | 合租必填 | 合租时房间拆分为床位 |
| 配套设施 | 否 | 空调/洗衣机/冰箱/宽带等 |
| 房源照片 | 是 | 至少 3 张，支持封面 |
| 视频 | 否 | |
| AR 场景 | 否 | V2.0 |
| 扩展属性 | 否 | 自定义字段（如"带阳台""近地铁"） |
房间状态机（核心）：
┌──────────────────────────────────┐
│ │
┌──▼───┐ 挂牌 ┌──────────┐ 签约 ┌──────────┐
│ 空置 │───────>│ 预定中 │──────>│ 在租中 │
└──┬───┘ └────┬─────┘ └────┬─────┘
│ │ 取消/超时 │ 退租
│ └──────┐ │
│ 维修/停用 ▼ ▼
└──────>┌─────────┐ ┌──────┐ ┌──────┐
│ 维修中 │ │ 空置 │<──│ 空置 │
└────┬────┘ └──────┘ └──────┘
│ 维修完成
└──────> 空置业务规则：
合租场景规则（重要，易被忽略）：
合租房间内按床位分别出租，每个床位可独立签约与收租。
| 编号 | 规则 |
|---|---|
| BR-PM-10 | 合租房间拆分为若干床位，每个床位有独立状态与价格 |
| BR-PM-11 | 床位的出租与占用独立判定：同一房间内 A 床可已租、B 床仍空置 |
| BR-PM-12 | 房间整体状态由床位汇总推导：全部空置=空置；部分在租=在租（仅部分）；全部在租=满租 |
| BR-PM-13 | 房间挂牌价在合租时取各床位价格之和（用于展示与统计） |
| BR-PM-14 | 床位签约后生成独立合同与独立账单，租客之间互不影响 |
| BR-PM-15 | 公共区域费用（水电、保洁）按人数或面积分摊，分摊规则可配置 |
为什么单列这条：合租是国内长租公寓的主流形态之一。
若把房间当作不可分割的整体出租，会导致"一间房只能租给一个人"，
直接损失一半出租能力。研发必须按床位粒度实现占用与结算。
验收标准：
描述：支持 Excel 批量导入房间，适应运营商已有台账。
要求：
验收标准：
描述：以楼栋/楼层为维度，可视化展示所有房间状态（类似酒店房态图）。
要求：
车位作为可单独出租的资产，含车位号、类型、状态、价格。
描述：管理租客（自然人）与企业租客信息。
字段需求（个人）：
| 字段 | 必填 | 说明 |
|---|---|---|
| 姓名 | 是 | |
| 证件类型 | 是 | 身份证/护照/港澳通行证 |
| 证件号码 | 是 | 加密存储，全局查重 |
| 手机号 | 是 | 唯一 |
| 性别 / 生日 | 否 | 可从身份证解析 |
| 紧急联系人 | 否 | 姓名、关系、电话 |
| 职业/工作单位 | 否 | |
| 实名认证状态 | 自动 | 未认证/审核中/已认证/失败 |
| 标签 | 否 | 如"优质租客""曾逾期" |
业务规则：
330***********1234）⚠️ 合规红线：
描述：租客签约前需完成实名认证。
流程：
上传证件照 → OCR 识别 → 活体检测/人脸比对 → 权威源核验 → 认证结果要求：
验收标准：
字段：企业名称、统一社会信用代码、法人、联系人、营业执照。
业务规则：
描述：记录租客履约行为，支持跨租户查询。
信用信息包含：
业务规则：
验收标准：
记录与租客的电话、短信、微信、现场沟通内容，形成完整服务档案。
描述：创建租赁合同，完成多方在线签署。
字段需求：
| 字段 | 必填 | 说明 |
|---|---|---|
| 合同编号 | 自动 | 按规则生成 |
| 合同类型 | 是 | 长租/短租 |
| 房源 | 是 | 可多选（一合同多房间） |
| 承租方 | 是 | 个人或企业 |
| 共租人 | 否 | 多人合租时填写 |
| 担保人 | 否 | |
| 出租方 | 是 | 公司或个人 |
| 租期起止 | 是 | |
| 租金 | 是 | 支持每房间不同租金 |
| 付款周期 | 是 | 月付/季付/半年付/年付 |
| 押金 | 是 | 通常 1~2 个月租金 |
| 免租期 | 否 | |
| 递增条款 | 否 | 如每年递增 5% |
| 其他费用 | 否 | 物业费、停车费、宽带费 |
| 附件 | 否 |
签约流程：
① 创建合同（草稿）
② 填写信息、选择房间
③ 生成合同 PDF
④ 发起电子签署（租客 + 出租方）
⑤ 租客实名认证 + 签署
⑥ 出租方签章
⑦ 签署完成 → 合同生效 → 房间状态改为"在租"
⑧ 生成首期账单（含押金）业务规则：
HT+年月+序号）验收标准：
变更类型：
| 类型 | 说明 | 对账单影响 |
|---|---|---|
| 续租 | 延长租期 | 生成新账期账单 |
| 换房 | 更换房间 | 原房间释放，新房间占用 |
| 改价 | 调整租金 | 从生效日起按新价生成 |
| 变更当事人 | 增加/减少共租人 | 需重新签署 |
| 提前退租 | 提前终止 | 结算押金与违约金 |
业务规则：
验收标准：
描述：租客入住时记录房屋状况与水电底数。
记录内容：
业务规则：
描述：租客退租时办理交割与押金结算。
流程：
① 租客提交退租申请（或到期自动提醒）
② 约定退租日期
③ 退租交割：抄表、检查房屋状况、收回钥匙
④ 计算费用：未缴租金 + 水电费 + 损坏赔偿 - 押金
⑤ 押金退还（可部分扣除）
⑥ 合同终止，房间状态改为"空置"（或"维修中"）业务规则：
验收标准：
描述：按合同与账期自动生成账单。
账单类型：租金、押金、水电费、物业费、停车费、违约金、其他
生成方式：
| 方式 | 场景 |
|---|---|
| 定时自动生成 | 每月固定日期（如每月 25 日生成下月账单） |
| 手动生成 | 补生成、特殊账单 |
| 事件触发 | 合同生效生成首期账单；入住生成押金账单 |
| 抄表触发 | 抄表后生成水电账单 |
业务规则：
验收标准：
支持渠道：支付宝、微信支付、（银联可选）
流程：
① 租客在账单页点击"去支付"
② 选择支付方式
③ 跳转支付（H5/小程序/App）
④ 支付完成 → 第三方回调 → 系统核销 → 账单状态更新
⑤ 通知租客"缴费成功"业务规则：
验收标准：
描述：一笔收款可核销多张账单，一张账单可被多笔收款核销。
支持的核销场景：
| 场景 | 示例 |
|---|---|
| 一次付清一张账单 | 最常规 |
| 一次付清多张账单 | 租客一次付 3 个月房租 |
| 多次分付一张账单 | 租客分 2 次付清 1 个月房租（部分核销） |
| 预收款 | 租客多付，余额留作后续 |
| 冲正 | 收错钱，需回滚核销 |
业务规则：
验收标准：
催缴策略（可配置）：
| 阶段 | 时间 | 动作 |
|---|---|---|
| 提醒 | 账单生成日 | 站内信 + 短信 |
| 到期提醒 | 到期日 | 短信 + Push |
| 逾期 1 天 | T+1 | 短信 + 电话（管家） |
| 逾期 7 天 | T+7 | 加收滞纳金 + 上门 |
| 逾期 30 天 | T+30 | 法务介入流程 |
| 逾期 90 天 | T+90 | 清退流程 |
业务规则：
押金生命周期：应收 → 已收（代管） → 退还 / 部分退还 / 全额扣除
业务规则：
要求：
日报表：当日收款总额、分渠道金额、核销明细
月报表：月度收入、应收/实收/欠费、开票金额
对账：与支付渠道逐笔核对，差异必须处理
验收标准：
描述：租客提交报修，管家受理并派单。
创建渠道：租客 App/小程序、电话（管家代录）、现场、设备告警自动创建、Agent 受理
字段需求：
| 字段 | 必填 | 说明 |
|---|---|---|
| 报修类型 | 是 | 水电/门窗/家具/家电/网络/其他 |
| 问题描述 | 是 | |
| 照片/视频 | 建议 | 便于判断问题 |
| 期望上门时间 | 否 | |
| 紧急程度 | 是 | 一般/紧急/特急 |
工单状态机：
待受理 → 已派单 → 已接单 → 处理中 → 待确认 → 已完成 → 已关闭
│ │ │ │
└─取消───┴────────┴───────取消──────┘业务规则：
派单方式：
业务规则：
SLA 指标：响应时限、上门时限、完工时限
要求：
支持设备类型：智能门锁、智能电表、智能水表、烟感、温湿度传感器、摄像头、空调控制器
字段需求：设备编号、型号、类型、所属房间、状态（在线/离线/故障）、固件版本、最后心跳时间
业务规则：
场景：
| 使用者 | 权限类型 | 有效期 |
|---|---|---|
| 租客 | 密码/指纹/App 开锁 | 租期内 |
| 保洁 | 临时密码 | 2 小时（一次性） |
| 维修工 | 临时密码 | 工单处理期间 |
| 看房客户 | 临时密码 | 1 小时 |
业务规则：
验收标准：
要求：
业务规则：
如"离家模式"：关闭所有灯、空调，门锁布防。
描述：租客在线上即可沉浸式看房。
功能：
业务规则：
描述：运营人员上传拍摄素材，配置场景。
要求：
业务规则：
经纪人远程讲解 + 租客同步浏览，支持实时语音。
能力：
业务规则：
⚠️ Agent 能力的边界（必须在 PRD 中明确）：
本模块为规划预留，详细需求待 V3.0 阶段细化。此处仅说明业务方向与约束。
| 风险 | 应对 |
|---|---|
| 流量冲击主业务 | 物理隔离 + 独立限流 |
| 库存超卖（秒杀） | Redis 预扣 + MQ 削峰，不用数据库行锁 |
| 与租赁业务的账务交叉 | 独立账套，定期汇总 |
本节是研发与测试的重点，规则冲突时以本节为准。
| 编号 | 规则 | 违反后果 |
|---|---|---|
| CR-01 | 同一房间同一时间段不能被两份生效合同占用 | 一房两租，重大纠纷 |
| CR-02 | 账单核销总额不得超过应收金额 | 财务账实不符 |
| CR-03 | 同一支付交易号不得重复入账 | 重复记账，资损 |
| CR-04 | 账单生成必须幂等 | 重复账单，租客投诉 |
| CR-05 | 合同变更必须留痕，不可直接修改原记录 | 法律纠纷时无法举证 |
| CR-06 | 短租库存扣减必须原子操作 | 超卖，客人到场无房 |
| CR-07 | 金额计算必须用整数（分） | 浮点误差，对账不平 |
| CR-08 | 所有涉及资金的写操作必须幂等 | 重复退款，资损 |
| 对象 | 状态流转约束 |
|---|---|
| 房间 | 空置↔维修中；空置→预定中→在租中；在租中→空置（仅退租） |
| 合同 | 草稿→待签→生效→变更中/已到期/已解约；生效后不可回草稿 |
| 账单 | 待缴→部分缴→已缴清；待缴→逾期；任何状态→作废（需审批） |
| 工单 | 待受理→已派单→已接单→处理中→待确认→已完成→已关闭 |
| 支付单 | 已创建→支付中→已支付→退款中→已退款 |
| OTA 订单 | 已接收→已确认/已拒单→已入住→已离店 |
| 编号 | 规则 |
|---|---|
| TR-01 | 所有跨天计算以租户所在时区为准（默认 Asia/Shanghai） |
| TR-02 | 账单账期按自然月计算，跨月按天拆分 |
| TR-03 | 短租间夜：入住日计入，离店日不计入 |
| TR-04 | 预定状态超时时间可配置（默认 24 小时） |
| TR-05 | 工单自动确认超时（默认 48 小时） |
| TR-06 | 合同到期提醒：60/30/15/7 天 |
| 事件 | 通知对象 | 渠道 |
|---|---|---|
| 账单生成 | 租客 | 站内信 + 短信 |
| 账单到期前 3 天 | 租客 | 短信 + Push |
| 逾期 | 租客 + 管家 | 短信 + 电话 |
| 支付成功 | 租客 + 财务 | 站内信 |
| 工单派单 | 服务人员 | App Push + 短信 |
| 工单完成 | 租客 | Push |
| 合同到期提醒 | 租客 + 管家 | 短信 |
| 设备离线 | 管家 | 站内信 |
| 场景 | 指标 |
|---|---|
| 房源列表查询 | P99 < 500ms |
| 房源详情 | P99 < 300ms |
| 账单列表 | P99 < 500ms |
| 支付下单 | P99 < 1s |
| 合同签约发起 | P99 < 2s |
| 报表查询 | P95 < 3s（复杂报表可异步） |
| 批量导入 1000 行 | < 30s |
| 月账单批量生成 1000 合同 | < 5min |
| 指标 | 目标 |
|---|---|
| 系统可用性 | 99.95%（年停机 ≤ 4.4h） |
| 支付链路可用性 | 99.9% |
| 数据库主备切换 | < 60s（有短暂闪断） |
| 计划内维护 | 不停机（灰度 + 滚动升级） |
| 故障恢复（RTO） | < 30min |
| 数据恢复点（RPO） | < 5min |
| 类别 | 要求 |
|---|---|
| 传输加密 | 全站 HTTPS（TLS 1.2+） |
| 存储加密 | 证件号、银行卡、密钥加密存储（KMS） |
| 密码策略 | 至少 8 位，含字母数字，90 天更换 |
| 登录安全 | 密码错误 5 次锁定；敏感操作二次验证 |
| 权限控制 | RBAC + 数据权限，最小权限原则 |
| 操作审计 | 关键操作全留痕，日志不可篡改 |
| 数据脱敏 | 证件号、手机号中间位脱敏展示 |
| 防爬防刷 | WAF + 接口限流（房源数据是爬虫重点目标） |
| 合规 | 个人信息保护法（PIPL）；等保三级（建议） |
| 端 | 要求 |
|---|---|
| B 端 Web | Chrome/Edge/Firefox 最新两个版本；1920×1080 起 |
| 租客小程序 | 微信小程序 |
| 租客 App | iOS 14+、Android 8+（V2.0） |
| 管家 App | iOS 14+、Android 8+（V2.0） |
| 要求 | 说明 |
|---|---|
| 数据保存期限 | 合同及相关记录保存至少合同结束后 3 年（法律要求） |
| 个人信息删除 | 支持租客行使删除权（法务确认保留例外） |
| 数据导出 | 租户可导出自己的全部数据（防止被平台锁定） |
| 异地备份 | 每日备份，异地保留 30 天 |
| 审计留存 | 操作日志保留至少 1 年 |
| 类别 | 供应商（建议） | 用途 | 优先级 |
|---|---|---|---|
| 支付 | 支付宝、微信支付 | 收租、押金、退款 | P0 |
| 电子签章 | 法大大 / e签宝 / 上上签 | 合同签署 | P0 |
| 实名认证 | 阿里云实人认证 | 租客实名 | P0 |
| 短信 | 阿里云短信 | 通知、验证码 | P0 |
| 地图 | 高德地图 | 地图选房、位置服务 | P0 |
| 电子发票 | 百望 / 航信 | 发票开具 | P1 |
| OTA | 携程、美团、飞猪 | 渠道分销 | P2 |
| 第三方 AR | 贝壳如视 / 众趣 | AR 拍摄与建模 | P2 |
| 智能硬件 | 门锁、水电表厂商 | IoT 设备 | P2 |
| Push | 极光 / 厂商通道 | App 推送 | P1 |
| 编号 | 要求 | 原因 |
|---|---|---|
| IN-01 | 所有外部调用必须设超时（默认 10s） | 防止线程耗尽 |
| IN-02 | 所有外部调用必须支持重试（指数退避） | 应对网络抖动 |
| IN-03 | 所有回调处理必须幂等 | 第三方会重复回调 |
| IN-04 | 回调必须先落库再处理 | 防止处理崩溃丢数据 |
| IN-05 | 必须记录完整调用日志（请求/响应/耗时） | 排查与计费 |
| IN-06 | 必须有降级方案（第三方不可用时） | 保证主流程可用 |
| IN-07 | 支付必须日终对账 | 发现账实不符 |
| IN-08 | 密钥必须加密存储（KMS），不得硬编码 | 安全红线 |
| 依赖 | 不可用时的降级方案 |
|---|---|
| 短信 | 改用站内信 + Push，记录待发队列 |
| 支付 | 提示稍后重试，支持线下转账人工核销 |
| 签章 | 转线下纸质签约流程 |
| 实名认证 | 转人工审核 |
| 地图 | 降级为文本地址选择 |
| OTA | 停止订单接收，改为人工确认 |
| AR | 降级为图片+视频看房 |
| 报表 | 指标 | 更新频率 |
|---|---|---|
| 出租率分析 | 出租率、空置房间数、按楼盘/户型分布 | 每日 |
| 收入报表 | 应收/实收/欠费、按费用类型、同比环比 | 每日 |
| 现金流报表 | 收款流水、押金余额、退款 | 每日 |
| 房源周转 | 平均空置天数、招租周期、续租率 | 每周 |
| 报表 | 指标 |
|---|---|
| 账单催缴清单 | 逾期房间、租客、金额、逾期天数 |
| 工单统计 | 工单量、响应时长、完成率、满意度 |
| 房源动态 | 新签、退租、维修中房间 |
| 设备状态 | 在线率、故障设备、异常告警 |
| 报表 | 指标 |
|---|---|
| 收款日报/月报 | 分渠道金额、核销明细 |
| 对账报表 | 与支付渠道差异明细 |
| 发票报表 | 已开票金额、待开票 |
| 押金台账 | 代管押金总额、待退、已退 |
| 报表 | 指标 |
|---|---|
| 我的账单 | 已缴、待缴、逾期 |
| 我的合同 | 租期、租金、押金 |
| 能耗明细 | 水电用量与费用趋势 |
| 看板 | 使用人 | 核心内容 |
|---|---|---|
| 平台总览 | 平台运营 | 租户数、房源总量、GMV、活跃度 |
| 租户经营看板 | 租户管理员 | 出租率、收入、欠费、工单 |
| 管家工作台 | 管家 | 我的房间、待办、今日工单 |
| 财务工作台 | 财务 | 今日收款、待核销、待开票、对账异常 |
技术要求：看板数据不可实时聚合主库（性能考虑），需预聚合或走独立分析库。
| 模块 | 验收项 | 通过标准 |
|---|---|---|
| 房源 | 楼盘/房间 CRUD | 全流程可用 |
| 房源 | 房间状态机 | 非法流转被拒绝 |
| 房源 | 批量导入 1000 行 | 30 秒内完成，错误有提示 |
| 租客 | 档案与实名 | 认证成功率 > 95% |
| 合同 | 在线签约 | 签署完成可下载含签章 PDF |
| 合同 | 续租/退租 | 流程完整，状态正确 |
| 收租 | 账单生成 | 1000 合同 5 分钟内完成且幂等 |
| 收租 | 在线支付 | 支持支付宝/微信，核销正确 |
| 收租 | 部分核销 | 多付/分付场景正确 |
| 收租 | 退款 | 审批流 + 核销回滚正确 |
| 收租 | 对账 | 日终对账差异可查可处理 |
| 工单 | 全流程 | 报修→派单→处理→评价闭环 |
| 工单 | 状态留痕 | 每步可追溯 |
| 权限 | 租户隔离 | A/B 租户数据完全不可见 |
| 权限 | 角色权限 | 各角色只能做授权范围内操作 |
| 审计 | 关键操作 | 可查到谁在何时改了什么 |
| 项 | 验收方法 | 通过标准 |
|---|---|---|
| 性能 | 压测（100 并发） | P99 < 500ms（核心查询） |
| 可用性 | 故障演练 | 单节点故障不影响服务 |
| 不停机升级 | 灰度发布演练 | 升级期间无用户可感知中断 |
| 数据隔离 | 渗透测试 | 无跨租户数据泄露 |
| 支付幂等 | 重复回调测试 | 10 次回调只入账 1 次 |
| 防超卖 | 并发测试 | 20 并发抢 1 房，只成功 1 个 |
| 备份恢复 | 恢复演练 | 能在 RTO 内恢复 |
| 项 | 通过标准 |
|---|---|
| 试点楼盘跑通 | 至少 1 个楼盘完成"上架→签约→收租→报修→退租"全流程 |
| 租客可用性 | 租客能独立完成缴费与报修，无需人工指导 |
| 财务准确性 | 一周内账实相符，对账差异为 0 |
| 编号 | 假设 | 若不成立的影响 |
|---|---|---|
| AS-01 | 甲方能提供历史房源与租客台账（Excel/其他系统） | 需大量手工录入，上线延后 |
| AS-02 | 甲方有营业执照与合规资质 | 无法开通支付商户号 |
| AS-03 | 租客接受电子合同 | 需保留纸质签约流程 |
| AS-04 | 首批租户愿意配合试点 | 无法验证真实场景 |
| AS-05 | 第三方支付/签章账号能按时申请下来 | 支付功能阻塞 |
| 编号 | 风险 | 影响 | 等级 | 应对 |
|---|---|---|---|---|
| R-01 | 支付渠道申请周期长（可能 2~4 周） | V1.0 延期 | 🔴 高 | 第一周就启动申请 |
| R-02 | 历史数据质量差，导入困难 | 上线延后 | 🟠 中 | 提前做数据清洗评估 |
| R-03 | 租客不接受线上缴费 | 收租效率无提升 | 🟠 中 | 保留线下登记 + 人工核销 |
| R-04 | OTA 渠道对接周期长（接口审批） | V2.0 延后 | 🟠 中 | 提前联系渠道 BD |
| R-05 | AR 内容制作成本高 | V2.0 成本超支 | 🟠 中 | 先做标杆房源，不全量 |
| R-06 | 智能硬件兼容性差 | IoT 功能受限 | 🟠 中 | 先选定 1~2 个厂商深度合作 |
| R-07 | 个人信息合规风险 | 法律风险 | 🔴 高 | 法务提前介入，做隐私评估 |
| R-08 | 跨租户租客信息共享引发争议 | 合规/口碑风险 | 🔴 高 | 在用户协议中明确告知并获授权 |
| R-09 | 秒杀/直播流量打垮主库 | 主业务不可用 | 🔴 高 | 物理隔离，独立集群 |
| R-10 | 需求蔓延导致 V1.0 延期 | 交付风险 | 🟠 中 | 严格版本边界，V1.0 冻结范围 |
| # | 问题 | 影响 | 建议 |
|---|---|---|---|
| Q-01 | 长租与短租是否同时上线？ | 影响一期范围与工期 | 建议一部长租，二部短租 |
| Q-02 | 是否需要对接甲方已有 ERP/财务系统？ | 影响集成工作量 | 需明确接口清单 |
| Q-03 | 房东端是做 Web 还是小程序？ | 影响开发量 | 建议先做小程序 |
| Q-04 | 是否要求私有化部署？ | 架构方案完全不同 | 需尽早确认 |
| Q-05 | 首批上线楼盘数量？ | 影响压测与容量规划 | 建议 1~2 个试点 |
| Q-06 | 是否需要多语言（如面向外籍租客）？ | 影响 i18n 改造 | 建议预留 |
| Q-07 | 数据保留期限与删除策略？ | 合规要求 | 需法务确认 |
| 术语 | 说明 |
|---|---|
| 租户 | SaaS 平台上的一个客户（运营公司），数据隔离单元 |
| 房源/房间 | 可出租的最小单元 |
| 整租/合租 | 整套出租 / 按房间或床位出租 |
| 长租/短租 | 按月计租 / 按天计租 |
| 间夜 | 酒店/短租的库存单位（一晚一间） |
| 账期 | 账单对应的费用周期 |
| 核销 | 把收到的钱对应到具体账单的过程 |
| 冲正 | 撤销一次错误的核销 |
| 交割 | 入住/退租时对房屋状况的确认 |
| 押金 | 租客预先支付的担保金 |
| 滞纳金 | 逾期缴费的罚金 |
| 工单 | 一次服务请求（报修、保洁等） |
| 影子（设备） | 设备当前状态的快照 |
| OTA | 在线旅游平台（携程/美团/飞猪） |
| SLA | 服务等级协议（响应/完工时限） |
| Agent | AI 智能体，能自主调用工具完成任务 |
| 需求编号 | 功能 | 对应核心表 | 版本 | 优先级 |
|---|---|---|---|---|
| PT-001 | 租户开通 | tenant, tenant_config | V1.0 | P0 |
| PT-002 | 员工权限 | user_account, role, permission | V1.0 | P0 |
| PT-004 | 操作审计 | 各表状态日志 + 审计表 | V1.0 | P0 |
| PM-001 | 楼盘管理 | property, building, unit, floor | V1.0 | P0 |
| PM-002 | 房间管理 | room, room_status_log, room_amenity | V1.0 | P0 |
| PM-003 | 批量导入 | room（批量写入） | V1.0 | P0 |
| TM-001 | 租客档案 | tenant_person, tenant_org | V1.0 | P0 |
| TM-002 | 实名认证 | tenant_person（verify 字段） | V1.0 | P0 |
| TM-004 | 信用黑名单 | credit_profile | V1.0 | P0 |
| CT-001 | 合同签约 | contract, contract_party, contract_file | V1.0 | P0 |
| CT-002 | 合同变更 | contract_change, contract_version | V1.0 | P0 |
| CT-003 | 入住交割 | checkin_record | V1.0 | P0 |
| CT-004 | 退租结算 | contract, contract_deposit | V1.0 | P0 |
| BL-001 | 账单生成 | bill, bill_item, bill_period | V1.0 | P0 |
| BL-002 | 在线支付 | pay_order, payment_channel | V1.0 | P0 |
| BL-003 | 收租核销 | payment, payment_allocation | V1.0 | P0 |
| BL-004 | 催缴 | dunning_record, late_fee_rule | V1.0 | P0 |
| BL-005 | 押金管理 | contract_deposit | V1.0 | P0 |
| BL-007 | 财务对账 | reconciliation_batch, reconciliation_diff | V1.0 | P0 |
| WO-001 | 报修工单 | work_order, work_order_flow, work_order_item | V1.0 | P0 |
| WO-002 | 派单 | dispatch_record, staff | V1.0 | P0 |
| SH-001 | 设备管理 | device, device_model, device_binding | V2.0 | P1 |
| SH-002 | 门锁权限 | access_grant, device_command | V2.0 | P1 |
| SH-003 | 远程抄表 | meter, meter_reading | V2.0 | P1 |
| AR-001 | AR 看房 | ar_scene, ar_scene_node, ar_hotspot | V2.0 | P1 |
| AG-001 | 智能客服 | agent_session, agent_message, knowledge_chunk | V3.0 | P1 |
| OTA | 渠道分销 | ota_channel, ota_room_mapping, ota_order, ota_inventory_sync | V2.0 | P2 |
| 商城 | 商城/直播/团购 | 独立库（待设计） | V3.0 | P3 |
以下表支撑前表中的细粒度功能，单独列出以便研发对照：
| 支撑表 | 对应需求 | 说明 |
|---|---|---|
contract_sign_flow | CT-001 | 签章流程状态、签署方、最终文件与哈希 |
contract_term | CT-001 | 合同条款（结构化、版本化） |
contract_room | CT-001 | 一份合同对应多个房间及其独立租金 |
refund | BL-003 | 退款单（含审批与渠道退款单号） |
invoice | BL-006 | 发票申请、开具、红冲 |
fee_item | BL-001 | 费用项字典（租金/水/电/物业/停车） |
guarantor | CT-001 | 担保人信息 |
bed | PM-002 | 合租场景的床位 |
parking_space | PM-005 | 车位（可单独出租资产） |
amenity / room_amenity | PM-002 | 配套设施字典与房间关联 |
rate_plan / rate_policy | PM-002 / 短租 | 价格方案与策略（连住折扣等） |
room_calendar | 短租（V2.0） | 间夜库存日历，防超卖核心 |
staff | WO-002 | 服务人员（技能、负载、服务范围） |
service_catalog | WO-001 | 服务项目录 |
dispatch_record | WO-002 | 派单记录（含拒单原因） |
sla_rule | WO-003 | SLA 规则（响应/上门/完工时限） |
inspection_task / inspection_record | WO-005 | 巡检任务与巡检记录 |
contact_record | TM-005 | 与租客的沟通记录 |
tenant_person_org | TM-003 | 个人与企业租客的关联 |
data_scope_rule | PT-002 | 数据权限（限定员工可见楼盘） |
media_asset / media_binding | PM-002 / AR-002 | 媒体元数据与业务绑定（文件存 OSS） |
device_shadow | SH-001 | 设备当前状态快照 |
scene / scene_action | SH-004 | 场景联动 |
ar_scene_version | AR-001 | AR 场景版本（重新拍摄保留历史） |
ar_camera_path | AR-001 | AR 漫游路线 |
vr_session | AR-001 | 看房行为数据（停留、热点点击） |
agent_definition / agent_tool | AG-001 | Agent 定义与可调用工具注册 |
agent_tool_call | AG-001 | 工具调用审计（Agent 误操作追责依据） |
agent_memory | AG-001 | Agent 长期记忆（跨会话画像） |
knowledge_doc / knowledge_chunk | AG-001 | 知识库与向量切片 |
prompt_template | AG-001 | 提示词版本管理 |
以下 14 张表是保障系统正确性与可运维性的技术设施，
不直接对应业务功能，但研发必须实现：
| 表 | 作用 | 为什么必须有 |
|---|---|---|
id_segment | 分布式 ID 号段 | 分库后主键不冲突（已验证并发安全） |
schema_migration | 迁移版本管理 | 标记破坏性变更，CI 卡控 |
feature_flag | 特性开关 | 灰度发布与不发版回滚 |
outbox_event | 出站事件表 | 保证"业务改了，消息一定发出去" |
inbound_callback | 入站回调表 | 第三方回调先落库，不丢可重放 |
idempotency_record | 幂等记录 | 支付/退款防重复执行 |
integration_provider | 集成配置 | 供应商密钥与主备管理 |
integration_call_log | 外部调用日志 | 排障、计费、限流依据 |
room_occupancy | 房间占用登记 | 排他约束防一房两租 |
media_variant | 媒体派生规格 | 缩略图/多清晰度/全景瓦片 |
device_credential | 设备凭证 | 设备密钥与证书 |
role_permission | 角色权限关联 | RBAC |
user_role_binding | 用户角色绑定 | RBAC |
user_tenant_binding | 用户租户绑定 | 一人可服务多租户 |
评审提示：若甲方质疑"为什么要建这些看起来没用到的表"，
请直接引用上表的"为什么必须有"列——这 14 张表是
支付防重、防超卖、不停机升级三项硬性要求的实现基础，缺一不可。
| 文档 | 说明 |
|---|---|
| UI/UX 设计稿 | 各端界面原型 |
| 接口文档 | OpenAPI 规范 |
| 测试用例 | 基于本 PRD 与业务规则编写 |
| 数据字典 | 完整字段定义（见《数据库设计》） |
| 用户手册 | 面向运营人员 |
| 运营手册 | 催缴、工单、纠纷处理 SOP |
文档结束。评审通过后进入 UI 设计与开发排期。