Primary category
主类型 type
单选。表达用户来到这里的主要目的：收费营地、野营地、住宿、景点、徒步路线、钓鱼点、停车区。
排序清晰审核好判断兼容旧数据
核心模型
不把 `type` 改成多选。保持系统简单：一个主类型负责主归类，多个能力标签解决重叠。
+
Cross features
能力标签 features
多选。表达它还具备什么：可住宿、可露营、可观景、可停车、可钓鱼、适合亲子、适合拍照、适合房车。
解决重叠筛选更准运营可纠偏
Don't
不要把 type 改成数组
例如 `type=[paid,lodging,scenic]` 会让排序、详情文案、后台审核、旧数据兼容都变复杂。
Do
主类型表达主要意图
正规营地附带木屋：主类型仍是收费营地，勾选“可住宿”。民宿旁可扎营：主类型是住宿，勾选“可露营”。
Data
现网 wild 需要被增强
175 上已有 wild 点带“民宿 / 风景区 / 观景点”语义，说明能力标签不是锦上添花，而是必要纠偏层。
用户端优化
发布页从“硬选类型”改为“先选主用途，再补充能力”。列表和地图也拆成主类型筛选 + 能力筛选。
发布地标Step 1/2
这个地点主要是什么？
🏕️ 收费营地以露营服务为主，有管理、有收费
🏨 住宿以睡觉过夜为主，如酒店、民宿、客栈、木屋
🏞️ 景点以游览、观景、打卡为主
它还具备哪些能力？
可住宿可露营可观景可停车可钓鱼适合亲子适合拍照适合房车
筛选与展示
- 按主类型筛选：用户找“住宿”时，主类型是住宿的点优先展示。
- 按能力筛选：用户找“可住宿”时，收费营地、停车区、景点里带住宿能力的点也能出现。
- 卡片展示：收费营地 · 可住宿 · 可停车 · 适合亲子。
- 详情展示：顶部显示主类型 + 能力标签，解释为什么它同时出现在多个筛选结果中。
不漏结果主次清楚用户少纠结
流程与运营规则
真正减少重叠混乱，靠发布引导、查重共建、后台审核纠偏三件事一起做。
录入判断规则
来露营选收费营地 / 野营地；如果有木屋或房间，再勾选“可住宿”。
来睡觉选住宿；如果院子或附近可扎营，再勾选“可露营”。
来游玩打卡选景点；如果能露营、停车、钓鱼，用能力标签补充。
同一物理地点优先合并成一个地标，用主类型 + 能力表达复合属性；只有入口、位置、经营主体、导航目的明显不同才拆点。
操作优化
- 发布查重提示从“附近已有营地”改成“附近已有相似地标”。
- 重复候选展示：名称、主类型、能力标签、距离。
- 给用户两个选择：补充已有地标，或确认这是新地点。
- 后台审核允许调整主类型和能力标签，不必简单驳回。
- 纠错入口增加“类型不准确 / 补充能力标签”。
落地建议
考虑现网 `camps` 已有 `tags`、`activities`、`facilities`、`terrain` JSON 字段，建议分两阶段，先不阻塞新增类型。
V1a：先补主类型加入 `lodging/scenic`，全端能创建、审核、筛选、展示。
V1b：能力标签轻量落地发布页增加交叉能力。若要最快，可先复用现有 `tags` 存储，不改 DB。
V2：结构化 features数据稳定后新增 `spot_features`，后端支持 `feature=` 查询，旧数据批量补标。
V3：运营闭环后台批量修正、纠错审核、查重合并工具，让复合地标长期不乱。
程序端接口口径
- /api/camp/list?type=lodging：找主类型是住宿的点。
- /api/camp/list?feature=can_lodge：找所有可住宿的点，包括营地、景点、停车区。
- 当用户点“住宿”频道，主类型命中排前，能力命中作为补充结果排后。
验收标准
- YoYo 能按“主要用途 + 还具备什么”录入复合地点。
- 住宿/景点与营地重叠时，前端能展示主次关系。
- 后台能纠正主类型并补能力标签。
- 查重候选能避免同一地点重复建多个点。
- 175 现有 wild 数据后续可按关键词和人工审核逐步补标，不急于迁移。