昨天，一张关于前阿里P10毕玄的内部聊天截图在技术圈引起了广泛讨论。截图中的核心观点是：随着 AI Coding 的发展，公司决定以后不再按技术栈划分技术岗位，所有技术岗统一称为 Agent 工程师。
这张截图的内容大致如下：
看到这张截图时，我联想到大约一周前在朋友圈看到的另一条动态：有朋友提到，他们的公司未来将不再分别招聘前端或后端工程师，而是只招聘全栈工程师。两者信息一交叉，让我感觉这或许并非个例，而可能代表了一种正在发生的趋势。
其背后的逻辑其实很清晰。随着 AI 编程能力的飞速提升，未来或许不再需要大量只精通某一狭窄领域的程序员。AI 可能更擅长直接产出代码，那么，一名全栈工程师的主要职责，将转向进行软件架构设计、监督AI工作并评审其产出的代码。换句话说，一个全栈工程师，手底下干活的“团队成员”可能都是AI。
设想一下：如果你是一名前端工程师，AI 帮你写好了后端代码，你却看不懂或无法有效监督，难道公司还要再配一名后端工程师吗？同理，后端工程师面对AI写的有问题的前端页面，如果自己不会修改，难道也要再配一名前端？这样，AI 提升了效率，但公司的人力成本并未降低，反而可能增加。
因此，未来随着 AI 能力的不断增强，具备通识能力、对各领域都有所了解的人，其价值可能会超过只精通单一领域的专家。通识能力强的人，通常拥有更强的跨学科整合能力、灵活应变能力、创新能力与协调能力。
回顾软件发展史，其实最初并没有这么细致的工种划分。计算机发展初期，一个工程师写完 GUI 界面，一个软件就完成了。后来，随着浏览器和软件项目的日益复杂，才逐渐细分出前端、后端、DBA、SRE、QA 等岗位。分工的本质是为了提高效率。
然而，AI 的出现，相当于给每位工程师配备了一支“随叫随到的全能团队”。它可以同时编写前端、开发接口、撰写脚本、补充单测、修改 CI 配置、查询日志，甚至帮你写好 Pull Request 的描述。
于是，一个根本性的问题浮现出来：当“写代码”这件事本身变得不再稀缺时，公司最稀缺的到底是什么？
我认为会变成以下三种核心能力：
第一，定义问题的能力。 即将一个模糊的业务需求，拆解为可落地、边界清晰、验收标准明确的具体任务。AI 很会写代码，但它无法替你决定“我们究竟要做什么、为什么做、做到什么程度才算完成”。如果问题定义错了，后续代码写得再快也是徒劳，甚至可能错得更快。
第二，系统性判断与工程决策能力。 例如，是否要引入一个新框架？是否要做微服务拆分？是否要上消息队列？是否值得为了性能重写某个模块？AI 能给你十种技术方案，但如何选择、其中的利弊权衡、以及未来可能面临的挑战，这更多依赖于工程师的“工程审美”和“经验”。
第三，跨域整合能力。 也就是能否将产品、业务、设计、数据、安全、成本、合规等多方面因素融合考量，最终交付一个能稳定运行的系统。过去一个人很难覆盖如此多的领域，所以只能分工协作。现在 AI 抹平了许多具体实现的鸿沟，反而更需要有人站在更高的视角，把整个链条串联起来。
因此，我特别理解毕玄提出的“统一叫 Agent 工程师”。这绝非简单地换个岗位名称，其本质是公司对“工程师”核心价值的重新定义。
过去的工程师更像一个标准化工种：前端负责页面，后端负责接口，大家像流水线一样拼装起来。而未来的工程师，则更像一个项目负责人，带领着一群 AI 助手。你的核心任务不是亲手拧紧每一颗螺丝，而是决定如何设计整台机器、如何安排工序、如何验收结果、如何保证质量与控制风险。
说得更直白些：未来许多公司可能不再需要大量“只会拧某种特定螺丝”的人，而是需要“能把一整台机器造出来并让它跑起来的人”。
那么，如果未来大家都成为 Agent 工程师，是否意味着你必须什么都精通？
我认为并非“什么都要会”，而是至少要做到以下两点：
第一，要能看懂不同领域的基本“语言”。 前端至少要理解组件、状态、路由；后端至少要明白接口设计、鉴权、缓存、限流；数据库至少要懂索引、事务、慢查询；运维至少要知道部署、监控、告警、回滚的基本流程。你不必像专家一样写得极其漂亮，但必须有能力判断 AI 产出的东西是否存在问题。
第二，要能把“交付”的闭环完整跑通。 即从需求分析到上线运维再到复盘迭代，你能独立或主导走完这条完整链路。AI 辅助编码只是中间一环，真正的工作是将代码变成一个稳定、可维护的产品。这要求你会测试、会验收、会监控、会定位问题、会持续迭代。
所以，我理解的“Agent 工程师”，更像是一种“软件交付工程师”。其交付物是完整的、可用的业务结果，而非某个技术栈下的局部产出。
这对技术人员个人意味着什么？我认为会发生几个现实的变化：
- 学习方式会变。 过去通常是先深入学好某个方向，才敢接手项目。未来可能会反过来，先基于项目开始动手，遇到不懂的就请教同事或询问 AI，在实践中查漏补缺。学习模式从“先学后用”转变为“以用促学”。
- 简历的价值点会变。 过去写“精通 Vue、精通 Spring”非常吃香。未来可能更具价值的是：“我独立交付过XX产品”、“我如何进行需求拆解与架构决策”、“我如何保证项目质量与稳定上线”。能力叙事将从罗列技术名词，转向讲述完整的交付故事。
- 竞争对手会变。 过去的竞争对手主要是同技术栈的开发者。未来，你将与“更善于利用 AI 工具的人”和“更擅长打通全流程的人”竞争。技术栈本身的壁垒在变薄，而方法论、工程思维和交付能力的壁垒在加厚。
在公司组织层面，我猜想结构会更趋向“围绕业务的产品小队”模式，而非传统的“按职能划分的技术部门”。每个小队聚焦一个业务目标，成员不再严格区分前后端，而是根据任务灵活流动。工程师可能会更频繁地与产品经理、运营直接对齐，因为你负责的是最终的业务结果，而不再只是一堆离散的技术任务。
当然，这其中也潜藏着一个巨大的风险：当公司把岗位合并为“全栈”或“Agent工程师”后，很容易出现一种局面——要求越来越多，但给予的资源和支持却越来越少，最终演变成“一个人干三个人的活”。AI 虽然提升了效率，但也可能让管理者产生错觉，认为软件开发不再需要时间打磨、不需要质量保障、不需要复盘优化，最终导致技术债疯狂堆积。
因此，我认为未来的优秀工程师，反而需要更懂得说“不”，更善于界定工作边界，更清晰地沟通成本与风险。因为你越能交付，就越可能被塞进更多需求。如果不懂得管理预期，你很可能被 AI 带来的“看似无限的产能”所拖垮。
最后，给各位同行一个非常具体的建议：如果你正在纠结“是否要转向全栈”，不必急于给自己贴标签。可以先尝试做一件事：选择一个你熟悉的业务场景，尝试借助 AI 工具，独立跑通从需求拆解、数据设计、接口开发、前端实现，到部署上线、监控、测试验收的完整链路。这个过程会让你无比清晰地认识到自己当前的能力边界，也能切身感受到 AI 能力的实际局限。
当你成功跑完一次完整的交付闭环，你其实已经在向一名真正的“Agent 工程师”迈进了。你会发现，所谓的通识，并非漫无目的的“博而不精”，而是围绕“交付价值”这一主轴，有方向地扩展自己的能力圈。你不是为了成为全栈而全栈，而是为了做出成果而必须拓宽边界。
对于整个行业来说，这是一次深刻的角色重塑。我们正从精细分工的时代，走向一个更强调整合、决策与交付的新阶段。这个过程充满挑战，但也孕育着新的机遇。如果你想了解更多关于行业趋势与开发者成长的讨论，欢迎来到 云栈社区 的开发者广场板块交流。同时，对于未来工程师需要具备的软件架构与系统设计能力，你也可以在后端 & 架构板块找到深入的探讨。
发表于 7 小时前
|
查看: 2|
回复: 0
