铁律：不采信模型输出。每条意见都要过"站不站得住 / 适不适用本项目"这一关，
再决定采纳、部分采纳还是驳回。
理由站得住。"包价旅游"看实质不看名目。本案的真实风险点：
落地动作：情报包全删"安排、行程、为您规划"类表述，改为
「点位信息参考」；每条点位的"最佳时段"保留（这是客观日出日落时间，非编排），
但不得出现"建议上午去 A 下午去 B"的串联式编排。
酒店业常态是"住宿+接送+早餐"，一般不被认定为旅游服务（缺"组织行程"要件）。
但 astra 点出的"转山前送、转山后接"确有问题——固定时序明显服务特定行程。
落地动作：券面不写"转山前后接送"，改为
「酒店往返固定上下车点接送服务」，切断与转山行程的关联表述。
这是本案最硬的雷，我们此前完全没考虑：
落地动作：请义父核验车辆与司机资质；在资质明确前，3288 档不建议公开售卖。
站得住。券是固定价，而高原旺季房价波动大——淡季 688 卖得掉，
旺季同价可能亏损，且券卖出去改不了价。
但有一条技术现实必须让义父知悉：我们的券模型是"买券=预约凭证"，
没有日历房态，现阶段无法按日期动态定价。要按日期定价就得回到日历房态开发。
折中方案：券面写明"旺季/节假日需补差价"或"以预约确认为准"。
站得住。材料里确实没说明车型、里程、人数、等待、司机资质、取消规则，
且长途责任大。建议：明确边界后再卖，或先下架。
"有无车"作为第一刀是有效的（决定要不要接送，直接影响成本结构）。
但 astra 补充的需求维度更精准——**按"要不要接送 / 要不要寄存 /
要不要休整 / 要不要情报"分类**更贴近付费动机。
可作为第二层细分，不推翻第一刀。
这是券模型相对日历房态的最大弱点：券卖多了不自动扣库存，
旺季可能"券卖超、房不够"，到店无房 = 退款 + 转运 + 差评。
落地动作：运营侧先建按日期/房型/车次的库存台账（人工即可），
券面写入"满房替代方案与退款规则"。
高原场景刚需。需三档规则（出发前/途中/不可抗力）+ 保险 + 紧急送医预案。
我建的路况上报通道可部分支撑"实时路况确认"。
实操判断准确。需：一名值班负责人 + 一个电话 +
四张表（预约确认/接车签到/餐食确认/异常升级）。
| astra 建议 | 我的取舍 |
|---|---|
| 暂停 3288 与外部资源成交 | ⚠️ 部分采纳——删除话术立刻做；3288 明确边界后可保留，不必一刀切下架 |
| 给 7081/7082 做一页纸条款并绑定库存 | ✅ 采纳，我来做（条款写进券描述 + A 端可改） |
| 人工调度表跑通未来 14 天 | ✅ 采纳，运营侧 |
现有券模型不支持，需改核销逻辑——这是技术债，提前说清免得后期返工。
这固然安全，但也意味着当前情报的实际导航价值有限，
团队实地采集应尽快排上日程。
astra 这轮评审质量高、可执行，12 条里我完全采纳 7 条、部分采纳 4 条、
保留 1 条。最该立刻处理的三件：
以上均已同步义父，待其对 3288 档与资质核验拍板。