前阿里P10毕玄的一张聊天截图火了。

前阿里 P10 的毕玄说：随着 AI Coding 的发展，公司决定以后不再按技术栈划分技术岗位了，公司所有的技术岗统一称为 Agent 工程师。在工作安排上相应的后续也就不再按照技术栈来安排，而是完全根据产品、项目任务来安排，这意味着以后一项工作里可能涉及各种技术领域，对于不同的领域，需要自己去学习，要么问同事，要么问 AI 。

我为什么突然想聊一聊这件事呢？因为我感觉这或许可能就是未来的一种趋势，当我看到这张截图的时候，我应该是在一周前，我朋友圈技术人比较多，认识很多公司，我实在想不起来了，看到一个朋友发了朋友圈说：以后他们公司不再招聘前端工程师或者后端工程师了，只招聘全栈工程师。

我当时没在意，当我昨天看到毕玄的截图，这么一交叉，感觉挺有意思的。

其实，道理很简单，随着 AI Coding 的发展，未来可能并不需要太多的精通某一个领域的程序员了，因为未来 AI 可能更擅长写代码，这时候，一个全栈工程师主要的任务就是进行软件架构的设计，监督 AI 工作，同时 Review AI 写的代码。一个全栈工程师，手底下干活的都是 AI 。

你试想一下，你是前端工程师的话，AI 帮你写完了后端，你看不懂或者无法监督 AI 后端的工作情况，难道再配一个后端工程师呢？同理，一个后端工程师，使用 AI 开发一个项目，前端页面 AI 写的有点问题，你不会修改？再给你配一个前端工程师吗？AI 可能提高了效率，但是，公司并没有降低成本啊，还多聘请了一个员工。

未来随着 AI 的发展，AI 的能力越来越强，具有通识能力的人，什么都懂得一点的人可能比在某一个领域精通的人更有价值。

通识能力强的人，一般具有跨学科能力，灵活应变的能力，创新的能力，协调的能力比精通某一个领域的人更强。

通识更有优势。

回想一下软件的发展史，其实一开始，并没有这么多工种，以前也是要给全栈工程师，那时候，计算机刚出来，写一个 GUI 界面，就可以了，后来随着浏览器的发展，软件项目也越来越复杂了，就开始划分了更多的岗位，分工的本质是提高效率。但是，随着 AI 的发展，很多岗位的工作 AI 都会干了，这时候，分工这件事就会发生一次“反向演化”。

以前分工是因为复杂度上来了，人脑和人手不够用，所以要把系统拆开，前端负责前端，后端负责后端，数据库有 DBA，运维有 SRE，测试有 QA。拆得越细，单点效率越高，交付越快。

但 AI 的出现，相当于给每个工程师发了一支“随叫随到的团队”。它可以同时写前端，写接口，写脚本，补单测，改 CI，查日志，甚至把你的 PR 描述都顺手写了。

于是问题来了：当“干活”这件事变得不稀缺的时候，公司最稀缺的到底是什么？

我觉得会变成三样东西。

第一，定义问题的能力。也就是把一个模糊的需求，拆成能落地的任务，把边界讲清楚，把验收标准讲清楚。AI 很会写代码，但它不会替你决定“我们到底要做什么，为什么做，做到什么程度算完”。这件事如果定义错了，后面写得再快都没用，甚至更糟，错得更快。

第二，系统性判断。比如，你要不要引入一个新框架，要不要做微服务，要不要上消息队列，要不要为了性能把某个模块重写。这些东西不是代码能力的问题，而是工程决策的问题。AI 能给你十种方案，但选哪一种，取舍是什么，未来一年会不会被打脸，这更像是工程师的“审美”和“经验”。

第三，跨域整合能力。也就是你能不能把产品，业务，设计，数据，安全，成本，合规这些东西揉到一起，做出一个能跑起来的系统。以前一个人很难覆盖这么多，所以只能分工。现在 AI 把很多具体实现抹平了，你反而需要一个人站在更高的视角把活串起来。

所以我特别理解毕玄说的“统一叫 Agent 工程师”。它本质上不是换个名字这么简单，而是公司在重新定义“工程师”到底是干嘛的。

以前的工程师像一个工种。你是前端，你就把页面写好。你是后端，你就把接口写好。大家像流水线一样拼起来。

以后更像什么？更像一个项目负责人带着一堆 AI 助手。你要做的不是亲自把每一颗螺丝拧紧，而是决定怎么设计机器，怎么安排工序，怎么验收结果，怎么保证质量，怎么控制风险。

说得直白点，以后很多公司可能不再需要那么多“只会拧某一种螺丝”的人了，它需要的是“能把一台机器造出来并跑起来的人”。

那问题又来了。

如果未来大家都叫 Agent 工程师，是不是意味着你什么都要会？

我觉得不是“什么都要会”，而是你至少要做到两件事。

第一，你要能看懂不同领域的基本语言。前端你至少能读懂组件，状态，路由这些概念。后端你至少能读懂接口设计，鉴权，缓存，限流这些概念。数据库你至少知道索引，事务，慢查询怎么回事。运维你至少知道部署，监控，告警，回滚怎么做。你不一定要像专家一样写得很漂亮，但你得能判断 AI 写的东西是不是在坑你。

第二，你要能把交付闭环跑通。也就是从需求到上线再到复盘，你能把这条链路完整走一遍。AI 帮你写代码只是中间一环，真正的工作是把它变成一个稳定可维护的产品。你得会测试，会验收，会监控，会定位问题，会迭代。

所以所谓“Agent 工程师”，我理解更像是“软件交付工程师”。交付的是结果，而不是某个技术栈里的局部产物。

这对个人意味着什么？

我觉得有几个很现实的变化。

1，你的学习方式会变。以前学技术是先把某个方向学深，才敢去碰项目。以后可能反过来，你先拿项目开干，遇到问题就问同事或者问 AI，然后边干边补知识。学习从“先学后用”变成“以用促学”。

2，你的简历打法会变。以前写“精通 Vue，精通 Spring”很吃香。以后可能更值钱的是“我独立交付过什么产品，我怎么做需求拆解，我怎么做架构决策，我怎么保证质量”。也就是说，能力叙事从技术名词变成交付故事。

3，你的竞争对手会变。以前你的对手主要是同技术栈的人。以后你会和“更会用 AI 的人”竞争，和“更会把活儿跑通的人”竞争。技术栈的壁垒变薄，方法论的壁垒变厚。

那公司层面会怎么变？

我大胆猜一下，组织结构会更像“产品小队”，而不是“技术部门”。每个小队围绕一个业务目标，里面的人不再严格区分前后端，而是按任务流动。今天你写页面，明天你写接口，后天你盯上线和监控。你可能会越来越频繁地跟产品经理和运营直接对齐，因为你拿到的是结果指标，而不是一堆技术任务。

当然，这里也有一个很大的风险。

当公司把岗位合并成“全栈”或者“Agent”，很容易出现一种情况：要求越来越多，给的资源越来越少，最后变成“一个人干三个人的活”。AI 虽然提高效率，但它也可能让管理者产生错觉，以为工程不再需要时间，不再需要质量保障，不再需要复盘，最后把技术债堆得更高。

所以我觉得未来真正厉害的工程师，反而要更会说“不”。更会给边界，更会谈成本，更会把风险讲清楚。因为你越能交付，越容易被塞更多需求。你不懂得管理预期，你就会被 AI 带来的“看似无限产能”拖垮。

写到这里，我其实想给大家一个很具体的建议。

如果你是一个还在纠结“我要不要转全栈”的工程师，你可以先不急着给自己贴标签。你先做一件事：选一个你最熟的业务场景，拿 AI 把整条链路跑一遍。从需求拆解开始，到数据库设计，到接口，到前端，到部署监控，到测试验收。你会在这个过程中非常清楚地看到自己缺什么，也会清楚地看到 AI 的边界在哪。

你跑完一次闭环，你就已经在向“Agent 工程师”靠近了。

而且你会发现，所谓通识，并不是博而不精，而是你有一个主轴，你围绕交付去扩展你的能力圈。你不是为了全栈而全栈，你是为了把结果做出来而拓宽边界。

#HOW I AI##科技先锋官#