夜雨聆风我最近在想一个问题：当一个 AI 能在三秒内写出你花了一下午才调通的代码时，你作为一个工程师，靠什么吃饭？
这个话题我犹豫了很久要不要写，因为一写就容易变成贩卖焦虑。但我跟自己说，如果聊不透、聊不出具体的东西，就不写。今天我觉得差不多想清楚了。
先讲一个行业里已经发生的变化。
过去你做技术，核心竞争力是“会不会写”。你会 Spring Boot，他不会，你厉害。你能手写一个 RPC 框架，别人只能调包，你牛。这些东西构成了一个工程师的市场价。
但现在这个逻辑在快速瓦解。你花十年练出来的编码能力，AI 可能三年就追平了。GPT-5.5 写出来的系统设计文档，深度和广度已经逼近高级工程师的水准。Claude Opus 4.8 在复杂重构任务上的表现，说实话，比很多五年经验的工程师还稳。
我说这些是有切身体验的。我现在写代码，八成是让 AI agent 去写的。我坐在旁边，看它一行一行往外吐，偶尔喊停，大部分时候让它跑完。你说我还会不会写？会。但速度已经被它拉开了数量级的差距。
以前做一个中等复杂度的功能，我要花三天。现在同样的功能，AI 二十分钟出初版，我再花半天审查和修正。三天变半天。这个效率差摆在这里，你没法假装看不见。
于是问题来了：如果“会不会写”不再是壁垒，那壁垒是什么？
我琢磨了很久，结论是两个字：上下文。
什么是上下文？你对接的这个业务，它的历史脉络、它的关键用户、它的核心约束、它踩过的坑、它为什么是今天这个样子——这些东西，AI 短期内补不了。
它可以把 GitHub 上所有开源代码都学一遍，可以看懂任何技术文档，可以用最优雅的设计模式组织代码。但它不知道你经手的那个支付系统为什么在流量高峰期有一个诡异的超时，不知道那一次挂掉之后运营打了多少通电话安抚客户，不知道你们后来加的那三条校验规则，每一条背后都有一个赔付的故事。
这些信息不在互联网上。在你的大脑里。
这就是上下文掌握度。
以前衡量一个工程师值多少钱，主要看技能稀缺性。你会 JVM 调优，并发编程这些高难度的技术，市场上没几个人会，你就贵。你会分布式事务，能徒手画时序图，你就值这个价。你懂内核、懂网络协议栈、懂编译原理，每多一项技能就多一份议价权。
AI 来了之后，技能稀缺性的权重在往下走。因为它把很多技能的学习成本打到了近乎为零。一个刚毕业的学生，用 AI 辅助，写出来的接口质量跟一个五年经验的工程师相比，差距在快速缩小。
但上下文掌握度的权重在往上走，而且是越走越高。因为 AI 没办法替你去开业务评审会，没办法替你记住三年前那个技术选型背后为什么放弃了某个方案，没办法替你感知到业务方说“这个需求不急”的时候表情里的犹豫。AI 需要你的判断力去执行。
这些只有你能捕捉到。
换句话说，你的不可替代性，正在从“我会写别人不会写的代码”转向“我知道该写什么、为什么写、写了之后会影响到谁”。
这和另一个趋势有关：往业务上游走。
我观察到一个行业现象，过去过细的分工，导致同一个需求，经过两层中间人传达之后，往往已经变味了。产品经理理解客户的诉求，转述给技术 leader，技术 leader 再拆解给一线开发——每一层都在做信息压缩和重新解释。
压缩的过程中一定会丢失细节。而且丢失有一个规律：核心流程丢不掉，因为文档上写着。丢掉的都是“边缘情况”——用户在某个特定条件下的操作习惯、某个历史遗留接口的特殊返回值、某个第三方服务的限流规则。
偏偏这些东西，是最容易导致线上 bug 的。
核心流程不出事，出事的永远是那个“我以为不会有人这样操作”的边缘场景。
我自己尝试过一个做法：能直接跟业务方聊的，就不通过中间层传话。效果立竿见影。以前通过中间层拿需求，做出来八成要返工，因为中间丢失的信息在提测的时候才暴露。直接聊过之后，返工率降到了两成以下。
中间层有价值，这个我不否认。但信息每多传一层，损耗就多一层。你能跳过几层，你交付的准确度就高几层。
而且 AI 加速了这个趋势。以前你写代码慢，没时间去聊业务，时间全耗在实现上了。现在 AI 帮你把写的环节压缩了，凭空多出来几个小时。
这几个小时最该花在哪？花在理解需求本身上。去问业务方到底要什么、为什么现在要、上线之后谁第一个用。
说到这里，有人可能会担心一个问题：既然 AI 都能写代码了，技术深度是不是不重要了？反正看不懂也能用。
这种想法极其危险。我必须把话说清楚：技术深度的底线提高了。以前你只需要会写，现在你需要会写、会审、会改——而且要能承担责任。AI 写的代码，出了问题锅是你的，锅甩不到 AI 头上。AI 无法帮你背锅。
行业里有不少这样的例子：AI 生成的代码直接推到生产环境，功能确实跑通了，但仔细一看，循环里嵌套了三次数据库查询，每次全表扫描。流量上来就是一颗定时炸弹。
而且这种事比你想象的更常见。AI 写代码有一个特点：它追求“正确”，但不追求“好”。
这些问题，只有你对整个系统的技术深度足够，才能看出来。
这跟十年前外包代码的问题一模一样。你把活交给别人写，自己看不懂，上线之后出了问题你连从哪里查都不知道。你以为在提效，实际是在积累技术债。区别在于，以前外包至少对面是个人，你还能找到人问责。现在对面是 AI，你连问责都无处可去。
而且技术债这东西有一个特性：它不会立刻爆发。它会在系统里安静地躺三个月、半年，然后在你最忙的那个周五下午给你一个惊喜。外包代码的技术债你还知道大概埋在哪个模块，AI 代码的技术债是均匀散布的，你根本不知道哪一行埋着雷。
所以结论很明确：AI 用得越深，对你技术底子的要求越高。使用它的前提，就是你有足够的技术判断力去驾驭它。你还得知道怎么去跟它描述你要实现的任务是什么。以及怎么去实现。所有的前提都是你对所有的东西都了解，你能掌控全局。
这件事想清楚之后，我对自己的人才模型也有了更新。
早些年行业里流行一个说法叫 T 型人才，一竖是技术深度，一横是知识广度。这个模型放在十年前没问题，但现在需要升级。
我更愿意叫它梯形。两根竖线。一根仍然是技术深度，但含义变了——以前拼的是“我能手写多复杂的算法”，现在拼的是“我能看懂、能审查、能修正 AI 写的代码，能判断方案对不对”。
另一根竖线是业务深度——我理解这个业务为什么存在、它服务谁、它的核心指标是什么、当前最大的瓶颈在哪。
两根竖线撑起上面那根横线：端到端的交付广度，从需求到上线到运维全链条能 hold 住。
没有技术深度这根竖线，你就是一个只会催 AI 的“传送带”，出事故的时候跑得比谁都快。没有业务深度这根竖线，你就只是执行器，永远在接任务、完成任务、再接任务，但永远不知道为什么要做这些事。
两根竖线缺一根，梯形就塌了。
而且我发现这个模型还有一个隐含的好处：它让你在团队里有了不可替代的角色定位。
一个人技术深度很强但不懂业务，他就是“那个写代码很快的人”。AI 来了之后，这个定位的护城河在变浅——因为 AI 也写得很快。
一个人业务深度很强但技术深度不够，他就是“那个很懂需求的人”。但他说出来的方案能不能落地，他自己没法判断，他没有执行力，还得靠别人把关。两根竖线都有的人，是“能判断做什么，也能判断怎么做”的人。这种人在任何团队里都是稀缺的。AI 再强，也取代不了这种复合判断力。
顺着这个思路再往下推一层，你会碰到一个更难的问题：怎么衡量自己的价值？
工程领域有一个趋势，越标准化、越可预测的工作，可验证结果的事情，越容易被自动化吃掉。写 CRUD 接口是最典型的——调参、拼 SQL、写模板代码，这些事 AI 已经比人快了。
但有一些东西很难标准化：判断、权衡、取舍、沟通。
举一个真实的例子。我在一个项目里遇到两个技术方案的选择：方案 A 实现快但后期扩展成本高，方案 B 实现慢但架构更干净。AI 能给两个方案都写出完整的代码，但它没办法替你做决策。
因为它不知道这个项目三个月后会有多少新需求叠上来。不知道团队里谁负责长期维护这块。不知道老板对首版交付时间的真实底线是两周还是两个月。
这些东西就是工程师的“非标”价值。它们很难写进 OKR，很难量化，但恰恰构成了不可替代性。
当你发现自己的工作内容里，可预测的、能写进 checklist 的部分越来越少，需要你根据自己的经验做判断的部分越来越多，恭喜你，你走对路了。
而且“非标”价值还有一个特征：它不能通过短期培训获得。
你能通过三个月的培训班学会 Spring Boot，但你没可能在三个月里学会判断“这个需求该不该现在做”。因为判断力来自踩过足够多的坑、见过足够多的失败案例、对不同选择的结果有肌肉记忆级别的感知。
AI 可以让你少踩一些技术坑，但业务判断的坑，你还得自己踩。有些东西只有被真实用户骂过一次，你才能记住。
但判断力的来源还有一个维度：商业嗅觉。这个维度被很多工程师忽略了。
我问过自己一个问题：如果你有很好的技术判断力，知道什么该做什么不该做，但你的判断方向是别人给你的，你算不算真正掌握了主动权？
答案是不算。因为判断力分两个层面：在别人给定的命题里做得好，是你做出了正确的事。自己能发现命题、定义命题，是你找到了该做的事。前者是驾驶技术，后者是导航能力。两个都重要，但第二个更稀缺。
现在这个时间点，对工程师来说是做产品最好的时代。AI 把做原型的成本压到了不可思议的地步——以前三个月才能搭出来的东西，现在三天就能出一个可演示的原型。这不是夸张，我自己日常就是这么干的。一个完整的管理后台，数据库结构建好、前后端通路跑通、基础 UI 搭完，AI 一上午搞定。
代码量级上的差距是指数级的碾压。
成本被压到这个程度之后，有一件事的逻辑彻底变了：试错不再是奢侈品。你不需要先写需求文档、再做排期、再组织团队、再开发六个月。你现在可以有一个想法，花三天出原型，直接丢到潜在用户面前——看他们到底感不感兴趣。
用户用不用，是唯一的答案。用户的眼睛比任何产品评审都诚实。
我以前也有过“我一个工程师掺和产品的事干什么”的想法。后来想明白了：这个时代最容易抓住机会的人，恰恰是工程师。因为你手里有 AI 这把刀，从想法到原型的速度，比产品经理画原型图还要快。
你比别人快这一步，你就多一次试错机会。多试十次，你就比别人多找到十个方向——其中只要有一个方向是对的，就已经值了。
商业嗅觉是什么？不是读了很多商业书籍，不是能分析市场趋势。商业嗅觉很简单——你坐在那里，能不能凭空想到一个场景：某些人正在被某个问题困扰，而你有能力用技术把它解决掉。哪怕这个场景很小，哪怕只解决了十个人的问题。
这种嗅觉加上技术能力，再加上 AI 的执行力，三件事搅在一起的时候，工程师就跳出了“接需求”这个角色。你不再等别人定义你要做什么，你开始定义产品本身。
这跟前面聊的东西是一脉相承的。你了解业务、有判断力——这些是你的底子。底子有了，加上商业嗅觉，你就成了“能发现该做什么需求的人”——远远超越了“能把需求做对”这个层次。
说到底，最好的武器是你自己——你知道自己该打哪。AI 只是帮你开枪的那把枪。
最后我还想聊一个常见的误解。
很多人觉得，离业务近的工作价值高，离业务远的就容易被替代。做 CRUD 接口的“离业务近”，做基础设施、中间件、运维的“离业务远”。
我不同意。这个二分法本身就有问题。
行业里那些把 K8s 集群玩明白的工程师，稀缺到什么程度？大厂开很高的薪资都抢不到。表面上看，这离业务十万八千里——他们不知道用户怎么用 App，不知道产品经理在推什么功能。
但他们知道集群什么时候扩容、能承受多大的突发流量、缩容策略怎么定才不会影响在线服务。这些判断背后全是对业务的理解：规模预期、容错要求、成本约束。
他们离业务非常近，只是他们的“业务”聚焦在系统可靠性和成本上，而 App 上的那个按钮“业务”聚焦在用户体验和转化率上。两者的“业务”不同，但“带着业务判断做技术”这个本质是一样的。
反过来，你写一个 CRUD 接口，如果你不知道谁调用这个接口、什么场景、量级多少、失败了会怎样——那你是离业务最远的工程师。
你写出来的东西跟 AI 写的没有本质区别，因为你们都只拿到了需求文档里的那几行字。文档上写的参数校验，你做了。文档上没写的边界情况，你也没问。等到上线之后发现有漏网之鱼，你只能说“需求文档上没写”。
这句话 AI 也能说。它就值这个价。
所以没有“离业务远近”的工种区分，只有“有没有带着业务判断”。你做任何技术工作，只要你在做的时候脑子里装着“谁会受影响、规模多大、失败代价是什么”这三个问题，你就是离业务最近的工程师。
这篇文章聊了七个点：往业务上游走、上下文掌握度是护城河、技术深度是使用 AI 的前提、梯形人才模型、做难以量化的事、带着业务判断做技术。
它们看起来是六个独立的观点，但底层是同一件事：AI 来了之后，工程师的价值锚点从“能做什么”变成了“知道为什么做、做到什么程度、做错了怎么办”。
前者是能力，后者是判断力。能力可以被拉平，判断力不能。能力让 AI 去跑，判断力只能靠你自己长出来。
所以别慌。AI 写得再快，也得有人告诉它写什么。那个人就是你。
《订阅官方的 Claude 和 Codex，我每个月比别人省一半》
《媒体说 AI 无所不能，但现实的 AI 智能体连代码都读不完》
有 AI 工作流定制或技术咨询需求，公众号后台私信我。
