接入大模型一个月后 API 账单暴涨 20 倍:一次 token 计费与上下文膨胀的复盘

2024 年,一次"我们的产品接入大模型对话功能,第一个月账单还好,第二个月直接暴涨了 20 倍"的事故,把我对"成本"这件事的理解,从头到尾翻新了一遍。我们在产品里加了个 AI 对话助手,接的是按 token 计费的大模型 API。第一个月账单下来,在预算之内,我很安心。第二个月,财务找上门:这个月的 API 账单,是上个月的【20 倍】。我第一反应是:用户涨了呗,业务做大了,成本跟着涨,天经地义。可我一拉数据就僵住了——同期我们的日活,只涨了大约 2 倍。用户 2 倍,成本 20 倍。这两个数字,怎么都对不上。如果成本是跟着用户走的,那它该涨 2 倍才对;它涨了 20 倍,意味着【每个用户身上,我们花的钱,也翻了快 10 倍】。可我们没改过价、没换过模型、没加过功能。同样是一个用户来聊天,凭什么这个月比上个月贵 10 倍?这 10 倍,是凭空冒出来的吗?如果成本不是简单地"按用户数线性增长"——那它到底是按【什么】在增长?我心里那个"用户多一倍、成本多一倍"的朴素假设,显然在什么地方,被狠狠打脸了。这件事逼着我把 token 到底是什么、大模型 API 为什么是无状态的、多轮对话的成本为什么会随轮数【平方】增长、上下文该怎么裁剪,彻底理清了。本文复盘这次实战。

问题背景

环境:产品里一个 AI 对话助手,接按 token 计费的大模型 API
事故现象:
- 第一个月账单:正常,在预算内
- ★ 第二个月账单:暴涨约 20 倍
- 但同期日活只涨了约 2 倍 —— 用户 2 倍,成本 20 倍

现场排查:
# 1. ★ 先拆开:是"调用次数"涨了,还是"单次成本"涨了
#    总成本 = 调用次数 × 单次平均 token 数 × 单价
$ 统计两个月的 API 调用日志
# 调用次数:涨了约 2.5 倍(和用户增长大致匹配,正常)
# ★★ 单次调用的平均 token 数:涨了约 8 倍 —— 问题在这

# 2. ★ 单挑一个长对话,逐轮看每次调用的 input token
$ 逐轮打印 input token 数
# 第 1 轮   input    320 tokens
# 第 2 轮   input    680 tokens
# 第 10 轮  input   4100 tokens
# 第 30 轮  input  13800 tokens     # ★★ 同一个对话,越聊越贵

# 3. ★★ 关键:看我们发给大模型的请求体长什么样
# messages: [
#   {role: system,    content: "你是..."},          # 系统提示
#   {role: user,      content: "第 1 轮问题"},
#   {role: assistant, content: "第 1 轮回复"},
#   {role: user,      content: "第 2 轮问题"},
#   {role: assistant, content: "第 2 轮回复"},
#   ... 一直堆到最新一轮 ...
# ]
# ★★ 每一轮调用,都把"从头到现在的完整对话历史"全发了一遍

根因(后来想清楚的):
1. ★ 大模型的对话 API 是【无状态】的 —— 它不记得你
   上一轮说过什么。
2. ★ 要让它"记得"上下文,只能每一轮,都把【完整的
   对话历史】重新发一遍。
3. ★★ 于是第 N 轮调用的 input,≈ 前面 1~N 轮所有内容
   的总和。对话越长,单轮越贵。
4. ★★ 一个 N 轮对话,发出去的 token 总量 ≈ 1+2+...+N,
   是【N 的平方】级别 —— 不是 N 的线性级别。第 1 轮
   那句话,在 30 轮对话里被重复发送了 30 次。
5. ★ 用户涨 2 倍 + 人均对话轮数也涨了 + 每个对话内部
   成本随轮数平方涨 —— 三个因子相乘,2 倍用户撑出
   20 倍账单。
6. ★ 还有帮凶:没设 max_tokens、失败重试无限叠、所有
   请求都用最贵的模型。
真相:token 是计费单位,多轮对话每轮重发完整历史,
让总成本随轮数【平方】增长。不裁上下文,账单必爆。

修复 1:账单暴涨——先拆成"调用次数"和"单次 token"

# === ★ 成本出问题,第一刀:把总成本拆成两个因子 ===

# === ★ API 总成本的构成 ===
# ★ 总成本 = 调用次数 × 每次平均 token 数 × token 单价
# ★ 单价一般是固定的(没换模型的话)。所以账单暴涨,
#   要么是【调用次数】涨了,要么是【单次 token 数】
#   涨了 —— 先分清是哪个,这俩的病因和解法完全不同。

# === ★ 因子 A:调用次数涨了 ===
# ★ 调用次数涨,可能是:
#  - 正常:用户变多、用户用得更勤;
#  - ★ 异常:失败重试风暴、某段代码死循环调 API、
#    定时任务配错频率 —— 这些会让次数毫无道理地暴涨。
# ★ 判断:把"调用次数的增长"和"用户量的增长"比一比。
#   次数涨幅 ≈ 用户涨幅 -> 正常;次数涨得远超用户
#   -> 去抓异常调用源。

# === ★★ 因子 B:单次调用的 token 数涨了 ===
# ★ 单次 token 涨,意味着你【每次喂给模型的东西变多了】。
#   这几乎一定是【架构 / 代码问题】 —— 比如上下文越堆
#   越长、prompt 越写越臃肿、塞了不该塞的大段文本。
# ★ 本文就是这一类。

# === ★ 把这两个数,分别统计出来 ===
# ★ 别只看账单总额。从调用日志里,把这两个维度
#   【分别】拉出来,按月 / 按天对比:
#  - 每天的 API 调用【次数】;
#  - 每次调用的【平均 input token】和【平均 output token】。
# ★ 本文一拉就清楚了:次数涨 2.5 倍(和用户匹配,
#   正常),但单次 token 涨了 8 倍 —— 矛头明确指向
#   "单次 token",根因在"我们喂进去的东西"。

# === 认知 ===
# ★ API 账单暴涨,第一刀把总成本拆成两个因子:调用
#   【次数】 × 单次【token 数】。次数涨且涨幅匹配用户
#   增长是正常,远超用户增长要去抓重试风暴/死循环等
#   异常调用源;★ 单次 token 涨意味着"每次喂给模型的
#   东西变多了",几乎一定是架构/代码问题。务必从日志
#   里把这两个维度【分别】统计出来对比,别只盯账单总额。

修复 2:核心根因——大模型无状态,每轮重发完整历史

# === ★ 这一节是全文核心:成本为什么随轮数"平方"涨 ===

# === ★★ 一个最容易被忽略的事实:对话 API 是"无状态"的 ===
# ★ 你以为大模型 API 像聊天软件:它记着你们的对话,
#   你接着说就行。★ 错。大模型的对话 API,是【无状态】
#   的 —— 你这一次调用,它【完全不记得】你上一次
#   说过什么、它上一次回过什么。
# ★ 那多轮对话的"记忆"从哪来?★★ 全靠【你自己】,
#   在每一次请求里,把【从头到现在的完整对话历史】
#   重新打包发一遍。模型每次都是"读完你发来的全部
#   历史,再接最后这一句话"。

# === ★★ 于是,成本的真相浮出水面 ===
# ★ 假设每一轮(一问一答)的内容大致是 T 个 token:
#  - 第 1 轮调用:发 ≈ 1×T(就本轮);
#  - 第 2 轮调用:发 ≈ 2×T(第 1 轮 + 第 2 轮);
#  - 第 N 轮调用:发 ≈ N×T(第 1~N 轮全部)。
# ★ ★ 整个对话累计发出去的 token:
#   T×(1 + 2 + ... + N) = T × N×(N+1)/2
#   —— 这是【N 的平方】级别,不是 N 的线性级别!
# ★ 换个直白说法:第 1 轮你说的那句话,在一个 30 轮
#   的对话里,被你【重复发送了 30 次】,每一次都
#   按 token 实打实地计费。

# === ★ 这就解释了"用户 2 倍、账单 20 倍" ===
# ★ 账单的膨胀,是三个因子【相乘】的结果:
#  - ① 用户数:涨了约 2 倍;
#  - ② 人均对话轮数:用户用顺手了,聊得更长,也涨了;
#  - ③ ★ 每个对话【内部】,成本随轮数【平方】增长。
# ★ 2(用户) × 更长的对话 × 平方膨胀 —— 三者一乘,
#   2 倍用户撑出 20 倍账单,数学上毫不奇怪。
# ★ ★ 我那个"用户翻倍、成本翻倍"的线性直觉,错就
#   错在:它只看见了因子 ①,完全没看见 ② 和 ③ ——
#   尤其是 ③ 那个藏在每个对话内部的平方增长。

# === 认知 ===
# ★★ 大模型对话 API 是【无状态】的,它不记得上一轮 ——
#   多轮对话的"记忆"全靠你每次请求把【完整历史】重发
#   一遍。于是第 N 轮调用要发前 1~N 轮全部内容,整个
#   对话累计发送的 token ≈ N×(N+1)/2,是【N 的平方】
#   级别 —— 第 1 轮那句话在 30 轮对话里被重发 30 次。
#   账单膨胀 = 用户数 × 人均轮数 × 对话内平方增长,
#   三者相乘,"用户 2 倍成本 20 倍"毫不奇怪。

# 直观演示:为什么总 token 是平方级
def total_tokens(n_rounds, tokens_per_round=400):
    sent = 0
    for n in range(1, n_rounds + 1):
        sent += n * tokens_per_round       # 第 n 轮要发前 n 轮全部
    return sent

print(total_tokens(10))    # 22000
print(total_tokens(20))    # 84000    ★ 轮数 ×2,token ×3.8
print(total_tokens(40))    # 328000   ★ 轮数 ×4,token ×14.9
# ★ 轮数翻倍,成本远不止翻倍 —— 这就是平方增长的杀伤力

修复 3:token 到底是什么——你究竟在为什么付钱

# === ★ 既然按 token 计费,先把 token 搞明白 ===

# === ★ token 不是字符,也不是单词 ===
# ★ token 是大模型切分文本的【最小单位】。一个 token,
#   大致是一个常见词、一个词的一部分、或几个字符 ——
#   它介于"字符"和"单词"之间。
# ★ 粗略换算:
#  - 英文:1 token ≈ 4 个字符 ≈ 0.75 个单词;
#  - ★ 中文:1 个汉字,通常要 1~2 个 token —— 也就是
#    说,同样"信息量"的中文,比英文更费 token、更贵。
# ★ ★ 别用"字符数"去估成本,中英文、标点、数字的
#   token 密度都不同,估出来能差很远。要算,就用
#   官方的分词器精确算。

# === ★ input 和 output:分开计费,价格还不一样 ===
# ★ 一次 API 调用,计费分成两块:
#  - input token:你【发进去】的(系统提示 + 对话
#    历史 + 本轮问题),本文暴涨的就是这块;
#  - output token:模型【生成返回】的内容。
# ★ ★ 关键:绝大多数模型,output token 的单价,比
#   input【贵好几倍】。所以"让模型别废话、答得精简"
#   不只是体验问题,也是真金白银的省钱。

# === ★ 还有个硬约束:上下文窗口(context window)===
# ★ 每个模型有个"上下文窗口"上限(比如 8K、32K、
#   128K token)—— 一次调用里,input + output 加
#   起来,【不能超过】这个上限。
# ★ ★ 多轮对话的历史无限往上堆,迟早撞上这个天花板:
#   要么 API 直接报错,要么最早的历史被悄悄截断丢弃
#   (模型"忘事"了)。所以裁剪上下文,不只为省钱,
#   也是【保证功能正确】的硬性需要。

# === 认知 ===
# ★ token 是大模型切分文本的最小单位,介于字符和单词
#   之间:英文 1 token≈4 字符,★ 中文 1 个汉字要 1~2
#   token 更贵 —— 别用字符数估成本,要用官方分词器算。
#   计费分 input(发进去的)和 output(生成的)两块,
#   ★ output 单价通常贵几倍,让模型答得精简也是省钱。
#   另有硬约束:上下文窗口上限,input+output 不能超,
#   历史无限堆会撞天花板报错或丢历史 —— 裁剪上下文
#   既为省钱也为功能正确。

import tiktoken

# ★ 发请求前,先把 token 数精确算出来 —— 让成本"可见"
enc = tiktoken.encoding_for_model("gpt-4")

def count_tokens(messages):
    total = 0
    for m in messages:
        total += len(enc.encode(m["content"])) + 4   # 每条消息有固定开销
    return total

msgs = [{"role": "system", "content": "你是一个客服助手"},
        {"role": "user", "content": "我的订单怎么还没发货"}]
print(count_tokens(msgs))     # 发请求前就知道这次要花多少 input token
# ★ 把这个数打点到监控,成本异常能第一时间发现,别等账单

修复 4:治本——给上下文做裁剪,别无限堆历史

# === ★ 根因是上下文无限膨胀,治本就是给它"裁剪" ===

# === ★ 策略 1:滑动窗口 —— 只保留最近 N 轮 ===
# ★ 最简单直接:每次请求,只发"系统提示 + 最近 N 轮
#   对话",更早的历史直接丢掉。
# ★ N 取多少,看业务对"记忆深度"的需求 —— 客服问答
#   往往最近 3~5 轮就够,N 不必大。
# ★ 效果:单次 token 从"随轮数线性涨"被摁成"恒定"
#   —— 平方增长当场被掐断。

# === ★ 策略 2:按 token 预算裁剪(比"保留 N 轮"更精确)===
# ★ "保留 N 轮"有个毛病:有的轮很短、有的轮很长,
#   按"轮数"裁不够精确。更好的办法:设一个 input
#   token 【预算】(比如 3000),从最新一轮往前累加
#   历史,加到预算上限就停。
# ★ 这样无论每轮长短,单次 input token 都被【钉在
#   预算之内】,成本完全可控、可预测。

# === ★ 策略 3:历史摘要压缩(既要记得久,又要省)===
# ★ 滑动窗口的代价是"忘事"——丢掉的早期历史,模型
#   就真的不知道了。如果业务需要"记得久":
# ★ 做法:把【较早的那段对话】,用模型【总结成一段
#   简短摘要】,后续请求只带"系统提示 + 早期摘要 +
#   最近几轮原文"。记忆基本还在,token 大幅压缩。
# ★ 代价:多一次"做摘要"的调用,且摘要有信息损失。
#   适合长对话场景;短对话用滑动窗口就够,别过度设计。

# === ★★ 别忘了:系统提示也算 token,且每轮都重发 ===
# ★ 那段长长的 system prompt,★ 每一轮调用都被完整
#   发送一次。它要是写了 2000 token,一个 30 轮的
#   对话光系统提示就烧掉 6 万 token 的纯开销。
# ★ 所以:系统提示要【精炼】,别把一大堆例子、规则
#   都堆进去;能放进代码逻辑的别放进 prompt。

# === 认知 ===
# ★ 根因是上下文无限膨胀,治本就是裁剪:① 滑动窗口 ——
#   只保留系统提示 + 最近 N 轮,把单次 token 从"随
#   轮数线性涨"摁成恒定,当场掐断平方增长;② 按 token
#   预算裁剪 —— 设 input token 预算从最新往前累加到
#   上限即停,比"保留 N 轮"更精确可控;③ 历史摘要
#   压缩 —— 把早期对话总结成摘要,兼顾长记忆与省钱,
#   代价是多一次调用且有信息损失。★ 系统提示每轮都
#   重发,务必精炼。

def build_messages(system_prompt, history, new_question,
                   keep_rounds=4, token_budget=3000):
    """滑动窗口 + token 预算,双重裁剪上下文"""
    msgs = [{"role": "system", "content": system_prompt}]

    # ★ 先按轮数裁:只取最近 keep_rounds 轮(一轮 = user + assistant)
    recent = history[-keep_rounds * 2:]

    # ★ 再按 token 预算裁:从最新往前累加,超预算就停
    picked, used = [], count_tokens(msgs)
    for m in reversed(recent):
        t = len(enc.encode(m["content"])) + 4
        if used + t > token_budget:
            break                       # ★ 预算用尽,更早的不要了
        picked.insert(0, m)
        used += t

    msgs += picked
    msgs.append({"role": "user", "content": new_question})
    return msgs

修复 5:其他几个在偷偷烧钱的坑

# === ★ 除了上下文膨胀,这几个坑也在悄悄烧钱 ===

# === ★ 坑 1:不设 max_tokens,模型可能长篇大论 ===
# ★ max_tokens 限制【单次输出】的 token 上限。不设它,
#   模型遇到开放性问题,可能洋洋洒洒输出一大篇 ——
#   而 output token 还是【贵的那部分】。
# ★ 按业务实际需要,给 max_tokens 设一个合理上限。

# === ★ 坑 2:失败重试,叠成"重试风暴" ===
# ★ 调用失败(超时、限流 429)就重试 —— 没问题。但
#   如果重试【没有退避、没有次数上限】:一次服务端
#   抖动,会引发海量重试,每一次重试都是一次实打实
#   的计费调用,账单瞬间被点着。
# ★ 必须:指数退避(等待时间逐次翻倍)+ 最大重试
#   次数上限(如 3 次)。

# === ★ 坑 3:完全相同的请求,没缓存,反复花钱 ===
# ★ 很多问题是高频重复的(FAQ 类、固定指令)。同样
#   的输入,你每次都老老实实调一次 API、付一次钱。
# ★ 做法:对【输入完全相同】的请求,把输出缓存起来,
#   命中缓存就直接返回,不再调 API。

# === ★ 坑 4:杀鸡用牛刀,简单任务也用最贵的模型 ===
# ★ "判断一句话情感正负""抽取几个关键词"这种简单
#   活,也一股脑丢给最强、最贵的旗舰模型 —— 浪费。
# ★ 做法:按任务难度【分级】路由 —— 简单任务用小
#   模型 / 便宜模型,复杂推理才上旗舰模型。

# === ★ 坑 5:别误以为 stream 能省钱 ===
# ★ 流式输出(stream)让用户一个字一个字地、更快
#   看到回复,体验确实更好。
# ★ ★ 但要清醒:stream【不改变 token 总量】,该花的
#   钱一分不少。它是【体验】优化,不是【成本】优化,
#   别指望靠它降本。

# === 认知 ===
# ★ 其他烧钱的坑:① 不设 max_tokens,模型可能长篇大论
#   且 output 贵 —— 设合理上限;② 重试无退避无上限会
#   叠成重试风暴,要指数退避 + 最大次数;③ 完全相同
#   的请求不缓存反复花钱 —— 对相同输入缓存输出;④ 简单
#   任务也用最贵旗舰模型是浪费 —— 按难度分级路由;
#   ⑤ stream 是体验优化不是成本优化,不改变 token
#   总量,别指望它降本。

修复 6:大模型成本排查纪律

# === 这次事故暴露的认知盲区,定几条纪律 ===

# === 1. ★ 账单暴涨先拆因子:调用次数 vs 单次 token 数 ===
$ 从日志分别统计:每天调用次数、单次平均 input/output token

# === 2. ★ 调用次数远超用户增长 -> 抓重试风暴/死循环 ===

# === 3. ★★ 大模型 API 无状态,多轮对话每轮重发完整历史 ===

# === 4. ★★ 多轮对话总成本随轮数【平方】增长,不是线性 ===

# === 5. ★ 上下文必须裁剪:滑动窗口 / token 预算 / 摘要压缩 ===

# === 6. ★ 系统提示每轮都重发,务必精炼,别堆一大篇 ===

# === 7. ★ 发请求前用 tiktoken 算 token 数,打点监控,别等账单 ===

# === 8. ★ 设 max_tokens 上限;重试要指数退避 + 次数上限 ===

# === 9. ★ 相同请求做缓存;按任务难度给模型分级路由 ===

# === 10. 排查"大模型账单暴涨"的步骤链 ===
$ 对比账单与用户增长             # ① 涨幅是否远超用户增长
$ 拆分调用次数 / 单次 token      # ② 定位是次数涨还是单次涨
$ 逐轮打印一个对话的 input token # ③ 看单次 token 是否随轮数膨胀
$ 检查上下文裁剪逻辑             # ④ 有没有无限堆历史
# 加裁剪 -> 单次 token 变恒定 -> 平方增长被掐断 -> 账单回落

命令速查

需求                          做法
=============================================================
拆解账单                      总成本 = 调用次数 × 单次 token × 单价
定位暴涨原因                  分别统计 调用次数 和 单次平均 token
看对话成本膨胀                逐轮打印一个对话的 input token 数
精确算 token                  tiktoken encoding_for_model 分词后计数
裁剪上下文(简单)            滑动窗口:只留系统提示 + 最近 N 轮
裁剪上下文(精确)            按 input token 预算,从新往旧累加到上限
裁剪上下文(长记忆)          早期对话用模型总结成摘要,只带摘要+近几轮
控制输出成本                  设 max_tokens 上限,提示模型答得精简
防重试烧钱                    指数退避 + 最大重试次数上限
省重复调用                    相同输入缓存输出;按任务难度分级用模型

口诀:大模型 API 无状态 多轮对话每轮重发完整历史
      总成本随轮数平方涨 不裁上下文账单必爆

避坑清单

1. API 账单暴涨先拆成调用次数和单次 token 两个因子,分别统计才能定位根因
2. 调用次数涨幅远超用户增长,要去抓重试风暴死循环定时任务这些异常调用源
3. 大模型对话 API 是无状态的,它不记得上一轮,记忆全靠你每次重发完整历史
4. 多轮对话第 N 轮要发前 N 轮全部内容,整个对话总 token 随轮数平方增长不是线性
5. token 不是字符也不是单词,中文一个汉字要一两个 token,别用字符数估成本
6. input 和 output 分开计费且 output 通常贵几倍,让模型答得精简也是省钱
7. 上下文历史无限堆会撞上下文窗口上限,要么报错要么早期历史被悄悄丢弃
8. 必须裁剪上下文,滑动窗口只留最近 N 轮或按 token 预算裁剪,可叠加摘要压缩
9. 系统提示每一轮调用都被完整重发,务必精炼别堆一大篇例子和规则
10. 不设 max_tokens 模型会长篇大论,重试要退避加次数上限,相同请求要缓存

总结

这次"用户涨 2 倍、账单涨 20 倍"的事故,纠正了我一个关于"增长"的、藏得极深的错觉。在我过去的脑子里,成本和用户之间的关系,简单得像一条直线:用户多一个,成本多一份;用户翻一倍,成本翻一倍。这条"线性"的直线,在我心里根深蒂固,根深到我从来没把它当成一个【需要验证的假设】——我把它当成了常识,当成了"事情本来就该这样"。所以当账单涨了 20 倍、用户只涨了 2 倍,我的第一反应不是"我的假设错了",而是"这个数字一定是哪里统计错了"。我宁可怀疑财务的报表,也没有怀疑过我脑子里那条直线。直到我把一个长对话的每一轮 token 数,一行一行打出来,我才亲眼看见那条直线根本不存在:第 1 轮 320,第 10 轮 4100,第 30 轮 13800——它不是在"匀速上坡",它是在【加速上坡】。我这才反应过来,我犯的错有多基础:多轮对话里,第 1 轮说的话,会在第 2 轮被重发一次、第 3 轮再重发一次……一个 30 轮的对话,开头那句话被我付费发送了 30 遍。成本不是正比于"轮数 N",而是正比于"N 的平方"。一条我以为笔直的线,其实从一开始就是一道越来越陡的抛物线——只是在对话还短的时候,抛物线的开头那一小段,看上去【太像】一条直线了,像到我第一个月完全没察觉,直到对话变长、曲线扬起,它才露出獠牙。复盘到最深,我意识到这件事真正教给我的,是要去关心一个增长的【形状】,而不只是它的【方向】。过去我看一个量在涨,我满足于知道"它在涨"——方向对了我就安心了。可"在涨"这件事,底下藏着天差地别的几种命运:有的涨是线性的,你加一分投入、它给你一分回报,稳稳当当;有的涨是平方的、是指数的,一开始温吞得让你放松警惕,某个临界点之后陡然失控,把你掀翻。同样是"涨",线性的涨是朋友,指数的涨是定时炸弹。而它们在早期,长着【几乎一模一样】的脸——这正是最危险的地方:你以为你在和一个温和的线性增长打交道,其实你怀里抱着的是一颗还没到引爆点的指数炸弹。这个教训,我后来到处都看见它的影子:一个 O(n²) 的算法,数据量小的时候和 O(n) 跑得一样快,数据一上量就卡死;一份技术债,刚欠下时无关痛痒,利滚利到某天让整个迭代停摆;一个缓存的击穿、一个连接的泄漏,平时风平浪静,到了某个量级骤然雪崩。它们的共性是:增长的【形状】是非线性的,但早期的形状【伪装】成了线性。这次最大的收获,是我给自己立了一条新规矩:每当我看到一个数字在增长,我不再满足于问"它涨了多少",我会逼自己多问一句——它增长的【形状】是什么?如果今天的规模翻 10 倍,这个数字会跟着翻 10 倍,还是会翻 100 倍、翻 1000 倍?如果我答不上来,那我就还没真正理解这个系统,我只是侥幸地待在那条抛物线还看起来像直线的、温柔的开头而已。token 那张越来越贵的账单教给我的,不是一个省钱技巧,而是一种更深的警觉:这个世界上最贵的代价,往往不是来自那些一望便知很陡的曲线,而是来自那些一开始平缓得让你彻底放下戒心、却在你看不见的地方悄悄积蓄着弯度的曲线。看一个增长,先看它的形状——方向只告诉你它在往哪走,形状才告诉你它最后会把你带到哪里。

—— 别看了 · 2026