刘总想法纪要 · 单商户 MVP 与双入口设计

• 日期：2026-09-21（下午至深夜对话整理）
• 整理人：小冈（R1）
• 性质：刘总本人设计思想的忠实记录，作为后续所有相关工作的最高依据；文中「落地状态」为整理时点的附注
• 原则：刘总想法原文原意优先，整理不做发挥；有出入以刘总后续指示为准

一、总基调：小而精，讲一个故事

刘总核心意图：小程序上线不是铺摊子，是讲一个故事。MVP 的定义 = 最低成本论证方案的可施行程度，不是仪式产品，不要大张旗鼓。

要点：

1. 一期只做一个商户：芝达布日温泉酒店。
2. 单的是商户供给，不是平台功能——刘总明确纠偏：平台能力一页不砍、全部保留；收窄的只是「上线初期开放哪些商户」。
3. 先造势再引流：先通过内容验证概念，出现有效的住宿咨询信号后，再放大承接。不先砸资源做流量。
4. 盘活「神山密钥」概念：转山取钥匙 / 到神山拿钥匙作为转山第一步——这是品牌故事主轴。
5. 纪律附注：此为神山秘境创造的品牌启程仪式，必须标注清楚，不得冒充宗教传统；「转山起点」实地未证实前不作为核心卖点。

二、双入口设计（刘总明确拍板）

刘总设计：一个小程序、两个入口、两种形态。不新增 appid，不隐藏平台能力，不砍页面。

落地状态（2026-09-21 深夜）：

• C 端 merchant-store 页已建，app.ts scene 分流已接线，推上 main ✓
• 真机模拟器实测：mid=8（芝达布日测试商户，is_test=true）专属页全链路跑通 ✓

三、商户页不单独定制——主管理后台选模板（刘总设计）

刘总指出：商户专属页不应单独定制手写代码，应该在主管理后台（a端）选择模板。第二家商户入驻 = 建档 + 选模板 + 生成专属码，零代码。

落地状态（2026-09-21 深夜，已推 main）：

• 后端：merchant_page_configs 表 + 公开只读端点（C 端 60s 缓存）+ admin CRUD（15 类组件白名单校验、版本自增、保存即发布）
• C 端：merchant-store 双模式——拉到 a 端 DSL 模板走 dsl-render 渲染；无模板降级内置布局，不白屏
• a 端：新页「商户页模板」（菜单 A3）——商户列表 + 预置三套模板（温泉酒店版/景区版/餐饮版）+ 组件树编辑 + 版本记录
• staging 已自动部署验证端点生效 ✓；生产随下次部署生效

四、合规路线：全推客服模式（刘总方向确认）

结合旅行社业务许可合规分析，刘总认可的最终形态：小程序只做信息 + 选择 + 客服入口，不碰交易确认与收款；客服人工对接供应商；成交线下完成。

要点：

1. 合规红线 = 包价旅游（2+ 服务组合 + 总价 + 平台担全责）；单项服务不需许可。
2. 客服话术红线：不代收、不打包报价、不承诺履约；付款引导到供应商自己的收款方式。
3. 系统记录 ≠ 交易确认：平台只是工具提供方。
4. 数据完整性不丢：客服在系统内建单（payment_mode=offline）→ 房态扣减 → 酒店 b 端确认 → 到店核销 → 消费归因，全链走系统。
5. 工程缺口仅一处：a 端「代客建单」表单（小开发项）。

五、工作方式纠偏（刘总批评，已立为纪律）

刘总 2026-09-21 23:35 批评：「我一直要的是小程序的功能，你怎么总是给我要具体的细节数据？你设计程序难道必须有具体的商户才能进行吗？」

纠正后的纪律（永久生效）：

1. 功能开发/演示不得以「真实商户数据未收集」为阻塞项——测试数据（is_test=true 种子）由小冈自造入库，功能验证先行。
2. 真实商务信息什么时候来、来不来，都不挡功能开发；信息到位后直接改字段。
3. 任何「需要刘总提供 XX 数据」的表述，提出前先自问：能不能自己造测试数据先跑通？ 能 = 不许列为待办给刘总。

（此纪律与 MEMORY 既有「运营参数禁提令」「一票否决三问」贯通；当晚已用自造芝达布日测试商户 #8 完成全链路实测，零索取。）

六、当前待办快照（2026-09-21 深夜时点）

附：本次对话产出的关联文档

• docs/analysis/2026-09-21-旅行社许可合规分析-神山秘境.html（合规六路径对比 + 推荐双轨）
• docs/plans/2026-09-21-神山密钥单商户MVP完整方案-R1起草.md（方案 v1-v3 演进）
• docs/plans/2026-09-21-芝达布日温泉酒店单商户小程序形态设计-v1.md（已标注作废——13 页收敛蓝图曲解了双入口设计，以本文档第二节为准）
• docs/white-label/tenants/zdb_hotel.yaml（租户声明，二期预留）