一個不能被 24 整除的數字：5 小時限額，是一套被算準的時間介面

2026 年 9 月 21 日晚間，V2EX 上出現了一則看起來像碎念的提問：「為什麼是 5h 限額，而不是 6h、4h、3h 限額呢？」發文者剛好在跟 AI 工具的用量額度搏鬥。這則帖子在一天內累積了五千多次瀏覽、三十五則回覆，最後變成一場關於數字選擇的集體解謎。表面上是工程師在抱怨額度不夠用，實際上被攤開來檢視的，是一個極小的設計決策：一個訂閱服務把重置週期設成幾小時，以及這個數字對使用者行為的影響。

先把 5 這個數字放進算式裡

討論串裡最有意思的一則回覆，來自一位 Android 使用者。他的猜想是：5 是附近幾個整數裡唯一不能整除 24 的選項。4 小時一天重置六次，6 小時一天四次，8 小時一天三次，每一天的節奏都會對齊。只有 5，會讓每天的刷新時間往前漂移五小時，使用者的體感是「今天中午刷新，明天變成清晨，後天又跳到深夜」。

這個觀察把問題從「額度給多少」轉到了「時間如何被排版」。一個能被 24 整除的週期，使用者可以寫一支簡單的定時腳本，每天固定時刻等額度回來，生活會長出一個穩定的節拍。5 小時的漂移打斷了這件事。原發文者後來回覆證實了這個困擾：他想寫腳本在某個時間點觸發刷新，結果發現必須替漂移留出幾小時的空檔，整個自動化方案變得彆扭。

從介面設計的角度看，這是一種刻意的不可規劃性。使用者無法把額度嵌進自己的作息，每次碰到額度用罄，面前只有兩個選項：等一段說不準多久才會回來的時間，或者升級方案。當等待本身無法被排程，等待的成本就被墊高了。

為什麼不是 4，也不是 7

討論串裡另一條線索同樣具體。有人指出 4 小時刷新會跟上班族的上午、下午節奏完美銜接，等於讓使用者在工作時段內穩定拿到兩三個完整週期，對服務方來說太劃算使用者了。反方向也有人提到，如果是 7 小時，週期太長，使用者在單位時間內碰壁的次數太少，付費升級的動機反而被稀釋。5 剛好卡在中間：短到讓人一天內反覆撞牆，長到讓每次撞牆都伴隨一段「再等一下說不定就好了」的期待。

一位回覆者把這層心理講得相當直白：如果是 8 小時限制，用完你就知道今天指望不上了；5 小時限制給你留了一點念想。這句話其實道出了限額設計的核心：額度從來都是期望管理工具，數字的選擇決定了使用者在碰壁那一刻的心理狀態。絕望讓人離開，念想讓人留下並考慮付費。

也有更務實的聲音。有人認為這只是產品團隊的幸運數字，有人說換成 6 小時使用者一樣會發帖問為什麼不是 5。這類回覆提醒我們不要過度解讀單一數字。但即使動機是隨手的，效果是結構性的：一個不能整除 24 的重置週期，客觀上就是讓任何穩定的個人排程失效，這一點不因為設計者有沒有惡意而改變。

使用者的反制，與反制暴露的東西

帖子下半段幾乎是一場民間工程展演。有人每天早上五點半設一個定時任務，讓服務在額度就緒時發一條通知，然後把可用窗口手動排成 8:00 到 10:30、10:30 到 15:30、15:30 到 20:30 三段。有人直接用 AI 幫自己配了一個偵測額度到期、自動回覆確認訊息的腳本，甚至有人把這套工具開源放上 GitHub，支援了幾種不同的客戶端。

這些 workaround 本身就是一份使用評測。當一羣技術使用者願意花一個晚上寫腳本去馴服一個 5 小時的週期，說明這個額度對他們的日常工作已經有實質重量，同時也說明原生介面沒有給出他們需要的資訊：刷新的確切時刻、剩餘的估算、以及一段可預期的等待。工具的價值在於可預期，這也是為什麼圍繞 AI 工具的信任與選擇，最後常常落到介面細節上，這與我們先前在智譜 zcode 上傳 git 記錄事件裡看到的邏輯一致：使用者判斷一個工具能不能託付，依據的從來都是那些被攤在陽光下的小設計。

數字是一種態度

把視野拉寬一點，訂閱制的限額設計一直在「慷慨」與「稀缺」之間找位置。給太多，付費方案失去意義；給太少，免費使用者直接流失。多數服務用月配額解決這個問題，一個月一次重置，簡單但粗躁。小時級重置是更精細的做法，它把「不夠用」的體感切成小塊，分散在一天裡反覆出現，每次都附帶一次升級的提醒。這套機制可以做得透明，也可以做得模糊，而重置時間會不會漂移，正是透明與模糊之間的那條線。

一個數字的選擇，最終是一種對使用者的假設。4 小時假設你希望被順著作息照顧，8 小時假設你一天只需要一次機會，5 小時假設你會為了不確定的等待反覆回到那個介面面前。V2EX 這則帖子可貴的地方在於，它把一個通常不被討論的數字放回了設計層面來審視。那個數字本身沒有對錯，但它值得被問一句為什麼。這次被問了，答案藏在算式裡，也藏在每一個開始寫定時腳本的人身上。