起草：小冈 R1 ｜ 2026-09-26 16:0x ｜ 刘总拍板口径：「让微信小程序先推出去，先积攒客户，先能证明它有价值，一切复杂的功能通过后期版本迭代更新」
载体：v3（miniprogram-v3，23 页，四页柜子架构）｜ 主 appid wx7ec46db1834dbd14（已有线上版本，本次为更新提审）
一、目标与原则
| 项 | 定案 |
|---|
| 唯一目标 | 小程序尽快过审上线，让游客能完成「看到酒店 → 在线订房 → 到店核销」闭环 |
| 证明什么价值 | ① 芝达布日温泉酒店能线上收客 ② 打包套餐券能引流到店 ③ 后台数据能跑通经营 |
| 迭代原则 | 一切复杂功能（玩法/在地/转山工具/分销/多商户）不删不丢，本版隐藏，后期版本逐批放开 |
| 判断标准 | 每个保留页面必须接真实 API+真实数据，演示假数据一律不进线上 |
二、版本范围
保留并打磨（6 页核心链路）
| 页面 | 现状 | 本版改动 | 工作量 |
|---|
| home 首页 | 柜子架构完成，内容是「阿里平台」口径 | 酒店化：A端配置注入（温泉实景 hero+酒店名+slogan「转山前后的一站温泉住宿」）；主按钮=在线订房；第二入口=套餐预售券；玩法/目的地/攻略区块配置清空即隐藏（判空逻辑现成） | 0.5 天 |
| hotel-booking 订房 | ✅ 实实现（room-types API+orders 下单 API 已接，226 行） | 只挂芝达布日一个商户；房型/日期/价格/游客信息/下单 | 0.5 天 |
| orders + order-detail | ✅ 实实现 | 无改动或微调（真实订单渲染验证） | 0.25 天 |
| redemption-code 券码 | ✅ 实实现（146 行） | 承载预售券：线下付款→登记领券→出示券码→b端核销 | 0.25 天 |
| profile 我的 | 未重做（旧壳） | 最小可用：订单入口+券码入口+客服入口，其余菜单折叠 | 0.5 天 |
| feedback 客服 | 存在 | 挂微信客服能力 | 0.25 天 |
隐藏（app.json 摘 tabBar+入口，文件全保留）
selection（玩法——今晚的灵感堆叠+文库聚合成果全部留档）、local（在地）、journey、content-library、voice-guide、guide-companion、merchant-store、passport、health-check、status-timeline、share-code、review 等——二期逐批放开。
tabBar：4 → 2
首页 / 我的。订单从「我的」进（下单成功页也会带订单直达），最小化不做第三个 tab。
三、预售券形态（建议线下先行，待刘总确认）
游客在小程序看套餐券（住宿+温泉+早餐 2天1晚 等打包 SKU）
→ 线下付款（到店/电话/微信转账，商户侧收款）
→ 商户在 b端/A端登记发放券码（或游客到店领码）
→ 游客小程序「我的-券码」出示 redemption-code
→ 到店 b端核销工作台扫码核销
- 为什么先线下：微信支付通道凭据未批（商户号验证流程中），线上购券走不通；线下登记链路现成，上线不受阻塞。
- 支付通道批复后：hotel-booking/套餐券下单切 wx.requestPayment，链路页无需重构（orders 状态机已支持 pending_pay→paid）。
- 替代选项（若刘总要线上）：套餐券按「0 元预售登记」或「到店付」下单占位——不推荐，订单语义混乱。
四、数据准备清单（唯一硬缺口，需要运营侧输入）
| # | 数据 | 谁给 | 备注 |
|---|
| 1 | 芝达布日商户主体确认 | 刘总 | 商户库有「芝达布日温泉」「芝达布日温泉酒店」两条——确认保留哪条（建议合并），房型挂对商户 |
| 2 | 房型 SKU 2-4 个 | 刘总/酒店 | 名称/价格/床型/可住人数/含早/库存日历（先手工按日补 30 天） |
| 3 | 打包套餐 SKU 1-3 个 | 刘总/酒店 | 名称/售价/内容物（住宿+温泉+早餐…）/有效期/数量 |
| 4 | 温泉实景图 3-5 张 | 刘总/酒店 | 首页 hero+房型卡（手机实拍即可，后期换专业图） |
| 5 | 酒店名/slogan/一句话介绍 | 已有 | 「芝达布日温泉酒店」「转山前后的一站温泉住宿」（9-21 蓝图定稿） |
数据录入通道：b端工作台（商户商品管理）或 A端后台，录入即出，前端零改动。
五、分工与排期（建议 T+3 提审）
| 时段 | 谁 | 事项 |
|---|
| D1 上午 | 刘总/运营 | 四项数据准备（上表）+ 确认预售券形态 |
| D1 下午 | 小冈 | tabBar 收敛+首页酒店化改造+profile 最小化；b端录房型（数据到位即录） |
| D2 全天 | 小冈 | 套餐券页接入+全链真机回归（订房→订单→券码→b端核销四跳全通）；A端品牌注入 |
| D3 上午 | 小冈 | 传体验版→刘总过目→修尾差 |
| D3 下午 | — | 提审（更新已有线上版本） |
六、风险与边界
| 风险 | 处置 |
|---|
| 微信审核看「微信支付未开通却卖券」 | 券明确标注「到店付款/线下凭证」，不用「支付」字样；房型下单若无支付通道则标注「到店付」或等通道批复再开订房——提审前需定 |
| 多商户内容残留（首页历史配置/搜索） | A端配置收敛到单商户；残留入口本版隐藏 |
| 芝达布日两条商户记录 | D1 确认合并，房型挂错=订单归属错 |
| 审核类目（住宿服务） | 已有线上版本过审记录，沿用原类目 |
| v3 在地/我的未重做 | profile 按最小可用处理（不做柜子级改造），上线后迭代 |
七、二期迭代路线（本版不做，仅登记方向）
- 支付通道批复 → 线上购券/在线支付订房
- 玩法板块放开（今晚已完成的灵感堆叠+文库聚合直接复用）
- 在地板块+主理人体系放开
- 多商户/平台版恢复（双入口模式）
- 分销/福钥/护照等增长功能
*本文档为执行基准。刘总确认预售券形态+数据到位后，D1 即开工。*
v1.1 更新（2026-09-26 16:35 刘总拍板）
1. 双自营酒店 + 商城
| 主体 | 定位 |
|---|
| 冈仁波齐城堡酒店 | 自营酒店①（商户库已有） |
| 芝达布日密钥酒店 | 自营酒店②（=芝达布日温泉，挂密钥品牌） |
| 商城 | 平台商品零售（SKU 待刘总定：转山装备/特产/温泉用品方向） |
2. 4 Tab 内容定案
| Tab | 内容 |
|---|
| 1 首页 | 双酒店门面+预售券主推（温泉实景 hero） |
| 2 客房·套餐 | 两家酒店房型（点卡片进 hotel-booking）+ 套餐券卡片 |
| 3 商城 | 商品列表（留姓名电话下单，同券逻辑或店员联系确认） |
| 4 我的 | 订单（姓名电话查询）+ 券码 + 客服 |
3. 交易形态定案（无登录·无支付通道依赖）
选券/房型 → 留姓名+电话 → 提交订单 → 生成二维码凭证
→ 到店出示二维码 → 商户扫码核销 → 线下支付
- 免登录：姓名+电话即身份，订单按电话查询归档
- 二维码：下单即生成（前端 canvas/复用 redemption-code 券码）
- 核销：b端扫码核销工作台现成
- 后端改造点：orders API 游客下单支持（匿名订单/姓名电话轻档案）——R1 后端改造项，D1 完成
4. 更新后数据清单
| # | 数据 | 备注 |
|---|
| 1 | 城堡酒店房型 SKU | 商户已存在，录房型即可 |
| 2 | 芝达布日密钥酒店房型 SKU | 商户改名/确认后录入 |
| 3 | 套餐券 SKU（两店各 1-2 个） | 线下支付价 |
| 4 | 商城第一批商品 3-5 个 | 图片/价格/介绍（刘总定品） |
| 5 | 温泉实景图 | hero+房型卡 |
v1.2 定稿（2026-09-26 16:41 刘总确认）
定位：内容引流平台（漂亮 C 端页面=视觉就是引流量）
- 首页第一屏（hero 五图+口号）与今日卡不动——打磨最久的资产原样保留
- 首页改动=屏3/屏4：内容精选大图流（文库头条）+ 毛玻璃券钩子「领预售券」+ 双酒店横滑入口
- 4 Tab：首页 / 玩法（✅已建成·灵感堆叠+文库聚合152篇）/ 发现（文库分栏）/ 我的（领券登记+券码）
- 视觉标准=玩法页语言全站拉齐：全屏沉浸大图/文字嵌渐变/堆叠翻卡/毛玻璃吸底/横滑色块卡/圣湖蓝纸感金藏红令牌体系
- 积客三钩子（全部姓名+电话轻登记）：①领券→二维码→到店核销线下付 ②内容页底部「让主理人帮你规划这程」留电话 ③住宿/温泉预约
- 交易垫底：hotel-booking 保留（双酒店：冈仁波齐城堡+芝达布日密钥）；商城 Tab3 并入或二期
- 数据池：姓名+电话+兴趣标签（看的内容/领的券）后台可导出，商户私域跟进
- 后端改造：orders 游客下单（匿名+电话归档）D1
- D1 开工序：首页屏3屏4 → 钩子链路 → 发现页 → 我的页；每页 automator 截图过目