核心用法
airbnb-reviews 是一项基于 StayingAPI 的跨平台住宿评价数据获取技能，主要用于读取民宿、酒店等住宿 listing 的用户评价与评分信息。该技能的核心 API 端点为 GET /v1/reviews，支持通过 platform（必填，可选值：airbnb/booking/vrbo）、listingId 或 url、limit、cursor、language 等参数获取分页评价数据。
使用时需配置环境变量 STAYINGAPI_KEY（以 stay_ 开头，stay_test_ 沙盒密钥可免费测试），并在请求头中携带 Authorization: Bearer $STAYINGAPI_KEY 和 User-Agent。技能采用 MCP（Model Context Protocol）架构，支持 OAuth 2.1 + PKCE 认证，避免密钥直接暴露在对话中。
该技能的一大特色是原生评分尺度保留：不同平台的评分标准（如 Airbnb/Vrbo 的 5 分制与 Booking.com 的 10 分制）在返回数据中完整保留，不会静默转换，便于进行平台间的真实对比分析。
显著优点
1. 跨平台统一 Schema：Airbnb、Booking.com、Vrbo 等主流 OTA 平台的数据以相同结构返回，大幅降低多平台集成成本
2. 零成本沙盒测试：stay_test_ 前缀的测试密钥可免费获取 fixtures 数据，便于开发调试
3. 计费友好设计：失败、空结果、被拦截的调用均不计费，仅成功调用消耗 credits
4. 异步任务支持：针对需要实时爬取的数据，提供 202 异步轮询机制，避免阻塞等待
5. 跨 OTA 比价能力：通过 /v1/price-compare 可获取同一房源在多平台的报价对比
潜在缺点与局限性
1. 平台覆盖不全：Google Hotels 平台暂不支持 listing 和 reviews 端点，需使用其他平台替代
2. 依赖外部 ID 质量：非 /v1/search 获取的 Vrbo ID 可能解析失败，建议使用搜索接口获取的标准 platformListingId
3. 异步调用复杂度：实时爬取场景需要实现轮询逻辑，需处理 Retry-After、退避策略、429 限频等问题
4. 分页行为不确定：部分端点或上游源的 hasMore/nextCursor 行为可能不一致，需以返回的 meta.pagination 为准
5. 数据覆盖度差异：跨平台比价时部分房源可能仅返回单一聚合报价，而非多平台详细对比
适合的目标群体
- 旅行类产品开发者：需要集成多平台民宿评价数据的 App、网站开发者
- 数据分析师/研究者：进行住宿行业竞品分析、用户情感分析的研究人员
- 房产管理运营者：需监控自身房源跨平台评价表现的专业房东或短租运营团队
- 价格监控工具开发者：构建跨 OTA 价格追踪与比价服务的开发者
使用风险
1. API 稳定性依赖：作为第三方聚合服务，StayingAPI 的可用性与上游平台（Airbnb 等）的反爬策略、接口变更有间接关联
2. 限频与成本：生产环境调用产生实际费用，高频场景需合理设计缓存策略；未遵守 120 requests/minute 限频将触发 429 错误
3. 数据时效性：评价数据依赖爬取，异步任务完成时间不确定（estimatedSeconds 为估算值），实时性要求高的场景需评估适用性
4. 密钥管理：生产密钥需安全存储，避免泄露导致滥用；建议使用 MCP 模式减少密钥暴露风险
5. 合规与商标：技能明确声明与 Airbnb 无隶属关系，商业使用时需注意平台数据使用条款的合规性