我的2025总结:写代码这件事,被AI抢走之后

这两年，一个问题被反复提起：

程序员会不会被 AI 取代？

特别是当你第一次认真用上 AI 编程助手 —— 过去需要几天才能敲完、查完、踩完坑的功能，现在一句话就能跑出一版雏形，很难不开始焦虑。

对我个人来说，2025 年也是一个不得不停下来，重新审视AI 和工程师关系的年份。

• 一方面，大模型工具已经深入到我几乎每天的工作流里；
• 另一方面，身边越来越多同事开始有类似的困惑和兴奋：
• "写代码的门槛好像越来越低了，要失业了"；
• "以前要一周才能搞完的东西，现在一上午就解决了"；
• "大模型太牛逼了，这都能实现"。

这篇文章，一方面是借着 Werner 演讲的脉络，试着用一个稍微冷静一点的角度来看这件事；另一方面，也可以看作是我对自己这几年，尤其是走到 2026 年时，和 AI 一起工作的一个小结：

• 为什么我们会觉得程序员要失业了？
• 写代码不再稀缺之后，工程师的价值到底是什么？
• 在这个新周期里，什么样的工程师会变得更重要？

一、为什么这波 AI，会让程序员格外焦虑？

先说一点亲身感受。

过去的一年，我在公司内部做了几个 大模型相关的应用项目，比如：

• 面向业务同学的 ChatBI、Data Agent，希望他们可以自然语言提问、自动生成可视化数据分析报表，尝试让 Agent 做数据洞察、归因分析等工作；
• 面向数据工程团队的 SqlMaker ，希望利用历史审计日志和元数据信息辅助业务同学开发SQL。

大模型在这一年里的进化速度，远超我的预期。

一开始做这些项目时，我心里对 LLM 的预期还停留在：

• 能帮忙写一点函数代码
• 能帮忙完善一下测试案例、写个文档、整理一下思路

但随着模型迭代、插件生态丰富，以及我们在内部逐渐把它接入更多真实场景，我发现自己原本的工作习惯，几乎是被强制重构了一遍。

比如写代码这件事：

• 一开始，我只是零星体验公司内部的 CodeMaker，当成高级版代码补全和代码阅读工具；
• 后来，随着内部编程工具的迭代，也陆续去体验了外部的 Cursor、Claude Code、Gemini CLI 等工具；
• 慢慢地，我发现自己已经很少再从空白文件开始写代码——
• 更多是：用自然语言把需求和约束描述清楚
• 让工具先给一版可跑的实现
• 然后我在这个基础上继续与工具交互直到达到最终目的，即所谓的 Vibe Coding

这个转变带来的冲击感非常强：

写代码这件事，本身正在被重塑。

它还不完美，仍然会犯很蠢的错误，仍然需要大量审查和验证， 但你很难不承认：写代码的方式，已经被彻底改变了。

站在现在往后看，很容易得出一个结论：

未来大模型只会越来越厉害。

于是有一天晚上，我在改完一堆 AI 生成的代码之后，靠在椅背上发了会儿呆。

我盯着屏幕上那些被我一行行改过的代码，突然有点恍惚：

如果再过几年，它能做的事情更多、做得更好，那我还需要靠什么立足？ 我每天在做的事情，会变成什么样子？

后来跟几个朋友吃饭时聊起这事，发现大家或多或少都有过类似的时刻——那种被迫停下来想一想的感觉，好像是这两年一线工程师共同的心情。

之所以会焦虑，很大程度上是因为我们长期默认了一个前提：

工程师的价值，主要来自写代码。

在很长一段时间里，这几乎是共识。

• 写代码是稀缺能力
• 能把人的想法，稳定地翻译成机器可以执行的逻辑
• 本身就需要大量训练和经验积累

但这两年，当 AI 编程工具真正进入日常工作之后，这个前提开始松动了。

• AI 已经能写代码了，而且写得越来越快
• 很多模型还在飞速迭代，今天惊艳的效果，几个月后就成了基础能力

过去写一个功能，是拿时间一点点换结果：

• 查文档、翻源码
• 试 API、对参数
• 改 bug、跑测试

哪怕只是一个简单的 CRUD，也得来回几轮，最后慢慢打磨到稳定上线。

而现在，很多时候只要一句话，AI 就能给出一个"一眼能跑"的版本：

• 代码不一定完美，但结构、调用、异常处理都有了
• 你更多像是在审稿和修稿，而不是从零开始写

于是那个最直接的问题就冒出来了：

再过几年，等 AI 技术更成熟了， 程序员是不是就真的没有存在感了？

Werner 在演讲里，并没有直接给一个"会 / 不会"的简单结论。 他先做了一件很工程师的事：回顾历史。

二、回头看，工程师从来没被消失，消失的是旧工作内容

如果把软件开发这几十年拉成长时间轴，会看到几次重要的抽象层级上移：

1. 最早的时代，工程师写的是非常具体、也非常脆弱的代码

• 每一条指令，都要直接贴合机器的运行方式
• 任何一个细节出错，程序就无法工作
• 当时，"会写这套代码"本身就是核心门槛

2. 后来，有了语言、编译器和运行时

• 编译器、运行时、标准库开始系统性封装复杂性
• 大量底层细节，从工程师的日常工作中被挪开
• 写程序的门槛持续降低，高层抽象持续出现

3. 再后来，系统规模越来越大，难题从写出来变成跑得住

• 系统能否长期稳定运行？
• 出了问题，能不能快速恢复？
• 数据是不是可靠、可追溯？

如果顺着这条线往下看，会发现一个很有意思的规律：

工程师从来没有消失。 被逐步移走的，是那些已经可以被稳定处理、可以交给工具和机制的部分。

• 汇编→高级语言
• 手写内存管理→GC
• 手撸 Socket→高层网络库
• 自搭运维→云平台与各种 PaaS

每一次工具革命，都让一部分旧工作内容消失。 但真正的工程问题，并没有变简单，只是变了方向。

今天 AI 对写代码这件事做的事情，本质上和当年的编译器、运行时很像：

• 它把从自然语言/需求到初版代码的过程进行了一次大规模自动化
• 它把很多重复劳动，从工程师的日常工作中挪开

所以问题并不是工程师会不会突然没了，而是：

当写代码不再是最稀缺的那件事，工程师每天在操心的事情，会变成什么？

三、当写代码不再稀缺，工程师的价值在哪里？

今年的 AI，对很多工程师来说，是一种非常直观、甚至有点"找不着北"的变化：

过去需要自己一行行敲出来的东西，现在一句话就 AI 替你写完了。

所以很多人会困惑：

"如果写代码不再稀缺，那我还剩下什么？"

Werner 的回答，其实很朴素，但也很扎心：

工程真正的价值，从来不只是把代码写出来。 只是很长一段时间里，这两件事高度重合了。

当系统还不复杂、工具还不成熟时：

• 谁能把代码写对、写稳
• 谁就基本解决了大部分问题

于是我们很自然地，把两件事画上了等号：

• 会写代码 ≈ 是个好工程师

但当抽象层级不断上移，"写代码"被拆分出来，这个等号就开始失效了：

• 写代码，变成了一种基础能力
• 而不是你最终交付的价值

真正留下来的，是那些更难被工具接手的事情，比如：

• 面对一个现实但并不清晰的问题，能不能先判断清楚到底该解决什么？
• 面对多个看起来都说得通的方案，谁来做取舍，谁来承担选择带来的后果？
• 当系统真正在现实世界运行， 出了问题，有没有人能站出来兜住，而不是继续往后甩锅？

这些事情，并不是 AI 出现之后才有的。 它们一直都在，只是过去被写代码这件事给掩盖了。

当"把代码写出来"本身就很难时，我们很自然，会把工程师的价值全部压在这里。 可一旦这件事变得不再稀缺，工程中那些原本没那么起眼的部分，就会一下子浮出来。

Werner 在演讲里，其实想强调的是：

工程师真正赖以安身立命的，从来都不是某一种具体工具。 而是在工具不断变化之后，依然有人能理解系统在做什么， 也有人愿意为系统带来的结果负责。

当写代码不再是最难的那一步时， 工程师的价值，就转移到了判断、取舍和对结果负责上。

四、什么样的工程师，会在这个时代变得更重要？

说到这里，原始那个问题其实已经变形了：

从"会不会被取代？" 变成了"在这个时代，什么样的工程师会变得更重要？"

Werner 为此发明了一个新词：

文艺复兴式工程师

他借用"文艺复兴"这个词，并不是为了浪漫化工程师，而是因为当年的处境和今天格外相似：

• 文艺复兴时期：新工具出现，旧秩序松动
• 当下的软件开发：AI 工具涌现，原有的分工和边界正在瓦解

在这个过渡期，Werner 觉得，文艺复兴式工程师大致会有这些特质：

1. 保持好奇心，看到新工具，第一反应是试试

当新工具、新技术出现时：

• 第一反应不是排斥，也不是嘲讽
• 而是这东西能帮我解决什么问题？

好奇心，会驱动我们：

• 主动学习，而不是被动应付
• 主动改变，而不是被环境推着走

没有好奇心，很容易沉浸在已有的舒适区里，用自己熟悉的旧世界，对抗一个已经变化了的新世界。

2. 通过实验理解系统行为，而不是只停留在纸面设计

在复杂系统中，设计阶段无法穷尽所有情况。系统的真实行为，只有在运行之后才会显现出来。

• 实验，不是额外的学习方式
• 而是工程必需的一部分

系统之所以需要不断试跑和调整， 正是因为它的表现，无法完全被提前推导出来。

3. 通过社会化的方式修正认知，而不是关起门来想象

当系统的行为由多个组件、多个角色共同决定时：

• 单一视角很容易失真
• 单点经验也很容易局部最优

通过什么来修正？

• 与他人讨论架构与方案
• 跟运维、测试、业务同学一起看系统真实使用情况
• 把自己的理解，和真实世界的反馈不断对齐

工程师需要的，不再只是会写代码的个人能力， 而是能参与到一个复杂系统的集体认知校准中去的能力。

4. 从整体层面理解系统，看到连锁反应

复杂系统，并不是局部功能的简单叠加。

• 一个小的改动，可能通过反馈回路，影响整体行为
• 一个本地最优的优化，可能损害整体的鲁棒性

工程能力的分水岭，正在体现在：

是不是只能在自己的模块里做局部优化， 还是能从整体系统出发，评估变化带来的连锁影响。

5. 把沟通视为工程的一部分，而不是额外工作

随着 AI 参与开发，很多东西变成"用语言描述，再由机器落实"：

• 需求、约束、假设
• 架构意图、边界条件、容错策略

这意味着：

能否准确描述结构、边界和预期， 直接影响系统是否按照预想运行。

沟通能力，在这里起到的作用并不是多写文档， 而是降低歧义，让人和机器、不同角色之间的理解尽可能一致。

6. 对系统结果承担责任，而不是只盯着代码好不好看

工具可以加快实现速度，但系统一旦进入真实世界：

• 一定会出 Bug
• 一定会遇到极端情况
• 一定会被以各种意想不到的方式使用

这时候，总要有人为系统的行为负责。

这要求工程师在看得更少代码的同时：

• 对系统整体理解得更深
• 对关键路径验证得更严
• 对上线和变更有敬畏感

评审、测试和流程存在的意义，不是束缚工程师，而是：

把工程意图，转化为可持续、可依赖的结果。

五、写代码之外：去长一些完全不相关的能力

说了这么多工程能力的话题，再往外走一步，会发现还有一层常被忽略、但在 AI 时代反而更重要的东西：

程序员的人生，不必被锁死在技术栈里。

过去，技术更新本身就足够耗费精力：

• 白天写业务、晚上补框架、新技术、新协议
• 订阅一堆技术号、刷社区、追版本发布会

很自然地，我们会觉得：

"先把技术学好吧，其他东西等以后有空再说。"

但当 AI 已经能帮你把很多查文档、补样板、写样式、搭骨架的工作接过去之后， 你手里其实被腾出了一部分时间和心力，可以去长一些看上去和技术完全不相关的能力。

先分享一段很个人的小经历。

我在大学时，曾经做了差不多 7 年的校园宣传工作：

• 拍活动、拍人物、拍各种乱七八糟的宣传照，剪辑宣传视频；
• 硬着头皮学了一些摄影、构图，以及最常用的那三把 PS 调色、抠图、排版。

当时完全没想到这些东西将来会和写代码有什么关系， 只是单纯觉得：好像能把一张照片、一个海报做得更好看一点，很有成就感。

后来进入技术岗位，开始做后端、做数据、做平台， 一路走来，我却越来越频繁地意识到：

这些宣传时期练出来的审美和画面感， 其实在软件设计里，到处都派得上用场。

• 设计一个配置页面或管理后台时， 会本能地去想视觉重心在哪、信息有没有拥挤在一块；
• 写一个监控大盘、调度流程图， 会下意识地把真正重要的东西放在视觉路径最顺的地方；
• 就连给内部写文档、PPT 的时候， 也会多想一步：读到这里的人，到底会先看到什么、会不会直接关掉页面。

这些都不算什么专业设计，只是大学那几年顺手学的摄影和 PS， 在很长一段时间里潜伏着，最后在完全意想不到的地方帮了忙。

所以，当我现在回头看那段和专业技术看起来没什么关系的经历时， 反而会觉得：

它们是让我在技术世界里，保留了一点别的感官的东西。

而这类东西，其实远不止审美一种。

比如最直接、也最容易被忽略的几类：

• 美术与审美：
• 去学一点素描、色彩、构图，哪怕只是跟着网课画几幅速写；
• 拿起相机，认真拍一组"同一个场景的不同构图"，再比较哪张更有感觉。
• 经济学与社会学视角：
• 为什么这个功能一定要做，而另外一个看起来很酷的功能迟迟不上线？
• 为什么某些看起来技术很一般的产品，依然活得很好？
• 读几本通俗的经济学入门书，搞清楚价格、成本、激励背后的逻辑；
• 去观察产品、公司、行业中的行为：
• 文学、历史、心理学：
• 读一点小说、传记、历史书，试着理解不同时代、不同行业的人是怎么做选择的；
• 看看人是怎么被说服、怎么犹豫、怎么后悔、怎么坚持的。
• 跨行业交流：
• 多跟不同行业的朋友聊聊，了解他们目前面临的发展和困难；
• 对照自身的技术能力，看看是否能提供某种解决方案；
• 这既是拓宽视野的方式，也可能为自己的职业发展多开一条路。

这些东西，看上去离写代码很远，甚至很业余。 但一段时间之后你会发现，它们悄悄改变的是：

• 你看世界的角度：不再只是 API、架构、性能，而是这里面有哪些人，各自在意什么；
• 你理解问题的维度：不仅是这能不能实现，还包括"这样做，别人会怎么感受、怎么行动"；
• 你和别人的连接方式：从聊技术扩展到聊经历、聊选择、聊普通人的生活。

某种意义上，这些非技术的东西，会让你变得更像一个完整的人， 而不是只在特定场景里被调用的"技术函数"。

当 AI 越来越擅长处理清晰、可形式化的问题时， 那些依赖长期体验和多维观察才能形成的判断，就越难被替代。

• 你拍过无数张废片之后，对什么是好画面会有自己的感觉；
• 你在经济周期起落里工作过几年，对风险和安全感会有自己的理解；
• 你和完全不同行业的人真诚聊过天，对什么是好生活不会只剩下 KPI 和薪资曲线。

这些东西，很难靠一两篇文章学会，也很难被 AI 在几次对话里直接传输给你。 它们更像是：

在漫长时间里，通过一次次尝试、失败和体验，慢慢长出来的一种厚度。

而写代码，也会在这个过程中悄悄发生变化：

• 你不再只是为了完成任务写代码，而是为了支撑某种你认同的体验、故事或改变；
• 你对好产品，好系统的定义，会带上一层自己的标准，而不仅仅是延迟多少、QPS 多高。

从这个角度看，当 AI 把很多纯技术环节变得更轻松之后，给自己留一点空间，去认真体验技术栈之外的世界，本身就是一种很重要的投资。

六、写在最后：AI 不会替代你，但会放大你是谁

Werner 的演讲，听完之后我反复想了好几天。

如果用一句话来概括他对AI 和工程师的看法，大概是：

AI 不会一夜之间把工程师替代掉， 但它会非常快速地，放大你原本是什么样的工程师。

• 如果一个工程师，只把自己定义成写代码的人，当写代码变得不再稀缺，自然会觉得自己被挤压到了角落。
• 如果一个工程师，把自己看作对系统结果负责的人， 那么 AI 只会成为你手里的一件强力新工具。

在这个写代码越来越不稀缺的时代， 最值得怕的，其实不是 AI， 而是我们习惯了用一套旧的标准，来衡量自己的价值。

工具会不断变化，抽象层会不断上移。真正不变的，是那群仍然愿意：

• 理解系统
• 面对现实
• 做出判断
• 承担后果

的工程师。

这，才是 AI 时代，程序员最难被替代的部分。

写完这篇文章，说实话，我自己也没有完全想明白。

很多问题，我也还在摸索：比如怎么平衡用 AI 提效和保持自己的手感，比如未来到底该往哪个方向深耕。但至少写完之后，比之前清晰了一点点。

如果你也在想这些问题，希望这篇文章能给你一点参考。