圈子里有个公认的"常识"：大模型账号不能共享。厂商条款写得很清楚，一个人一个号。多人共用，轻则限流，重则永久封禁。
但另一个事实是：公司不可能给每个员工买一个独立的大模型账号。一个 20 人的技术团队，全配齐每月大几千甚至上万，更别说额度还用不完、大量闲置。于是大家心照不宣地共用，然后某天中招——封号、停摆、换号、重配，折腾几个小时甚至一天。
大多数人解决这个问题的思路是"藏"：换 IP、加代理、伪造设备指纹，让厂商"看起来"是一个人。但这条路越走越窄。风控系统持续迭代，你在猫鼠游戏里永远是防守方，只要一次没跟上，全组的号一起凉。
所以我们后来换了个思路：既然厂商要的是"使用行为像真人"，那为什么不真的就像真人一样用？这就是账号调度系统的起点。
不是人数的问题，是健康度的问题
直觉上你会问"一个号能挂几个人"。但正确的问法是：这个号现在还能不能接新对话？
一个账号的状态不是"能共享"和"不能共享"两个档位。它是一个连续变化的健康度。我们给每个号打一个 0 到 100 的分数，由用量涨速、剩余额度比例、被限流次数、当前挂载人数、最近是否有异常响应等十几个因子综合算出。
账号的整个生命周期被划分为四个状态：健康 → 观察 → 亚健康 → 待退役，流转全自动，每个状态的切换都留审计日志。新号可以放心分配新对话，降到 10 分以下的号直接退役，任何新请求都不往它身上发。
所以"一个账号能共享几个人"没有固定答案。真正决定这个数字的，是账号当时的状态和使用模式。
自动分组：物理隔离故障半径
即便健康度管理做好了，还有一个容易被忽略的问题：批量故障。
如果某天厂商突然升级风控，同一个池里的号可能因为相似的使用特征被一锅端。我们的做法是把账号按每 4 个号一组自动分成小组。每个员工的请求只在当前小组内的账号之间流转。一个号出问题，只影响小组内的一小撮人，不会把整个团队拉下水。
任何单点故障的爆炸半径必须被物理隔离。
粘号：缓存定价决定成本
调度系统里有一项策略，不做技术的人第一眼看会觉得莫名其妙：为什么要"粘"在一个号上？
原因是厂商的缓存定价机制。同一段对话上下文如果连续发给同一个模型，大概率命中缓存，Token 单价降一截。反复跳号意味着每次都是全价。所以我们默认粘号，同一个会话不换号，除非当前号被系统判定危险或额度见底。
留余量：95% 就该切走
额度管理上有一个反直觉的细节：不能让号跑到 100%。
满额度触发的往往是硬阻断，而拒绝本身就会被风控系统记一笔。多来几次，一个正常账号可能在额度用尽的同时也被打上了异常标记。我们的系统在每个号跑到 95% 到 99% 之间时提前切走，留一小截余量做缓冲。看起来浪费了 1% 到 5%，实际省下的是一个可能被封的号。
风暴刹车：防止连锁翻车
调度系统最容易出事的时刻是短时间内大量账号接连异常。正常自动切换逻辑会在一个号挂掉之后立刻跳到下一个号。如果下一个也挂了，再跳再挂，系统在几秒内就能把整个池子全部轮一遍。
我们叫它"风暴"。风暴刹车规则很简单：当短时间内连续异常的账号超过阈值，系统立刻停止自动切换，把所有待处理请求挂起，转人工决策。这个刹车不会让你的系统不中断，但会让系统不死透。
调度比共享重要
回到标题的问题：一个 AI 账号到底能安全共享给几个人？
答案是：这不是人数的问题，是你能不能看清每个号的实时状态，以及你敢不敢在它变危险之前主动把它摘下来。
凑钱买号是第一步，也是最不重要的一步。真正让你睡个安稳觉的，是那套在你看不见的地方持续运转的调度引擎：打分、分组、粘号、留余量、刹车、留痕。每一层都在回答同一个问题：下一个请求，该往哪发才最安全。
