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

最近俺刷到一條新聞：

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

光看數(shù)字還不夠震撼，俺把時(shí)間線拉了一下

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

• 2025 年秋：50%

• 2026 年 4 月：75%

18 個(gè)月，從 25% 干到 75%。

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

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

皮查伊還順帶丟了一顆炸彈：用 Gemini 輔助開(kāi)發(fā)復(fù)雜項(xiàng)目，效率是純?nèi)斯さ?6 倍。

新聞出來(lái)，評(píng)論區(qū)就開(kāi)始兩極分化

一邊是樂(lè)觀派：

“不是 AI 取代你，是會(huì)用 AI 的人取代你。”

“AI 淘汰的不是程序員，是'只會(huì)寫增刪改查'的程序員�！�

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

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

這兩派俺覺(jué)得都有道理。。

但俺想多說(shuō)一層，你們關(guān)注的都是那 75%，沒(méi)人看剩下那 25%。

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

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

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

• AI 能生成一段沒(méi)錯(cuò)誤的代碼，但它不會(huì)告訴你“這段代碼 QPS 一高就會(huì)擊穿 Redis”；

• AI 能補(bǔ)齊所有單元測(cè)試，但它不會(huì)替你背“上線后凌晨被叫起來(lái) debug”的那口鍋。

AI 越強(qiáng)，寫代碼越不值錢；審代碼、定架構(gòu)、扛事故，越值錢。

所以回頭看開(kāi)頭那個(gè)問(wèn)題：“谷歌 75% 代碼是 AI 寫的，程序員還學(xué)什么？”

俺的答案是：正因?yàn)?AI 寫了 75%，你才更要學(xué)那 25%。

換句話說(shuō)，程序員這個(gè)崗位并沒(méi)有被淘汰，只是崗位說(shuō)明書被重寫了。

以前招聘 JD 寫的是：

“熟練使用 Java/Python，能獨(dú)立完成需求開(kāi)發(fā)。”

以后的 JD 會(huì)變成：

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

面試題也會(huì)跟著變。放心，下一輪八股會(huì)更難，不會(huì)更簡(jiǎn)單。

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

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

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

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

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

AI 替代的不是“程序員”這個(gè)崗位，它替代的是“只把自己當(dāng)打字員”的那批程序員。

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

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

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

【什么是限流？限流算法有哪些？怎么實(shí)現(xiàn)的？ 】

回答重點(diǎn)

限流就是限制到達(dá)系統(tǒng)的并發(fā)請(qǐng)求數(shù)，讓系統(tǒng)只處理能力范圍內(nèi)的請(qǐng)求，超出的直接拒絕或排隊(duì)。

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

常見(jiàn)的限流算法有四種：計(jì)數(shù)器、滑動(dòng)窗口、漏桶、令牌桶。

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

1. 計(jì)數(shù)器：維護(hù)一個(gè)計(jì)數(shù)器，請(qǐng)求來(lái)了加一，窗口結(jié)束后計(jì)數(shù)重置為零，超過(guò)閾值就拒絕

2. 滑動(dòng)窗口：記錄時(shí)間窗口內(nèi)每個(gè)請(qǐng)求的時(shí)間點(diǎn)，統(tǒng)計(jì)窗口內(nèi)請(qǐng)求數(shù)是否超限

3. 漏桶：請(qǐng)求先進(jìn)桶排隊(duì)，服務(wù)端定速?gòu)耐袄锶≌?qǐng)求處理，桶滿則拒絕

4. 令牌桶：定速往桶里放令牌，請(qǐng)求來(lái)了先拿令牌，拿到才能通過(guò)，拿不到就拒絕

計(jì)數(shù)器最簡(jiǎn)單，Java 里用 AtomicInteger 就能實(shí)現(xiàn)單機(jī)限流，放 Redis 里就是分布式限流。缺點(diǎn)是無(wú)法應(yīng)對(duì)突發(fā)流量，1 萬(wàn)個(gè)請(qǐng)求一瞬間涌進(jìn)來(lái)，計(jì)數(shù)器還沒(méi)超限但系統(tǒng)已經(jīng)被打爆了。

滑動(dòng)窗口解決了固定窗口的臨界問(wèn)題，能保證任意時(shí)間窗口內(nèi)請(qǐng)求數(shù)不超限。代價(jià)是要記錄每個(gè)請(qǐng)求的時(shí)間戳，內(nèi)存占用比較大。

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

令牌桶是定速往桶里放令牌，桶里有令牌就能處理請(qǐng)求。突發(fā)流量來(lái)了，桶里攢了 100 個(gè)令牌，這 100 個(gè)請(qǐng)求可以瞬間通過(guò)，比漏桶更靈活。Guava 的 RateLimiter 就是令牌桶實(shí)現(xiàn)的。

擴(kuò)展知識(shí)限流是什么？

首先來(lái)解釋下什么是限流？

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

那在我們工程上限流是什么呢？限制的是 「流」，在不同場(chǎng)景下「流」的定義不同，可以是每秒請(qǐng)求數(shù)、每秒事務(wù)處理數(shù)、網(wǎng)絡(luò)流量等等。

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

限流不可避免的會(huì)造成用戶的請(qǐng)求變慢或者被拒的情況，從而會(huì)影響用戶體驗(yàn)。

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

對(duì)了，限流也稱流控（流量控制）。

為什么要限流？

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

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

亦或是爬蟲等不正常流量，我們對(duì)外暴露的服務(wù)都要以最大惡意去防備調(diào)用者。

我們不清楚調(diào)用者會(huì)如何調(diào)用我們的服務(wù)，假設(shè)某個(gè)調(diào)用者開(kāi)幾十個(gè)線程一天二十四小時(shí)瘋狂調(diào)用你的服務(wù)，如果不做啥處理咱服務(wù)也算完了，更勝的還有DDos攻擊。

還有對(duì)于很多第三方開(kāi)放平臺(tái)來(lái)說(shuō)，不僅僅要防備不正常流量，還要保證資源的公平利用，一些接口都免費(fèi)給你用了，資源都不可能一直都被你占著吧，別人也得調(diào)的。

當(dāng)然加錢的話好商量。

小結(jié)一下

限流的本質(zhì)是因?yàn)楹蠖颂幚砟芰τ邢蓿枰氐舫^(guò)處理能力之外的請(qǐng)求，亦或是為了均衡客戶端對(duì)服務(wù)端資源的公平調(diào)用，防止一些客戶端餓死。

計(jì)數(shù)限流

最簡(jiǎn)單的限流算法就是計(jì)數(shù)限流了。

例如系統(tǒng)能同時(shí)處理 100 個(gè)請(qǐng)求，保存一個(gè)計(jì)數(shù)器，處理了一個(gè)請(qǐng)求，計(jì)數(shù)器就加一，一個(gè)請(qǐng)求處理完畢之后計(jì)數(shù)器減一。

每次請(qǐng)求來(lái)的時(shí)候看看計(jì)數(shù)器的值，如果超過(guò)閾值就拒絕。

非常簡(jiǎn)單粗暴，計(jì)數(shù)器的值要是存內(nèi)存中就算單機(jī)限流算法。

如果放在第三方存儲(chǔ)里，例如 Redis 中，集群機(jī)器訪問(wèn)就算分布式限流算法。

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

缺點(diǎn)就是：假設(shè)我們?cè)试S的閾值是1萬(wàn)，此時(shí)計(jì)數(shù)器的值為 0， 當(dāng) 1 萬(wàn)個(gè)請(qǐng)求在前 1 秒內(nèi)一股腦兒的都涌進(jìn)來(lái)，這突發(fā)的流量可是頂不住的。

緩緩地增加流量處理和一下子涌入對(duì)于程序來(lái)說(shuō)是不一樣的。

而且一般的限流都是為了限制在指定時(shí)間間隔內(nèi)的訪問(wèn)量，因此還有個(gè)算法叫固定窗口。

固定窗口限流

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

• 請(qǐng)求次數(shù)小于閾值，允許訪問(wèn)并且計(jì)數(shù)器 +1；

• 請(qǐng)求次數(shù)大于閾值，拒絕訪問(wèn)；

• 這個(gè)時(shí)間窗口過(guò)了之后，計(jì)數(shù)器清零；

看起來(lái)好像很完美，實(shí)際上還是有缺陷的。

固定窗口臨界問(wèn)題

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

雖然窗口內(nèi)的計(jì)數(shù)沒(méi)超過(guò)閾值，但是全局來(lái)看在 0.55s-1.05s 這 0.5 秒內(nèi)涌入了 200 個(gè)請(qǐng)求，這其實(shí)對(duì)于閾值是 100/s 的系統(tǒng)來(lái)說(shuō)是無(wú)法接受的。

為了解決這個(gè)問(wèn)題引入了滑動(dòng)窗口限流。

滑動(dòng)窗口限流

滑動(dòng)窗口限流解決固定窗口臨界值的問(wèn)題，可以保證在任意時(shí)間窗口內(nèi)都不會(huì)超過(guò)閾值。

相對(duì)于固定窗口，滑動(dòng)窗口除了需要引入計(jì)數(shù)器之外還需要記錄時(shí)間窗口內(nèi)每個(gè)請(qǐng)求到達(dá)的時(shí)間點(diǎn)，因此對(duì)內(nèi)存的占用會(huì)比較多。

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

• 記錄每次請(qǐng)求的時(shí)間

• 統(tǒng)計(jì)每次請(qǐng)求的時(shí)間 至 往前推1秒這個(gè)時(shí)間窗口內(nèi)請(qǐng)求數(shù)，并且 1 秒前的數(shù)據(jù)可以刪除。

• 統(tǒng)計(jì)的請(qǐng)求數(shù)小于閾值就記錄這個(gè)請(qǐng)求的時(shí)間，并允許通過(guò)，反之拒絕。

但是滑動(dòng)窗口和固定窗口都無(wú)法解決短時(shí)間之內(nèi)集中流量的突擊。

我們所想的限流場(chǎng)景是：

每秒限制 100 個(gè)請(qǐng)求。希望請(qǐng)求每 10ms 來(lái)一個(gè)，這樣我們的流量處理就很平滑，但是真實(shí)場(chǎng)景很難控制請(qǐng)求的頻率，因此可能存在 5ms 內(nèi)就打滿了閾值的情況。

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

再多說(shuō)一句，這個(gè)滑動(dòng)窗口可與TCP的滑動(dòng)窗口不一樣。

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

接下來(lái)再說(shuō)說(shuō)漏桶，它可以解決時(shí)間窗口類的痛點(diǎn)，使得流量更加平滑。

篇幅有限，完整答案可以點(diǎn)擊下方小程序進(jìn)行查閱：

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

不僅有傳統(tǒng)八股文，場(chǎng)景題、項(xiàng)目題、系統(tǒng)設(shè)計(jì)題等等應(yīng)有盡有，還在不斷更新中！

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

且，現(xiàn)在邀請(qǐng)好友注冊(cè)并成為會(huì)員，還可獲得 10% 的分傭！詳情見(jiàn)面試?guó)喞卵?qǐng)有賞規(guī)則（網(wǎng)頁(yè)版面試?guó)嘃c(diǎn)擊頭像查看）

網(wǎng)頁(yè)端網(wǎng)址：www.mianshiya.com