阿里云 CodingPlan 计划太坑了吧

[fingerxie]

我 2 月 26 日买一个月都 pro 套餐，只给了 28 天。

我记得以前买的会员服务，最低按月是 30 天的，我同样的价格，不同月份居然得到的东西还不一样。

[lzoje]

逻辑不会是月份加一日期不变吧

[malusama]

乐死了，是因为 2 月份只有 28 天，2 月份买就只给 28 天么。 是不是 vibe codeing 出来的代码

[LMark]

而且据说还是量化模型

[drainlin]

我昨天缴停车费包月也是这个逻辑，无语

[viking602]

我买的时候看到这个也挺无语的

[zw2019]

一样一样的

[Inn0Vat10n]

你反馈给经理, 会补偿的

[subpo]

可以了，毕竟给 18000 次请求，给 deepseek 买 8 个 lite 套餐，都可以直接蒸馏 claude 了 （狗头

[280303]

晚两天在下手

[pigf]

@drainlin +1

[mogutouer]

他选择二月运营这个活动，还少给两天，不知道是故意还是不小心的。太小气了。

我昨天又买了试了一下，就是在 chrome 里写个扩展，让他读取余量信息显示。
结果搞了好几个小时 k2.5 搞不定，M2.5 也不行，glm5 更白搭，他自己的 qwen3.5 也不行，感觉这些模型都是阉割版的，最后用 codex 搞出来的。
分别用他们几个尝试读 html 解析，读那个 zeldaEasy.broadscope-bailian.codingPlan.queryCodingPlanInstanceInfoV2 接口，尝试失败后让他们自己定方案，都没完成。要么是接口参数没存对，要么是 html 处理有问题（那个用量弹窗要鼠标经过才会出现）。

总之试下来，国产也就跑分强点，实际用起来都白搭啊，劝各位生产力还是直接上 claude 或 codex 。

[urlk]

还真是 ...

[Curtion]

这还真是一个值得仔细思考的问题，我之前还好奇为什么腾讯视频开通一年会有 372 天,多了一周，原来每个月都按 31 天来算的

[xiaoxiaomingming]

每个月 30 天计算，1 年是 360 天
每个月按照实际天数计算，1 年是 365 天或者 366 天

[surfwave]

minimax 的 coding plan 是按照 30 天一个月来计算的，而不是按照自然月的对日。这种 28 天的月计划确实不公平。

[crytis]

无所谓，你就差那几天么，没到时间早就用完了

[dassh]

其实它可能是按自然月的一种算法，也没错，不然会出现一些反直觉的东西：
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 日

[SkywalkerJi]

2 月份买，就给 28 ，太抠了。

[selca]

我还去问了我的客服，他说这是个好问题。
然后没有下文了

[selca]

@selca #19 准确来说，是客服给我说了就是因为 2 月只有 28 天后，咱就没聊后续内容了。
https://imgur.com/a/qC1fUWV