标题的日期，精确到月，是因为AI的变化实在太多，很多话不能说太满 😁
这两年，关于AI与程序员的讨论里，最热闹的一种说法，是“写代码这件事越来越不值钱了”。这话不能说全错，但它很容易把人带偏。
因为真正发生的变化，不是软件工程突然不重要了，而是恰恰相反：AI让“写代码”这件事变得更便宜了，但让“控制复杂度”这件事变得更贵了。
换句话说，AI时代真正的差距，不再是谁能多写几个函数、谁能多肝几个页面，而是谁能把系统拆得清楚、边界定得稳定、错误关在局部、扩展做得收敛。AI可以帮你写代码，但它并不能自动帮你成为架构师。很多时候，它甚至会反过来逼着一个程序员，逐步走向架构思维。
所以如果今天还把“资深工程师”的价值理解成“写代码更熟练的人”，那其实已经有点落后了。到了2026年，资深工程师更重要的角色，是成为那个能够驾驭AI、控制复杂度、约束系统演化方向的人。
一、AI时代，真正稀缺的不是编码速度，而是复杂度控制能力
很多人会误以为，AI最强的地方在于“写得快”。但我自己的体感是，AI带来的最大变化其实不是速度，而是开发流程被彻底改写了。
以前一个工程师拿到需求，往往是边查资料、边试方案、边写代码、边修补。这个流程虽然不优雅，但因为手是自己的，脑子也是自己的，所以即便中途绕路，整体还是收得回来。
但AI介入之后，情况变了。它写得太快了，快到如果你自己脑子里没有一个清晰的结构，没有一个明确的边界，没有一个稳定的实现路径，它就会以极高的效率，把混乱也一起放大。
所以问题就变成了：AI到底擅长什么？
我越来越倾向于这样概括：AI擅长在既定边界内施工，但不擅长替你定义长期稳定的边界。AI更擅长延续架构，而不是创造架构。
这背后的差异非常大。
如果一个系统本来就模块清晰、职责明确、接口稳定，那么AI接手写代码时，效果通常会很好。因为它知道这个模块该做什么、不该做什么；知道数据从哪里来、该往哪里去；知道修改一个地方，不应该顺手把别的层也一起改了。
但如果一个系统本来就是一团乱麻，没有明确边界，没有统一入口，没有稳定接口，AI并不会突然像天降神兵一样把它理顺。相反，它大概率会沿着现有的混乱继续往下写，而且因为它写得快，混乱扩散得也更快。
这就是为什么我越来越觉得，AI时代真正的分水岭不是“谁会写代码”，而是“谁能控制复杂度”。
说到底，软件工程并不是“功能做出来就结束了”。真正困难的部分，是功能越来越多之后，系统会不会失控：
- 改一个地方，会不会影响三个看似无关的地方。
- 新增一个功能，是不是必须同时修改五个模块。
- 出一个bug，能不能快速定位在一个明确边界内。
- 同样的能力，是不是出现了三套相似但彼此不兼容的实现。
- 一个AI生成的补丁，究竟是在填砖，还是在往项目里继续堆屎。
这些问题，表面上看不是“写代码”的问题，实际上恰恰是资深工程师最核心的价值所在。
二、为什么说“难测试的函数”，往往本身就设计得有问题
我觉得最能体现资深工程师功底的细节之一，就是对“可测试性”这件事的理解。
很多人刚接触测试的时候，会把它理解成一个发布前的验收动作：写几个单元测试，保证功能没坏，就差不多了。这个理解不能说错，但太浅。
因为更深的一层是：测试不仅仅是在验证代码，测试也在反向暴露设计质量。
最典型的一个现象就是：如果一个函数很难测试，那它大概率不是“测试不好写”，而是“这个函数本身设计得有问题”。
比如有这样一类函数，看起来只是在“处理订单”，实际上它在一个函数里同时做了这些事：
- 校验前端传来的参数。
- 查询数据库里的用户信息。
- 计算优惠券和价格。
- 调第三方支付接口。
- 写订单表。
- 发站内消息。
- 记录审计日志。
这种函数在AI时代特别常见，因为AI很喜欢把“从A到B能跑通”当作第一优先级。于是你让它实现一个下单流程，它很可能就给你写出一个又长又全、功能也确实能跑的“大一统函数”。
但问题马上就来了：你该怎么测试它？
如果你要测“优惠券计算是否正确”，却必须先mock数据库、mock支付接口、mock消息系统、mock日志系统，这就说明这里有明显的问题。因为你真正想验证的是“价格计算逻辑”，但整个函数把一堆副作用搅在了一起，导致一个本来应该很纯粹的业务规则，变成了一个极难隔离的测试对象。
这时候资深工程师看到的，不是“测试麻烦”，而是下面这些设计信号：
- 这个函数职责过多，不符合单一职责。
- 业务计算和外部副作用耦合过深。
- 输入输出不清晰，核心逻辑没有被提纯。
- 依赖没有被抽象成接口，导致替换困难。
- 边界没分好，应用层、领域层、基础设施层混在一起。
相反，一个更收敛的设计，通常会把这件事拆成几层：
- 参数校验单独处理。
- 价格计算抽成一个纯函数或明确的领域服务。
- 支付调用通过接口注入。
- 持久化通过仓储层统一处理。
- 消息通知和日志记录交给事件或后置流程。
这样一来，你要测试“价格计算逻辑”，只需要喂几个输入、比对几个输出即可；你要测试“下单流程是否串联正确”，再去做集成测试。也就是说，测试的颗粒度终于和设计的颗粒度对齐了。
这类细节非常重要，因为它反映的是一种更本质的能力：资深工程师并不是比别人更会写测试，而是更早意识到，测试成本本身就是设计成本的一面镜子。
同样的例子，其实还可以在很多地方看到：
- 一个React组件如果必须挂一堆全局状态、路由、网络请求和定时器才能测试，往往说明它承担了太多控制逻辑。
- 一个服务如果想测某个分支，必须先准备十几张表的数据，说明它的上下游依赖已经过重。
- 一个工具函数如果输入输出说不清楚，总要依赖当前时间、环境变量、全局配置，那它的行为就天然不稳定。
- 一个模块一改就牵一片，测试要跟着改一大片，说明系统里没有真正稳定的接口边界。
所以从这个角度看，测试不是AI时代的“补救工具”，它更像是系统设计是否收敛的一张体检表。
三、AI最大的风险，不是写错代码，而是把复杂度扩散得更快
很多人会说，现在都有自动化测试了，AI就算乱写一点也没关系，反正最后跑测试就好了。
我觉得这也是一个很容易误导人的想法。
因为测试当然重要，但测试不是万能保险丝。一个系统如果从结构上就是发散的，那么AI带来的问题，不一定表现为“测不过”，而很可能表现为：虽然都能测过，但维护成本越来越高，测试成本也越来越高，最终整个系统越来越笨重。
举一个非常具体的例子。
假设你要实现三个入口都能触发同一类业务能力，比如：
- 用户在Web端点击按钮可以生成报告。
- 用户在后台任务里定时生成报告。
- 管理员在运营后台也可以手动触发生成报告。
如果设计收敛，这三个入口最终都会汇聚到同一个核心服务里。也就是说，入口可以有多个，但核心逻辑只有一个统一收口点。这样你测试时，重点测这个核心能力就行。
但如果AI在没有明确约束的情况下，分别为这三个入口各写了一套“差不多但不完全一样”的实现，那么短期看功能也都做出来了，甚至测试你也都可以补上。但后续问题会越来越严重：
- 以后改一次报告生成规则，要改三处。
- 三个地方稍有不同步，就会出现“同样的功能在不同入口结果不一致”。
- 每新增一个边界条件，都得补三套测试。
- 未来排查bug时，很容易以为修了一处就结束，结果另两处还在悄悄出错。
这就是复杂度扩散。它不一定立刻炸，但它会不断吃掉未来。
所以资深工程师在AI时代要做的，不是简单告诉AI“帮我把这个功能做了”，而是先把收敛点设计好：
- 哪些能力必须统一入口。
- 哪些状态只能在单一来源里维护。
- 哪些错误必须用统一方式处理。
- 哪些扩展只能通过约定的接口进入。
- 哪些层不允许直接跨层调用。
你可以把这理解成“给AI划厕所”，这个比喻虽然不雅，但非常形象：不是不让它干活，而是必须让它在你规定的边界内干活。它可以施工，但不能满屋乱抹水泥。
四、资深工程师在2026年的第一任务，是先搭地基，再让AI施工
所以到了今天，我越来越觉得，资深工程师和AI协作，最合理的模式不是“我想到哪说到哪，AI写到哪算哪”，而是另一种顺序：
先设计，再实现；先定义边界，再分配施工；先确定验收方式，再让AI批量生成。
这看起来像一句废话，但实际上和很多人的真实做法完全相反。
很多人现在用AI开发项目，还是停留在“探索-实现-修补”的旧路径里。遇到一个需求，就赶快让AI先写；写崩了再补提示词；补不回来再继续重写。整个过程看似很忙，实际上人被AI拖着走，项目也会逐步变成一个越来越难收拾的试验场。
而资深工程师更应该做的是：
- 先把模块划分想清楚。
- 先把目录结构和依赖方向定下来。
- 先把核心数据流和状态边界确定下来。
- 先把哪些是核心模块、哪些是非核心模块分层。
- 先把接口和验收标准写清楚。
然后再把相对机械、边界明确、容易验证的部分交给AI去铺。
比如：
- 管理后台的CRUD页面。
- 表单校验与展示组件。
- 一些明确输入输出的数据转换。
- 围绕既有接口生成的调用代码。
- 已经确定模式下的重复性样板代码。
但像下面这些事情，就不能指望AI自己悟出来：
- 一个系统的收敛点应该在哪里。
- 哪些抽象应该提炼，哪些提炼反而是过度设计。
- 哪些接口未来变化频率高，需要先做隔离。
- 哪些模块一旦出错，影响面会非常大，需要人为兜底。
- 一个项目到底该继续补，还是应该局部推倒重来。
这些东西，才是资深工程师的壁垒。
五、第二个变化：最佳实践会比以前更重要，因为AI会放大团队的工程习惯
AI时代还有一个很容易被低估的变化：以前一个团队工程习惯差一点，最多只是人写代码写得乱一点；现在如果工程习惯差，AI会把这种坏习惯大规模复制出来。
所以最佳实践在今天不再只是“优雅”，而是直接关系到你能不能稳定放大产能。
这个时候，技术选型的意义也变了。以前很多人选型，更多是在比较性能、生态、招聘、个人熟悉度。现在还要多加一层：这个技术栈是否有利于AI持续接手，是否有利于工程收敛，是否能减少上下文切换和重复建设。
比如做全栈项目，为什么我会觉得Next.js这类方案在AI时代特别有现实意义？
不是因为它“热门”这么简单，而是因为它让很多原本分散的事情更一体：
- 页面、路由、服务端逻辑、接口可以放在同一套工程里。
- 前后端共享类型和模型会更自然。
- 同一个仓库里，AI更容易理解上下文。
- 部署链路和开发链路更统一，减少“前端一套、后端一套、接口文档又一套”的裂缝。
这并不是说所有项目都必须用Next.js，而是想说明：资深工程师在AI时代更需要理解“什么技术栈能让AI更稳定地参与协作”。
1. 桌面端项目：对大多数个人项目来说，没必要再走原生优先
这个问题我觉得很典型。
如果今天你是做一个个人项目，或者一个典型的AI辅助工具类项目，比如：
- 本地知识库整理工具。
- OCR文档处理器。
- 本地剪贴板增强工具。
- 小型图片标注工具。
- AI对话客户端。
这类项目很多人还会本能地想到：桌面软件是不是要重新走一套更重的桌面技术路线，比如直接上C++、C#，或者分别啃不同平台的原生GUI体系？
但对于绝大多数这类项目来说，真正更符合AI时代工程现实的选择，往往是Tauri或者Wails。
原因很简单：
- 你可以继续使用自己更熟悉的前端技术栈来做UI。
- 用Web技术写界面，AI生成速度通常更快，调整成本也更低。
- 原生层只保留必要的系统能力调用，不必从头把整套桌面GUI生态重新捡起来。
- 项目的前后端上下文更统一，AI不需要频繁在多套完全不同的开发范式之间切换。
尤其对个人项目来说，很多时候你的真正目标不是“写一款体现原生功底的桌面软件”，而是“尽快把一个能用的产品落地”。如果你的核心价值在业务逻辑、工作流设计、AI能力接入，而不在桌面渲染性能极限，那么一开始就走过重的原生路线，往往是在错误的地方消耗精力。
这背后体现的，其实正是资深工程师的判断：不是为了显示自己会更多技术，而是为了让项目以更低复杂度、更高迭代速度落地。
2. 手机端项目：很多场景下，不必一上来就做双原生
移动端同理。
现在很多项目，尤其是工具类、内容类、企业内部使用类、轻交互类App，如果还一上来就规划iOS + Android双原生，其实往往意味着：
- 两套技术栈。
- 两套工程体系。
- 两套构建与发布链路。
- 两套UI细节维护成本。
- AI也要跟着切换两套完全不同的上下文。
对于很多项目来说，这种复杂度未必值得。
如果它本质上是一个以Web能力为核心、需要快速触达移动端的产品，那么CapacitorJS这类方案就很有现实意义。它不是万能药，但对大量“先做出来、先验证场景、先快速迭代”的项目来说，非常合适。
比如：
- 一个企业内部审批工具。
- 一个内容订阅或知识库客户端。
- 一个连接现有Web后台的小型运营工具。
- 一个围绕AI能力做的轻应用。
- 一个先验证需求、后续再决定是否重做原生的MVP产品。
这时候，资深工程师真正该问的不是“什么最纯粹”，而是“什么最适合当前目标”。如果业务还没跑通，产品路径还没验证，团队规模也不大，那么优先选择更统一、更省切换成本、对AI更友好的方案，本身就是一种成熟。
换句话说，AI时代的最佳实践，很多时候不是“技术最重”，而是“工程上最收敛”。
六、第三个变化：技术人不能再只守着原来的专业边界，能力平移会越来越重要
如果说前面两点讲的是“如何在软件内部与AI协作”，那么第三点讲的是更大的变化：AI正在降低跨领域工作的门槛，所以技术人不能再只困在自己原来的专业标签里。
以前很多技术人员的成长，是在一个相对稳定的轨道里完成的。
比如一个人原来做后端，就一直做后端；原来做客户端，就一直做客户端；原来做Web，就继续在Web体系里深挖。能力当然会越来越深，但边界也往往越来越固定。
但AI出现之后，情况开始变化了。因为它虽然不能替你提供真正的系统判断，却可以显著降低你跨到相邻领域时的信息摩擦。你以前不会的东西，现在不一定立刻精通，但至少可以更快上手、更快做出原型、更快理解整体链路。
这就意味着，资深工程师未来更有价值的一种能力，不只是“在原领域里越钻越深”，而是“把原本已经积累的经验，迁移到新的问题域里”。
电子相框，就是一个很典型的例子
表面上看，电子相框好像只是一个很简单的小硬件：一个屏幕、一个外壳、一个播放照片的程序。但如果你真的把它当成产品来做，就会发现它其实是一个典型的软硬件结合场景。
一个只会写纯软件的人，以前可能会觉得这不是自己的领域；一个只懂硬件的人，又可能很难把它做成有完整体验的产品。但在AI时代，一个有软件工程经验的人，完全可以更自然地往这个方向平移。
比如你如果去做一个面向家庭场景的电子相框，真正要考虑的事情可能包括：
- 设备首次配网怎么做，老人能不能操作。
- 手机端或Web端怎么上传照片。
- 多个家庭成员如何共享一个相框。
- 后台如何管理相册、播放顺序、定时切换、远程推送。
- 设备断网、重启、存储异常时怎么兜底。
- 本地缓存和云端同步怎么配合。
- 屏幕常亮、自动休眠、定时唤醒这些状态如何管理。
你会发现，这里面当然有硬件因素，但大量关键问题其实仍然是软件工程问题：
- 状态管理怎么收敛。
- 设备端和服务端的接口怎么设计。
- 配网流程和账号体系怎么打通。
- 多端同步如何保证最终一致性。
- 故障恢复路径怎么设计得足够简单。
也就是说，一个原来做软件的资深工程师，如果借助AI去补足一些自己过去没深入过的领域知识，比如嵌入式交互、局域网通信、设备管理后台、移动端壳层接入，那么他完全可以切入这类以前不会轻易碰的项目。
而这种能力平移，本质上不是“会的更多”这么简单，而是“能把自己的工程判断带到新的真实场景里”。
这对未来非常重要。因为未来更有竞争力的人，不一定是单点技术最强的人，而很可能是那些能把软件能力和具体行业、具体设备、具体场景结合起来的人。
七、到了2026年，资深工程师更像“AI施工队的总包方”
如果要把上面的意思再概括得更直白一点，我会觉得，资深工程师和AI的关系，越来越像总包方和施工队的关系。
AI当然能干活，而且很多时候干得很快。但总包方的价值，从来不是亲自去拌每一车水泥，而是：
- 知道地基该怎么打。
- 知道哪些地方承重，不能乱改。
- 知道水电管线该怎么走，后续才不会返工。
- 知道哪些施工虽然快，但会留下长期隐患。
- 知道什么时候该让工人继续干，什么时候必须停下来返工。
放到软件工程里也是一样。
资深工程师未来最核心的能力，未必是自己一天能写多少行代码，而是：
- 能不能提前判断复杂度会从哪里扩散。
- 能不能把系统收敛到少数稳定边界上。
- 能不能根据项目目标做出务实而非炫技的技术选型。
- 能不能把AI纳入一个可控的开发流程，而不是让它反客为主。
- 能不能把已有的软件经验平移到更广阔的产品和行业场景里。
八、结语
很多人总喜欢把AI时代理解成一种“程序员是否会被替代”的二元问题。但在我看来，这个问题本身就有点偏。
真正值得关注的，不是谁会不会被完全替代，而是同样都在使用AI的前提下，工程师之间的价值差异会被重新拉开，而且拉开的方式和过去不一样了。
以前差距可能更多体现为谁写得更快、谁API更熟、谁框架经验更多；但往后，差距会越来越体现为谁更能控制复杂度、谁更会做系统收敛、谁更能选对路线、谁更能把AI放进一个受控的工程体系里。
所以到了2026年，资深工程师真正该追求的，不是把自己变成一个更高配的“码农”，而是把自己变成一个能够驾驭AI的系统设计者。
AI可以帮你写代码，但决定一个项目最终走向的，依然是那个能控制复杂度的人。