上海
75% 新代码，都不是人写的
最近俺刷到一条新闻：
“谷歌 CEO 皮查伊宣布：公司内部新编写的代码，75% 由 AI 生成，然后再交给人类工程师审核。”
光看数字还不够震撼，俺把时间线拉了一下
2024 年 10 月：AI 生成代码比例25%
2025 年秋：50%
2026 年 4 月：75%
18 个月，从 25% 干到 75%。
这不是“稳步上升”，这是“指数级爬坡”。
顺便说一句，这也不是谷歌一家的事。Meta 早就放话，2025 Q4 部分组织要求工程师提交的代码改动里，55% 必须是 “Agent-Assisted”直接写进 KPI 了。
皮查伊还顺带丢了一颗炸弹：用 Gemini 辅助开发复杂项目，效率是纯人工的 6 倍。
新闻出来，评论区就开始两极分化
一边是乐观派：
“不是 AI 取代你，是会用 AI 的人取代你。”
“AI 淘汰的不是程序员，是'只会写增删改查'的程序员。”
另一边是冷水派，一句话让整个楼塌了：
“谷歌这一招，表面是提效，实际是在测试'最低人力配置'。”
这两派俺觉得都有道理。。
但俺想多说一层，你们关注的都是那 75%，没人看剩下那 25%。
而程序员未来值多少钱，不是取决于 AI 能写多少，而是取决于你能不能吃下那 25%。
这 25% 是什么？是审核、架构、需求、边界、翻车兜底。
AI 能写一个能跑的登录接口，但它不知道你们公司同一套账户体系在 6 个业务线里是怎么串的；
AI 能生成一段没错误的代码，但它不会告诉你“这段代码 QPS 一高就会击穿 Redis”；
AI 能补齐所有单元测试，但它不会替你背“上线后凌晨被叫起来 debug”的那口锅。
AI 越强，写代码越不值钱；审代码、定架构、扛事故，越值钱。
所以回头看开头那个问题：“谷歌 75% 代码是 AI 写的，程序员还学什么？”
俺的答案是：正因为 AI 写了 75%，你才更要学那 25%。
换句话说，程序员这个岗位并没有被淘汰，只是岗位说明书被重写了。
以前招聘 JD 写的是：
“熟练使用 Java/Python，能独立完成需求开发。”
以后的 JD 会变成：
“能指挥 AI 输出可用代码，能 Review 复杂系统的 AI 产出，能在 AI 出错时快速定位并兜底。”
面试题也会跟着变。放心，下一轮八股会更难，不会更简单。
那作为正在准备面试、或者刚上班两三年的同学，俺给三条具体建议
把 Cursor / Claude Code / Copilot 用出肌肉记忆：不是“偶尔打开一下”，是“默认开着”。不会用 AI 的程序员，在 2026 年等同于不会用 IDE；
练“审代码”比练“写代码”重要：找 AI 给你生成一段代码，然后自己 code review，挑出三条可以优化的地方（这是以后面试的标准动作）；
多花时间在“AI 做不了的事”上：系统设计、业务建模、复杂排查、团队沟通。这些是你的 25%，也是你的护城河。
最重要的一句话送给所有还在焦虑的同学
AI 替代的不是“程序员”这个岗位，它替代的是“只把自己当打字员”的那批程序员。
把自己从“代码生产者”升级成“代码决策者”，谷歌这 75% 对你就不是坏消息，而是涨薪的理由。
大家怎么看？你们公司现在 AI 写代码的比例大概多少？评论区聊聊～
今天俺和大家分享一道「后端场景题面试题」。
【什么是限流？限流算法有哪些？怎么实现的？ 】
回答重点
限流就是限制到达系统的并发请求数，让系统只处理能力范围内的请求，超出的直接拒绝或排队。
本质上是在用户体验和系统稳定性之间做权衡。
常见的限流算法有四种：计数器、滑动窗口、漏桶、令牌桶。
四种限流算法的核心思想：
计数器：维护一个计数器，请求来了加一，窗口结束后计数重置为零，超过阈值就拒绝
滑动窗口：记录时间窗口内每个请求的时间点，统计窗口内请求数是否超限
漏桶：请求先进桶排队，服务端定速从桶里取请求处理，桶满则拒绝
令牌桶：定速往桶里放令牌，请求来了先拿令牌，拿到才能通过，拿不到就拒绝
计数器最简单，Java 里用 AtomicInteger 就能实现单机限流，放 Redis 里就是分布式限流。缺点是无法应对突发流量，1 万个请求一瞬间涌进来，计数器还没超限但系统已经被打爆了。
滑动窗口解决了固定窗口的临界问题，能保证任意时间窗口内请求数不超限。代价是要记录每个请求的时间戳，内存占用比较大。
漏桶的特点是宽进严出，不管请求来得多猛，出去的速度是恒定的。优点是流量极其平滑，缺点是没法应对突发流量，明明系统有余力也只能慢慢处理。
令牌桶是定速往桶里放令牌，桶里有令牌就能处理请求。突发流量来了，桶里攒了 100 个令牌，这 100 个请求可以瞬间通过，比漏桶更灵活。Guava 的 RateLimiter 就是令牌桶实现的。
扩展知识限流是什么？
首先来解释下什么是限流？
在日常生活中限流很常见，例如去有些景区玩，每天售卖的门票数是有限的，例如 2000 张，即每天最多只有 2000 个人能进去游玩。
那在我们工程上限流是什么呢？限制的是 「流」，在不同场景下「流」的定义不同，可以是每秒请求数、每秒事务处理数、网络流量等等。
而通常我们说的限流指代的是限制到达系统的并发请求数，使得系统能够正常的处理部分用户的请求，来保证系统的稳定性。
限流不可避免的会造成用户的请求变慢或者被拒的情况，从而会影响用户体验。
因此限流是需要在用户体验和系统稳定性之间做平衡的，即我们常说的trade off。
对了，限流也称流控（流量控制）。
为什么要限流？
前面，我们提到限流是为了保证系统的稳定性。
日常的业务上有类似秒杀活动、双十一大促或者突发新闻等场景，用户的流量突增，后端服务的处理能力是有限的，如果不能处理好突发流量，后端服务很容易就被打垮。
亦或是爬虫等不正常流量，我们对外暴露的服务都要以最大恶意去防备调用者。
我们不清楚调用者会如何调用我们的服务，假设某个调用者开几十个线程一天二十四小时疯狂调用你的服务，如果不做啥处理咱服务也算完了，更胜的还有DDos攻击。
还有对于很多第三方开放平台来说，不仅仅要防备不正常流量，还要保证资源的公平利用，一些接口都免费给你用了，资源都不可能一直都被你占着吧，别人也得调的。
当然加钱的话好商量。
小结一下
限流的本质是因为后端处理能力有限，需要截掉超过处理能力之外的请求，亦或是为了均衡客户端对服务端资源的公平调用，防止一些客户端饿死。
计数限流
最简单的限流算法就是计数限流了。
例如系统能同时处理 100 个请求，保存一个计数器，处理了一个请求，计数器就加一，一个请求处理完毕之后计数器减一。
每次请求来的时候看看计数器的值，如果超过阈值就拒绝。
非常简单粗暴，计数器的值要是存内存中就算单机限流算法。
如果放在第三方存储里，例如 Redis 中，集群机器访问就算分布式限流算法。
优点就是：简单粗暴，单机在 Java 中可用 Atomic 等原子类、分布式就 Redis incr。
缺点就是：假设我们允许的阈值是1万，此时计数器的值为 0， 当 1 万个请求在前 1 秒内一股脑儿的都涌进来，这突发的流量可是顶不住的。
缓缓地增加流量处理和一下子涌入对于程序来说是不一样的。
而且一般的限流都是为了限制在指定时间间隔内的访问量，因此还有个算法叫固定窗口。
固定窗口限流
它相比于计数限流主要是多了个时间窗口的概念，计数器每过一个时间窗口就重置。规则如下：
请求次数小于阈值，允许访问并且计数器 +1；
请求次数大于阈值，拒绝访问；
这个时间窗口过了之后，计数器清零；
看起来好像很完美，实际上还是有缺陷的。
固定窗口临界问题
假设系统每秒允许 100 个请求，假设第一个时间窗口是 0-1s，在第 0.55s 处一下次涌入 100 个请求，过了 1 秒的时间窗口后计数清零，此时在 1.05 s 的时候又一下次涌入100个请求。
虽然窗口内的计数没超过阈值，但是全局来看在 0.55s-1.05s 这 0.5 秒内涌入了 200 个请求，这其实对于阈值是 100/s 的系统来说是无法接受的。
为了解决这个问题引入了滑动窗口限流。
滑动窗口限流
滑动窗口限流解决固定窗口临界值的问题，可以保证在任意时间窗口内都不会超过阈值。
相对于固定窗口，滑动窗口除了需要引入计数器之外还需要记录时间窗口内每个请求到达的时间点，因此对内存的占用会比较多。
规则如下，假设时间窗口为 1 秒：
记录每次请求的时间
统计每次请求的时间 至 往前推1秒这个时间窗口内请求数，并且 1 秒前的数据可以删除。
统计的请求数小于阈值就记录这个请求的时间，并允许通过，反之拒绝。
但是滑动窗口和固定窗口都无法解决短时间之内集中流量的突击。
我们所想的限流场景是：
每秒限制 100 个请求。希望请求每 10ms 来一个，这样我们的流量处理就很平滑，但是真实场景很难控制请求的频率，因此可能存在 5ms 内就打满了阈值的情况。
当然对于这种情况还是有变型处理的，例如设置多条限流规则。不仅限制每秒 100 个请求，再设置每 10ms 不超过 2 个。
再多说一句，这个滑动窗口可与TCP的滑动窗口不一样。
TCP的滑动窗口是接收方告知发送方自己能接多少“货”，然后发送方控制发送的速率。
接下来再说说漏桶，它可以解决时间窗口类的痛点，使得流量更加平滑。
篇幅有限，完整答案可以点击下方小程序进行查阅：
我们精选了近两年的高频面试真题，已经有 10000 多道面试题目啦，由大厂资深面试官手写答案，押题命中率超高！
不仅有传统八股文，场景题、项目题、系统设计题等等应有尽有，还在不断更新中！
目前优惠最低特价 129 元即永久（限时上架）畅看所有面试题和答案，正式运营价格为 399+，不要错过这次优惠哈！
且，现在邀请好友注册并成为会员，还可获得 10% 的分佣！详情见面试鸭拉新邀请有赏规则（网页版面试鸭点击头像查看）
网页端网址：www.mianshiya.com
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
