敢上新是勇气，能收住才是本事

上篇讲了张磊凌晨 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 精打"。用了 tiktoken（OpenAI 官方 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 三件套工具

张磊团队用的"精确计量三件套"是——

第一件：tiktoken（OpenAI 官方 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 三个细节坑

张磊事后复盘时列了三个细节坑——

坑 1：Anthropic 的 prompt caching 不计入"输入 token"。如果你的 prompt 命中了 Anthropic 的 cache（cache_write +25% / cache_read -90%），cache 命中的部分按 cache_read 单价算，不按 input 单价算。你的 usage service 必须识别"cache 命中"这个事件，否则账单对不上。

坑 2：function calling 的 token 数包含 tool 定义。如果你用 OpenAI 的 function calling，tool 定义 + tool 返回值都算 token。张磊事后算了一笔账——他的 tool 定义平均 800 token，每次 function calling 实际消耗的 token 比预期多 40%。

坑 3：流式输出的 token 计数需要累加。如果你用 stream=true 调用 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% 预警的价值是"早"——给运维人员留出排查时间。张磊团队每次收到 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 模式

• 检测指标：长 prompt（>2000 token）/ 重复 prompt（相似度 > 90%）/ 高频 prompt 模式
• 触发阈值：单用户 1h 内重复 prompt > 100 次 = 异常
• 处置动作：限流 → 验证码 → 临时封禁
• 工程实现：prompt embedding + 余弦相似度 + Redis 计数器

张磊事后列了真实案例——攻击者故意把 system prompt 写得很长（包含"你是一个专业的客服，请详细回答用户问题"等冗余指令）。长 prompt 检测触发了告警——单用户 prompt 平均长度 2000+ token，是历史基线的 10 倍。

5.2 四类异常检测的优先级

这四类异常检测不是平等优先级——张磊事后给团队排了优先级：

P0 必须实时检测（延迟 < 1 分钟），P1 准实时（延迟 < 5 分钟），P2 离线分析（延迟 < 1 小时）。

5.3 一个反常识洞察

张磊事后给团队总结了一个反常识洞察——“异常检测不是为了抓坏人，而是为了抓异常。”

为什么？

因为 上篇讲过的三类异常（恶意刷量、业务突增、配置错误），业务突增和配置错误都不是"坏人"——它们是正常用户 / 正常运营导致的。但它们的账单放大效应跟恶意刷量一样。

异常检测的本质不是反欺诈，而是反"账单放大"——任何让账单非预期增长的异常，都应该被检测出来。

5.4 一个核心金句

这一节的核心金句，独立成段你必须记住——

四类异常检测不是反欺诈，是反"账单放大"——业务突增和配置错误都不是"坏人"，但它们的账单放大效应跟恶意刷量一样。

IP 频率异常检测不是单 IP 检测，是子网维度检测——攻击者用 67 个 IP 绕过单 IP 检测，但 / 16 子网维度的检测抓得到。

六、五层防护策略——五道闸把恶意刷量挡在发生之前

精确计量 + 三级限额 + 实时告警 + 异常检测四道闸配好了，最后一层是五层防护策略——把四道闸的告警和处置动作整合成一条完整的"拦截链"。

张磊复盘会上立的第五条规矩——“任何 AI 功能上线前，必须把用户/租户/全局/IP/行为五层防护策略配齐，否则不准上线。”

6.1 五层防护策略的层级职责

6.2 五层防护的拦截链

恶意刷量的请求会按"先 L5 → 再 L4 → 再 L1 → 再 L2 → 再 L3"的顺序被检测——

1. L5 行为层先检测（prompt 模式异常 → 限流）
2. L4 IP 层再检测（IP 子网异常 → 限流）
3. L1 用户层再检测（用户配额超限 → 验证码/封号）
4. L2 租户层再检测（租户配额超限 → 拒绝服务）
5. 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 cache（OpenAI / 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