敢上新是勇气能收住才是本事上篇讲了张磊凌晨 4 点 13 分那个 8000 美元账单。这一期卷袖子干活——把张磊事后 3 个月的整改方案拆给你看。后文你看到的所有四道闸 五层防护的具体工具、阈值、配比、踩坑都是张磊复盘会上亲口说的真实经验——不靠花钱最多解决靠分层设计解决。这件事最反直觉的一点是把月度账单从不可预测变成可预测、把恶意刷量尝试拦截率从 0% 提到 100%、把客户投诉率从 5.2% 降到 0.4%成本只增加了 18%。这就是工程治理的胜利——不是花更多钱是把每一笔 token 算到能看见、能拦住、能退。一、反差开场——从单晚 8000 美元到 3 个月零超账单先把张磊整改后的数字摆出来。上篇讲张磊凌晨 4 点 13 分单晚烧光 8000 美元、月度账单 5.2 万、年度差点融资砍半。这是 6 个月前的数字。6 个月后——月度账单从不可预测5 万→25 万变成可预测月度 5.3-5.8 万偏差 ±10%恶意刷量尝试拦截率100%90 天内发生 11 起刷量尝试全部在 95% 配额阶段被拦截客户投诉率从 5.2% 降到 0.4%超账单事件0 起。0 起。0 起。告警有效性80% 预警 100% 触达95% 熔断 100% 触发100% 封号 100% 执行数字本身不稀奇稀奇的是这件事是怎么做出来的。张磊复盘会上说过一句——“我以为要把预算翻倍才能解决问题结果发现真正解决问题的是分层设计预算只是顺带的。”具体来说张磊团队 3 个月里做了四件事——第一件事把用量计量从按次粗算改成按 token 精打。用了 tiktokenOpenAI 官方 tokenizer Anthropic tokenizer 自建 usage service 三件套每次调用的输入/输出 token 数被精确打点每个租户的实时用量被精确汇总。第二件事把全局单一配额改成用户/租户/全局三级限额。用户级日 10 万 token 租户级月 1 亿 token 全局月 10 亿 token三层叠加每一层都有独立的告警和熔断。第三件事把月度用完才告警改成80%/95%/100% 三档告警。80% 触发邮件/短信预警95% 触发熔断拒绝新请求100% 触发封号。第四件事把事后查日志改成事前异常检测。IP 频率异常、单用户突增、夜间异常、特定 prompt 模式四类检测实时跑异常触发即降级/限流/封号。四件事做完后月度账单从不可预测变成可预测恶意刷量拦截率 100%。这不是技术升级是流程重设计。这一期我们就把这四件事拆开讲——用量计量怎么精打、三级限额怎么配、实时告警怎么设、异常检测怎么做、多租户分摊怎么落地、金句怎么收束。二、第一道闸 精确计量——tiktoken Anthropic tokenizer 自建 usage service用量计量是 AI 计费体系的第一道闸。为什么第一道闸是计量不是限额因为没有计量限额就是空中楼阁。你跟客户说日 10 万 token但你不知道客户用了多少——限额就是一句空话。张磊事后给团队立的第一条规矩——“任何 AI 功能上线前必须先把 usage 打点接到 usage service否则不准上线。”2.1 三件套工具张磊团队用的精确计量三件套是——第一件tiktokenOpenAI 官方 tokenizer。用法在请求进入 OpenAI 之前用 tiktoken 计算 prompt 的 token 数 用 max_tokens 字段预估输出 token 数。tiktoken 的精度是 OpenAI 平台计费的 99.9%误差 0.1%。第二件Anthropic tokenizer。用法跟 tiktoken 类似但 Anthropic 的 tokenizer 是闭源的通过官方 API 调用。如果你的业务同时接 OpenAI 和 Anthropic需要两套 tokenizer。第三件自建 usage service。用法每次调用都打点 4 个字段——tenant_id / user_id / model / token_count输入 输出。这些数据实时写入 ClickHouse / Doris 之类的 OLAP 数据库支撑 7 天/30 天/90 天的聚合查询。2.2 三个细节坑张磊事后复盘时列了三个细节坑——坑 1Anthropic 的 prompt caching 不计入输入 token。如果你的 prompt 命中了 Anthropic 的 cachecache_write 25% / cache_read -90%cache 命中的部分按 cache_read 单价算不按 input 单价算。你的 usage service 必须识别cache 命中这个事件否则账单对不上。坑 2function calling 的 token 数包含 tool 定义。如果你用 OpenAI 的 function callingtool 定义 tool 返回值都算 token。张磊事后算了一笔账——他的 tool 定义平均 800 token每次 function calling 实际消耗的 token 比预期多 40%。坑 3流式输出的 token 计数需要累加。如果你用 streamtrue 调用 OpenAI每次回调只返回一小段内容average 10-50 token你需要在客户端累加这些 token 数否则你的 usage service 会少计 30-50%。2.3 一个核心金句这一节的核心金句独立成段你必须记住——精确计量不是统计 token而是建立按调用 × 按租户 × 按时间窗三维度的实时打点。没有 usage service限额不是空中楼阁而是客户的随便用——你的日 10 万 token在客户看来就是随便用。这一节还有一个反常识洞察——精确计量的成本是月度 500-2000 元按 ClickHouse 集群 写入流量算但它能帮你省下的是月度几万到几十万的账单失控风险。精确计量不是成本中心而是风险对冲中心。三、第二道闸 三级限额——用户/租户/全局精确计量打点完了下一步是给每个层级配限额。张磊复盘会上立的第二条规矩——“任何 AI 功能上线前必须配用户/租户/全局三级限额否则不准上线。”3.1 三级限额的层级职责第一层用户级User Quota。单个用户 ID / 账号的限额。典型值日 10 万 token / 月 1000 万 token触发动作超限 → 限流 / 验证码 / 临时封号设计要点用户级限额保护个体——单个用户被刷不会影响其他用户第二层租户级Tenant Quota。单个企业租户 / 组织的限额。典型值日 500 万 token / 月 1 亿 token触发动作超限 → 强制升级套餐 / 拒绝服务设计要点租户级限额保护组织——单个租户被刷不会影响其他租户第三层全局级Global Quota。平台整体 / 全租户汇总的限额。典型值日 1 亿 token / 月 10 亿 token触发动作超限 → 紧急熔断 / 排队队列 / 全局降级设计要点全局级限额保护平台——全平台流量失控时不会击穿云厂商配额3.2 三层叠加 vs 三层择一很多团队犯的错是三层择一——只配全局限额或者只配租户限额。三层择一的代价是——只配全局限额单个租户被刷会影响所有租户只配租户限额单个用户被刷会烧光租户配额只配用户限额恶意刷量用 670 个账号绕过用户限额烧穿租户配额张磊复盘会上立的规矩是三层叠加——三个层级都配限额每个层级独立告警和熔断。用户级保护个体、租户级保护组织、全局级保护平台。3.3 配额继承模型但三层叠加有个工程难题——配额是用户从租户继承还是用户独立张磊选了继承 借用——默认用户配额 ≤ 租户配额用户不能超过租户特殊管理员可以为某些用户借用租户配额让用户用租户的一部分配额超限用户的请求从租户配额扣减租户配额耗尽时该租户所有用户都被限流这套模型的好处是——租户管理员可以灵活分配配额但租户整体不会被超刷。3.4 一个核心金句这一节的核心金句独立成段你必须记住——三级限额让风险分层——用户限额保护个体租户限额保护组织全局限额保护你自己。三层叠加 vs 三层择一——只配全局限额单个租户被刷影响所有租户只配租户限额恶意刷量用 670 个账号绕过用户限额。限额不是省钱是救命——别等账单来了才想起来。3.5 三级限额的核心心智张磊事后给团队总结过一个核心心智——“三级限额不是三个配额而是三层保险。”为什么这么说因为三层保险不是平均分布的——用户级保险最细每天配额小、租户级保险中等每月配额中、全局级保险最大每月配额大。细的保险先触发先止损——这是为什么用户级触发概率最高、影响最小的设计。三级限额不是装 3 个配额而是装 3 层不同粒度的保险——细的先触发、粗的最后兜底。四、第三道闸 实时告警——80% 预警 / 95% 熔断 / 100% 封号三级限额配好了下一步是给每个层级配实时告警。张磊复盘会上立的第三条规矩——“任何 AI 功能上线前必须配 80%/95%/100% 三档告警否则不准上线。”4.1 三档告警的设计逻辑阈值触发动作响应时间典型场景80%邮件 / 短信预警异步通知5 分钟内“已用 80%请注意”95%强制熔断拒绝新请求 / 排队队列同步触发即时“已用 95%新请求进入排队”100%紧急封号 / 全租户暂停立即执行即时“已用 100%暂停服务”80% 预警的价值是早——给运维人员留出排查时间。张磊团队每次收到 80% 预警后会花 30 分钟排查是哪个用户在用、为什么用这么多。30 分钟内找到原因并处置 90% 的异常。95% 熔断的价值是止损——在到达 100% 之前强行熔断避免账单爆炸。张磊事后统计——11 起恶意刷量尝试全部在 95% 阶段被熔断没有一起烧到 100%。100% 封号的价值是保险——极端情况下的兜底。正常情况下 100% 不会触发因为 95% 已经熔断了但万一 95% 熔断失效100% 封号能保住平台不被击穿。4.2 告警通道选型张磊团队用的告警通道是四通道叠加——邮件异步通知5 分钟内到达短信紧急通知30 秒内到达电话重大事故1 分钟内人工接通IM 群实时同步10 秒内上篇讲过张磊手机静音模式淹没告警——这是张磊复盘后改的他给自己配了短信 IM 群双通道邮件只发给团队其他人。4.3 一个反常识洞察张磊事后给团队总结了一个反常识洞察——“80% 预警不是为了省 token是为了买排查时间。”为什么因为 80% 触发后还有 20% 的余量。如果运维人员能在 30 分钟内找到异常并处置账单可能只会超 5%如果运维人员没收到预警等账单爆炸才发现可能已经超 100%。80% 预警买的不是 token是时间。4.4 一个核心金句这一节的核心金句独立成段你必须记住——三档告警不是三个阈值而是一个时间梯度——80% 预警买时间95% 熔断止损100% 封号保险。80% 预警不是为了省 token而是为了买排查时间——30 分钟内找到异常账单只超 5%等账单爆炸才发现已经超 100%。告警通道不是越多越好而是越能叫醒人越好——邮件给团队、短信给自己、IM 群给所有人。五、第四道闸 异常检测——IP 频率 / 单用户突增 / 夜间异常 / prompt 模式三档告警配好了下一步是异常检测——在告警触发之前先把异常识别出来。张磊复盘会上立的第四条规矩——“任何 AI 功能上线前必须配 IP 频率 / 单用户突增 / 夜间异常 / prompt 模式四类异常检测否则不准上线。”5.1 四类异常检测的工程实现第一类IP 频率异常检测指标单 IP 在时间窗内1min / 5min / 1h的请求数触发阈值超过 P99.9 历史值 × 2 异常处置动作限流 → 验证码 → 临时封禁工程实现Redis Sorted Set 滑动窗口张磊事后列了真实案例——凌晨 2:13攻击者用 67 个 IP 同时调用每个 IP 每分钟 3 次没触发 IP 频率限制。但 67 个 IP 共享同一个 / 16 子网——子网维度的检测触发了告警。IP 频率异常检测不只是单 IP还要做子网维度的检测。第二类单用户突增检测指标单用户在时间窗内的 token 消耗 / 调用次数触发阈值超过历史均值 × 5 异常处置动作限流 → 二次验证 → 人工审核工程实现ClickHouse 实时聚合 历史基线对比张磊事后列了真实案例——某付费租户在双 11 当天调用量涨 8 倍业务突增正常但其中 1 个用户的调用量涨 50 倍异常。用户维度的突增检测比租户维度的突增检测更细。第三类夜间异常检测指标凌晨 0:00-6:00 时间段的请求量 / token 消耗触发阈值夜间请求量 / 日间请求量 20% 异常处置动作自动告警 临时降级夜间禁用高消耗功能工程实现时间维度 请求量的简单对比张磊事后立了硬规矩——“凌晨 0:00-6:00 时间段新功能上线前必须先经过夜间异常测试”。具体做法让功能在夜间灰度发布 7 天监控夜间请求量是否异常。第四类特定 prompt 模式检测指标长 prompt2000 token/ 重复 prompt相似度 90%/ 高频 prompt 模式触发阈值单用户 1h 内重复 prompt 100 次 异常处置动作限流 → 验证码 → 临时封禁工程实现prompt embedding 余弦相似度 Redis 计数器张磊事后列了真实案例——攻击者故意把 system prompt 写得很长包含你是一个专业的客服请详细回答用户问题等冗余指令。长 prompt 检测触发了告警——单用户 prompt 平均长度 2000 token是历史基线的 10 倍。5.2 四类异常检测的优先级这四类异常检测不是平等优先级——张磊事后给团队排了优先级优先级异常类型触发频率误报率P0单用户突增高低P0IP 子网频率异常高低P1夜间异常中低P2prompt 模式异常低高容易误报P0 必须实时检测延迟 1 分钟P1 准实时延迟 5 分钟P2 离线分析延迟 1 小时。5.3 一个反常识洞察张磊事后给团队总结了一个反常识洞察——“异常检测不是为了抓坏人而是为了抓异常。”为什么因为 上篇讲过的三类异常恶意刷量、业务突增、配置错误业务突增和配置错误都不是坏人——它们是正常用户 / 正常运营导致的。但它们的账单放大效应跟恶意刷量一样。异常检测的本质不是反欺诈而是反账单放大——任何让账单非预期增长的异常都应该被检测出来。5.4 一个核心金句这一节的核心金句独立成段你必须记住——四类异常检测不是反欺诈是反账单放大——业务突增和配置错误都不是坏人但它们的账单放大效应跟恶意刷量一样。IP 频率异常检测不是单 IP 检测是子网维度检测——攻击者用 67 个 IP 绕过单 IP 检测但 / 16 子网维度的检测抓得到。六、五层防护策略——五道闸把恶意刷量挡在发生之前精确计量 三级限额 实时告警 异常检测四道闸配好了最后一层是五层防护策略——把四道闸的告警和处置动作整合成一条完整的拦截链。张磊复盘会上立的第五条规矩——“任何 AI 功能上线前必须把用户/租户/全局/IP/行为五层防护策略配齐否则不准上线。”6.1 五层防护策略的层级职责层级防护对象触发条件处置动作L1 用户层单用户用户配额超限限流 → 验证码 → 临时封号L2 租户层单租户租户配额超限强制升级 → 拒绝服务L3 全局层全平台全局配额超限紧急熔断 → 排队队列 → 全局降级L4 IP 层单 IP / 子网IP 频率异常限流 → 验证码 → 临时封禁L5 行为层单用户行为行为异常突增/夜间/prompt 模式限流 → 二次验证 → 人工审核6.2 五层防护的拦截链恶意刷量的请求会按先 L5 → 再 L4 → 再 L1 → 再 L2 → 再 L3的顺序被检测——L5 行为层先检测prompt 模式异常 → 限流L4 IP 层再检测IP 子网异常 → 限流L1 用户层再检测用户配额超限 → 验证码/封号L2 租户层再检测租户配额超限 → 拒绝服务L3 全局层最后兜底全局配额超限 → 紧急熔断正常用户不会触发任何一层——恶意刷量的请求会在某一层被拦截账单爆炸的概率从 100% 降到 1%。6.3 一个反常识洞察张磊事后给团队总结了一个反常识洞察——“五层防护不是叠加是漏斗——恶意刷量会在最严的那一层被拦截。”为什么因为恶意刷量的特征是在某一项严重异常——要么 IP 频率异常要么 prompt 模式重复要么账号突增。五层防护的每一层都能抓到不同类型的异常恶意刷量很难同时绕过所有层。五层防护不是装 5 个工具是装 5 个不同视角的监控——总有一个视角能看到异常。6.4 一个核心金句这一节的核心金句独立成段你必须记住——五层防护不是叠加是漏斗——恶意刷量会在最严的那一层被拦截。五层防护不是装 5 个工具是装 5 个不同视角的监控——总有一个视角能看到异常。七、多租户分摊实现——共享账户余额 vs 各自计量五层防护配好了最后一层是多租户分摊——老板问到底是哪个租户在烧钱怎么答张磊复盘会上立的第六条规矩——“任何 AI 功能上线前必须配多租户分摊机制共享账户余额 各自计量否则不准上线。”7.1 多租户分摊的三大难题难题 1共享资源的算力消耗。AI 推理是共享的——一个 prompt 可能用同一批 GPU同一批 GPU 还可能被多个租户的请求共享。业内目前的做法——按实际消耗 token × 模型单价 × 共享系数1.1-1.5分摊。共享系数取决于该租户的请求是否复用了其他租户的 KV cache / prefix caching。难题 2缓存命中的成本归属。如果租户 A 的 prompt 命中了租户 B 的 prefix cacheOpenAI / Anthropic 都支持 prompt caching那省下来的 token算谁的业内目前的做法——“谁命中归谁”。缓存命中省下来的 token 算租户 A 的功劳不算租户 B 的成本。但这个算法有个边界 case——如果租户 B 是被命中方即他的 prefix 被租户 A 命中他没拿到任何好处还可能被分摊算力成本。难题 3超额租户的道德风险。如果租户 A 烧光了池子里的 80% 余额租户 B 在月底想用的时候发现余额不够——这叫公地悲剧。业内目前的主流做法——双轨制平台先按账户余额池扣费月底再按租户实际消耗二次结算多退少补。7.2 双轨制的具体实现张磊选了双轨制 分组隔离——账户余额池所有租户共享一个月度余额池10 亿 token任意租户调用都从这个池子里扣租户实际消耗每个租户的 token 消耗被实时打点user_id → tenant_id月底二次结算按租户实际消耗 / 池子总消耗的比例分摊账户余额池扣的费用 租户实际消耗 × 单价多退少补账户余额池剩余的部分如果有按租户实际消耗比例退还分组隔离把租户按用量分成 A/B/C 三组每组共享 AI 后端组间隔离这套模型的好处是——租户有共享安全感池子足够大平台有超额赚钱月底分摊可能比预扣更多但避免了公地悲剧超额租户会被二次结算发现。7.3 一个反常识洞察张磊事后给团队总结了一个反常识洞察——“多租户分摊不是技术问题是治理问题——租户之间要公平租户和平台之间也要公平。”为什么因为分摊算法的公平性直接影响租户的续费意愿。如果某个租户发现自己被分摊了比实际消耗更多的费用他会选择离开如果某个租户发现自己被补贴了他可能会刷量套利。双轨制账户余额池 实际消耗二次结算是 2026 年最稳的分摊方案——它不是完美的但它是公开透明的租户能算清楚自己付了多少。7.4 一个核心金句这一节的核心金句独立成段你必须记住——多租户分摊不是技术问题是治理问题——租户之间要公平租户和平台之间也要公平。双轨制账户余额池 实际消耗二次结算是 2026 年最稳的分摊方案——它不是完美的但它是公开透明的。八、计费账单的可视化——用户看到自己用了多少管理员看到哪个租户异常五层防护配好了分摊机制落地了最后一步是计费账单的可视化。张磊复盘会上立的第七条规矩——“任何 AI 功能上线前必须配计费账单可视化用户侧 管理员侧否则不准上线。”8.1 用户侧的账单可视化用户侧的账单可视化要做到三件事——第一件实时用量查询。用户可以登录控制台实时查看自己今日/本月用了多少 token、消耗了多少金额。第二件用量预警。当用户用量达到 80%/95%/100% 时系统自动推送邮件/短信/IM 通知。第三件用量趋势。用户可以看到自己过去 30 天的用量趋势图识别哪天突然涨了。张磊事后复盘时特别强调——“用户侧账单可视化不是为了赚更多钱是为了减少客户投诉——90% 的’账单异常’投诉其实是’用户自己不知道用了多少’。”8.2 管理员侧的账单可视化管理员侧的账单可视化要做到三件事——第一件租户用量排行榜。管理员可以看到所有租户的用量排行榜识别哪个租户在涨。第二件异常租户标记。异常租户用量突增/被刷/超限会被自动标记管理员第一时间介入。第三件分摊明细。管理员可以看到每个租户的分摊明细包括实际消耗 / 账户余额池扣费 / 二次结算退款。8.3 一个反常识洞察张磊事后给团队总结了一个反常识洞察——“账单可视化不是给老板看的是给用户看的——用户越清楚自己用了多少投诉越少续费意愿越高。”为什么因为**“我付了多少钱是用户的核心焦虑**。如果用户不能实时看到自己的用量他会怀疑你们是不是乱收费”。如果用户能看到实时用量他会相信我用多少付多少。账单可视化是 AI 时代 SaaS 的信任基础设施——没有它所有 AI 计费都是空中楼阁。8.4 一个核心金句这一节的核心金句独立成段你必须记住——账单可视化不是给老板看的是给用户看的——用户越清楚自己用了多少投诉越少续费意愿越高。账单可视化是 AI 时代 SaaS 的信任基础设施——没有它所有 AI 计费都是空中楼阁。九、金句收束——把每一笔 token 算到能看见、能拦住、能退这一期我们讲了五件事——第一件事精确计量——tiktoken Anthropic tokenizer 自建 usage service 三件套把每一次调用的 token 数精确打点支撑三级限额的实时查询。第二件事三级限额——用户/租户/全局三层叠加每层独立告警和熔断保护个体/组织/平台三个层级。第三件事实时告警——80%/95%/100% 三档告警80% 预警买时间95% 熔断止损100% 封号保险。第四件事异常检测——IP 频率 / 单用户突增 / 夜间异常 / prompt 模式四类检测把账单放大器扼杀在发生之前。第五件事五层防护 多租户分摊 账单可视化——把四道闸的告警和处置动作整合成完整的拦截链多租户分摊解决老板问谁在烧钱账单可视化建立用户信任。这一期和 上篇的反常识认知是把AI 计费 电力消耗翻译成AI 计费 装电表 配限额 设告警 抓异常。你看到这里可能会有个疑问——“如果我把四道闸 五层防护都装上是不是就不会再被刷了”答案是——不会 100% 不会但你已经被保护了。张磊复盘会上的统计——11 起恶意刷量尝试全部在 95% 配额阶段被拦截没有一起烧到 100%。100% 拦截率不代表绝对安全代表风险可控。这就是工程治理的胜利——不是消除所有风险是把风险控制在可预测范围内。张磊事后跟团队说过一句话——“AI 计费这件事最反直觉的不是它复杂是它工程化。复杂的是你愿不愿意把’装电表、配限额、设告警、抓异常’这些看似简单的动作每一个都做到位。”AI 计费不是按调用次数是把每一笔 token 算到能看见、能拦住、能退。AI 计费不是按调用次数是按电力消耗、按工程纪律、按分层防护。未来真正会管 AI 成本的人不是选了最便宜模型的人而是装了电表、配了限额、设了告警、抓了异常的人。这三句话串起来就是这一期的核心金句。附张磊复盘会上的 10 条工程纪律备忘清单这一期我们讲了张磊的四道闸 五层防护。把这一期里散落的工程纪律重新整理成一份备忘清单——每一条都可以贴在你工位旁边每天上线前扫一眼。纪律 1任何 AI 功能上线前必须先把 usage 打点接到 usage service否则不准上线。纪律 2任何 AI 功能上线前必须配用户/租户/全局三级限额否则不准上线。纪律 3任何 AI 功能上线前必须配 80%/95%/100% 三档告警否则不准上线。纪律 4任何 AI 功能上线前必须配 IP 频率 / 单用户突增 / 夜间异常 / prompt 模式四类异常检测否则不准上线。纪律 5任何 AI 功能上线前必须把用户/租户/全局/IP/行为五层防护策略配齐否则不准上线。纪律 6任何 AI 功能上线前必须配多租户分摊机制共享账户余额 各自计量否则不准上线。纪律 7任何 AI 功能上线前必须配计费账单可视化用户侧 管理员侧否则不准上线。纪律 8任何 AI 功能上线前必须先在测试环境跑 24 小时比对测试环境用量与生产环境基线的偏差超过 20% 才能上生产。纪律 9凌晨 0:00-6:00 时间段新功能上线前必须先经过夜间异常测试——7 天灰度监控夜间请求量。纪律 10每月只允许增加 20-30 条新规则关键词/告警阈值/异常模式但拦截率必须提升 5% 以上。这 10 条工程纪律不是为了让你记住是为了让你下次上线 AI 功能时——第一反应不是模型怎么这么贵而是我的电表装了吗、限额配了吗、告警设了吗、异常抓了吗。未来真正会管 AI 成本的人不一定是选了最便宜模型的人而是把 10 条工程纪律每一条都做到位的人。写在最后从被刷爆到可控的距离这一期我们讲了张磊的四道闸 五层防护。如果你只看一句金句那应该是——AI 计费不是按调用次数是把每一笔 token 算到能看见、能拦住、能退。这一期的核心是把 上篇的反常识认知AI 计费 装电表翻译成可落地的工程纪律——能看见精确计量 用量打点 实时聚合能拦住三级限额 三档告警 五层防护能退多租户分摊 账单可视化 用户侧管理这三件事加在一起就是 AI 时代的计费基础设施。张磊事后跟团队说过一句收束的话——“AI 计费这件事最反直觉的不是它复杂是它工程化。复杂的是你愿不愿意把’装电表、配限额、设告警、抓异常’这些看似简单的动作每一个都做到位。”未来真正会管 AI 成本的人不是选了最便宜模型的人而是把能看见、能拦住、能退这六个字焊死在每一个 AI 功能上线流程里的人。把这一期的工程纪律贴在你工位旁边每天上线前扫一眼。敢上新是勇气能收住才是本事。关于 ArchAIHarness这篇文章是「看懂 AI 与智能体」专栏的一部分由ArchAIHarness持续输出。ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产主张架构师定义秩序AI 在秩序中生长。人立法AI 执行体系审计。如果你也希望 AI 在明确的架构边界内协作而不是在混沌中碰运气欢迎到 GitHub 上看看我们在做什么组织主页github.com/ArchAIHarness — 了解完整理念与资产全景本专栏zhuanlan-ai-and-agents— 所有文章的源码与发布记录实践指南docs— 架构哲学、工程方法和落地指南开源工具agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools工程样例framework— FDE 第一年装备清单 .md