AI写了90%代码,大厂程序员正在经历煎熬时刻

发布时间:2026/7/5 12:27:27
AI写了90%代码,大厂程序员正在经历煎熬时刻 1. 从「全栈」到「Vibe Coding」一个时代的转向如果你在 2022 年问一个大厂程序员「什么才是护城河」答案大概率是系统设计能力、抽象能力、踩坑经验。但在 2025 年之后这个问题开始不断被 Al Agent 重新定义。当 Claude Code、Cursor、Copilot、Codex CLI 和各家内部的代码大模型代理能够一次性完成需求分析、接口定义、上下游对齐和代码生成时一个让人不安的比例出现了在一次日常功能迭代中AI 实际产出的代码量已经达到甚至超过 90%。这 90% 并不是只会堆样板代码的「低级代码」而是能够跑通复杂业务逻辑、兼顾边界条件、甚至主动加上异常处理的工程级代码。大厂程序员正在经历的不再是「会不会被替代」的焦虑而是一种更隐秘的煎熬当 AI 把最吃经验、最需要设计直觉的那部分工作做完你要坐在那个位置扮演什么角色2. 那些让老员工集体破防的瞬间大厂工程师最初对 AI 编程工具的态度是轻松的。无非是 Stack Overflow 的替代品帮忙写写脚本、生成一些单元测试。但真正让他们破防的是下面这些具体瞬间代码评审变成了「点确认」同事提交的 MR 几乎完全由 Claude 生成逻辑滴水不漏注释详尽到让你挑不出任何多余优化。以前二十分钟才能读完的 diff现在两分钟扫完而你甚至不知道是自己能力变强了还是评审这件事变得可有可无了。从零到一不再需要你老板交给你一个中型需求说「你用一下工具两个半天给我」。你打开 Cursor用自然语言描述需求、上下文和约束AI 在十分钟内生成了完整可运行的第一版代码。你发现自己最熟练的「切分层、搭架子、写核心逻辑」的过程被完全压缩成了一段提示词。故障检修成了「人肉验证器」线上出问题时你习惯性地拉日志、看链路、查配置而身边的同事直接把错误堆栈喂给 Claude CodeAI 不仅定位到了根因还把修复方案和回归测试用例一并输出。那一刻你意识到严格来说排查过程你只是抄了日志。这些瞬间叠加在一起形成了一种「工程师效能空心化」的恐惧产能依然很高代码质量甚至更好但你自己写下的那部分代码变成了最不重要的一层胶水。3. 不可替代的 10%才是真的修罗场假设 AI 真的覆盖了 90% 的编码工作那剩下的 10% 是什么答案并不乐观因为这 10% 正是大厂程序员过去最想回避的那些工作决策负责当 AI 给出三种可行方案时谁来为最终的选择承担系统风险AI 不会为你凌晨三点接电话。跨团队对齐产品经理、运营、数据、合规、法务、其他业务线研发……这些人的需求从来不是标准化输入而是充满矛盾、妥协和政治考量的模糊指令。隐式知识的编码公司内部为什么有这条别扭的规则为什么那个看起来无用的字段不能删为什么这个接口必须保持幂等这些只活在老员工脑子里的上下文AI 很难在短期内从代码仓库中自己学到。架构演进方向的判断AI 可以帮你重构一个模块但它很难告诉你「整个系统应该在什么时候从单体拆解为微服务又在什么时候合并回来」。大厂程序员正在经历煎熬不是因为 AI 太强而是因为 AI 让分工发生了剧烈位移。以前你 90% 的时间在写代码10% 的时间在沟通和决策。现在写代码的时间被压缩到 10% 以内而你不得不面对另一项你并不擅长却越来越重要的工作承担模糊性、做出判断、对结果负责。4. 真正的煎熬工具在进化评价体系还停在原地更让大厂程序员感到不公的是虽然工作方式已经发生了根本变化但企业的绩效评价体系远没有跟上。在很多团队的 OKR 和晋升答辩模板里仍然充斥着「代码贡献量」「核心模块代码行数」「独立完成的复杂需求数」这类用代码量来衡量价值的指标。当 AI 帮你写了 90% 的代码你在晋升述职时要怎么讲「我用提示词驱动完成了这个项目」听起来不够硬核。「我负责把关和决策」这种软性描述在评审委员会眼里没有量化说服力。「我优化了 AI 的提示词让生成准确率从 70% 提升到 95%」这算不算一个正经的工程成果这才是真正的煎熬时刻你明明比以前更高效了解决业务问题的速度更快了但在现有的话语体系里你却感觉自己的价值正在被平台稀释。有些大厂已经开始试点将「AI 协同能力」「复杂决策质量」纳入考核但更多团队还在新旧评价标准之间撕扯而一线程序员正是那个被撕扯的对象。5. 重新寻找自己的位置从写代码的人到定义代码的人面对这种煎熬一部分程序员选择愤怒或摆烂而另一部分人已经开始重新定位自己的职业身份。他们不再把「我手写了多少行代码」当作勋章而是开始训练一种新的能力系统建模能力而不是代码实现能力能用结构化语言描述业务域、实体关系、状态机和数据流然后让 AI 把你脑子里的模型变成代码。你负责的是「对不对」AI 负责的是「怎么写」。约束工程而不是自由编码学会在提示词、上下文规则和审查流程中编码你的工程判断让 AI 在一个由你定义的安全边界内运行。验证驱动开发把大量心力从「写逻辑」转移到「写测试」「压测」「可观测性建设」上。当代码主要由 AI 生成时你唯一的锚点就是事实它到底有没有产生预期的生产行为沟通与妥协能力不回避与产品、运营、管理层之间的复杂对话。这部分「人」的工作恰恰是 AI 最不擅长的。一位在大厂工作了十年的资深工程师说得很直接「以前我们画类图是为了指导自己写代码现在画类图是为了指导 AI 写代码。区别在于原来你画错了一个属性还可以在代码里偷偷改回来现在画错了AI 会把整个系统按照错误的模型生成出来代码量越大损失越大。」这意味着以前允许模糊、允许边写边改的工作习惯已经失效了。你必须比以往任何时候都更清楚自己在构建什么以及为什么这么做。6. 熬过去的人会成为新的标准与其说 AI 正在淘汰程序员不如说 AI 正在淘汰一种工作模式。那种依赖大量人力堆砌代码、靠信息差保护个人价值的能力红利期即将结束。未来的大厂程序员大概率会分化为两种角色AI 驱动型工程师擅长用 AI 规模化解决问题工作重心从代码行数转移到系统设计的严谨性和需求的可解释性上。领域专家型工程师在某一个特定领域拥有极深的认知和决策经验AI 是他们的执行层而他们是 AI 的策略层。这两种角色都有一个共同点他们的价值不体现在手写代码的速度上而体现在定义问题和验证方案的能力上。对于正在经历煎熬的大厂程序员来说痛苦不来源于 AI 本身而来源于发现自己过去十年积累的肌肉记忆正在快速贬值。但这未必是一件坏事。当机械性的编码负担被 AI 拿走剩下的正是人类工程师最不应该回避的东西思考复杂问题、做出艰难抉择、承担最终的责任。也许是时候放下对代码行数的执念重新学习如何做一名「技术决策者」了。