精准预测，避免Altium Designer“许可不够用”尴尬

硬件团队喊AD许可不够，跟软件团队喊CI流水线卡住，是两种完全不同的病。后者可能是真堵，前者十次里有七八次，是一个人把席位占着在开评审会，或者头天晚上忘了关软件，第二天早上那台机器还在池子外面挂着。你登上Private Server或者On-Demand后台一看，可用席位确实显示为零，但产线上真正在拉线、在覆铜的人可能连一半都不到。

根源不在于“买少了”。Altium Designer的许可回收逻辑，跟大多数人对“超时释放”的直觉是反着的。 Private Server走的是AIS（Altium Infrastructure Server），里面有一个Seat return timeout interval，默认给你填的是4小时，而且它判断“回不回收”的依据不是软件有没有在被操作，是客户端机器有没有进入休眠或者无响应。工程师把AD最小化，去开两个小时的原理图评审会，或者锁屏去吃午饭，AIS不会碰这个席位。它只认“机器挂没挂”，不认“人走没走”。On-Demand那边稍微好一点，有Groups分组，可以按组切分席位，Roaming借出也有明确的时间边界，到点即停，没有宽限期。但Groups分得好不好、有没有人把Roaming时间设得离谱地长，全是管理员手动决定的事，默认状态下它不会替你预测任何东西。再加上硬件团队的使用节奏本身就是脉冲式的，原理图集中绘制、PCB集中拉线、评审前集中改版，按“最多同时有几个人在线”去配席位，等于用最高那一周的瞬时压力，给剩下四十几周交房租。

几个反复出现的坑，AD环境里尤其典型：

坑一：把AIS的4小时默认超时当成“已经管住了”。 很多人知道Private Server有自动回收，就没再往下看。4小时意味着什么？早上八点半check out，人锁屏去产线，十二点半AIS才可能开始判断这台机器是不是还活着。一个上午，这个席位对排队的人就是不存在的。更隐蔽的是，AIS判断的是机器响应，不是AD进程，笔记本合盖休眠能触发回收，但台式机屏幕一关、人跑去开会，机器醒着，席位就醒着。按这个逻辑去续费或者加购，买回来的还是给锁屏界面交的房租。

坑二：On-Demand的Roaming变成“长期外借”。 On-Demand借出到本地，时间是你自己设的。有人设两周去出差，有人设一个月图省事，到期之前这个席位不会回到池子里，而且Roaming到期是硬停，没有宽限期，人在外地画到一半被切断，最后挨骂的是IT。更麻烦的是，很多企业同时跑Private Server和On-Demand，两边的池子是分开的，一边排队一边闲置，管理员在两个后台之间来回看，靠人肉做调度。

坑三：跳过维护期，后面补钱还带滞纳金。 AD的永久授权有一条线容易被采购忽略：如果中间停掉了维护，以后再想续上，要补缴历史维护费外加10%的滞纳金。有人觉得“软件还能跑就先不续”，等到需要原厂支持或者版本升级的时候才发现，省下来的那点维护费，补回去的时候多了一截。二手授权看起来便宜，新授权六到七折，但断缴维护之后功能受限的风险一样存在，这笔账不提前算清楚，第三年就会冒出来。

坑四：TASKING编译器和桌面AD抢同一个逻辑。 用Altium生态做嵌入式的团队，TASKING的TLM和AD的许可虽然走不同管理器，但CI/CD构建代理是不睡觉的。Jenkins或者GitLab的流水线在夜里反复触发编译，占着TASKING的浮动席位，第二天早上做交互开发的工程师进来，池子已经被构建任务清过一遍了。人跟自动化的需求混在一个池子里排队，不分开管，永远分不清“真的缺席位”还是“构建脚本在吃席位”。

第一层，别先看后台那个“可用数”，先看check-out时长和活跃密度。 Private Server的AIS有Reports，On-Demand后台也有历史使用报表，至少拉八周，覆盖至少一个完整的原理图冻结和PCB投板周期。重点不是峰值几个人，是把单次占用时长超过正常作业周期、但活跃操作密度很低的会话单独拎出来。AIS的日志里能看到check-out和release的时间戳，跟工程师的实际产出节奏对一下，哪些是“人在画”，哪些是“机器在替人排队”，一清二楚。手工做就Excel，别嫌土。

第二层，零成本的回收和分组调整。 Private Server那边，把AIS的Seat return timeout从默认的4小时压到1小时，这是AIS允许的最低值，对于硬件团队这种“锁屏去开会”的高频场景，一小时已经够宽容了。在压缩超时之前，提前跟硬件组打个招呼，让保存习惯跟上，别闷声直接改。On-Demand那边，把Groups按项目节奏拆开，评审前集中用AD的人放在一个组，日常高频画图的人放在另一个组，组间席位不互相挤占。Roaming的借出时间统一设一个上限，比如三个工作日，到期前系统会提醒，别让人把出差和借出混成一件事。

第三层，拿使用曲线去谈采购结构，而不是拿人头。 把第一层跑出来的“真实活跃并发”和“check-out并发”放在一张图上，两条线的差距就是回收和分组能吃掉的水分。如果真实活跃峰值长期低于已购席位的七成，先别签增购单。永久授权和订阅之间的选择，别只看第一年，永久授权加维护的长期总持有成本在席次稳定时仍然有优势，但维护断缴的滞纳金条款要提前放进采购备忘录里；项目制、短期外包介入频繁的团队，On-Demand的弹性才值那个溢价。TASKING那边如果CI/CD用量确实大，单独评估构建代理的席位需求，不要跟桌面设计席位搅在同一个谈判桌上。

第四层，当AIS的1小时粒度已经不够用、或者你同时要管AD和TASKING两套池子，再考虑工具。 值得看的是能识别“软件进程在，但键鼠长时间无活动”的监控，而不是只读服务器release事件的那种。OpenLM那类工具在AD环境里做的事情说白了就一句话：把“design camping”和真实画图分开，把“true denial”和“池子被roaming占着”分开。上工具的时机是你已经手动跑过一轮回收和分组、清楚自己缺的是分钟级闲置识别还是CI/CD与桌面的分池调度，而不是让工具替你做第一轮判断。

华东一家做工业控制板的硬件团队，AD用户大概四十出头，Private Server管着30个浮动席位，另外还有几套TASKING给嵌入式组用。连续三个季度，硬件组长每次评审前都在群里吼“谁把AD占着不用”，采购那边收到的信号一直是“不够，得加”。拉了AIS八周日志，check-out峰值确实摸到过28，但把时长和活跃密度拆开之后，单次占用超过两小时且无键鼠活动的会话，占了日均check-out次数的三成以上，锁屏和最小化到后台是主要形态。CI/CD那边的TASKING池子在夜间被构建任务吃掉接近一半的可用时长。做了三件事：AIS超时从4小时压到1小时；On-Demand按“日常设计”和“评审/临时”拆了两个Group，Roaming上限统一三天；TASKING的构建代理单独排夜间窗口，不和早高峰的交互开发抢同一段。一个席位没加，30个浮动席位支撑四十多人，评审周的denial从每天五六次降到一两次，TASKING早高峰的排队基本消失。后来采购问要不要趁折扣加几个，硬件组长自己说先把下一轮日志跑完再说。