75% 新代碼，都不是人寫的

最近俺刷到一條新聞：

“谷歌 CEO 皮查伊宣布：公司內部新編寫的代碼，75% 由 AI 生成，然后再交給人類工程師審核�！�

光看數字還不夠震撼，俺把時間線拉了一下

• 2024 年 10 月：AI 生成代碼比例25%

• 2025 年秋：50%

• 2026 年 4 月：75%

18 個月，從 25% 干到 75%。

這不是“穩(wěn)步上升”，這是“指數級爬坡”。

順便說一句，這也不是谷歌一家的事。Meta 早就放話，2025 Q4 部分組織要求工程師提交的代碼改動里，55% 必須是 “Agent-Assisted”直接寫進 KPI 了。

皮查伊還順帶丟了一顆炸彈：用 Gemini 輔助開發(fā)復雜項目，效率是純人工的 6 倍。

新聞出來，評論區(qū)就開始兩極分化

一邊是樂觀派：

“不是 AI 取代你，是會用 AI 的人取代你�！�

“AI 淘汰的不是程序員，是'只會寫增刪改查'的程序員。”

另一邊是冷水派，一句話讓整個樓塌了：

“谷歌這一招，表面是提效，實際是在測試'最低人力配置'�！�

這兩派俺覺得都有道理。。

但俺想多說一層，你們關注的都是那 75%，沒人看剩下那 25%。

而程序員未來值多少錢，不是取決于 AI 能寫多少，而是取決于你能不能吃下那 25%。

這 25% 是什么？是審核、架構、需求、邊界、翻車兜底。

• AI 能寫一個能跑的登錄接口，但它不知道你們公司同一套賬戶體系在 6 個業(yè)務線里是怎么串的；

• AI 能生成一段沒錯誤的代碼，但它不會告訴你“這段代碼 QPS 一高就會擊穿 Redis”；

• AI 能補齊所有單元測試，但它不會替你背“上線后凌晨被叫起來 debug”的那口鍋。

AI 越強，寫代碼越不值錢；審代碼、定架構、扛事故，越值錢。

所以回頭看開頭那個問題：“谷歌 75% 代碼是 AI 寫的，程序員還學什么？”

俺的答案是：正因為 AI 寫了 75%，你才更要學那 25%。

換句話說，程序員這個崗位并沒有被淘汰，只是崗位說明書被重寫了。

以前招聘 JD 寫的是：

“熟練使用 Java/Python，能獨立完成需求開發(fā)�！�

以后的 JD 會變成：

“能指揮 AI 輸出可用代碼，能 Review 復雜系統(tǒng)的 AI 產出，能在 AI 出錯時快速定位并兜底�！�

面試題也會跟著變。放心，下一輪八股會更難，不會更簡單。

那作為正在準備面試、或者剛上班兩三年的同學，俺給三條具體建議

• 把 Cursor / Claude Code / Copilot 用出肌肉記憶：不是“偶爾打開一下”，是“默認開著”。不會用 AI 的程序員，在 2026 年等同于不會用 IDE；

• 練“審代碼”比練“寫代碼”重要：找 AI 給你生成一段代碼，然后自己 code review，挑出三條可以優(yōu)化的地方（這是以后面試的標準動作）；

• 多花時間在“AI 做不了的事”上：系統(tǒng)設計、業(yè)務建模、復雜排查、團隊溝通。這些是你的 25%，也是你的護城河。

最重要的一句話送給所有還在焦慮的同學

AI 替代的不是“程序員”這個崗位，它替代的是“只把自己當打字員”的那批程序員。

把自己從“代碼生產者”升級成“代碼決策者”，谷歌這 75% 對你就不是壞消息，而是漲薪的理由。

大家怎么看？你們公司現在 AI 寫代碼的比例大概多少？評論區(qū)聊聊～

今天俺和大家分享一道「后端場景題面試題」。

【什么是限流？限流算法有哪些？怎么實現的？ 】

回答重點

限流就是限制到達系統(tǒng)的并發(fā)請求數，讓系統(tǒng)只處理能力范圍內的請求，超出的直接拒絕或排隊。

本質上是在用戶體驗和系統(tǒng)穩(wěn)定性之間做權衡。

常見的限流算法有四種：計數器、滑動窗口、漏桶、令牌桶。

四種限流算法的核心思想：

1. 計數器：維護一個計數器，請求來了加一，窗口結束后計數重置為零，超過閾值就拒絕

2. 滑動窗口：記錄時間窗口內每個請求的時間點，統(tǒng)計窗口內請求數是否超限

3. 漏桶：請求先進桶排隊，服務端定速從桶里取請求處理，桶滿則拒絕

4. 令牌桶：定速往桶里放令牌，請求來了先拿令牌，拿到才能通過，拿不到就拒絕

計數器最簡單，Java 里用 AtomicInteger 就能實現單機限流，放 Redis 里就是分布式限流。缺點是無法應對突發(fā)流量，1 萬個請求一瞬間涌進來，計數器還沒超限但系統(tǒng)已經被打爆了。

滑動窗口解決了固定窗口的臨界問題，能保證任意時間窗口內請求數不超限。代價是要記錄每個請求的時間戳，內存占用比較大。

漏桶的特點是寬進嚴出，不管請求來得多猛，出去的速度是恒定的。優(yōu)點是流量極其平滑，缺點是沒法應對突發(fā)流量，明明系統(tǒng)有余力也只能慢慢處理。

令牌桶是定速往桶里放令牌，桶里有令牌就能處理請求。突發(fā)流量來了，桶里攢了 100 個令牌，這 100 個請求可以瞬間通過，比漏桶更靈活。Guava 的 RateLimiter 就是令牌桶實現的。

擴展知識限流是什么？

首先來解釋下什么是限流？

在日常生活中限流很常見，例如去有些景區(qū)玩，每天售賣的門票數是有限的，例如 2000 張，即每天最多只有 2000 個人能進去游玩。

那在我們工程上限流是什么呢？限制的是 「流」，在不同場景下「流」的定義不同，可以是每秒請求數、每秒事務處理數、網絡流量等等。

而通常我們說的限流指代的是限制到達系統(tǒng)的并發(fā)請求數，使得系統(tǒng)能夠正常的處理部分用戶的請求，來保證系統(tǒng)的穩(wěn)定性。

限流不可避免的會造成用戶的請求變慢或者被拒的情況，從而會影響用戶體驗。

因此限流是需要在用戶體驗和系統(tǒng)穩(wěn)定性之間做平衡的，即我們常說的trade off。

對了，限流也稱流控（流量控制）。

為什么要限流？

前面，我們提到限流是為了保證系統(tǒng)的穩(wěn)定性。

日常的業(yè)務上有類似秒殺活動、雙十一大促或者突發(fā)新聞等場景，用戶的流量突增，后端服務的處理能力是有限的，如果不能處理好突發(fā)流量，后端服務很容易就被打垮。

亦或是爬蟲等不正常流量，我們對外暴露的服務都要以最大惡意去防備調用者。

我們不清楚調用者會如何調用我們的服務，假設某個調用者開幾十個線程一天二十四小時瘋狂調用你的服務，如果不做啥處理咱服務也算完了，更勝的還有DDos攻擊。

還有對于很多第三方開放平臺來說，不僅僅要防備不正常流量，還要保證資源的公平利用，一些接口都免費給你用了，資源都不可能一直都被你占著吧，別人也得調的。

當然加錢的話好商量。

小結一下

限流的本質是因為后端處理能力有限，需要截掉超過處理能力之外的請求，亦或是為了均衡客戶端對服務端資源的公平調用，防止一些客戶端餓死。

計數限流

最簡單的限流算法就是計數限流了。

例如系統(tǒng)能同時處理 100 個請求，保存一個計數器，處理了一個請求，計數器就加一，一個請求處理完畢之后計數器減一。

每次請求來的時候看看計數器的值，如果超過閾值就拒絕。

非常簡單粗暴，計數器的值要是存內存中就算單機限流算法。

如果放在第三方存儲里，例如 Redis 中，集群機器訪問就算分布式限流算法。

優(yōu)點就是：簡單粗暴，單機在 Java 中可用 Atomic 等原子類、分布式就 Redis incr。

缺點就是：假設我們允許的閾值是1萬，此時計數器的值為 0， 當 1 萬個請求在前 1 秒內一股腦兒的都涌進來，這突發(fā)的流量可是頂不住的。

緩緩地增加流量處理和一下子涌入對于程序來說是不一樣的。

而且一般的限流都是為了限制在指定時間間隔內的訪問量，因此還有個算法叫固定窗口。

固定窗口限流

它相比于計數限流主要是多了個時間窗口的概念，計數器每過一個時間窗口就重置。規(guī)則如下：

• 請求次數小于閾值，允許訪問并且計數器 +1；

• 請求次數大于閾值，拒絕訪問；

• 這個時間窗口過了之后，計數器清零；

看起來好像很完美，實際上還是有缺陷的。

固定窗口臨界問題

假設系統(tǒng)每秒允許 100 個請求，假設第一個時間窗口是 0-1s，在第 0.55s 處一下次涌入 100 個請求，過了 1 秒的時間窗口后計數清零，此時在 1.05 s 的時候又一下次涌入100個請求。

雖然窗口內的計數沒超過閾值，但是全局來看在 0.55s-1.05s 這 0.5 秒內涌入了 200 個請求，這其實對于閾值是 100/s 的系統(tǒng)來說是無法接受的。

為了解決這個問題引入了滑動窗口限流。

滑動窗口限流

滑動窗口限流解決固定窗口臨界值的問題，可以保證在任意時間窗口內都不會超過閾值。

相對于固定窗口，滑動窗口除了需要引入計數器之外還需要記錄時間窗口內每個請求到達的時間點，因此對內存的占用會比較多。

規(guī)則如下，假設時間窗口為 1 秒：

• 記錄每次請求的時間

• 統(tǒng)計每次請求的時間 至 往前推1秒這個時間窗口內請求數，并且 1 秒前的數據可以刪除。

• 統(tǒng)計的請求數小于閾值就記錄這個請求的時間，并允許通過，反之拒絕。

但是滑動窗口和固定窗口都無法解決短時間之內集中流量的突擊。

我們所想的限流場景是：

每秒限制 100 個請求。希望請求每 10ms 來一個，這樣我們的流量處理就很平滑，但是真實場景很難控制請求的頻率，因此可能存在 5ms 內就打滿了閾值的情況。

當然對于這種情況還是有變型處理的，例如設置多條限流規(guī)則。不僅限制每秒 100 個請求，再設置每 10ms 不超過 2 個。

再多說一句，這個滑動窗口可與TCP的滑動窗口不一樣。

TCP的滑動窗口是接收方告知發(fā)送方自己能接多少“貨”，然后發(fā)送方控制發(fā)送的速率。

接下來再說說漏桶，它可以解決時間窗口類的痛點，使得流量更加平滑。

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

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

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

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

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

網頁端網址：www.mianshiya.com