这半年裁员的消息没断过。一轮接一轮，名单里不乏工作五年十年、技术并不差的人。配合着另一条线的新闻，某某模型又能写代码了、又能做设计了、又能顶替某个岗位了，很多人心里那根弦是绷着的：下一个会不会轮到我。
绷着之后，常见的反应有两种。一种是不看不想，照旧干自己那摊活，心想 AI 还早呢；另一种是焦虑，可焦虑完也不知道该干嘛，到点了该怎么干还怎么干。这两种我都理解，但方向我觉得都不太对。
下面说说我的看法。
先主动让 AI 替代自己
我自己的做法，是把这个恐惧倒过来用。
你怕 AI 替代你，那不如自己先动手，主动让它替代你试试看。具体说，就是把你每天干的活摊开，挑出那些重复的、不太需要你独特判断的，一件件丢给 AI 去做。写周报、查日志、改格式、初版代码、整理资料，先让它做，你来挑错、来收尾。做着做着你会发现，自己其实已经在 AI 时代里面了，而不是站在外面观望。
这里有个区分值得说清楚。黄仁勋有句被引滥了的话，大意是你不会被 AI 取代，但会被一个用 AI 的人取代。顺着这句往下想，还有一层：一个职业从来不是单一任务，是一大堆任务粘在一起。就说一个程序员，写代码只是其中一块，他还要对需求、拆问题、跟人对齐、在一堆烂摊子里做判断、最后为结果负责。AI 现在能把这里头不少任务做得像模像样，但把这些任务接起来、在模糊的地方拍板、出了事担着，这个完整的职业，它还接不住。
所以主动让 AI 替代自己，替代掉的是那些任务，不是你这个人。省下来的时间和精力，正好投到 AI 接不住的地方去。绕一圈你会发现，最想被 AI 替代的那批人，反而最不容易被裁，因为他在这个过程里已经把自己练成了会用 AI 的人。真正悬的，是那些死活不让 AI 碰自己工作的人。
别死磕 Coding，重心前移或后移
具体到软件这行，转法可以再说细一点。
得承认，Coding 这个环节，是这波里最先被啃动的。代码补全、整段生成、改 bug、补测试，模型干得一天比一天顺。这意味着，我该深耕 Java 还是 Python、这个语法怎么写这类问题，价值在很快地贬。你在这上面继续投时间，回报率不如从前了。
把重心从 Coding 本身挪开，有两个方向，一前一后。
往前移，是往上游走。一个需求下来，系统怎么分层、模块边界怎么切、瓶颈会出在哪、几个方案各自要付什么代价，这些 AI 能给你出主意，但最后拍板靠的是你的视野和经验。把时间花在把架构想透、把技术方案做扎实上，这部分的价值不但没被 AI 稀释，反而因为下游变快了，显得更要紧。下游越便宜，上游的判断越值钱。
往后移，是往下游走，去当那个懂业务、能担责的人。AI 写的代码看着挺对，可它不知道你们这行的隐性规矩，不知道这个字段历史上踩过哪些坑，不知道这个边界条件放到你们业务里到底意味着什么。它写错了不担责、不背锅，背锅的是你。所以审 AI 的产出到底对不对，本身就是一份越来越重的活，前提是你得真懂业务，懂到能一眼看出它哪里想当然了。
这两个方向看着相反，内核其实是一个：你的价值从会写，挪到会判断。
AI 是放大器，专业的事交给专业的人
还有个担心常被提起：有了 AI，是不是大家就被拉平了？人人都能让 AI 写代码、做方案，那专业还值钱吗。
我的看法正相反。AI 更像个放大器，它放大的是你本来就有的东西。
拿我自己熟的性能优化来说。这些年踩过的坑、知道哪些指标真正该看、知道瓶颈一般藏在什么地方，这些经验我能直接喂给 AI，让它顺着我的判断去干，做出来的工具、给出来的方案，是带着我的经验的。换一个不懂性能优化的人，让同一个 AI 做同一件事，他问不出对的问题，AI 给的方案哪里不对他也看不出来。同样一个模型，在懂行的人手里和不懂的人手里，产出差一大截。
所以专业不是被 AI 抹平了，是被 AI 放大了。你越懂，它帮你放得越大；你不太懂，它放大的可能是你的错。这也正是前面说要往技术深度走的原因：深度是这台放大器的输入，输入越厚，放大出来的东西越值钱。
这个放大器的逻辑反过来也成立。你可能一看 AI 能写代码，就动念头：是不是能用 AI 把上下游那些人也替了，前端、设计、DBA、产品，一个人带着 AI 全包。劝你打消这个念头。同一台放大器，在你手里放大你的专业，在他们手里放大他们的专业。一个专业前端用 AI 做出来的东西，大概率比你这个后端用 AI 做的前端要好，因为他知道哪儿有坑、什么算好、什么不能碰。你拿 AI 去顶替比你更专业的人，放大的是你在那个领域的外行判断，结果常是看着能跑、细看全是毛病。
所以更靠谱的姿势是协作：各人守着各人的专业，各自拿 AI 放大，而不是想着谁把谁替了。专业的事，还是交给专业的人去用 AI 做。
用上 AI，活不会变少
还有个误会得拆一下：用上 AI，是不是活就少了、人就轻松了。
照我的体感，不是。反倒是凭空多出来一摊活。AI 干得好不好，特别吃你喂给它的东西，上下文给得全不全、工具配得顺不顺、规矩立得清不清。这些都得你去调：prompt 和 skill 要一遍遍打磨，知识库要喂、要持续更新，你手里的工程本身也得改造到 AI 用着顺手的程度。
这块我之前单独写过一篇，核心是工程要先达到 AI-Ready。在没 ready 之前就急着堆各种 AI 工具、上多 Agent 协同平台，是本末倒置，顺序反了，效果好不到哪去。先把架构、基础组件、知识库、每个环节的 skill 这些地基铺好，AI 才使得上劲。
所以活没变少，只是换了一批：从自己埋头干，变成把系统调到 AI 能替你干好。后面这件事，门槛其实一点都不低，甚至更吃功力。
别躲着，去用
说到底，我想讲的就一件事：别躲，去用。
这波变化不会因为谁不舒服就停下来。你适应也好，不适应也好，它都在发生。区别只在于，早点把它当工具上手的人，能干的事反而变多了，一个人能覆盖的范围、能试的方向，都比从前大。被淘汰的，从来不是被 AI 淘汰，是被那些适应得比你快的同行淘汰。
往好处想，AI 把很多事的门槛拉低了，一个人能做成的事比以前多。前提是你得先上手用起来，光盯着裁员新闻焦虑，没用。
第三、四点说的「把工程调到 AI-Ready」「往技术深度走」，我整理成了一个 harness 工程实践系列，从 harness 到底指什么、skill 怎么分层、知识库怎么搭，到复杂任务的 spec 怎么写，都在里面，中英日韩四语都有。想往深里看的可以读这个：
harness-engineering-practice：github.com/androidZzT/...