雪哒

Appearance

雪哒运营 Skill — 需求清单 ​

按场景拆分，每条需求是完整的垂直切片（含后端接口 + 应用逻辑），独立交付独立验收。

需求 1: 雪场数据查询与录单 ​

解决什么问题：运营查雪场信息要登后台手动翻，录入新报价要对着海报一项项填，效率低易出错。

包含：

  • 雪场列表/详情查询（雪况、天气、雪道、公告）
  • 雪场照片查询（按日期、来源筛选）
  • 数据写入：运营发海报图 → AI 解析价格/名额/行程 → 结构化写入后台

验收标准：能用自然语言查到任意雪场的实时信息；发一张报价海报能自动解析并更新到系统。

需求 2: 聊天室盘活 ​

解决什么问题：雪场聊天室是死群，用户发消息没人理，没有持续内容输出。

两套角色：

官方角色（身份公开，用户知道是官方）：

  • 捧场王：用户发照片/视频 → 2 分钟内识别内容给出内行夸奖
  • 情报局：每天早 8 点 + 下午 4 点推送雪况干货 + 雪票卡片
  • 撮合红娘：定期抛出拼车/拼房/互拍话题

用户马甲（伪装成普通雪友，与需求 6 共用马甲号池）：

  • 响应官方话题（"我也去渔阳！双板，求组队"）
  • 在别人的照片下接话（"这是万龙的 G3 道吧？上周我也去了"）
  • 自然聊天，制造"群里有人在聊"的氛围

后端需要提供：

  • GET /api/v1/chatrooms/{id}/messages — 拉取消息（按时间/类型筛选）
  • POST /api/v1/chatrooms/{id}/messages — 发消息（需支持指定发送身份：官方助手 or 马甲用户 ID）
  • 马甲号身份切换能力（同一接口，不同 identity 参数）

验收标准：选一个冷启动雪场聊天室上线，官方角色 + 3-5 个马甲号同时活跃，观察 1-2 周真实用户活跃度变化。

需求 3: 端内社区运营 ​

解决什么问题：端内社区冷启动没内容，用户发帖没人互动。

两套角色：

官方角色（身份公开）：

  • 动态秒回：用户问"云顶明天风大吗？" → 查天气数据秒回 + 附雪票链接
  • 内容填充：以官方马甲号发布攻略、雪况、活动到端内社区

用户马甲（伪装成普通雪友，与需求 6 共用马甲号池）：

  • 发帖：晒轨迹截图、雪场照片、装备开箱
  • 互动：给真实用户帖子点赞、评论（"这个板子怎么样？我也在看"）
  • 在闲置帖下帮顶，在活动帖下报名

后端需要提供：

  • GET /api/v1/community/posts — 轮询帖子（按类型/时间筛选）
  • POST /api/v1/community/posts — 发帖（需支持指定马甲用户 ID）
  • POST /api/v1/community/posts/{id}/comments — 评论（同上）
  • POST /api/v1/community/posts/{id}/like — 点赞

验收标准：端内新帖 10 分钟内有互动；社区每天 ≥5 条官方内容 + ≥10 条马甲号内容。

需求 4: 小红书内容生产 ​

解决什么问题：小红书内容全靠人写，无法利用雪哒独家数据规模化产出差异化内容。

包含：

  • 从后端拿真实数据（雪场/票务/教练/排行榜）打包成 factPack
  • 基于数据自动生成文案（比价攻略、雪况播报、里程战报、教练推荐、照片精选等）
  • 一题多稿 A/B、自动查重
  • 高表现内容复投（换标题/封面二次分发）

验收标准：给定选题 + 数据，5 分钟内出 2-3 个可用文案版本。

需求 5: 订单与数据看板 ​

解决什么问题：看大盘数据要登多个后台拼凑，查订单要手动翻列表。

包含：

  • 票务商品/订单查询（按雪场/日期/状态筛选，含汇总）
  • 教练列表/订单查询
  • 运营大盘（DAU、新增、下单、收入）
  • 内容看板（曝光、互动、涨粉、转化归因）
  • 自动生成运营日报

验收标准：一句话能查到任意维度的订单和数据；每天自动出日报。

需求 6: 马甲号 Agent 体系与冷启动填充 ​

解决什么问题：平台冷启动阶段排行榜空、社区冷、聊天室没人，真实用户进来觉得是空壳就走了。

核心思路：每个马甲号背后是一个独立的 OpenClaw Agent，有自己的人格、记忆和行为逻辑。不是脚本控制的傀儡，是能自主判断和互动的"虚拟用户"。

6.1 Agent 架构 ​

每个马甲号 = 一个 OpenClaw Agent 实例：

puppet-agent-001/
├── SOUL.md        ← 人设（昵称、性格、滑雪水平、常去雪场、说话风格）
├── MEMORY.md      ← 记忆（发过什么帖、跟谁聊过、去过哪个雪场）
├── HEARTBEAT.md   ← 行为循环（什么时候该发言、该互动、该上传轨迹）
└── config         ← 绑定的用户 ID、活跃时段、行为参数

Agent 能力：

  • 自主判断：看到聊天室里有人问"渔阳今天人多吗"，Agent 根据自己的人设和记忆决定要不要回、怎么回
  • 记忆连续：上周说过"我下周去万龙"，这周会发"万龙回来了，G3 道粉雪绝了"
  • 个性差异：话多的 Agent 每天 5-8 条，安静的 1-2 条；技术流 Agent 聊装备参数，社交型 Agent 组局拼车
  • 互相互动：Agent A 发了轨迹，Agent B 会评论"你这速度可以啊"——基于各自的人设自然产生

后端需要提供：

  • POST /api/v1/puppets — 创建马甲号（返回用户 ID + Auth Token）
  • GET /api/v1/puppets — 查询马甲号列表
  • PATCH /api/v1/puppets/{puppetId} — 更新马甲号信息
  • 每个马甲号需要一套独立的 Auth Token，Agent 用这个 Token 调用所有标准用户 API（发帖/评论/上传轨迹/聊天）
  • 不需要专门的马甲号 API——马甲号走正常用户的 API 路径，跟真实用户一模一样

OpenClaw 侧需要：

  • Agent 模板：一套标准化的 SOUL.md / HEARTBEAT.md 模板，填入人设参数即可生成新 Agent
  • 编排层：一个 orchestrator 管理 50-100 个 puppet agent 的生命周期（创建/启停/监控/调参）
  • Cron 调度：每个 Agent 有自己的心跳节奏（不是所有 Agent 同时活跃）

6.2 轨迹生成与排行榜填充 ​

每个 Agent 自己生成轨迹（不是中央统一灌入）：

  • Agent 根据人设选雪场（常去的 1-3 个）
  • 根据水平生成合理轨迹（初学者短/慢/初级道，高手长/快/高级道）
  • 根据记忆保持连续性（"上周在富龙滑了 3 天"→ 这周轨迹也在富龙附近）
  • 上传轨迹后会在社区/聊天室分享（"今天 G3 道的雪况一般"）

后端需要提供：

  • 标准用户轨迹上传 API（Agent 用马甲号的 Auth Token 调用，跟真实用户一模一样）
  • 每个雪场的雪道 GPS 路线数据（供 Agent 生成轨迹用）

节奏：每日新增 20-80 个 Agent 上榜，不一次灌满。

6.3 行为规范与风控 ​

自然性保障（靠 Agent 人设 + 记忆，不靠规则硬编码）：

  • 每个 Agent 的 SOUL.md 定义说话风格，天然不同
  • 记忆系统保证不会重复说同样的话
  • 活跃时段分散（有人是早起型，有人是夜猫子）
  • Agent 之间的"对话"是各自独立决策的结果，不是编排好的剧本

人工兜底：

  • 编排层监控异常行为（某 Agent 突然高频发言、内容重复）
  • 随时可以暂停/调整单个 Agent
  • 定期 review Agent 产出质量

验收标准：排行榜 100+ 活跃用户；聊天室有持续"用户间"互动；社区每天 10+ 条马甲内容；翻看任意马甲号的历史，都像一个真实用户的时间线。

依赖关系 ​

需求 6 (马甲号体系)
  ├── 需求 2 (聊天室) 消费马甲号：官方角色 + 用户马甲
  ├── 需求 3 (社区) 消费马甲号：官方角色 + 用户马甲
  └── 排行榜填充：需要轨迹上传接口 + 雪道 GPS 数据

需求 1 (雪场数据) ← 需求 2/3/4 都需要雪场数据
需求 1 + 需求 5 (订单/看板) ← 需求 4 (小红书内容) 需要这些数据

建议顺序：

  1. 需求 1（雪场数据）+ 需求 6.1（马甲号管理） — 基础设施，并行开工
  2. 需求 2（聊天室）+ 需求 3（社区） — 消费上面两个，可并行
  3. 需求 6.2（轨迹生成）+ 需求 4（小红书内容）+ 需求 5（看板） — 按优先级排

优先级建议 ​

优先级需求理由
P0需求 1 雪场数据所有功能的数据基础
P0需求 6.1 马甲号管理聊天室/社区/排行榜都依赖，越早搞越好
P0需求 2 聊天室盘活冷启动最急迫
P1需求 3 端内社区和聊天室一起解决冷启动
P1需求 6.2 轨迹生成+排行榜排行榜不能空着
P1需求 4 小红书内容公域获客主力
P2需求 5 订单与看板运营提效