我 2 月 26 日买一个月都 pro 套餐，只给了 28 天。
我记得以前买的会员服务，最低按月是 30 天的，我同样的价格，不同月份居然得到的东西还不一样。
 |
1
lzoje 15 小时 33 分钟前
逻辑不会是月份加一日期不变吧
|
 |
2
malusama 15 小时 33 分钟前
乐死了，是因为 2 月份只有 28 天，2 月份买就只给 28 天么。 是不是 vibe codeing 出来的代码
|
 |
3
LMark 15 小时 28 分钟前
而且据说还是量化模型
|
 |
4
drainlin 15 小时 25 分钟前
我昨天缴停车费包月也是这个逻辑，无语
|
 |
5
viking602 15 小时 12 分钟前
我买的时候看到这个也挺无语的
 |
 |
6
zw2019 15 小时 11 分钟前
一样一样的
|
 |
7
Inn0Vat10n 15 小时 9 分钟前
你反馈给经理, 会补偿的
|
 |
8
subpo 15 小时 7 分钟前
可以了，毕竟给 18000 次请求，给 deepseek 买 8 个 lite 套餐，都可以直接蒸馏 claude 了 （狗头
|
 |
9
280303 15 小时 4 分钟前
晚两天在下手
|
 |
11
mogutouer 14 小时 56 分钟前
他选择二月运营这个活动，还少给两天，不知道是故意还是不小心的。太小气了。
我昨天又买了试了一下，就是在 chrome 里写个扩展，让他读取余量信息显示。 结果搞了好几个小时 k2.5 搞不定，M2.5 也不行，glm5 更白搭，他自己的 qwen3.5 也不行，感觉这些模型都是阉割版的，最后用 codex 搞出来的。 分别用他们几个尝试读 html 解析，读那个 zeldaEasy.broadscope-bailian.codingPlan.queryCodingPlanInstanceInfoV2 接口，尝试失败后让他们自己定方案，都没完成。要么是接口参数没存对，要么是 html 处理有问题（那个用量弹窗要鼠标经过才会出现）。 总之试下来，国产也就跑分强点，实际用起来都白搭啊，劝各位生产力还是直接上 claude 或 codex 。 |
 |
12
urlk 14 小时 38 分钟前
还真是 ...
|
 |
13
Curtion 14 小时 33 分钟前
这还真是一个值得仔细思考的问题，我之前还好奇为什么腾讯视频开通一年会有 372 天,多了一周，原来每个月都按 31 天来算的
|
 |
14
xiaoxiaomingming 14 小时 14 分钟前
每个月 30 天计算，1 年是 360 天
每个月按照实际天数计算，1 年是 365 天或者 366 天 |
 |
15
surfwave 14 小时 3 分钟前
minimax 的 coding plan 是按照 30 天一个月来计算的，而不是按照自然月的对日。这种 28 天的月计划确实不公平。
|
 |
16
crytis 14 小时 2 分钟前
无所谓，你就差那几天么，没到时间早就用完了
|
 |
17
dassh 13 小时 55 分钟前  2
其实它可能是按自然月的一种算法，也没错，不然会出现一些反直觉的东西：
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 日 |
 |
18
SkywalkerJi 13 小时 29 分钟前
2 月份买，就给 28 ，太抠了。
|
 |
19
selca 13 小时 29 分钟前
我还去问了我的客服，他说这是个好问题。
然后没有下文了 |
|
20
selca 13 小时 27 分钟前
|
 |
21
rmrf 13 小时 22 分钟前
火山和阿里云都买了，火山多一天，是 29 天 [哈哈]
|
 |
23
fcten 13 小时 5 分钟前
CodingPlan 不是主要看限额的吗，限额用完了，不是早点重置更好？如果限额都用不完……不如考虑按量付费的 api 吧
|
 |
24
w169q169 12 小时 57 分钟前 3
除了上面说的那个问题，还有其他坑
 它宣传支持 minimax 、glm 、kimi ，看着挺全，但实际体验真的不行，实际上只能用 qwen3 。最大的问题是不是阿里的模型，完全吃不到 cache 。 本质上它就是把各家厂商的 API 聚合在一起，然后用多个 token 做负载均衡。 问题来了 —— 缓存是按 token 维度算的。 一请求，它随机用不同 token 去打后端： 每个 token 都是“新用户” 每次都是全量重算 根本没有历史 cache 命中 用那种大上下文模型（比如 claude-code 这种动不动几十 k context 的）基本直接起飞。 没 cache 的情况下，全量推理一次，30 秒起步都算客气的。 体验就是：又慢，又贵，还不稳定。 还有一个更骚的操作 —— 它会额外做一层敏感词检测。 只要触发，它直接给你 403 。 我就在 openclaw 问了一句 polymarket 上美伊战争的赔率是多少，结果直接给我禁了。 后面啥都问不了，一直 403 。 |
 |
25
Breacher 12 小时 34 分钟前
作为一个程序员，不得不说，按月订阅使用自然月而不是固定的 30/31 天去计算这样子最方便省事，直接使用编程语言的标准库去计算下一个周期的开始日期就好了。毕竟如果按照固定 30 天，一年下来用户还是少了几天；如果固定 31 天那么一年下来又给用户多了几天。前提是得说清楚，明确告知用户。
|
 |
26
zerovoid 12 小时 17 分钟前
阿里的逻辑应该是这样的，
你 2 月 26 日买一个月，那他就给你开到 3 月 26 日， 但是 2 月份只有 28 天，那就感觉比 30 天少 2 天了。 |
 |
27
yeh 11 小时 48 分钟前
阿里基操是这样子的，连续包月，一年后发现实际只给了 360 天，5 年能多出来一个月。
发现这个事也挺巧的，习惯性记账，然后发现每个月的实际扣款日慢慢提前了。 |
 |
29
Semantic 11 小时 22 分钟前
隔壁实测，套路云 的 GLM-5 上下文只有 73728 tokens 。这种长度根本没法干活
|
 |
30
jobives2023 11 小时 16 分钟前
有些国内的模型是看起来单价便宜，但实际消耗很多 token ，去年买过一次 kimi 的模型用在 claude code 测试了一下，一个 BUG 跑了 30 多块钱还没搞定，换成 claude 模型 5 分钟就解决了
|
 |
31
lijunjieone 10 小时 54 分钟前
我觉得 kimi 好像更坑，我买了一个月的，一会小时限制，一会频率限制，一会周限制到期。改成 qwen3.5 还是可以用的。
|
 |
32
realpg PRO 还是腾讯系到位, 记得以前就他家的给的足, 按月就 31 天 按年就 366 天.
|
 |
33
cloverzrg2 9 小时 57 分钟前
cursor 这个月也是 28 天吧
|
 |
34
yean 9 小时 50 分钟前
AI 变现，也是应该的
|
|
35
mogutouer 9 小时 44 分钟前
@dassh #17 都没毛病，问题出在他不是显示下个月几号到期，而是显示剩余 XX 天，导致这种感觉加重。这是典型的靠信息输出和设计就能解决的问题，他非要选一个最得罪人的方式。
|
 |
36
win8en 9 小时 40 分钟前 via Android
我买完在 opencode 里面没办法用，不知道咋回事，明天再看看
|
 |
37
liuliuliuliu PRO 有很多都是按自然月算的，腾讯云 cloudbase 也是自然月
|
 |
38
wang93wei 8 小时 35 分钟前
其实理论上按自然月算挺合理的，，，
|
 |
39
joynvda 8 小时 18 分钟前
今天通过阿里云的 coding plan 调用 glm-5; 结果报了个上游额度用满了（大概的意思，当时在办公室跑 cc ）。
我心想阿里的 coding plan 在 bigmodel 的下游？ |
 |
40
BeiChuanAlex 7 小时 44 分钟前
这里体现出一个有意思的细节，腾讯是算 31 天的，它是做游戏的，阿里是做电商的，按照自然月算。
因为做游戏如果你按照自然月算，那玩家就要跳起来了  |
|
41
BeiChuanAlex 7 小时 43 分钟前
@wang93wei #38 不合理，产品这么设计容易引起用户反感，因为与心理预期不一致
|
 |
42
CC11001100 5 小时 2 分钟前
@dassh 这个处理就很简单啊，对于按月订阅，非 2 月份按自然月来跟之前一样，2 月份订阅直接补 1 天或者 2 天就完事儿了（考虑闰年，补到最低 30 天别让用户觉得自己吃亏了就行了），用户要是觉得这里有漏洞可以占便宜了，非要一个月一个月的续也行，但是通常按年付费本身就自带了很大力度的折扣足以抵消没有必要这样折腾算下来并不划算，所以对于年付用户来说并没有吃亏，月付和年付都可以平衡，核心利益点在于厂商愿不愿意让渡这个利益来换取更多的用户支持（火山引擎好像已经在让渡这几天了缺的在补了），按自然月这个出发点很有道理很有逻辑，但是做生意更多的是考虑人的角度，就是要让客户觉得占到便宜了他才乐意屁颠屁颠长长久久持续支持你的产品 😅
|
Select Language