# 客满房非房收入服务平台｜开发计划与验收 V6

版本日期：2026 年 9 月 30 日。本文是产品拆解与交付计划建议，周期从需求和关键依赖确认后的第 1 周起算，不是固定上线承诺。估算基于下述团队与首期范围；正式排期应在技术评审、支付主体和小程序主体确认后锁定。

## 0. 开发优先顺序：1–14

按下表逐项交付可评审结果。每一项的 PC、管理小程序及相关用户入口在同一迭代一起设计、开发、联调和验收；共用账号、机构、商品、订单与权限服务，不把小程序排在 PC 完工之后。

| 顺序 | 优先级 | 研发项目 | 本轮评审应看到的交付结果 | 前置依赖 |
|---|---|---|---|---|
| 1 | P0 | 服务商两种入驻方式 | 服务商直接添加酒店/商户；生成邀请码→机构登记→绑定邀请服务商，重复或失效码不可用 | 机构模型、邀请码规则 |
| 2 | P0 | 新机构首页与登录 | 酒店默认入口，酒店→商户→服务商→中台顺序；新机构账号从统一首页进入本组织 PC/小程序 | 入驻机构、账号归属 |
| 3 | P0 | 员工账户、当值与审计 | 酒店新增员工、岗位、启停、本人信息；登记当值班次，每次关键操作追溯员工/机构/对象/变更前后 | 账号服务、组织成员模型、审计事件 |
| 4 | P0 | 角色与管理权限 | 菜单/数据/字段/动作一致；技师仅本人任务、前台无分账、服务商不代履约；接口验收可复现 | 员工账号、角色职责上限 |
| 5 | P0 | 机构与个人资料、基础筛选 | 酒店名称/房量/开业时间/照片/钻级；酒店商户服务商资料完善、用户本人资料；区域和项目筛选 | 机构关系、地区编码、媒体存储、资料权限 |
| 6 | P0 | 供货产品与酒店在售、授权调价 | 商户产品/库存；酒店选品、新建本店商品、上/下架及本店售价；新单价格快照，旧单不变 | 机构权限、产品和覆盖范围、价格规则 |
| 7 | P0 | 三来源商机、抢单与移动上传 | 酒店共享、服务商上传、趣会议等工具上传；会议/团队统一商机池抢单报价，协议单位认领跟进；原来源与上传人固定留存 | 机构、权限、商机分类、来源归因、匹配规则 |
| 8 | P0 | 服务核销与商品履约 | 驿呼百应下单，商户派工，本单技师到店核销与服务；酒店只读；商品供货配送 | 产品配置、人员、库存、核销凭证、通知 |
| 9 | P0 | 收入与个人提成台账 | 支付/退款/分账/结算、客房单列；个人提成按来源及规则单独记账，本人汇总可下钻 | 订单状态机、归因快照、支付账户、规则版本 |
| 10 | P1 | 服务商拓店与资源公海 | 底部添加入口；线索领取、电话联系、结果回填、保护期、转成酒店/商户 | 机构与线索模型、员工归因、重复校验 |
| 11 | P1 | 单层推荐奖励与排行榜 | 酒店推荐酒店、服务商发展酒店/商户；首单达标审核、退款冲正；服务商前十使用已支付订单的累计应计分账同口径 | P0 订单及结算事实、推荐关系、营销预算规则 |
| 12 | P1 | CRM、协议与人脉 | 协议单位上传后的完整跟进、协议价/有效期、负责人提醒、企业订单关联 | 联系人权限、客户模型 |
| 13 | P1 | 高级排期与运营效率 | 资源容量、并发占用冲突、人员排班、批量运营、获客漏斗与渠道转化 | P0 日历、数据归因、稳定订单事实 |
| 14 | P2 | 伙伴分红 | 伙伴档案、贡献台账、分红规则、批次与审批，独立于订单分账与推荐奖励 | 商业规则、合同、审批与责任边界 |

V6 原型可提前展示 P1/P2 页面用于评审；这不表示它们已经接通真实交易。推荐归因字段从 P0 开始保留，奖励正式发放在 P1 验证后开放；这样试点首批门店的来源可追溯，同时先保证接单、权限与财务正确。前后端接口与多端联调贯穿 1–9，不作为最后补做的一项。

## 1. 本轮业务翻译

平台首先要把“谁卖、谁接、谁履约、谁收益”记录清楚，再做经营汇总和扩张。

| 业务线 | 客户入口与销售主体 | 接单与履约 | 酒店看到什么 | 收入口径 |
|---|---|---|---|---|
| 到店服务 | 驿呼百应扫码；外部服务商户为服务提供方 | 商户接单，员工派工，技师执行本人任务 | 经营数量、订单状态、核销结果；有财务权限者查看酒店分账 | 酒店取得场所收益；不把商户服务营业额全部计为酒店收入 |
| 商品售卖 | 驿呼百应扫码；酒店为售卖主体 | 供货商户接单、备货、配送与售后协同 | 商品销售、订单进度；有财务权限者查看酒店收益 | 商品交易额与供货商份额、酒店收益分别记录 |
| 酒店大消费 | 酒店共享、服务商上传、趣会议等工具上传的统一商机；酒店承接后为销售主体 | 酒店抢单/接单、分项报价，客户确认后履约 | 活动会议、婚庆、团队、宴会、协议等本店订单 | 客房、非房分项核算；合作意向不等于已成交收入 |

会议、团队、协议单位是本轮统一管理的商机类型；酒店共享、服务商上传、趣会议等工具上传是商机来源。跨店转介是流转事件，驿呼百应是另一条商品/服务获客链。原订单号、原来源、原酒店和当前承接酒店分别保留。趣会议不依赖入住身份；驿呼百应房码是场景归因，不作为已核验入住凭证。

管理中台围绕服务商、酒店门店、商户、产品、财务分账、岗位权限六个管理域展开，每一域均应提供“汇总 → 列表筛选 → 主体详情 → 关联订单/账单”路径。PC 与管理小程序共用身份、组织归属、业务权限和同一订单状态。

## 2. 排期假设与范围

建议首期核心交付团队约 7–8 人：产品负责人 1、UI/UX 1（前期全时）、后端 2、PC 前端 1、小程序前端 1、测试 1；项目/运维可由 0.5–1 人共享承担。酒店、商户、财务各安排一名业务验收代表。若只有 2–3 人开发，不能简单沿用以下周期。

首期按单一试点城市、10–20 家酒店、2–4 家履约/供货商户、有限商品与服务目录建设；先支持约定支付方式和一种结算路径。PMS/OTA 全量库存联动、多城市复杂税务、开放式招商、复杂授信、自动投放和伙伴股权分红不计入 P0。

四类 B 端组织为总部、服务商、酒店、商户。首期建议共用一个管理小程序工程并按身份显示工作台，酒店端命名为“客满房非房收入”；趣会议、驿呼百应保持独立用户入口与产品定位，实际小程序数量与主体在第 1 周确认。

| 阶段 | 相对周期建议 | 完成目标 | 依赖和退出条件 |
|---|---|---|---|
| 准备与冻结 | 第 1–2 周 | 字段字典、角色矩阵、订单状态机、支付/分账方案、原型评审冻结 | 支付和小程序主体可用，业务边界、取消退款责任、产品规则由业务负责人确认 |
| P0：可接单与收入闭环 | 第 3–10 周开发联调，第 11–12 周试点 | 直接添加/邀请码入驻、新机构登录、员工权限、订单商品、PC/小程序同步和财务对账形成闭环 | 关键外部接口可用；P0 验收通过并完成试点真实账单核对 |
| P1：拓店增长与运营效率 | P0 后约 4–6 周 | 资源公海、单层推荐/奖励审核、收入排行、协议人脉；高级排期按容量评审增量 | P0 订单、归因及结算数据稳定；奖励预算与规则确认 |
| P2：伙伴协作与分红 | P1 后约 6–10 周，独立立项 | 伙伴分红规则、贡献台账与批次 | 商业规则、合同、收益归属、审批方案另行确认，不挤占接单与结算主流程 |

不同阶段可少量重叠进行设计；依赖支付/小程序审核的等待时间应单独记录。若 P0 试点存在金额不平、越权访问、重复接单或资金回调不可靠，先修复并复验，再扩大门店数量。

## 3. P0：先完成能接单、能履约、能核对收入的闭环

### 3.1 账号、机构、员工与权限

服务商入驻必须同时交付“直接添加”和“生成邀请码登记”两条路径。创建后酒店或商户出现在对应服务商和总部列表，并能从统一首页用自己的账号进入机构首页。邀请码应绑定类型、邀请服务商、有效期及使用状态；机构的真实上线状态与仅提交登记分开。

- 建立总部 → 服务商 → 酒店/商户归属；独立记录销售主体、履约主体和收益主体，不用一条机构字段兼任所有关系。
- 支持用户名密码、短信加密码验证、微信扫码三种 PC 登录方案；正式接入短信、微信授权和会话管理，禁用账号后及时撤销会话。
- 总部配置账号，机构负责人维护授权范围内的员工；酒店店长/前台/财务、商户老板/员工/技师、服务商负责人/运营/财务分别授权。
- 权限同时检查机构范围、菜单、字段和操作；岗位职责设上限。技师只能访问本人已派任务，前台不看分账，服务商不代酒店抢单或代商户履约。
- 权限服务由后端统一执行；前端隐藏按钮仅用于交互提示。账号停用、调岗、跨组织、撤权都写审计。
- 酒店 PC 明确展示当前登录员工、岗位和当值班次；“当值”描述值班安排，实际操作责任仍绑定真实登录账号，不能选择另一个员工代替归因。交班保留起止时间、交班说明及待办。
- 关键流程写不可变审计事件：登录/当值、上传/抢单/报价、价格和上下架、资料、权限、核销、退款与审核；记录操作人、组织、渠道、对象、结果、前后值和关联订单。界面查询与导出也应留访问日志，不把前端埋点等同审计证据。

**验收**：两种入驻均能创建正确归属的机构，新增账号能进入本机构首页；同一账号 PC/小程序读取一致授权；用直接接口请求、替换订单 ID、旧会话和跨机构账号验证无法越权。撤销履约或财务权限后，菜单、接口、导出和已有页面数据均受限制。

### 3.2 酒店与产品配置

- 酒店档案包含名称、房量、开业时间、照片、钻级、省市区、地址、服务商、联系人、开通状态和非房项目；钻级注明门店填报/平台审核来源。商户与服务商提供机构资料；本人资料独立编辑，不因此修改员工角色。P0 同步提供省→市→区县联动与非房项目筛选，叠加名称/状态并可一键重置，汇总与列表同口径。
- 产品区分到店服务、商品、酒店大消费项目。配置价格/规格、售卖方、履约方、酒店适用范围、可服务时段、库存或承接能力、退款条件及分账规则版本。
- 供货主商品与门店在售记录分层：商户维护 SKU、库存与履约覆盖；酒店维护选品、门店上下架和许可范围内的零售价。门店调整不改别店售价，也不改变已下单金额。未授权调价、低于规则边界、商户停用、无库存或范围不匹配时，服务端拒绝新单。
- 酒店新建本店商品时必须指定有效履约商户及范围；不能创建没有供货/履约责任方的在售商品。平台审核或商户确认是生产环节，正式上线需明确责任承担；门店不能直接编辑他人的供货主数据。
- 服务和商品上架须满足门店已开通、商户已生效、城市/范围匹配；下架或停用后用户端不可新下单，历史订单保留原规则快照。
- PC 配置通过同一后端 API 同步到小程序；价格、状态、库存和权限不能分别维护。版本号和更新时间用于排查前后端显示差异。

**验收**：中台新增/修改项目后，相应用户端和商户端显示相同配置；不同城市不会下发给不覆盖该城市的商户；失效价格、下架产品和跨门店产品在接口层不能购买。

### 3.3 三条接单履约链

酒店大消费 P0 同步交付基础订单日历：按日/月查看已确认订单的活动日期、场地、项目和状态，点击进入对应订单明细；订单改期、取消或确认后日历同步更新。此项属于日常接单基础功能，不延至 P1。高级场地容量、冲突拦截、商户排班和资源优化放入 P1。

| 链路 | P0 必做动作 | 状态约束 |
|---|---|---|
| 三来源会议 / 团队 → 酒店 | 酒店共享 / 服务商上传 / 工具上传 → 商机池匹配 → 酒店抢单 → 分项报价 → 客户确认 → 付款与履约 | 来源及上传人创建时固定；抢单原子互斥；客户确认不等于付款 |
| 三来源协议单位 → 酒店 | 酒店共享 / 服务商上传 / 工具上传 → 协议资源池 → 酒店认领 → 跟进 → 后续真实订单 | 认领资源不是抢订单；资源本身不计收入，跟进与转订单均保留来源 |
| 驿呼百应 → 到店服务 | 酒店房码归因 → 服务选择 → 支付 → 商户接单 → 员工派工 → 本单技师到店核销 → 服务完成 → 客人确认 | 技师只能核销本人已派订单；凭证限定订单且一次有效；酒店无核销/派工/完成服务权限；核销不等于服务完成或资金结算 |
| 驿呼百应 → 商品售卖 | 酒店房码归因 → 商品选择 → 库存锁定/支付 → 供货商户接单 → 配送 → 客人确认 | 酒店是售卖主体；供货和履约商户独立记录；超卖、拒单、缺货有异常处理 |

同时支持取消、超时未接、改期、拒单、投诉和退款状态。消息通知需有失败重试和站内待办；不能把“消息已发出”当作“对方已接单”。

客满房非房收入底部导航固定“首页 / 订单中心 / 上传 / 分账 / 我的”。“上传”首屏分别提供会议商机、团队商机、协议单位。会议和团队进入商机池抢单报价；协议单位进入资源池认领跟进；只有后续真实订单支付才进入经营收入。首页突出可抢会议数量、待办、今日/本月非房收入和刷新时间；读取同一订单/账本事实，不用定时变化的假数字。

跨店转介首期限定一跳：未支付、未开始履约的需求可在获得客户同意后转给目标酒店；目标重新报价，客户确认新酒店前不迁移正式承接关系。已支付转单涉及退款和合同责任，单独评估，不在首期直接开放。酒店上传线下需求应提供独立客户确认凭据/链接，酒店不能代客户点击确认。

**验收**：同时两家酒店抢同一需求只能成功一家；重复点击、重复回调不重复建单；用户取消后不能继续履约；目标酒店、原酒店、服务商的订单与财务归属在转介前后可追溯。

### 3.4 财务分账与收入核对

- 订单金额拆为客房与非房。酒店非房所得、商户履约份额、服务商份额、平台份额及客房收入独立记录。
- 保存下单时分账规则版本和价格快照；新规则只影响约定生效后的订单，不回改已完成账单。
- 使用支付流水、业务订单、分账账本、退款/冲正记录、结算批次形成可核对链路；金额按整数分计算，明确尾差归属。
- 待支付、已支付、履约完成、售后审核、可结算、已结算分别建状态；冻结金额不能直接提现或结算。
- 支付与退款回调做验签、幂等、重试与异常对账。正式资金路径须先由支付方案与业务主体确定，原型比例不能直接当成正式合同。
- 员工个人提成单独记录受益人、归因订单、计算基数、规则版本、预计/已结算/冲正状态；操作人不自动等于获客推荐人或提成人。本人只见自己的汇总与明细，老板查看团队需要相应授权。员工提成、推荐奖励、酒店伙伴分红不得重复记入四方分账总额。
- 酒店员工的专属驿呼百应推广链接记录单一酒店、员工和推广码；下单时保存归因快照，满足规则后计提。不得用当值员工替代推广来源，也不得把审核后的门店推荐奖励自动分给每位员工。

**验收**：抽样订单“客房收入 + 四方非房份额 = 订单实付分配基数”；取消退款产生可追溯冲正；跨日对账无未解释差额；金额汇总可逐笔下钻，未支付预算与合作意向不进入实收 GMV。

### 3.5 P0 交付与上线门槛

交付 API 文档、数据字典、数据库迁移、部署与回滚说明、权限矩阵、日志与报警、支付对账步骤、客服异常处理手册和验收记录。测试环境、预发布和生产环境分离，配置与密钥分环境管理。

推荐上线门槛：全部 P0 业务验收案例通过；阻断交易/数据越权/资金不一致问题为 0；完成备份恢复演练；至少用一轮约定试点订单验证支付、退款、履约、分账和财务人工核对。试点结果由业务、技术、财务共同签收。

## 4. P1：服务商拓店、推荐增长与运营效率

| 模块 | 计划内容 | 验收关注点 |
|---|---|---|
| 高级场地与人员排期 | 在 P0 订单日历上增加会场容量、并发资源占用、商户排班、冲突判断和改期提醒 | 资源与订单关联；冲突不能静默覆盖；容量和时段规则可配置 |
| 运营效率优化 | 基于 P0 区域/项目筛选，增加保存常用条件、批量跟进、覆盖缺口和效率指标 | 原始筛选口径不变；批量操作仍按机构权限逐条校验 |
| 企业协议 | 企业档案、适用酒店、协议价、有效期、授权联系人、额度与履约订单关联 | 新协议意向不计成交；到期停用；变更保留版本；确认主体与实际交易可追溯 |
| 人脉资源 | 企业联系人、活动/会务资源、合作跟进、负责人分配、提醒和转换订单 | 联系人按组织与岗位授权；跟进记录保留；避免重复导入；资源线索不直接当作订单收入 |
| 服务商运营 | 名下门店开通进度、活跃度、商品/服务覆盖、异常闭环与培训 | 门店指标可回到订单事实；服务商仅操作授权范围，不承担业务方接单按钮 |
| 资源公海 | 资源领取、电话联系、未接通/有意向/无意向/待拜访等结果、下次跟进、去重与归还 | 拨号不自动变为已联系；线索归属与机构服务商归属分开；跟进记录保留实际员工 |
| 单层推荐 | 服务商拓酒店/商户、酒店推荐酒店；推荐码与直接推荐人、登记机构、首笔有效成交绑定 | 不因注册或邀请人数奖励；只有首单完成、支付、结算等条件满足后可审核；同一目标不重复计奖 |
| 奖励与排名 | 推荐奖励独立台账、预算/规则版本、人工审核与退款冲正；服务商收入前十 | 审核不是打款；自荐/重复资料/取消单不计奖；榜单标明已支付订单的累计应计分账，含待结算/冻结，不等同已到账；不足十家按实际家数显示 |

推荐关系只保留直接推荐人，不设计多层级抽佣。奖励金额、比例、周期、资金承担方与首单达标标准必须经业务确认后配置；原型的 200 元、100 元及提成比例都是测试示例。先用真实试点数据验证拓店成本、激活率、首单率、30 日留存、净收益，再扩大奖励预算。服务商主要考核已激活门店与持续交易；酒店推荐看有效上线与首单，避免只追求注册量。

基础省市区/项目筛选和按日/月查看已确认订单的日历均为 P0；P1 增加拓店公海、推荐奖励、高级排期、冲突管理和运营效率能力，不推迟基础接单入口。

## 5. P2：伙伴分红，独立立项

伙伴分红先定义伙伴身份、贡献归因、计提基数、分红周期、规则版本、退款追回、退出及审批流程，再建设伙伴档案、台账、批次与对账。订单分账与伙伴分红分别建账，不能直接混成一个比例字段。

**验收前提**：业务方给出明确规则与样例合同流程，涉及分红基数、资金承担方和历史收益的责任边界经过业务确认。P2 的周期与费用应单独报价，未经确认不自动纳入 P0 合同。

## 6. 可执行验收清单

| 编号 | 测试场景 | 期望结果 | 负责人 |
|---|---|---|---|
| A01 | 三种登录、账号停用、跨端退出 | 真实授权校验；停用/退出生效；没有演示密码后门 | 后端 + 测试 |
| A02 | 机构切换、员工调岗、技师订单 ID 替换 | 机构隔离；越权接口拒绝；审计可查 | 后端 + 测试 |
| A03 | 中台改商品价格/范围/上下架 | PC/小程序读取同一配置；新订单使用新版本，旧单快照不变 | 前后端 + 商品运营 |
| A04 | 三来源会议/团队商机并发抢单、报价后客户确认 | 三来源同池；原子抢单；报价分项；来源及上传人不变，客户确认不伪造付款 | 前后端 + 酒店 |
| A05 | 服务接单派工、技师开始/完成 | 角色权限正确；酒店只看核销经营；客人确认独立 | 商户 + 测试 |
| A06 | 商品支付、缺货、配送、售后 | 销售与履约主体明确；库存/退款异常闭环 | 商户 + 酒店 + 测试 |
| A07 | 未支付需求跨店转介 | 原来源不变；目标报价；客户确认后迁移当前承接；原酒店不重复计收入 | 酒店 + 测试 |
| A08 | 支付/退款回调重复、失败重试 | 幂等处理；状态不跳错；账务无重复记账 | 后端 + 财务 |
| A09 | 非房/客房/四方分账/冻结/结算抽样 | 分项相加一致；冻结不结算；实收和预估分开 | 财务 + 测试 |
| A10 · P0 | 区域/项目/名称/状态组合筛选、重置、基础日历 | 列表与汇总一致；日/月可查看已确认订单、点击进明细；改期取消同步 | 前端 + 酒店运营 |
| A11 · P1 | 高级资源占用冲突、协议到期 | 按规则提示或阻止；历史记录完整 | 酒店运营 + 测试 |
| A12 | 备份恢复、版本回滚、通知失败 | 有可执行恢复步骤；待办可补偿；数据仍可核对 | 运维 + 测试 |
| A13 · P0 | 两名员工先后当值并操作同一订单 | 每条日志归因真实账号、班次与对象，含变更前后；交班不篡改原归因 | 酒店 + 测试 |
| A14 · P0 | 酒店上架/调价、商户下架、旧订单回看 | 本店售价生效、其他店不变；失效产品不能下单；旧订单保留旧价 | 商户 + 酒店 + 测试 |
| A15 · P0 | 底部上传三类内容、资料编辑、本人提成 | 会议团队入商机池；协议单位入资源认领；来源归因不变，资料权限正确，提成不串人 | 多端前端 + 测试 |
| A16 · P0 | 错误技师/错误订单码/重复核销/酒店尝试核销 | 全部拒绝；正确技师的一次有效核销记录可追溯；核销不自动支付 | 商户 + 测试 |
| A17 · P1 | 公海领取、拨号取消、结果回填、转机构 | 互斥归属；未拨通不记已联系；跟进与入驻保持来源和操作人 | 服务商 + 测试 |
| A18 · P1 | 推荐登记、重复目标、首单退款、规则改版 | 登记不计奖；只奖励一次直接推荐；退款可冲正；旧审核快照不变 | 运营 + 财务 + 测试 |
| A19 · P1 | 收入榜与机构财务明细核对 | 同一周期同口径可追溯；金额受岗位限制；不足十家不凑数 | 运营 + 财务 |
| A20 · P0 | 分别从酒店、服务商、趣会议上传协议单位并认领跟进 | 三来源统一可筛选；认领后来源/机构/上传人固定；不因认领产生收入 | 服务商 + 酒店 + 测试 |
| A21 · P0 | 已有订单跨店甩单、伙伴记录回看 | 既有订单和伙伴数据保留；甩单轨迹保留原来源及上传人；不重置历史财务 | 酒店 + 财务 + 测试 |

## 7. 原型与正式工程的区别

| 当前 V6 原型用于确认 | 正式开发必须补齐 |
|---|---|
| 页面结构、按钮、数据字段、角色视图、区域筛选、状态流转 | 数据库、API、服务端鉴权、并发、事务与审计持久化 |
| 本浏览器本地数据联动、演示账号与身份切换 | 真实组织账号、微信与短信、登录会话、员工授权 |
| 示例订单、分项报价、模拟分账账本 | 真支付/退款/对账、规则快照、资金结算与异常冲正 |
| 浏览器里的小程序外观 | 微信小程序工程、真机适配、平台审核、发布与订阅消息 |
| 页面上“可见”和“可点”的业务边界 | 接口层同样拒绝越权，导出与缓存也受控 |

原型能点通不等于已经上线，不能把浏览器本地存储当作正式业务数据库。正式验收以测试环境和试点环境的接口、订单、日志、资金流水及验收记录为证据。

## 8. 启动前需要锁定的决策

1. 明确首期试点城市、酒店/商户名单和五到十个首发商品或服务包。
2. 明确支付收款主体、四方分账方案、退款责任、客房收费及结算周期。
3. 明确三个 PC 登录方案和三个产品入口的微信主体、账号、域名、短信供应商。
4. 冻结角色矩阵、酒店已开通项目、地区编码和商户覆盖范围。
5. 约定 P0 交付范围与验收案例，P1/P2 独立列入后续迭代；每周用真实流程演示跟踪进度。

建议从“新增机构员工 → 配置产品 → 客人提交 → 业务方接单履约 → 客人确认 → 财务核对”这条完整链路组织研发与演示，避免页面全部完成后才开始联调。


## 本轮硬件与异业联盟增量

硬件 UI 与本地模拟交互已补充，详见 [硬件接入与协作开发](硬件接入与协作开发.md)。正式后端、厂家真实沙箱及单店试点按 G4–G6 关卡推进。

异业联盟尚处方案阶段，详见 [异业联盟业务方案](异业联盟业务方案.md)：酒店导流外部商户消费、商户反向提供酒店商机、现有酒店跨店甩单分开建模。新增联盟消费核销权属于实际履约商户；酒店推荐收益与商户成交额分别核算；会议/团队/协议单位沿用三来源并扩展渠道归因。