Token，正在替你算 KPI
最近鸭鸭刷到一条话题：
“2026 年，国内某大厂被曝将 Token 消耗量纳入 KPI 考核，排名直接挂钩转正和晋升。周鸿祎在近期互联网座谈会上也表示，智能体普及后，Token 消耗可能飙升数十倍甚至百倍。”
什么意思呢？就是说——
以后你每个月在公司烧了多少 AI Token，直接写进你的绩效单。
鸭鸭看到这条，第一反应是：“这不胡闹儿吗。”
但再翻几条，发现数据比段子还离谱：
- 国家数据局：全国日均词元调用量从 2024 年初的 1000 亿，飙到 2026 年 3 月的 140 万亿——两年涨了超过 1000 倍；
- Meta 内部搞起“AI 消耗竞赛”：8.5 万员工一个月烧掉 60 万亿 Token，只为抢排行榜上一个勋章；
- OpenAI 某工程师：单周一个人就消耗 2100 亿 Token 刷榜；
- DeepSeek 刚刚静默升级 API：上下文从 128K 直接干到 1M Token——一个请求能塞下整套《三体》三部曲。
看到这组数据的时候，鸭鸭心里只剩一句话：
不是你在用 AI，是 AI 在用你。
评论区很快就分成了两派——
乐观派：
“Token 消耗量=AI 使用深度=产出潜力，该卷就得卷。”
“会用 AI 的人价值被放大，不会用的人风险在积累。”
冷水派：
“Token 消耗量跟 Excel 用量、PPT 页数、代码行数一码事。有帮助吗？有一丢丢，但它代表不了真正的功劳。”
“有人靠刷 Token 登顶榜单被领导表扬，实则一半消耗量是在用 AI 整理个人笔记和改简历。”
最扎心的是一条中层吐槽：
“用得少，说明你没把 AI 真正用起来；用得太多，又会被问是不是在乱烧预算。”
……
但跳出来看，这件事的本质压根就不是 “Token 该不该当 KPI”，而是——
公司第一次遇到了一个它自己也不知道怎么算的变量。
以前考核是最简单的：代码行数、需求数、工时、故事点、OKR。这些东西公司玩了二十年，有标准、有基线、有对比。
但 AI 进来之后，产出逻辑一下子乱了：
- 一个用 AI 的工程师，可能 30 分钟写完别人一天的活；
- 一个团队每天烧几百万 Token，但谁也说不清是“高效”还是“浪费”；
- HR 想衡量，只能找个“看得见摸得着”的指标——Token 量就是现成的尺子。
所以 Token 变成 KPI，不是因为它对，而是因为它方便。
就像二十年前公司考核程序员靠“代码行数”一样——那个年代你要是每天提交 1000 行，简直就是劳模，但今天大家都知道这玩意儿没意义。
Token 现在就是新时代的“代码行数”。
它会火一阵，然后被骂，最后被淘汰。
而且鸭鸭还想多说一句——
别以为用 AI 越多就越厉害，Token 消耗量其实是你的“隐形工资条”。
你每调一次 AI，背后都是公司在给 OpenAI、给 DeepSeek、给火山引擎付真金白银的账单。HR 看的是 KPI 数字，老板心里盘的是另一笔账：这帮人这个月又给我烧了多少钱。
公司发你工资，本质是希望你帮它赚钱或省钱。控 Token 消耗，本质上就是在控公司成本。
所以，一个聪明的员工，是用最少的 Token 解决最多的问题；一个被裹挟的员工，是用最多的 Token 假装自己很努力。
真正会留下来的 KPI，一定是三个复合指标——
- Token / 产出比（烧了多少换来了什么）
- AI 辅助覆盖率（你工作流里有几个环节挂上了 AI）
- 产出质量（AI 生成的东西，被人工纠正的比例有多高）
这三条才是未来的游戏规则。
作为正在准备面试、或者刚上班两三年的同学，鸭鸭给你三条实在建议——
- 别再比“我用过多少次 AI”，开始比“我让 AI 替我省了多少小时”：面试讲故事别说 “我用 Cursor 很熟”，说 “我用 AI 把原本两天的工作压到了 3 小时，产出还多了 30%”；
- 把 AI 嵌进工作流的每个节点：从取数、清洗、分析、写代码、写文档、Review——每多嵌一个环节，你的 AI 辅助覆盖率就高一分；
- Review AI 产出的能力，比使用 AI 的能力更稀缺：以后值钱的不是“会问 AI”，是“能看出 AI 哪里错了”。
AI 时代真正的 KPI 不是你烧了多少 Token，而是在同样一度电、一份工资里，你比没 AI 的自己，多做了多少事。
至于那些只会刷 Token 量的同事——
放心，第一批倒下的，就是他们。
大家公司有没有开始把 AI 使用情况纳入考核？评论区聊聊～
……
今天和大家分享一篇 后端场景题面试题。
【即时通讯项目中怎么实现历史消息的下拉分页加载？ 】
回答重点
下拉分页加载本质上是增量加载，每次下拉请求一小部分新数据追加到已有列表里，形成无限滚动的效果。
核心实现方案是游标分页，而不是传统的基于页码或偏移量的分页。
传统分页的问题在于数据会变。
用户在聊天室里持续收到新消息，如果按偏移量分页，第一页查了第 1-5 条，正准备查第二页的第 6-10 条
结果这时候来了 5 条新消息，原来的第 6-10 条变成了第 11-15 条，你再用 limit 5, 5 查出来的还是之前的第 1-5 条，数据就重复了。
新消息插入后，偏移量指向的数据就变了：
游标分页的做法是用一个游标值来跟踪位置，不依赖偏移量。
一般选消息的自增 ID 或时间戳作为游标，每次查完把最后一条记录的 ID 返回给前端。
下次前端带着这个游标值来请求，后端查 ID 小于游标值的数据：
SELECT * FROM messages
WHERE id < :cursorId
ORDER BY id DESC
LIMIT 5;
这样不管中间插入了多少新消息，查询都是从上次的位置往前翻，不会受新数据影响。
扩展知识
游标分页的性能优势
游标分页除了解决数据一致性问题，性能也比传统分页好得多。
传统偏移分页 limit 10000, 10 要先扫描跳过前 10000 条记录，偏移量越大越慢。
游标分页直接用 where id < xxx 走索引定位，不用扫描前面的记录，不管翻到第几页性能都差不多。
游标字段的选择
游标字段需要满足几个条件：
- 唯一性，不然定位会出问题
- 排序稳定，字段值不能变来变去
- 有索引，保证查询效率
- 不频繁更新，减少定位漂移
IM 系统里消息 ID 是最常用的游标，自增、唯一、有主键索引。
时间戳也能用，但要注意精度问题，秒级时间戳在高并发下可能重复，同一秒内的多条消息就分不清先后了。
更稳妥的方案是时间戳 + ID 复合游标，时间戳相同的情况下用 ID 兜底：
SELECT * FROM messages
WHERE (timestamp < :cursorTimestamp OR (timestamp = :cursorTimestamp AND id < :cursorId))
ORDER BY timestamp DESC, id DESC
LIMIT 10;
游标分页的适用场景
游标分页特别适合这几类场景：
- 数据持续增长，像 IM 消息、社交动态、日志流，新数据一直在插入
- 大数据量翻页，数据量上百万千万级别，传统分页深页查询会很慢
- 数据迁移同步，按游标批量拉取数据做增量同步
但游标分页有个局限：不支持直接跳页。用户想直接跳到第 100 页，游标分页做不到，只能一页一页翻过去。
所以如果业务上需要跳页能力，还得用传统分页，不过一般 IM 场景下拉加载不需要跳页。
前端配合实现
后端返回数据的时候，除了消息列表，还要带上下一页的游标值和是否还有更多数据的标识：
{
"messages": [...],
"nextCursor": "1234567890",
"hasMore": true
}
前端拿到 hasMore 为 false 就知道到底了，不用再发请求。下拉触发时带上 nextCursor 请求下一页，拿到数据追加到列表头部。
篇幅有限，更多 后端场景面试题 可以进入面试鸭进行查阅。
