看了 AWS CTO Werner 的谢幕演讲，有一句感受特别强烈： “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 编程工具真正进入日常工作之后，这个前提开始松动了。
- 很多模型还在飞速迭代，今天惊艳的效果，几个月后就成了基础能力
过去写一个功能，是拿时间一点点换结果：
哪怕只是一个简单的 CRUD，也得来回几轮，最后慢慢打磨到稳定上线。
而现在，很多时候只要一句话，AI 就能给出一个"一眼能跑"的版本：
于是那个最直接的问题就冒出来了：
再过几年，等 AI 技术更成熟了， 程序员是不是就真的没有存在感了？
Werner 在演讲里，并没有直接给一个"会 / 不会"的简单结论。 他先做了一件很工程师的事：回顾历史。
二、回头看，工程师从来没被消失，消失的是旧工作内容
如果把软件开发这几十年拉成长时间轴，会看到几次重要的抽象层级上移：
最早的时代，工程师写的是非常具体、也非常脆弱的代码
后来，有了语言、编译器和运行时
再后来，系统规模越来越大，难题从写出来变成跑得住
如果顺着这条线往下看，会发现一个很有意思的规律：
工程师从来没有消失。 被逐步移走的，是那些已经可以被稳定处理、可以交给工具和机制的部分。
每一次工具革命，都让一部分旧工作内容消失。 但真正的工程问题，并没有变简单，只是变了方向。
今天 AI 对写代码这件事做的事情，本质上和当年的编译器、运行时很像：
- 它把从自然语言/需求到初版代码的过程进行了一次大规模自动化
所以问题并不是工程师会不会突然没了，而是：
当写代码不再是最稀缺的那件事，工程师每天在操心的事情，会变成什么？
三、当写代码不再稀缺，工程师的价值在哪里？
今年的 AI，对很多工程师来说，是一种非常直观、甚至有点"找不着北"的变化：
过去需要自己一行行敲出来的东西，现在一句话就 AI 替你写完了。
所以很多人会困惑：
"如果写代码不再稀缺，那我还剩下什么？"
Werner 的回答，其实很朴素，但也很扎心：
工程真正的价值，从来不只是把代码写出来。 只是很长一段时间里，这两件事高度重合了。
当系统还不复杂、工具还不成熟时：
于是我们很自然地，把两件事画上了等号：
但当抽象层级不断上移，"写代码"被拆分出来，这个等号就开始失效了：
真正留下来的，是那些更难被工具接手的事情，比如：
- 面对一个现实但并不清晰的问题，能不能先判断清楚到底该解决什么？
- 面对多个看起来都说得通的方案，谁来做取舍，谁来承担选择带来的后果？
- 当系统真正在现实世界运行， 出了问题，有没有人能站出来兜住，而不是继续往后甩锅？
这些事情，并不是 AI 出现之后才有的。 它们一直都在，只是过去被写代码这件事给掩盖了。
当"把代码写出来"本身就很难时，我们很自然，会把工程师的价值全部压在这里。 可一旦这件事变得不再稀缺，工程中那些原本没那么起眼的部分，就会一下子浮出来。
Werner 在演讲里，其实想强调的是：
工程师真正赖以安身立命的，从来都不是某一种具体工具。 而是在工具不断变化之后，依然有人能理解系统在做什么， 也有人愿意为系统带来的结果负责。
当写代码不再是最难的那一步时， 工程师的价值，就转移到了判断、取舍和对结果负责上。
四、什么样的工程师，会在这个时代变得更重要？
说到这里，原始那个问题其实已经变形了：
从"会不会被取代？" 变成了"在这个时代，什么样的工程师会变得更重要？"
Werner 为此发明了一个新词：
文艺复兴式工程师
他借用"文艺复兴"这个词，并不是为了浪漫化工程师，而是因为当年的处境和今天格外相似：
- 当下的软件开发：AI 工具涌现，原有的分工和边界正在瓦解
在这个过渡期，Werner 觉得，文艺复兴式工程师大致会有这些特质：
1. 保持好奇心，看到新工具，第一反应是试试
当新工具、新技术出现时：
好奇心，会驱动我们：
没有好奇心，很容易沉浸在已有的舒适区里，用自己熟悉的旧世界，对抗一个已经变化了的新世界。
2. 通过实验理解系统行为，而不是只停留在纸面设计
在复杂系统中，设计阶段无法穷尽所有情况。系统的真实行为，只有在运行之后才会显现出来。
系统之所以需要不断试跑和调整， 正是因为它的表现，无法完全被提前推导出来。
3. 通过社会化的方式修正认知，而不是关起门来想象
当系统的行为由多个组件、多个角色共同决定时：
通过什么来修正？
工程师需要的，不再只是会写代码的个人能力， 而是能参与到一个复杂系统的集体认知校准中去的能力。
4. 从整体层面理解系统，看到连锁反应
复杂系统，并不是局部功能的简单叠加。
工程能力的分水岭，正在体现在：
是不是只能在自己的模块里做局部优化， 还是能从整体系统出发，评估变化带来的连锁影响。
5. 把沟通视为工程的一部分，而不是额外工作
随着 AI 参与开发，很多东西变成"用语言描述，再由机器落实"：
这意味着：
能否准确描述结构、边界和预期， 直接影响系统是否按照预想运行。
沟通能力，在这里起到的作用并不是多写文档， 而是降低歧义，让人和机器、不同角色之间的理解尽可能一致。
6. 对系统结果承担责任，而不是只盯着代码好不好看
工具可以加快实现速度，但系统一旦进入真实世界：
这时候，总要有人为系统的行为负责。
这要求工程师在看得更少代码的同时：
评审、测试和流程存在的意义，不是束缚工程师，而是：
把工程意图，转化为可持续、可依赖的结果。
五、写代码之外：去长一些完全不相关的能力
说了这么多工程能力的话题，再往外走一步，会发现还有一层常被忽略、但在 AI 时代反而更重要的东西：
程序员的人生，不必被锁死在技术栈里。
过去，技术更新本身就足够耗费精力：
很自然地，我们会觉得：
"先把技术学好吧，其他东西等以后有空再说。"
但当 AI 已经能帮你把很多查文档、补样板、写样式、搭骨架的工作接过去之后， 你手里其实被腾出了一部分时间和心力，可以去长一些看上去和技术完全不相关的能力。
先分享一段很个人的小经历。
我在大学时，曾经做了差不多 7 年的校园宣传工作：
- 拍活动、拍人物、拍各种乱七八糟的宣传照，剪辑宣传视频；
- 硬着头皮学了一些摄影、构图，以及最常用的那三把 PS 调色、抠图、排版。
当时完全没想到这些东西将来会和写代码有什么关系， 只是单纯觉得：好像能把一张照片、一个海报做得更好看一点，很有成就感。
后来进入技术岗位，开始做后端、做数据、做平台， 一路走来，我却越来越频繁地意识到：
这些宣传时期练出来的审美和画面感， 其实在软件设计里，到处都派得上用场。
- 设计一个配置页面或管理后台时， 会本能地去想视觉重心在哪、信息有没有拥挤在一块；
- 写一个监控大盘、调度流程图， 会下意识地把真正重要的东西放在视觉路径最顺的地方；
- 就连给内部写文档、PPT 的时候， 也会多想一步：读到这里的人，到底会先看到什么、会不会直接关掉页面。
这些都不算什么专业设计，只是大学那几年顺手学的摄影和 PS， 在很长一段时间里潜伏着，最后在完全意想不到的地方帮了忙。
所以，当我现在回头看那段和专业技术看起来没什么关系的经历时， 反而会觉得：
它们是让我在技术世界里，保留了一点别的感官的东西。
而这类东西，其实远不止审美一种。
比如最直接、也最容易被忽略的几类：
- 美术与审美：
- 去学一点素描、色彩、构图，哪怕只是跟着网课画几幅速写；
- 拿起相机，认真拍一组"同一个场景的不同构图"，再比较哪张更有感觉。
- 经济学与社会学视角：
- 为什么这个功能一定要做，而另外一个看起来很酷的功能迟迟不上线？
- 读几本通俗的经济学入门书，搞清楚价格、成本、激励背后的逻辑；
- 文学、历史、心理学：
- 读一点小说、传记、历史书，试着理解不同时代、不同行业的人是怎么做选择的；
- 看看人是怎么被说服、怎么犹豫、怎么后悔、怎么坚持的。
- 跨行业交流：
- 多跟不同行业的朋友聊聊，了解他们目前面临的发展和困难；
- 这既是拓宽视野的方式，也可能为自己的职业发展多开一条路。
这些东西，看上去离写代码很远，甚至很业余。 但一段时间之后你会发现，它们悄悄改变的是：
- 你看世界的角度：不再只是 API、架构、性能，而是这里面有哪些人，各自在意什么；
- 你理解问题的维度：不仅是这能不能实现，还包括"这样做，别人会怎么感受、怎么行动"；
- 你和别人的连接方式：从聊技术扩展到聊经历、聊选择、聊普通人的生活。
某种意义上，这些非技术的东西，会让你变得更像一个完整的人， 而不是只在特定场景里被调用的"技术函数"。
当 AI 越来越擅长处理清晰、可形式化的问题时， 那些依赖长期体验和多维观察才能形成的判断，就越难被替代。
- 你拍过无数张废片之后，对什么是好画面会有自己的感觉；
- 你在经济周期起落里工作过几年，对风险和安全感会有自己的理解；
- 你和完全不同行业的人真诚聊过天，对什么是好生活不会只剩下 KPI 和薪资曲线。
这些东西，很难靠一两篇文章学会，也很难被 AI 在几次对话里直接传输给你。 它们更像是：
在漫长时间里，通过一次次尝试、失败和体验，慢慢长出来的一种厚度。
而写代码，也会在这个过程中悄悄发生变化：
- 你不再只是为了完成任务写代码，而是为了支撑某种你认同的体验、故事或改变；
- 你对好产品，好系统的定义，会带上一层自己的标准，而不仅仅是延迟多少、QPS 多高。
从这个角度看，当 AI 把很多纯技术环节变得更轻松之后，给自己留一点空间，去认真体验技术栈之外的世界，本身就是一种很重要的投资。
六、写在最后：AI 不会替代你，但会放大你是谁
Werner 的演讲，听完之后我反复想了好几天。
如果用一句话来概括他对AI 和工程师的看法，大概是：
AI 不会一夜之间把工程师替代掉， 但它会非常快速地，放大你原本是什么样的工程师。
- 如果一个工程师，只把自己定义成写代码的人，当写代码变得不再稀缺，自然会觉得自己被挤压到了角落。
- 如果一个工程师，把自己看作对系统结果负责的人， 那么 AI 只会成为你手里的一件强力新工具。
在这个写代码越来越不稀缺的时代， 最值得怕的，其实不是 AI， 而是我们习惯了用一套旧的标准，来衡量自己的价值。
工具会不断变化，抽象层会不断上移。真正不变的，是那群仍然愿意：
的工程师。
这，才是 AI 时代，程序员最难被替代的部分。
写完这篇文章，说实话，我自己也没有完全想明白。
很多问题，我也还在摸索：比如怎么平衡用 AI 提效和保持自己的手感，比如未来到底该往哪个方向深耕。但至少写完之后，比之前清晰了一点点。
如果你也在想这些问题，希望这篇文章能给你一点参考。
本文转载自公众号【数据漫谈人生】，感谢原作者分享；如涉及版权问题请联系删除。
