同一個付費服務，有兩種呼叫方式，各自宣稱吃不同的預算池。帳面上該扣的那一池完全沒動，另一筆加購額度卻在悄悄減少。照說明文字推出第一個解釋，把加購上限調大；兩小時後發現對不上，又推出相反的第二個解釋，一樣錯。一個早上，錯了兩次。
這像是懷疑家裡哪台電器最耗電。研究說明書上標的瓦數，永遠比不上把全部電源關掉、記下電表數字，再一台一台開來看表跳多少準。計費和配額這類外部黑箱也是同樣道理——文件寫的是「典型用法」，用的入口未必落在那個分類裡。說明文字只能當假設來源，不能當結論。
分界點在哪裡
第三次，放棄再讀文件，改成做實驗。先讓系統完全靜止，把所有讀數記下來當基線；再用其中一個入口丟一筆最小、唯讀、幾乎不花成本的工作，只盯著「哪一個數字動了」。換另一個入口，重做一次。兩輪測完，哪個入口吃哪個池，一目了然，而且可重複驗證。分界點不在讀懂文件的哪一句話，而在有沒有把系統逼到「乾淨」的狀態去看因果。
容易誤判在哪三個地方
第一，把官方說明當成實作本身。計費文件通常只描述最常見的那條路徑，當下用的入口可能根本不在那個描述範圍內。第二，系統還有背景活動時盯讀數，噪音會讓因果關係被挑選性解讀——這也是確認偏誤最容易發作的場景。第三，讀數本身有延遲與快取；一開始每二十秒抓一次用量，直接被限流鎖了十幾分鐘，反而更看不清楚，後來改成每兩分鐘一次才穩定下來。
怎麼確認是真因
三個條件缺一不可：靜止基線、單一變因（一次只動一個入口）、反向驗證（換一個入口重測，看數字會不會換邊跳）。還有一件事得老實面對——同一服務的命令列、程式介面、網頁後台，可能各走各的計費路徑。這次只量清楚其中兩個，第三個沒測，就該老實記成未知，不外推成「大概也一樣」。
留給下一次的提醒
推論期間做的所有配置變更，都該標成暫時、可一鍵收回的狀態。錯誤推論的代價不只是認知偏差——它會讓人在當下就去調高上限、核准預算、改派工策略，等於把一個還沒驗證的假設，直接寫成了正在生效的設定。花二十分鐘做一次可重複的小實驗，比讀兩小時說明文字可靠。文件負責提出假設，實驗才負責給答案。
— 邱柏宇
One Bill, Two Entry Points, Two Wrong Guesses
A single paid service exposes two different ways to call it, each supposedly drawing from its own budget pool. The pool that should have dropped stays flat. A separate top-up balance quietly drains instead. The first reading of the documentation produces one theory, so the top-up ceiling gets raised. Two hours later the numbers still don’t line up. A second, opposite theory gets tried. Also wrong. Two mistakes before lunch.
It’s the same problem as guessing which appliance drives up the electric bill. Reading the wattage printed on the label never settles it as cleanly as cutting all power, writing down the meter, then switching devices on one at a time to watch the number move. Billing and quota systems are the same kind of external black box — the docs describe the typical usage path, and the thing being called may not sit on that path at all. Documentation is a source of hypotheses, not a conclusion.
Where the line actually falls
On the third attempt, reading stopped and testing started. Let the system sit completely idle, record every readout as a baseline. Send one minimal, read-only, near-zero-cost job through one entry point, watch which number moves. Repeat through the other entry point. Two passes in, the attribution is obvious — and repeatable. The turning point isn’t a better sentence in the manual. It’s whether the system was driven into a clean, idle state before anyone tried to read cause and effect out of it.
Three ways to misread it
First: treating the official description as the implementation itself. Billing docs usually describe the most common path; the entry point in use may not belong to that category at all. Second: watching readouts while background activity is still running — noise lets confirmation bias pick whatever causal story looks right. Third: the readouts themselves lag and cache. Polling usage every twenty seconds triggered a rate limit that locked the whole thing out for over ten minutes — slower is what actually worked, settling into a two-minute interval.
How to confirm it’s real
Three conditions, none optional: an idle baseline, a single variable (move one entry point at a time), and reverse verification — swap the entry point and see if the number that moves switches sides. One more thing worth admitting: the same service’s command line, SDK, and web console may each route through a different billing path. Only two of those got measured this time. The third stays marked unknown. No extrapolating “probably the same.”
What’s worth keeping for next time
Every configuration change made during the investigation phase should be flagged temporary and reversible in one step. A wrong inference doesn’t just cost a cognitive bias — it gets written straight into live settings: ceilings raised, budgets approved, dispatch strategy changed, all based on a guess that hadn’t been checked yet. Twenty minutes of a repeatable experiment beats two hours of reading. Documentation proposes. The experiment decides.
— 邱柏宇
延伸閱讀
https://justfly.idv.tw/s/CVUbFCZ