面試官：“你一天燒多少 Token？” 我：“不知道。” 面試官：“那你別面了，回去吧。”

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，一定是三個復合指標——

1. Token / 產出比（燒了多少換來了什么）

2. AI 輔助覆蓋率（你工作流里有幾個環節掛上了 AI）

3. 產出質量（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
ORDERBY id DESC
LIMIT5;

這樣不管中間插入了多少新消息，查詢都是從上次的位置往前翻，不會受新數據影響。

擴展知識游標分頁的性能優勢

游標分頁除了解決數據一致性問題，性能也比傳統分頁好得多。

傳統偏移分頁 limit 10000, 10 要先掃描跳過前 10000 條記錄，偏移量越大越慢。

游標分頁直接用 where id < xxx 走索引定位，不用掃描前面的記錄，不管翻到第幾頁性能都差不多。

游標字段的選擇

游標字段需要滿足幾個條件：

1. 唯一性，不然定位會出問題

2. 排序穩定，字段值不能變來變去

3. 有索引，保證查詢效率

4. 不頻繁更新，減少定位漂移

IM 系統里消息 ID 是最常用的游標，自增、唯一、有主鍵索引。

時間戳也能用，但要注意精度問題，秒級時間戳在高并發下可能重復，同一秒內的多條消息就分不清先后了。

更穩妥的方案是時間戳 + ID 復合游標，時間戳相同的情況下用 ID 兜底：

SELECT*FROM messages
WHERE(timestamp<:cursorTimestamp OR(timestamp=:cursorTimestamp AND id <:cursorId))
ORDERBYtimestampDESC, id DESC
LIMIT10;

游標分頁的適用場景

游標分頁特別適合這幾類場景：

1. 數據持續增長，像 IM 消息、社交動態、日志流，新數據一直在插入

2. 大數據量翻頁，數據量上百萬千萬級別，傳統分頁深頁查詢會很慢

3. 數據遷移同步，按游標批量拉取數據做增量同步

但游標分頁有個局限：不支持直接跳頁。用戶想直接跳到第 100 頁，游標分頁做不到，只能一頁一頁翻過去。

所以如果業務上需要跳頁能力，還得用傳統分頁，不過一般 IM 場景下拉加載不需要跳頁。

前端配合實現

后端返回數據的時候，除了消息列表，還要帶上下一頁的游標值和是否還有更多數據的標識：

{
"messages": [...],
"nextCursor": "1234567890",
"hasMore": true
}

前端拿到 hasMore 為 false 就知道到底了，不用再發請求。下拉觸發時帶上 nextCursor 請求下一頁，拿到數據追加到列表頭部。

篇幅有限，完整答案可以點擊下方小程序進行查閱：

我們精選了近兩年的高頻面試真題，已經有 10000 多道面試題目啦，由大廠資深面試官手寫答案，押題命中率超高！

不僅有傳統八股文，場景題、項目題、系統設計題等等應有盡有，還在不斷更新中！

目前優惠最低特價 129 元即永久（限時上架）暢看所有面試題和答案，正式運營價格為 399+，不要錯過這次優惠哈！

且，現在邀請好友注冊并成為會員，還可獲得 10% 的分傭！詳情見面試鴨拉新邀請有賞規則（網頁版面試鴨點擊頭像查看）

網頁端網址：www.mianshiya.com