背景：v2 正式台账显示 93 页中 57 页为零请求壳页（P0 补线 40 页）。用户提出「是否只做温泉酒店就够引流」。
结论：「小切口上线」方向正确；但切法不是「只留酒店」，而是「一条完整可用闭环 + 内容承载 + 本地工具」的精选版（≈36 页）——理由与方案如下。
一、为什么「小切口」是对的
- 审核：空壳页/半成品是微信提审的常见驳回理由（「功能不完整」）——93 页全量提审=驳回风险高；
- 体验：被内容引流进来的用户点到壳页=穿帮（信任受损）；精选版每页都是活的；
- 工期：40 页补线 vs 精选版只需补齐 ~8 页（hotel-booking / orders / status-timeline / order-cancel-reason / order-refund-preview / wish-wall / 工具页验证 / 核销链 368）；
- 与既定战略一致：最小自营样板先行（GPT-6 修订原则）——单点打通，再长出来。
二、为什么不是「只做温泉酒店」
- 承接链需要内容：被小红书/内容引来的人，需要「看懂这是什么地方」（衣领/密钥/温泉内容页）——纯酒店页=广告感，转化反而低；
- 工具是留存点：转山工具（清单/藏历/安全）是「来了还会再用」的理由——不依赖后端、天然可用；
- 福钥是机制：福钥/任务已接线（B 档）——是「做任务省转山钱」的承接；去掉=丢了平台特色；
- 审核类目：纯单一酒店售卖的小程序类目受限（商家自营 vs 平台）——保留内容+工具+多业态入口的形态更稳。
三、精选版范围建议（93 → ≈36 页）
保留（拟）：
- 入口：home / selection / local / profile / play-scene（导航）
- 酒店闭环：category-hotel / category-rental / product-detail / hotel-booking（补）/ package-booking / payment-confirm / pay-result / orders（补）/ order-detail / status-timeline（补）/ order-cancel-reason（补）/ order-refund-preview（补）
- 内容承接：guide-home / guide-detail / culture / guide-article / local-scene / wish-wall（补）
- 工具：pilgrimage / prepare-checklist / safety-check / oxygen-map / tibetan-calendar / kora-timer（工具可用性逐页验证）
- 福钥留存：fuyue-task-detail / passport / certificates / redeem-log / membership
- 核销：redemption-code / verify（WIP-368 修复后）
- 支撑：login / settings / agreement / feedback / emergency-contacts / sos
延期（二期）：demand-*（需求域）/ scene-*（场景打卡）/ kora-track（轨迹）/ commission-ledger（分销）/ trip-detail / private-route / route-detail / coupons / 其余静态页
四、附带校准一个观念
小程序不是「引流器」，是「承接器」——引流靠内容（小红书/抖音），小程序负责「被吸引来的人不流失」：能看懂、能订、能联系。所以目标不是「页面多」，是「核心路径零摩擦」。
五、执行方式（若拍板）
- 出「精选版清单」（保留/延期逐页定稿）；
- 提审版从 app.json 摘除延期页（代码保留·后续版本放出）；
- 集中补齐精选版 8 页壳（按台账模式=页面级直连）；
- 走真机回归+提审。
-- 冈子 2026-09-17（待拍板：范围建议 v1）