跳到主要内容

游牧周记第47期

· 阅读需 12 分钟
Suhe
Suhe
This site owner

标签​

Neocloud， Coreweave, Nebius

影视​

流人 season 5​

这一季还是那么好看，而且变成轻松喜剧了，毕竟上一季有点沉重，算是喘口气的作品。

开发​

expo+RevenueCat的促销码问题​

用RevenueCat一年半以上了，没想到过测试促销码吗？ 我现在才发现这个问题是因为有老用户提出。 后来找遍网络都没人提及，官方似乎也很模糊（回去再看看docs）。 AI多数含混不清，只有kimi板上钉钉地说没有解决方案。 太奇葩了，这么牛的平台居然不支持。 其实兑换成功后，dashboard上确实看到了这笔交易，说明rc能正常读取的，只是app端如何解决似乎无办法? 以前我用的https://github.com/hyochan/react-native-iap也非常简单就搞定了啊，几乎无感的设计，于是我又去看了看，这个组件还在不断更新中，可能哪天我要回归？

附上kimi的回答，我现在非常欣赏它。

把 docs.revenuecat.com 全站翻了一遍，结论可以一句话先说完：
RevenueCat 2025 年依旧「看不到」任何通过 App Store 手动兑换的 Promo Code（一次性内购那 100 个码）。
官方只支持「订阅类 Offer Codes」，而它们跟 Promo Code 完全是两套东西。下面把散落在各文档/社区帖里的关键信息按话题汇总，给你一份「官方拼图」。

1. Promo Code（消费类）在 RevenueCat 里的真实表现​

  • 交易会被 当成原价购买 写进 Charts & CustomerInfo，价格、take-home 比例都不变，没有任何字段标记它是 promo。
  • 仪表盘里 offer_code = null 就表明 不是 Offer Code；Promo Code 不会出现在这里。
  • 苹果/Google 的 API 不会把「用了 promo code」这件事告诉 RevenueCat，所以 SDK、webhook、ETL 全程都 无法区分。
  • 官方在 iOS Subscription Offers 文档里直接把「In-App Purchase Promo Codes」列为 ⚠️ Not recommended，理由：
    – 只能 100 个/6 个月
    – 不能商用
    – Revenue 不准
    – 不支持 presentCodeRedemptionSheet。

2. 订阅侧 Offer Codes ≠ Promo Code​

  • Offer Codes 必须先在 App Store Connect 建「订阅优惠」，再在 RevenueCat Dashboard 绑定同一个 Subscription Price ID；
    消费类 IAP 没有 Price ID，走不通这套流程。
  • 用户用 Offer Code 兑换后，RevenueCat 会把首笔交易记成 $0，offer_code 字段会写进 CustomerInfo & webhook；续费按正常价格追踪——这些福利只对订阅生效。

3. 社区反复出现的「我该怎么追踪 Promo Code 用户？」​

  • 官方员工统一答复：
    – 追踪不了；
    – 真想归因，只能自己维护「码-用户」映射，然后 Granted Entitlements 发奖。
  • 有人尝试用 App Store Connect 里看到的「Subscriber ID」去撞 RevenueCat original_app_user_id，发现 两边 ID 对不上，完全无法关联。

4. 官方给出的可行替代方案​

方案是否支持消费类RevenueCat 能否识别备注
① 原生 Promo Code✅❌100/6 个月，Revenue 不准，不推荐
② Offer Codes❌（仅订阅）✅需订阅产品 + Price ID
③ Granted Entitlements✅✅自建码系统，调用 /promotional API 发奖
④ 后端直接解锁内容✅❌不走商店，不走 RevenueCat，需自记账

5. 结论与行动指南​

  1. 如果你做的是一次性内购（金币、解锁关卡等），放弃用苹果原生 Promo Code 做归因——RevenueCat 2025 年依旧拿不到任何标志位。
  2. 想让 RevenueCat 图表、CustomerInfo、webhook 都能区分「促销用户」，只能自建兑换系统：
    – 前端输入码 → 后端验证 → 调用 RevenueCat Granted Entitlements API 发权益；
    – 权益事件会带 store=PROMOTIONAL，方便后续分析。
  3. 若坚持要用原生 Promo Code，也请务必在后台 手动维护「已发码名单」，用户进 App 后通过 syncPurchases() 把交易拉下来，再靠自己映射发奖，RevenueCat 侧仍显示原价。

再看perplexity的回答：

Revenurecat 2025最新版确实支持苹果的Promo Codes（优惠码）功能，特别是通过Apple的Offer Codes（优惠码）实现定制化的促销和试用。根据RevenueCat的官方文档，Promo Codes可以在App Store Connect中配置，用户可以通过这些优惠码获得折扣或试用期，支持在应用内直接兑换 。revenuecat​

支持情况​

  • 优惠码配置：可以在App Store Connect中预先创建，并通过RevenueCat的Customer Center自动展示和应用 。revenuecat+1​

  • 兑换方式：用户可以通过苹果提供的兑换页面（包括在应用内弹出兑换页面或跳转到App Store）完成Promo Code的兑换 。revenuecat​

  • 内购设计：建议在设计时，利用Apple的Offer Codes实现针对特定用户群或优惠的个性化促销，确保符合苹果的政策，并可以通过RevenueCat自动管理订阅状态。revenuecat+1​

设计建议​

  • 促销码的申请：在苹果商店后台通过App Store Connect配置优惠码（Offer Codes）。

  • 应用内兑换流程：

    • 通过Purchases.shared.presentCodeRedemptionSheet()弹出兑换界面（建议在用户操作需要兑换时调用），

    • 或者跳转到苹果的兑换链接(https://apps.apple.com/redeem?)让用户在Safari或App Store应用中完成兑换。revenuecat​

  • 配合RevenueCat自动匹配：兑换成功后，RevenueCat会自动检测到新交易，并同步用户的订阅状态。revenuecat​

关于主要消费类内购​

  • 如果是订阅类的内购，建议在设置时使用苹果的Offer Codes形成优惠策略，结合RevenueCat的自动订阅管理，确保优惠和促销体验流畅。

  • 设计过程中，应确保Promo Codes的创建、兑换流程符合苹果政策，避免因违规操作被拒 。revenuecat​

总体而言，Revenurecat 2025支持苹果Promo Codes，设计上需在苹果后台配置优惠码，在App中引导用户兑换，利用RevenueCat自动同步订阅信息，实现无缝体验。

总而言之，revenuecat好好做它的订阅简化工作就行，普通的消费类产品，就用react-native-iap去玩。下一个版本我准备这样改。

Offer code 新尝试​

react-native-iap（现在还是用expo-iap）专门处理消费类产品的offer code（对于iOS就是promo codes），其他的仍然用revenueCat。

现在发现一个现象，真机测试时，expo-iap的监听，要等约20秒才能获得充值完成信息。 如果此时报错“无法连接/重试”，多等等似乎还是会有监听到，但关闭CodeRedemptionSheet似乎就不行了。 如果不用内置CodeRedemptionSheet，在appStore充值等于打水漂（Gemini说是因为：App Store 的沙盒测试环境和真实的 App Store 是完全隔离的，有道理）。

testFlight也没有什么改善。

最后的方法是直接审批上线测试，发现一切似乎正常了，从兑换完成到监听成功，约有5秒延迟，但没有丢失的现象。

以上均指iOS，GooglePlay的促销代码至今没有用过，反正我有自己的代码销售体系（见之前creem.io的周记）。

Claude Code的国内用法​

不只是修改配置，调用国内大模型。 还要在大模型中方便选择和切换。 于是有了开源项目：claude-code-router. （这个作者正在找寻杭州的的AI Agent相关开发工作。） 这个项目除了自己cli外，还有个内置的web ui。 但第一次要自己写config.json这一点有些折腾人，一个字也不能写错，文档不是太清楚。

到这里还没完，README中提到：

Now you can use models such as GLM-4.5, Kimi-K2, Qwen3-Coder-480B-A35B, and DeepSeek v3.1 for free through the iFlow Platform.
You can use the ccr ui command to directly import the iflow template in the UI. It’s worth noting that iFlow limits each user to a concurrency of 1, which means you’ll need to route background requests to other models.
If you’d like a better experience, you can try iFlow CLI.

于是引出了iFlow这个平台（及其cli工具），上面有很多大模型，好像都是免费，我原本准备用siliconFlow的，发现很多收费不便宜（而且都是流量计费，不比国外的便宜）。

为什么能这么做？我问了Kimi：

claude-code-router 是一个「零配置」反向代理 + 动态路由网关，让你把 Claude Code（只认 Anthropic 格式）无缝对接到 任意 OpenAI/Anthropic 兼容端点，并且支持：

  • 多模型负载均衡

  • 自动重试 / 降级

  • 免费额度聚合（核心卖点）

一句话：iflow 把「免费」当拉新手段，且机房资源自建，烧得起；对路由器作者来说，免费池越深，项目吸引力越大，所以文档里 80% 示例都以 iflow 为默认上游。

风险与注意

  1. 免费池随时可能缩紧
    iflow 用户协议留了一条「平台有权调整免费额度」，路由器作者已做「自动感知下线」，但仍建议关键业务留 1 个付费 key 做兜底。

  2. 数据合规
    iflow 目前未披露等保/SOC 报告，金融、医疗、政府项目慎用。

  3. 速率突发
    免费节点不保证 SLA，大促/新模型开放日容易出现 30-60 s 的排队，路由器会降级，但体感仍比直连慢。

结论速记

  • claude-code-router = 免费额度聚合器 + 智能降级网关

  • iflow.cn 之所以被力推，是因为「模型多、额度大、不限速、续命玩法多」

  • 个人/原型阶段，用路由器+iflow 基本可以实现「0 元跑 Claude Code」；生产环境务必加至少 1 个付费上游做兜底。

kimi所说的这些免费额度和原因等，我在iflow官网均为见到。 但确实也没找到额度限制和实际使用的收费情况，只有个token记录页面，对一个expo app老项目init一下生成CLAUDE.md就用了差不多60k tokens。

最后提一下，Silicon Flow官方也支持快速配置集成进Claude Code的，这里

供应商转换器（Transformers）​

在配置上面的集成国产大模型过程中，遇到的概念。 大体如下：

在 CCR（claude-code-router）UI 里看到的「供应商转换器」其实就是一个请求/响应格式转换器。
它的作用只有一句话：
把 Claude Code 发出的“Claude 原生格式”请求，转成目标厂商能识别的格式；再把厂商回包转成 Claude 能解析的格式。

  • Claude Code 本体只认 Anthropic 的 /v1/messages 接口格式（message create 那套）。

  • 市面上绝大多数中转站或国内平台只提供 OpenAI 格式（/v1/chat/completions）或 Gemini 原生格式（/v1beta/models/…）。

  • 如果不做转换，直接转发就会 404 或报 “model not found”。

因此 CCR 内置了 3 种现成的「供应商转换器」：

  1. Anthropic
    几乎不改包，仅替换 key、base_url，适用于官方 Claude 或已经“原生兼容 CC”的渠道。

  2. OpenRouter / OpenAI
    把 claude 的 message create 请求转成 OpenAI 的 chat completions 格式；回包再把 choices[0].message.content 映射回 content 数组。

  3. Gemini
    把请求转成 Gemini 的 generateContent 格式，并处理候选回复、安全过滤等字段。

在 UI 里怎么选​

  • 如果你的地址以 /v1/chat/completions 结尾 → 选 OpenRouter（或 OpenAI）。

  • 如果以 /v1beta/models/ 结尾 → 选 Gemini。

  • 如果平台声明“已支持 Claude Code 原生接口” → 选 Anthropic。

我遇到的全是OpenAI格式。

哪些模型支持webSearch​

CCR的配置中会有专门webSearch设置，但哪些模型是支持的呢？ 在Silicon Flow中有时提到网页浏览、搜索等字样，但不清晰。 kimi这样回答的，但我现在非常不信任它：

截至 2025-10 月，官方自带“联网搜索（webSearch）”能力、且国内开发者可直接调用的模型只有下面几类，其余都需要自己在网关层再包一层 Bing/Google 搜索 API 才能算“支持”。

  1. OpenAI 官方

    • gpt-4.1

    • gpt-4o
      其余（o3 / o3-mini / o4-mini 等）均不支持 web-search 工具，会直接报错 Hosted tool 'web_search_preview' is not supported

  2. Google Gemini 系列

    • gemini-2.5-pro

    • gemini-2.5-flash
      在 CCR 里只要把 webSearch 路由指到这两个模型即可生效，官方已内置实时搜索插件

  3. 百度智能云千帆

    • ERNIE-X1-Turbo-32K
      通过入参 web_search=true 开启联网，搜索源为百度自家索引

  4. 智谱 GLM-4-Flash-250414
    官方文档写明“实时网页检索”能力，且模型本身免费，但搜索端有 QPS/额度限制

  5. Ollama 生态
    0.4.x 版本后提供统一的 Web-Search API，凡是跑在 Ollama 上的模型（qwen2.5、llama3.3、gemma2 等）只要上下文够长（≥32 k）都可“一键”获得联网能力；不过搜索服务需要自己在后台配 Bing/Google Key

一句话总结
真正“原生”就带联网搜索、且国内直接能调用的：
gpt-4.1 / gpt-4o、gemini-2.5-pro/flash、ERNIE-X1-Turbo、GLM-4-Flash-250414，以及 Ollama 0.4+ 上的所有模型（需自配搜索 Key）。
除此之外的“国产大模型”要想联网，都得自己再包一层搜索 API。