2026，我开始重新审视程序员这份工作

有时候回头想想，我学编程的那个年代和现在已经完全不一样了。

大学的时候我是真的很喜欢折腾技术。和同学一起打竞赛、找实习、做项目，研究各种新东西，总觉得每天都有学不完的东西。今天研究 Java，明天搞数据库，后天开始折腾 Linux。项目里突然需要一个自己完全没接触过的东西，就从头开始查资料、看教程，很多东西都是一点一点磕出来的。

我到现在还记得大一暑假看的那本《疯狂 Java 讲义》，八百多页，厚厚的一本。那时候是真的抱着它一页一页往后啃，后来整本书都被翻得不像样了，有些地方折过，有些地方画得到处都是，碰到没理解的内容就重新往前翻。

那时候学编程的方式和现在也很不一样。书里配套的视频教程、示例源码，很多都放在随书附带的光盘里。拿到书之后，还得先把光盘里的视频和源码拷到电脑上，一边看书，一边对着视频和示例代码自己敲。现在回头看，“从光盘里拷源码”这件事已经很有年代感了，但当时觉得再正常不过。

遇到书里讲不明白的地方，就只能继续自己找资料。去 B 站搜视频，去 CSDN 翻博客，去各种论坛看看有没有人遇到过类似的问题。运气好第一页就能找到答案，运气不好搜出来十篇文章八篇互相转载，剩下两篇还是几年前的版本，照着改完发现还是报错，那就继续搜。

那时候当然没有 ChatGPT，更没有今天这些 Coding Agent。学习一项新技术，很多时候就是从一本书、几个视频、一份 Demo 开始，自己搭环境，自己敲代码，报错了自己查，再一点一点把整个东西弄明白。

一个 Bug 卡一整个下午，在当时再正常不过。有时候下午没解决，晚上回宿舍脑子里还在想到底哪里出了问题，第二天突然想到一种可能，打开电脑试一下，跑通了，那一天心情都会很好。

现在回头看，这种学习方式确实有点“笨”，但很多东西，也就是这么一点一点磕出来的。

那时候，写代码真的像打游戏一样

我一直觉得，喜欢写代码的人多少能理解这种感觉。

有些人可以坐在电脑前打几个小时游戏，研究装备、研究打法、研究怎么过 Boss，一抬头发现已经凌晨了。我写代码有时候也是这种状态，一个问题没解决之前会一直想：为什么这里不对，是不是某个边界条件没处理，这个结构还能不能更简单，有没有更好的实现？然后不断修改、运行、失败、再修改。

真正沉浸进去之后，几个小时很快就过去了。尤其是一个原本完全不懂的东西，被自己一点一点弄明白，最后真的跑起来，那种感觉和游戏里终于打过一个很难的 Boss 没什么区别。

所以后来我也越来越喜欢研究底层。一个东西会用了，还想知道为什么能用，框架里面到底做了什么，这个机制为什么这样设计，源码是怎么实现的。甚至明明已经有成熟方案了，有时候还是忍不住想，这个东西好像也不复杂，要不自己写一个？

现在回头看，很多轮子其实根本没必要造，从投入产出来看甚至有点浪费时间。但那时候不会这么想，因为本身就觉得有意思。热爱这种东西，本来就没法完全按照投入产出来计算。

后来工作了，我反而开始给自己划技术边界

大学的时候，其实没有那么明确的前端、后端边界。那时候做自己的项目，基本上什么都得自己来。后端接口自己写，数据库自己设计，前端页面自己做，也会研究前端工程化，项目完成之后再折腾服务器、部署、域名这些东西。

我很喜欢这种从头做到尾的感觉。一个想法最开始可能只是脑子里的一个念头，慢慢把数据库设计出来，把接口写出来，把页面做出来，再部署到服务器上。最后输入域名，看到自己写的东西真正跑在互联网上，而且其他人也可以访问，那种成就感和单独完成一个功能其实完全不一样。

很多技术也是在这个过程中学会的。并不是先决定“我要学前端”“我要学 Linux”，而是项目做到这里需要什么，就去研究什么。页面需要做得更完整，就研究前端；项目需要上线，就去折腾 Linux、Nginx、数据库和部署；遇到性能或者稳定性问题，再继续往下找原因。那时候不会特别在意某项技术到底属于哪个岗位，只关心怎么把自己的项目真正做出来。

后来进入职场之后，情况开始发生变化。

公司的研发体系有了更明确的岗位分工，前端、后端、测试、运维、算法都有各自的职责。当时整个行业对于程序员成长的主流认知，也更强调在一个方向上持续深耕。一个人的精力毕竟有限，与其每个方向都懂一些，不如选择一个方向不断往深处走，逐渐形成自己的专业能力。

所以后来我选择了后端。

从 Java、Spring，到数据库、Redis、消息队列、微服务，再到性能、安全和架构，技术栈越走越深，关注的东西也越来越集中。以前做自己的项目时，我想的是“这个东西怎么完整做出来”，工作之后慢慢变成了“这个后端问题怎么解决得更好”。

很长一段时间里，我对程序员成长路径的理解其实很简单：技术不够，就继续往深处走。框架会用了就去理解原理，原理知道了就去看源码，业务开发熟练了就研究中间件、分布式和架构。似乎只要一直往下钻，技术足够深，自然就会形成自己的护城河。

我以前确实很相信这件事，因为在那个时代，技术能力真的需要时间积累，很多东西不是看两篇文章就能掌握的。一个工程师能快速判断线上问题、设计出相对合理的系统、知道某个技术方案后面有什么坑，背后往往是几年甚至更长时间一点点磨出来的。

所以我们这些做技术的人多少会有一点属于自己的骄傲：我懂这个，这个问题我能解决，这个系统我能搭起来，别人搞不定的 Bug 我可以继续往下查。这种能力带来了很强的职业认同，直到 AI 开始真正进入开发工作。

2025 年，我第一次在身边看到岗位真的发生变化

2024 年的时候，AI 更多还是一个辅助工具。不会的问一下，报错了贴进去分析一下，写重复代码时让它帮忙生成，程序员仍然是绝对的主角。

但到了 2025 年，事情开始不一样了。AI 写前端的能力进步得太快，一张设计稿、一张截图，甚至只需要描述一下想要什么样的页面，它就能直接生成一个完成度相当高的版本。我们组最后一个主要做切图工作的前端后来也离开了，而这个岗位没有再按照原来的方式补回来。

这件事对我的冲击，比在网上看十篇“AI 将取代程序员”的文章都更直接。AI 不一定会突然把一个完整职业消灭掉，它更可能先一层一层吃掉一个职业里最标准化、最容易描述、最容易验收的工作。今天是切图，接下来可能是 CRUD、基础测试、简单数据处理、常规接口和模板化代码。

到了现在，这种变化已经真切地发生在自己身上。以前一个 Bug 能卡一下午，现在告诉 AI“帮我分析这个异常，结合当前项目找到根因并修复”，它自己读日志、搜代码、分析调用链、改文件、跑测试，最后告诉我已经处理完成。

以前学习一个完全陌生的技术，要先找教程、学语法、搭环境、照着 Demo 跑，再慢慢尝试真正的项目。现在更多时候是先让 AI 把第一版跑起来，再从真实代码里反向理解。以前一个想法冒出来，第一反应可能是“这个至少得搞几个周末，算了”，现在会变成“要不先让 AI 跑一下看看”，几个小时之后可能已经有了一个能用的雏形。

这当然很爽，但也带来了一种以前没有过的感觉。

我们曾经引以为傲的技术，突然没有那么稀缺了

这可能才是 AI 真正让我产生触动的地方。我们这些曾经以技术为荣的人，原来的护城河正在被重新定义。

以前技术是有明显门槛的。想成为一个能独立干活的程序员需要很长时间，你知道别人不知道的东西，你能解决别人解决不了的问题，你能把别人做不出来的东西实现出来。这些能力需要大量时间获得，所以自然显得珍贵。

但 AI 出现之后，这层壁垒突然被撞开了一道口子。以前一个完全不会前端的人想做一个像样的页面，需要先学 HTML、CSS、JavaScript，再学框架，现在他可以直接告诉 AI“按照这个设计做一个页面”。一个不熟悉 Python 的后端，以前可能因为学习成本直接放弃某个想法，现在可以让 AI 先完成大部分实现，再去理解其中关键的部分。

很多事情以前的问题是“你会不会”，现在越来越变成“你到底想做什么”。当技术获取和实现的成本迅速下降之后，掌握某一种技术本身，确实没有以前那么稀缺了。

但我慢慢觉得，技术当然没有失去价值。真正发生变化的是，技术依然是底座，但技术本身不再天然等于护城河。以前这两个概念很容易被我们混在一起，AI 只是把它们强行拆开了。

以前那些时间，并没有白花

现在我依然认为底层知识非常重要。数据库、网络、操作系统、并发、缓存、中间件、分布式系统，这些东西不会因为 AI 会写代码就突然失去价值，只是我对“为什么要学习底层”的理解发生了变化。

以前多少有一点实现情结，一个东西学会了最好自己实现一次，看到一个组件会想它内部到底怎么写。现在我没有以前那么执着了。我需要理解数据库索引为什么有效，但没必要为了证明自己懂再实现一遍 B+ 树；我需要理解线程池为什么可能把系统拖垮，但不意味着必须自己造一个线程池；我需要知道消息为什么可能重复消费、缓存为什么会击穿、事务为什么会失效。

因为这些知识现在承担了一个更重要的作用：让我有能力判断 AI 到底写得对不对。

AI 可以一分钟生成几十个文件，同样也可以一分钟制造几十个文件的技术债。如果完全不懂基础，很容易从“使用 AI”变成“相信 AI”，这两件事完全不同。

真正留下来的，不只是某个 API、某个框架或者某种写法，而是这么多年慢慢形成的判断力。看到一个系统，大概知道哪里容易出问题；线上出现异常，知道应该先从什么方向排查；看到一个技术方案，知道哪里值得怀疑；面对陌生问题，不会因为没有现成答案就完全不知道从哪里开始。这些东西才是以前那些“笨功夫”真正留下来的。

人人都能写代码，不代表人人都能做好软件

AI 把写代码的门槛降下来之后，很容易产生另一种错觉：既然一个完全不会编程的人，现在也能通过几轮对话做出一个能运行的项目，那程序员是不是也没那么重要了？

前段时间团队里就遇到过一个很典型的情况。业务部的同事借助 AI 做出了一个完整的小项目，从页面、后端到数据库都能正常运行，但在部署上线的时候，因为缺少对运行环境、安全边界和部署方式的理解，很快就出现了敏感配置暴露等问题。

项目“能跑”没有问题，但从“能跑”到“能上线”，中间其实还隔着软件工程。

一个真正进入生产环境的系统，要考虑的远不只是功能有没有实现。安全、性能、稳定性、监控、异常处理、数据一致性、部署方式、故障恢复，这些东西很多时候根本不会写在需求里，却决定了一个系统能不能真正承担业务。

所以我并不觉得“人人都能借助 AI 写代码”等于“人人都可以取代程序员”。AI 可以快速补齐实现能力，但不会自动补齐一个人踩过的坑、经历过的事故，以及多年项目实践形成的工程经验。

以前很多专业门槛体现在“这个东西你会不会写”，现在代码越来越容易获得之后，门槛开始往后移动：你知不知道一个东西除了能跑之外，还应该满足什么。

AI 省下来的时间，我开始投向更高层的问题

还有一个以前没太意识到的变化，就是 AI 把大量重复性的、低认知负担的工作接走之后，我的时间结构发生了明显变化。

以前一天的时间很容易被各种杂事填满，写 CRUD 接口、调样式、修简单 Bug、处理琐碎的运维问题。这些事情单独看都不复杂，但会持续切碎时间和注意力。等到忙完这些，脑子已经转不动了，根本没有精力去关注更高层的东西。

现在 AI 承担了相当一部分这样的工作，我就有更多时间去关注以前想关注但总是没空认真想的问题。比如系统架构层面，现在的方案能不能撑住未来的业务增长，哪些模块已经开始腐化，有没有更合理的拆分方式；比如产品层面，这个需求背后真正的业务诉求是什么，有没有更简单的解法，用户真正困扰的是什么；再比如团队层面，当前的开发流程哪里在拖后腿，技术债务的优先级应该怎么排。

以前这些问题不是不想管，是确实没有精力。每天都被下一行代码该怎么写追着跑，哪有空抬头看路。现在代码层面的事情不需要占据那么多时间了，终于可以把一部分精力从“怎么实现”抽出来，去思考“为什么做”和“做什么”。

所以我现在给自己定了一个原则：如果一件事 AI 能处理到七八十分，就尽量交给它，把自己的时间留给判断、权衡、取舍和方向。

两件事，让我开始重新理解“解决问题”

前阵子遇到一个和智能匹配有关的需求。原来的实现是前后端交互，前端负责渲染，后端调用算法团队提供的接口，具体的匹配逻辑都封装在算法那边。产品觉得匹配效果一般，希望提高准确率，但算法团队人力不足，改造成本又高，如果涉及模型训练，不仅有人力成本，训练本身也需要时间。

我刚接手的时候看了一眼，第一反应其实很传统：底层调用的是算法接口，那效果问题不就是算法的问题吗？服务端这边再怎么改，效果能好过算法直接优化？于是我把问题抛回去了。

后来产品实在等不了了，算法那边也确实抽不开身，我们重新坐下来聊了一次。既然算法短期没法改，那是不是可以换一条路？后来我们讨论出了一个方案，让大模型结合 MCP 去完成一部分匹配逻辑。当时谁也拿不准效果到底怎么样，但至少是一条可以尝试的路径。

最后实践下来，效果明显好于预期。

这件事让我意识到，如果一开始就盯着“服务端怎么改”“算法该不该改”这些职责边界，很可能折腾半天问题还是没解决。真正让事情往前走的，是先把“这事该谁干”放下，重新看看问题本身到底是什么，还有没有其他解法。

另一个变化发生在工作方式上。

以前被业务需求追着跑的时候，每天的状态基本就是接需求、写代码、修 Bug、上线，然后继续下一个需求。业务永远做不完，需求永远排不完，人很容易一直被钉在这种节奏里。那时候就算知道有些东西应该沉淀，也很难真正抽出时间去做，偶尔想整理一下团队规范、工具链或者最佳实践，新的业务一来，很快又被打断了。

现在因为 AI 接走了大量具体实现工作，我开始有余力去做以前一直觉得重要但总没时间做的事情。其中一个我越来越重视的方向，就是研究怎么让自己和团队更好地 Vibe Coding。

这里说的并不只是“学会怎么跟 AI 聊天”，而是把 AI 开发本身逐渐做成一种工程能力。比如团队有哪些编码规范、架构约定、安全要求，可以整理成 Skill；一个项目有哪些上下文、公共组件和约束，可以提前维护好，不需要每次重新告诉 AI；哪些重复性的开发模式可以沉淀成模板，哪些能力适合通过 MCP 提供，AI 写出来的代码应该怎么验证和评审，这些东西都值得持续维护。

以前很多经验只存在于人的脑子里，新人来了需要一点一点带，换一个项目又要重新熟悉。现在我越来越觉得，这些经验也应该整理成 AI 能理解和复用的资产，让 Coding Agent 一进入项目，就能够知道这个团队怎么写代码、这个系统有哪些边界、哪些地方不能随便改。

从这个角度看，维护 Skill、项目上下文、Prompt、Agent 规则这些事情，和以前做脚手架、公共组件、CI/CD 没有那么大区别。它们不一定直接完成某个业务需求，但能够影响之后一连串需求的开发效率和质量。

以前我理解的“提升效率”，更多是让自己代码写得更快一点。现在我更愿意去想，能不能让整个团队少做一些重复劳动，让 AI 少犯一些重复的错误，让一次积累能够在后面的项目里不断复用。

解决一个业务问题当然有价值，但如果能够进一步解决“以后怎么更高效地解决这一类业务问题”，杠杆会更大。

做开发这几年，我越来越觉得程序员没那么“高贵”

这几年还有一个挺明显的变化，就是对程序员这个职业慢慢祛魅了。

刚开始学编程的时候，很容易觉得程序员是一个挺特别的职业，掌握着很多别人看起来很神秘的东西。但做了这么多年之后，我越来越觉得其实没有那么神秘。程序员本质上就是一种技术工，只不过我们使用的工具是编程语言、数据库、框架和服务器。

AI 出现之后，这种感觉更明显了。

以前很多事情必须由程序员亲自完成，是因为只有程序员掌握这些工具。现在 AI 开始替人操作这些工具之后，“会不会亲手写出来”自然没那么重要了。

但这并不意味着程序员没有价值，只是价值不能再完全建立在代码本身。工作中的我，首先还是一个解决问题的技术人员，代码、架构、AI 都是可以使用的手段。

想明白这一点之后，我也开始把两件以前经常混在一起的事情分开：我喜欢写代码，和我的工作是程序员，并不是完全相同的一件事。

我还是喜欢写代码，遇到感兴趣的问题还是会研究源码、折腾技术，甚至为了一个好玩的东西写到很晚。但职业发展是另一回事，不能因为自己喜欢某种技术，就把所有问题都往这项技术上套，也不能因为一个东西写起来很爽，就忽略它到底有没有必要存在。

热爱让我愿意一直写代码，但职业要求我不能只会写代码。

技术栈的边界，又重新打开了

有时候想想还挺有意思的，我的技术路线好像绕了一圈。

大学的时候什么都写，从前端、后端一直做到部署上线；工作之后因为岗位分工和当时对职业发展的理解，我选择了后端，花了很多年不断往这个方向深入；现在 AI 出现之后，我反而又开始慢慢往全栈走了。

最近我也加入了团队的 AI 全栈小组，开始真正按照这种方式参与开发。一个需求拿过来，不再那么强调它到底属于前端、后端还是 AI，而是先把整个问题看完整，再决定应该怎么解决。

需要页面就做前端，需要数据处理就用 Python，需要接入大模型就研究 Agent、MCP 和工作流，需要快速验证一个想法，就借助 AI 先把完整链路跑起来。后端依然是我比较扎实的技术支点，但它已经不像以前那样决定我的工作边界了。

当然，我理解的 AI 全栈并不是什么都做到专家级，而是有自己足够扎实的技术支点，同时不再因为技术栈的边界提前放弃一种解法。熟悉的地方自己深入，不熟悉的地方借助 AI 快速进入，最后把不同的技术组合起来，把完整的问题解决掉。

所以现在我越来越不愿意用“Java 工程师”或者“后端工程师”这样的标签限制自己。Java 依然是我的技术基础，但它更像一个支点，而不是一道边界。

某种程度上，我好像又回到了大学时候做自己项目的状态：从一个想法开始，不太在意它属于哪个岗位，只想着怎么把它真正做出来。

只是这一次，手里的工具不一样了，自己的技术积累也不一样了。

到了 2026 年，我开始重新审视自己的发展

以前我的成长路径很简单：技术不够，就继续往深处学。

这条路当然没有错，但现在我不会再把全部成长时间都投入到某一个技术栈。除了继续保持技术深度，我开始有意识地补以前关注得比较少的东西：业务为什么要做这件事，用户真正的问题是什么，一个方案的成本和收益是否匹配，有没有更简单的解法。

这种变化也直接影响了我的工作方式。

以前拿到需求，很容易马上进入实现：表怎么设计、接口怎么定义、代码放在哪里。现在我会尽量让自己晚一点进入代码，先把问题、目标、边界和风险想清楚，再让 AI 开始工作。

另一方面，我也开始把更多精力投入 AI Coding 本身。不是单纯研究哪个模型写代码更快，而是研究怎么把 AI 真正融进研发流程。团队的编码规范、架构约定、安全要求能不能整理成 Skill，项目上下文能不能持续维护，重复性的开发模式能不能沉淀成模板，Agent 经常犯的错误能不能通过规则和工作流解决。

以前一次开发结束之后，留下来的主要是代码。现在我希望还能留下一些下一次可以继续复用的东西。

如果某个规范每个项目都要重新告诉 AI，那就把它沉淀下来；如果某类问题 Agent 总是犯错，那就想办法从流程上解决；如果一个人的经验能够整理成团队和 AI 都能复用的能力，那它产生的价值就不只属于这一次需求。

所以我现在理解的成长，已经不只是从 Java 工程师变成一个更资深的 Java 工程师。我更希望自己逐渐变成一个以技术为基础，能够理解业务和用户、跨过技术边界解决完整问题，同时也能够借助 AI 放大自己和团队能力的人。

写在最后

从大一暑假抱着一本八百多页的 Java 书一点一点往后啃，到今天一句话让 AI 读项目、改代码，其实也没过去特别久，但整个开发世界已经完全不一样了。

那些年花在技术上的时间并没有白费，只是它们留下来的东西和我以前理解的不太一样。我依然会继续研究技术、继续写代码，也依然会因为一个有意思的问题折腾很久，因为我确实喜欢这件事。

只是到了 2026 年，我不再那么执着于“我要成为一个多厉害的 Java 工程师”。

我更想知道自己能不能把一个复杂的问题真正解决掉，能不能借助 AI 做以前一个人做不了的事情，又能不能在解决之后留下一些东西，让自己和团队下一次做得更快、更好。

从大学时候什么都想自己做，到工作之后选择后端深耕，再到现在重新走向 AI 全栈，好像绕了一圈，但又不是回到了原点。

以前手里只有代码，现在多了 AI。

而我想做的，是把这两样东西都用好。