最近在技术社区刷到 Yuchen Jin 关于 AGI 的那番讨论，说实话，第一反应是松了口气。大家都在喊 AI 要接管一切的时候，有人站出来说"该做的活一样都跑不掉"，这话听着就踏实。他的观点其实不复杂：AGI 很强，但它到来之后，前端页面还是得有人去调样式，幻灯片还是得亲自排版，税表到点还是得自己填。很多人把这句话理解成"AI 不行"，我觉得恰恰相反——正是因为 AI 变得足够强，一个人能借助它完成的事情边界大大扩展了，那些真正需要亲自动手的环节，反而成了决定产出质量的关键。
作为一个常年泡在前端领域、经历过各种框架更迭和工具革命的从业者，我对这个判断特别有共鸣。尤其最近几年，AI 编程助手已经深度嵌入了日常工作流，但你会发现一个很有意思的现象：能用好 AI 的人，往往是那些原本基本功就扎实的人。AI 可以帮你生成一百行代码，但你得知道哪一百行是对的；AI 能帮你排出一版幻灯片，但你可能得自己理清楚逻辑主线之后才知道让它怎么排。这篇文章我想从 Yuchen Jin 这句话出发，结合我自己在真实项目里摸爬滚打的经验，聊聊 AGI 时代里前端这个行当的真实处境，以及那些"还得自己做"的事到底教会了我们什么。
1. AGI 再强，"会做"和"能判断"终究是两码事
先说一个最扎心的事实：很多人对 AGI 的期待是"我不用学了，它什么都会"。但实际操作中你会发现，当 AI 给出的结果你不具备判断力的时候，局面反而更糟糕。就像标题里说的，报税这种事，AI 完全可以帮你算出应该填多少、怎么抵扣最优，但问题在于——税表上的数字最终签字的是你，数据填错了责任也是你的。这时候如果你连基本的税收逻辑都不懂，AI 给你一个"看起来专业"的结果，你敢直接提交吗？
1.1 判断力才是 AI 时代的稀缺品
我在团队里带过不少新人，也面试过几百个前端候选人，一个很明显的趋势是：随着 AI 工具越来越顺手，候选人写代码的速度确实变快了，但代码的质量和稳定性并没有同步提升。因为代码生成之后要跑起来、要维护、要处理边界情况，这些环节没法靠"提示词"解决，你得靠对人脑对系统运行机制的理解去定位问题。
比如前阵子我们项目遇到一个性能问题：一个数据列表在渲染时偶发卡顿，肉眼看着不规律，很难复现。当时的排查路径是先怀疑数据结构，又怀疑网络请求，折腾一圈之后发现是某个 JSON 字符串化相关的操作在数据量大时触发了严重的性能瓶颈。这个问题的根源涉及运行时内存分配、浏览器垃圾回收机制、大数据量下的渲染策略等等，如果你对这些底层原理没有概念，你会连排查方向都找不到。AI 此时能帮你优化某一段具体代码，但"该怀疑哪里、往哪个方向查"这个决策过程，真的只能靠自己的技术积累。
1.2 前端业务的不可言说部分
再往深了说，前端这个工种本身就有大量"不可言说"的成分。需求文档里写着"按钮要更醒目一点"，你觉得把字体加大加粗就行，但产品经理的真实意图可能是想把按钮放在一个视觉锚点上，让它形成用户的操作习惯。这种"只可意会"的需求，AI 是读不出来的。它没法在评审会上替你跟产品经理来回掰扯，也没法感知"这个交互在这个业务场景下用户会觉得顺手还是别扭"。AI 能解决的是"怎么实现"的问题，而前端工作中真正值钱的部分是"该实现什么"和"这么做合不合适"。
所以，每当看到热搜里反复出现"前端八股文""前端面试题 2026"这类关键词时，我反而觉得这是一件好事。它说明行业依然在用一套相对严格的标准筛选人，而不是靠"会不会用 AI 工具"来定胜负。八股文背后考察的计算机基础、网络原理、数据结构，本质上都是在训练一个人的系统判断力。
2. AI 能写代码了，前端工程师的价值反而更重了
有个观点最近挺流行：AGI 都来了，初级前端的活肯定要被替代。这个说法有一定道理，但替代的其实是"代码翻译"这个环节——把设计稿变成 HTML/CSS、把接口文档变成逻辑调用。这些工作 AI 确实干得不错。但整个前端交付链条里，"翻译"只是最末端的一环，前面还有需求梳理、信息架构、交互设计、技术选型、性能预算、异常兜底，后面还有监控反馈、迭代优化、技术债治理。这些环节不仅没被替代，反而因为 AI 拉高了单个环节的效率，倒逼从业者把精力放在更上游的思考上。
2.1 一个真实的开发场景：AI 生成代码之后的烂摊子
拿我们最近做的一个后台管理系统举例吧。有同事图省事，直接把一个包含复杂表单校验和数据联动逻辑的需求丢给 AI 生成，表面上代码能跑，点两下好像也没啥问题。但等到了联调阶段，问题开始集中爆发：表单校验的时序不对、某些极端输入没处理、接口异常时没有统一拦截、部分浏览器版本直接报错。最终这些代码还是要人工重写。AI 生成的代码就像一份"看着没病"的体检报告，但你要真想让它稳定运行在生产环境，还是得靠工程师逐行审查边界、理解业务。
这个案例给我的触动挺大的。它说明了一个道理：AI 降低了某些操作的下限，但丝毫没有降低交付标准的下限。你总不能跟用户说"这个页面在有网络问题时可能会白屏，因为 AI 没考虑到"对吧？所以实际工作中，我反而越来越强调 team 里成员的代码审查能力——你能不能在 AI 给出的方案基础上，补全异常分支、识别潜在风险、调整更合理的结构。这种能力，说实话 AI 很难学走，因为它来自对真实业务场景的理解和大量实战经验的沉淀。
2.2 "能写"到"写好"之间，隔着一条经验河
具体到前端开发的技能点，比如 JSON.stringify 的性能优化。很多刚入门的朋友知道这个方法能把对象转成字符串，但不知道在数据量上去之后它会变成性能瓶颈。我之前在优化一个实时大盘页面时，数据源每秒钟推送几十条更新，其中有一个字段是嵌套了三层的对象，序列化和反序列化的开销直接让页面掉帧。如果当时只是盲目上 Worker 处理大文件上传、或者用 otherside 的花哨技术，都解决不了问题——关键就是定位到了这个序列化点，然后通过数据扁平化、增量更新和缓存策略，把单次更新的耗时从几十毫秒降到了个位数。
这种定位问题的过程，AI 可以辅助你排查，但它没有办法替你做决定的。你会发现热词里"signalR 前端应该怎么获取数据""前端 websocket 怎么用"这类搜索量一直都很大，背后其实都是同一个诉求：在面对真实、复杂的实时数据场景时，工程师需要自己判断该选什么方案、怎么做数据流设计。AI 能给你标准的连接代码，但"用 SignalR 还是 WebSocket、重连策略怎么设计、消息格式怎么定、前端的状态怎么同步"，这些决策必须由了解业务痛点和系统瓶颈的人来做。
2.3 前端面试也在变化：AI 考不出来的是解决问题的过程
2026 年的前端面试题明显变得更有意思了，区别于前几年那种纯粹死记硬背的题，现在面试官更倾向给一个"线上页面卡顿，请你判断可能原因"这类开放式问题。这种题没有标准答案，考察的就是排查链路是否清晰、有没有自己的调试方法论。相比之下，记忆某个 API 的参数列表反而是最不重要的——因为这类知识 AI 随时可以告诉你，面试官真正想确认的是你这个人值不值得培养，遇到问题时的第一反应是"打开百度搜一下"还是"从内存、网络、渲染路径几个维度逐一排除"。
我在带人时也明显感觉到，给新人一个问题清单，让他们用 AI 辅助排查具体的线上 bug，他们能很快给出结论；但如果追问一句"为什么你会优先检查这个环节？"很多人的思路就开始乱了。这种从"知道怎么做"到"知道为什么这么做"之间的差距，就是资深前端和初级前端的分水岭。而这份差距，AI 暂时弥补不了。
3. 幻灯片和报税背后的共同逻辑：结构化思维无法外包
文章标题里提到的幻灯片和报税，看起来和前端八竿子打不着，但琢磨久了你会发现，它们折射出的其实是同一个能力——结构化思维。做幻灯片不是把文字往幻灯片里一扔就完事，而是要在有限的空间里组织信息层级，让听众顺着你的思路走；报税也不是照着表格乱填，而是要理解各种收入类型、扣除项、以及政策的适用范围，本质上是把复杂的规则梳理成一套适用于自己情况的映射关系。这种逻辑梳理和抽象的能力，才是最核心的"人类技能"。
3.1 不会做幻灯片的人，给 AI 一百个提示词也没用
我见过太多人声称"用 AI 做幻灯片很快"，但你问他做出来的东西为什么长这样、逻辑主线是什么、每一页之间的递进关系是什么，他完全答不上来。因为他只是在套一个模板，往里填内容，内容之间的逻辑联系是断裂的。AI 可以根据你的关键词生成一页页花哨的排版，但它不知道这页三年规划里最重要的转折点是你想强调的"AI 基建成本下降"，还是"团队重心转向业务侧"。这种对表达重心的判断，来源于你对自己工作和目标的深度理解，这个理解不能外包。
3.2 报税背后的合规意识，本质上也是一种"前端思维"
报税这个例子有点专业，但其实很容易理解。你打开税务系统，会发现它同样是一套巨大的信息输入和状态管理界面，你得保证自己提交的数据和实际情况一致，得了解不同收入类别对应的税率计算方式。如果只看 AI 输出的一串数字，你可能永远无法理解"为什么我的年终奖要单独计税""为什么这笔稿费收入扣的税和工资不一样"。这些细节，恰恰决定了你能不能合理合法地优化税务成本。
这跟前端开发里的"状态管理"特别像。页面下拉框选了一个值，后续展示的字段要联动变化，某些操作必须有权限才能执行，这些本质上都是状态驱动的界面逻辑。一个优秀的前端工程师，本质上就是一个"状态管理大师"，他懂得如何让系统的每个状态都符合预期、符合业务规则，并且处理好各种状态间的转换和边界。报税算下来，无非是把自己的财务状态映射到一套国家规定的"状态机"里，一表填错，后续全乱。
3.3 底层能力迁移：把复杂系统拆成可执行步骤
不管是写代码、做幻灯片还是报税，底层都离不开"把复杂系统拆解成小步骤"的能力。前端开发里，一个大型后台项目要拆成模块、组件、状态、接口层；做幻灯片时要把一个宏大的主题拆成章节、页面、要点；报税时要按收入的类别、时间、来源去分门别类。这套拆解能力，才是 AGI 怎么发展都难以完全替代的核心素养。AI 可以把一个已拆好的问题执行得很好，但它不擅长帮你定义"这个问题该拆成哪些维度"。
这也是为什么许多公司招聘资深前端时，越来越看重候选人有没有"业务理解能力"。你不光要知道 React 的生命周期或者 Vue 的响应式原理，你还要能听懂业务方讲的一个模糊的诉求，然后把它拆成清晰的技术方案，再逐步落地。AI 时代，从"模糊需求"到"清晰方案"之间的鸿沟，依然需要人来跨越。
4. 当 AI 成了标配，2026 年的前端该拼什么
既然 AI 无法避免地进入每个开发者的日常，与其焦虑"AI 会不会替代前端"，不如思考"AI 时代的资深前端应该具备哪些不可替代的竞争力"。我结合自己带团队和做技术服务的经验，分享几个我认为越来越重要的方向。
4.1 代码审查能力被严重低估
AI 生成的代码，最大问题不是跑不通，而是"表面能跑"但经不起推敲。我接手过不少 AI 生成的项目代码，常见的毛病包括：把不该暴露的接口写进前端逻辑、错误处理泛滥但没针对性、状态更新方式不统一导致竞态、组件粒度混乱增加维护成本。这些问题不像语法错误那样一眼可见，需要有经验的工程师在多一次的评审中识别出来。所以，我特别建议有上进心的前端开发者在日常工作中刻意练习代码审查——不光是看自己 team 的代码，也可以去翻翻知名的开源项目，思考别人为什么会用这种写法，优点在哪，风险在哪。
这种能力积累到一定程度，你看一眼 AI 生成代码的结构，就能大概判断出它有没有走偏。这种直觉不是天生的，全靠常年和真实代码打交道的经验堆出来。
4.2 调试能力：AI 时代的"侦探学"
前面提到过内存泄漏排查和大批量序列化性能瓶颈，这些都是调试问题的典型场景。我把调试能力叫作"侦探学"，因为它本质上是一个归纳、假设、验证的过程：观察现象、收集数据、形成假设、设计实验、确定根因。AI 可以帮你分析一段代码的复杂度，但没法帮你判断"用户反馈页面卡顿，是网络慢、渲染慢、还是内存泄漏"这种开放问题。开放问题的解决路径不唯一，也没有万能药，需要你基于系统架构和用户反馈去搭建一个合理的排查框架。
对于想提升调试能力的朋友，我的建议是不要只盯着自己写的页面，多去处理一些"别人写的烂代码"和"年代久远的历史项目"。那些代码里充斥着各种诡异的使用方式和未文档化的外部依赖，调试它们才能真正锻炼出从蛛丝马迹里找到根源的能力。
4.3 全链路性能优化：从 JSON.stringify 到 Worker 上传
标题提到"前端、幻灯片和报税还得自己做"，我猜很多人会忽略"前端"这两个字其实包含了一个非常庞大的知识体系。就拿性能和交互体验来说，真实项目里的复杂度远超教科书。前面讲到的 JSON.stringify 性能优化，只是冰山一角。再比如大文件上传，传统方案是直接塞进 FormData 一把梭，但到了几 GB 的文件，这条路就堵死了。现在标准的做法是采用分片上传加 Web Worker 做后台计算，避免阻塞 UI 线程；同时还要处理网络中断后的断点续传、服务端的即时校验、以及并发上传的分片调度。这些步骤，AI 可以给你提供每一段的代码样板，但整个方案的技术选型、架构设计和兼容性考量，还是得靠人来做。
我记得有次做视频资产管理系统，用户要上传几十个 G 的拍摄素材，前端如果处理不好，页面直接崩溃。当时我先是评估了主线程的性能影响，决定引入 Web Worker 来处理文件的读取、分片和哈希计算；然后又设计了并发数为 3 的上传队列，避免网络拥塞；再通过服务端的秒传校验，让用户重复上传时几乎不用等待。这一整套链路下来，AI 只是帮我们把一些常用的工具函数写好了，核心的架构设计、异常处理、以及和产品经理对需求的调整，都是靠团队内部的讨论定下来的。你说这些经验值钱吗？非常值钱。
4.4 学会当 AI 的"老板"，而不是同事
最后聊一个比较抽象但很重要的能力——如何支配 AI。大部分人的默认做法是直接抛一个任务给 AI："帮我写一个登录页"，AI 吐出来一个能用但平庸的结果。更好的姿势是把 AI 当成一个执行者，而你更像一个产品经理兼技术负责人：你先拆好需求结构、定好技术边界、列清楚约束条件，再让 AI 按你的框架去生成细节代码。比如"帮我实现一个基于 React 的表单验证组件，字段包含用户名和邮箱，验证规则包括必填和格式校验，错误提示要内联展示，且提交按钮在验证失败时不可点击。请先输出组件结构，再输出核心逻辑。"你会发现，当你把边界画得越清晰，AI 生成的结果就越贴近你的预期。如果生成得不对，你还能基于自己对状态管理的理解去纠正它。这种能力，本质上还是来自扎实的前端基本功。
5. 我的日常工作流：AI 负责初稿，我负责定稿
最后结合个人实操，分享一些我在项目里实际沉淀下来的工作方法。我觉得这是对"AGI 到来后生活依旧"最直接的一种回应——AI 当然会全面渗透到我的日常，但我自己的认知框架和工作习惯，反而变得更加重要了。
5.1 用 AI 辅助需求分析和方案设计
我现在接到一个前端需求，第一件事不是打开编辑器，而是先在文档工具里把需求拆解成几个核心问题：这个功能的目标用户是谁？使用路径是什么？核心指标是什么？在这些问题没有清晰答案之前，我不会让 AI 写任何代码，而是让它作为外脑帮我把可能的技术方案列出来，甚至让 AI 扮演产品经理来挑毛病。在这个过程中，AI 最大的价值不是给我答案，而是通过对话帮我把脑海中模糊的想法逐渐具象化。但怎么判断 AI 给的方案是不是最优，框架搭得合不合理，依然靠自己的经验。
5.2 代码实现阶段，AI 给了我更多时间做 Code Review
写代码的环节，AI 确实帮我节省了大量敲键盘的时间。过去实现一个完整的 CRUD 页面，可能需要写很多重复的表格、表单和弹窗代码；现在，我可以直接让 AI 按我的要求生成页面骨架，再手动调整交互细节。省下来的时间，我会用来做什么？第一，做更细致的代码审查，把潜在的性能隐患和状态管理缺陷扼杀在代码提交之前；第二，和产品、后端同学深入沟通，提前识别接口定义和数据结构的坑；第三，写自动化测试，把核心业务路径的稳定性兜住。
我举一个具体的例子。前阵子接了一个报表中心的需求，涉及大量的动态列、多选筛选、排序、分页和导出。这种项目如果全人工敲，至少要一周多；但借助 AI 生成基础组件和页面，我两天就把第一版搭了出来。剩下的时间全部花在和业务方确认数据口径、调整筛选逻辑、以及把导出功能在大数据量场景下做性能验证上。最终交付时，页面的稳定性和可扩展性都远超以往，这就是合理地把 AI 当成效率杠杆带来的成效。
5.3 但"责任"和"兜底"，依然只能自己承担
分享这么多，我想强调的是：AI 可以接管"执行"，但它无法接管"责任"。页面线上出了 bug，用户不会说"这是 AI 写的有问题"，他只会觉得"你们团队的工程质量不过关"。报税填错了，税务部门也不会因为"是 AI 帮我报的"就网开一面。做幻灯片逻辑混乱，听众也不会因为"这页是 AI 生成的"就更容易理解。一切交付最终指向的还是"你"这个人——你的专业判断、你的经验沉淀、你的责任意识。
前端行业恰恰是最能体会到这种"责任"的地方：你写下的每一行代码，都要对真实的用户行为负责；你做的每一个交互决策，都会影响千万次点击背后的使用感受。AGI 的到来让工具的边界拓宽了，但没有改变"你要对自己产出的东西负责"这个底层事实。
5.4 给前端开发者的一条实在建议
如果你现在正处于职业早期，或者正在为 2026 年的面试做准备，我把多年的经验浓缩成一句话：把 AI 当成你的"加速器"，但永远不要当成你的"外挂大脑"。多花时间钻研底层原理，亲手解决几个棘手的线上问题，踏踏实实把几个复杂功能做深做透，这些笨功夫在任何时代都值钱。面试官和项目负责人看重的，从来不是你会多少工具，而是你面对未知问题时，能不能扛得住、拆得开、解决得掉。
回到 Yuchen Jin 那句话，AGI 到来后生活依旧——这句话听起来像是一种乐观的躺平，但在我看来，它其实是对人类自身能力的一种重要肯定。技术再怎么演进，前端工程师、内容创作者、每一个普通个体所具备的判断力、责任心和创造力，依然是我们在这个世界上立足的根本。别焦虑 AGI 会带走什么，先把手头该做的事一件一件做好。写前端也好，做幻灯片也好，报税也好，每一件"自己亲手做完"的事，最后都会长成你身上别人抢不走的那部分能力。
