他选择二月运营这个活动，还少给两天，不知道是故意还是不小心的。太小气了。 我昨天又买了试了一下，就是在 chrome 里写个扩展，让他读取余量信息显示。 结果搞了好几个小时 k2.5 搞不定，M2.5 也不行，glm5 更白搭，他自己的 qwen3.5 也不行，感觉这些模型都是阉割版的，最后用 codex 搞出来的。 分别用他们几个尝试读 html 解析，读那个 zeldaEasy.broadscope-bailian.codingPlan.queryCodingPlanInstanceInfoV2 接口，尝试失败后让他们自己定方案，都没完成。要么是接口参数没存对，要么是 html 处理有问题（那个用量弹窗要鼠标经过才会出现）。 总之试下来，国产也就跑分强点，实际用起来都白搭啊，劝各位生产力还是直接上 claude 或 codex 。
其实它可能是按自然月的一种算法，也没错，不然会出现一些反直觉的东西： 1. 这个月 5 号买的，下月 5 号过期，很直觉 2. 2026 年 2 月 26 号买的一年，2027 年 2 月 26 号到期 （如果按 30/月，31/月这种写死的方法，就难做到了） 与下是 AI 回复的： Stripe 按月订阅的自然月逻辑是：以订阅创建日为锚点（ billing cycle anchor ），后续每个月都取该月中最接近锚点日的那一天；当月没有该日时，自动取当月最后一天 Stripe 。 你的例子（ 1 月 31 日订阅） 订阅创建日：1 月 31 日（锚点日 = 31 日） 下一个周期：2 月 28 日（ 2026 年为平年，2 月只有 28 天） Stripe 下下个周期：3 月 31 日（ 3 月有 31 天，回到 31 日） Stripe 通用规则（按月订阅） 锚点日 = 订阅创建日（默认） Stripe 后续每个月： 若当月天数 ≥ 锚点日 → 按锚点日扣费 Stripe 若当月天数 < 锚点日 → 按当月最后一天扣费 Stripe 其他常见示例 3 月 31 日订阅 → 4 月 30 日 → 5 月 31 日 → 6 月 30 日 2 月 29 日（闰年）订阅 → 3 月 29 日 → 4 月 29 日 → 5 月 29 日
