深挖线 · 2026-09-15 · 初稿 → GPT-6 审查 → 本定稿
审后关键修正：补「最低运营与停服边界」· 「AI 全速开发」是误判 · 运营优先序 · 两闸门 · 内容按时效分流
朴素追问：「转山季结束后那几个月，谁在管、钱从哪来？」
精确问题：强季节性业务的两半（旺季交付/淡季运营建设）+ 「有上线没运营」死法的防线。
方向 A · 双季制【保留】旺季=交付+采集；淡季=加工+建设。淡季 KPI 修正：看问题关闭、有效内容覆盖、复制验证——不能只数功能与文章。
方向 B · 最低运营与停服边界（新增）：闭季明确——①哪些服务关闭（列表）②咨询谁接（渠道与时限）③历史订单如何善后（进行中订单的承诺履行）④重新开季如何验收。停止获客不代表既有承诺结束。
方向 C · 运营责任表（六列版）：一类内容一行的六列（主责/备份/可信来源/有效期/失效动作/升级联系人）。分级策略：路况/安全——持续核实，无能力核实时明确「未核实/已过期」并关闭依赖该信息的推荐与承诺；主理人营业信息——到期未确认标「营业待确认」并停止接单入口；历史故事/历程档案——可冻结；攻略——拆分稳定知识与动态条件。
方向 D · 现金规划【强化】12 月月表 + 滚动 13 周周表；先锁定覆盖至下次可靠回款的不可削减支出，再批开发预算；压力测试（旺季收入不足/回款推迟/额外善后）。预收只能对应明确服务期与退款条款；冬游预售不做平台资金池。
方向 E · 「AI 全速开发」纠正：AI 不能替代当地核实、主理人协调与现场验收；人员恢复也是交付能力建设。淡季开发须「有预算的验证开发」——不是默认全速。
方向 F · 内容按时效分流（不按季节一刀切）：路况即时发布并到期失效；攻略旺季纠错；故事淡季加工。「全量收集」改最小必要采集、明确授权、可撤回；UGC 标原始时间与地点，不包装成实时见闻。
方向 G · 两个闸门（新增）：
方向 H · 冬游/复制窗（验证项）：政策适用性、冬季可达性、供给需求、第二目的地季节均未验证——不作排期与预算依据，先验证。