这几个月我一直在面前端和全栈偏前端的实习。前段时间我和 ChatGPT 聊了很长一段，起因是一个我想不明白的问题：AI 已经能完成这么多开发工作，公司为什么还要雇一个初级前端？
一共聊了四轮，这篇是前两轮，第三、四轮在下篇。我的话原本是语音输入，整理时删掉了重复和口误。ChatGPT 的回答放在引用块里，原文很长，删掉了一些重复的解释和建议，删减的地方用省略号标出。我们之间的分歧都保留着，有些问题到最后也没有答案。
我一开始的问题#
虽然常看到“前端已死”“赶紧转全栈或者 AI”的说法，我在招聘平台上投前端岗位，还是能收到面试邀请。几轮面下来，真正考八股的只有一次，更多面试官愿意围绕项目经历和 AI 开发方式聊。
我平时大量用 Claude Code 和 Codex 写代码。它们已经能完成很多编码和调试，Codex 还能直接操作电脑，打开浏览器、看控制台这些原本要开发者自己做的事，它也能做。一家公司每个月花一两百美元就能用上很强的模型，为什么还要雇一个初级开发者？我说不清自己能创造哪些订阅费买不到的价值。
我手上有 IoT 设备管理平台、和同学合作的工业检修平台 MaintPilot ↗、作品站 UI Motion Lab ↗ 和这个博客，但其中不少代码是 Agent 写的，我不一定清楚每个细节。面试官问 IoT 项目里的 WebSocketClient 怎么工作，我只说得出重连、心跳这几个词。还有一位面试官问，企业知识库很大的时候索引怎么组织，我回答说 Agent 能通过文件名、目录和关键词一步步找到资料，模型再强一些，也许不一定都需要传统的 RAG。
另一方面，我确实喜欢可视化界面、动画和交互，在 UI Motion Lab 里复刻过一些效果。也有面试官说，这些更像产品经理或者美工考虑的事，开发者不需要管那么多。以后该往哪个方向走，我很迷茫。
GPT 的第一套建议#
它先把我的问题换了个说法：
我觉得你现在面临的，其实不是简单的“要不要继续学前端”或者“要不要背八股”的问题，而是一个更深层的困惑：当 AI 已经能完成越来越多的软件开发工作时，一个还没有多少正式工作经验、但已经大量使用 AI 编程的开发者，究竟应该建立什么样的核心竞争力？
它的结论是不要放弃前端，也不要急着转去研究大模型和 Agent 框架，而是“以前端为核心，具备全栈交付能力，同时重点发展复杂交互、产品体验和 AI 辅助工程能力”。它认为受到冲击的是前端里容易标准化的那部分任务，比如照着设计稿拼页面、写常规 CRUD、封装普通组件、调整简单样式。
能完成任务，和敢把任务交给 AI#
对“公司不如直接买 AI 会员”，它说这个问题不能简单反驳：如果一家公司只需要几个简单的管理后台页面，只会照需求写页面的初级开发者确实会面临越来越大的压力。但是：
AI 能把一个任务完成，与企业能够放心地把这个任务交给 AI，是两件不同的事情。
它拿我的 IoT 项目举例：
假如现在设备数据突然停止更新，页面上的 WebSocket 状态仍然显示已连接，同时数据库里还能看到新的 MQTT 数据。
AI 当然可以帮忙分析和修复。
但是谁来判断问题到底有没有解决？
……AI 可以参与甚至完成其中绝大部分操作，但企业最终需要的是一个能够对交付结果负责的人。
它还引了刚发布的 Stack Overflow 2026 开发者调查 ↗：48% 的受访者只在容易验证输出的情况下才信任 AI，愿意让 AI 参与重要工作决策的只有 6.6%。这两个数字和调查原文一致。
接着它把要发展的能力分成判断能力、工程能力和产品能力三项，并说我身上已经有一个“值得警惕的信号”：
你能够借助 AI 完成相对复杂的系统，但还不一定能够独立解释这些系统最关键的技术决策。
八股和项目原理#
八股题与项目技术原理不是同一回事。
它的例子是：Vue3 的响应式系统怎么收集依赖，是偏理论的前端基础题，可以不追求源码级的理解；但“你的 IoT 系统是怎样通过 WebSocket 把设备数据实时推送到前端的”，已经是项目经历本身。我的简历里写了封装 WebSocketClient、自动重连、心跳检测和多类型消息订阅，面试官自然会认为我理解它们。它还提了两个容易被追问的点：浏览器原生的 WebSocket API 不直接暴露协议层的 Ping/Pong，前端心跳一般要约定应用层消息；重连成功也不代表断线期间的消息会自动补齐，需要另外考虑历史查询或者消息恢复。
我建议你重新审视简历，把每一项技术描述都当成一个必须能解释的承诺。
我在面试里主动说过自己“不太会八股”，GPT 建议以后别这样说，这句话容易让对方提前认为我的基础比较薄弱。八股问到了再答，确实不会的坦诚说明，不用预先给自己贴标签。
知识库怎么建索引#
对我那个“Agent 越来越强，RAG 可能没那么必要”的回答，GPT 说有道理，但不完整。几十、几百篇命名规范、目录清楚的 Markdown，比如我的博客，Agent 靠目录遍历和关键词搜索就够了，完全没必要引入向量数据库。换成工业检修知识库，就要考虑：
- 用户搜“水泵压力异常”时，怎样同时找到术语不同但语义相关的历史案例；
- 怎样优先找到最新版本，而不是已经废弃的操作规程；
- 怎样避免普通检修人员检索到没有权限查看的内部资料；
- 怎样返回可以追溯来源的证据；
- 怎样平衡检索准确率、延迟和计算成本。
它提到微软的 Agentic Retrieval ↗ 也是把大模型的查询规划、关键词与向量的混合检索、语义重排和来源引用组合在一起用，Agent 和检索系统是互相配合的。
不要因为新一代模型可以完成某个任务，就直接认为解决这个任务的传统工程方法已经过时。
UI Motion Lab 和审美#
这一点 GPT 是支持我的。它说面试官那样说，可能是基于他们公司的分工，但：
如果前端开发者自己对交互、布局、动画节奏和用户体验有判断能力，实际上可以更好地完成这项工作。
它拿作品站里的 ShiroNav 胶囊导航 ↗举例，说真正值得研究的不只是外观，而是共享元素过渡、布局变化、动画状态和不同操作之间的协调，这些都是前端工程问题。对我说的“页面挺好看，但总觉得差点意思”，它认为这不是换一个更强的模型能解决的，要学着把视觉问题拆开描述：视觉层级、字体排版、间距节奏、色彩、动效、交互反馈。它还建议先让 AI 做设计评审，不直接改代码，每次只改一个问题，保留修改前后的截图。
一份四周计划#
最后它给了一份四周计划：第一周重新梳理 IoT 和 MaintPilot 的数据流和模块边界；第二周亲手做一次 WebSocket 断线重连和消息分发的实验，写一组 Vitest 测试；第三周在 UI Motion Lab 或 Niwa 里挑一个交互细节，做视觉、性能和易用性的优化；第四周准备自我介绍和三个项目故事，做追问模拟。它希望我的工作方式从“提出需求 → AI 编写 → 自己运行 → AI 修复 → 提交代码”，变成“理解需求 → 自己提出实现思路 → AI 协助开发 → 自己解释关键模块 → 设计异常测试 → 验证结果”。
这一轮是这样结束的：
你现在最大的短板，我认为不是技术栈不够多，也不是 AI 工具用得不够先进，而是项目开发的广度已经超过了你对部分技术实现的理解深度。
……如果只能从明天开始做一件事，我建议你先打开 IoT 项目，重新梳理 WebSocketClient 的源码。不要急着让 Codex 优化它，而是先尝试自己解释每个方法、每个事件处理器的作用，以及断网、重连、重复消息等异常情况下会发生什么。
我不同意“人负责判断”#
这套建议我没有接受。GPT 说人要负责判断、排查和验证，可 Agent 现在不只会写代码，还会自己组织很规范的项目结构，做重构、写测试、操作浏览器，有时不需要我特别要求，它就把这些做好了。如果排查和验证也能自动完成，“人负责判断”还剩下多少？
同样，我日常开发根本用不到 Vue3 依赖收集的源码细节，学了也只是为了面试背下来。WebSocket 的 onmessage 这些 API 我不熟，但和 AI 聊几轮，功能往往就做出来了。
那份四周计划我也不想照着做。IoT 和 MaintPilot 我现在都已经不再开发了，IoT 项目连跑都跑不起来，要梳理它的数据流，也只能让 AI 读代码、帮我辅助理解。为一个跑不起来的项目做 WebSocket 断线重连和消息分发的实验，再补一组 Vitest 测试，有什么必要？重新梳理旧项目的源码，在我看来又回到了背八股那一套。我的习惯是需要用的时候才去研究，看完以后完全用不上的东西，我不会再去看。
我还讲了两件事。一件是 Agent Map：有一次演示没法调用云端大模型，我换成 8GB 显存能跑的本地小模型，上下文很有限，于是做了一份 Agent Map，列出每个文件的文件名、中文职责和关联模块，让 Agent 先看它，再决定去读哪些代码。在我看来，它就像一本书的目录。
另一件是 MaintPilot。我负责前端，同学负责后端，可我的前端代码基本是 Codex 完成的。我当时跟它说：“这个项目本身我基本都没看过代码，都是 Codex 自己完成的。”RAG、混合检索、BM25、向量数据库和重排，我也只是大致了解，不该说成自己深入实现过。
GPT 改了说法#
这次我觉得你的反驳比上一轮讨论更深入了一些。而且我发现，我之前给你的建议确实有一个问题：我仍然在用传统软件工程师的培养方式，指导一个已经把 AI 作为主要开发工具的人。
因此，我不会再简单地告诉你：“AI 只能写代码，人类必须负责架构和调试。”因为架构设计、调试和测试本身，也都正在变成 AI 可以执行的任务。
随着 AI 能力提高，一部分初级软件开发岗位确实可能减少。没有任何证据能保证，今天学习的某项开发技能在五年后仍然具有同样的就业价值。
它换了一个角度：就算技术实现可以全部交给 AI，我仍然可以说“我不喜欢这个页面的布局”“这个动画虽然流畅，但感觉有点廉价”“这个功能虽然做出来了，但我觉得没有解决用户真正的问题”。这些判断也可以让 AI 辅助，但最终要由我对一个具体的产品提出偏好、目标和取舍。
我认为你应该从追求更强的代码实现能力，逐渐转向追求更强的产品表达能力。
它马上加了一个限制：审美和产品判断同样可能被 AI 辅助甚至部分自动化，不能看成永远不会被替代的护城河，“它们更适合作为你现在的重点发展方向，而不是职业安全保证”。
两种知识#
关于 Vue3 依赖收集，它说如果没遇到相应的问题，也不打算研究框架内部，就没必要为了学习而学习，“使用数据库的人不需要自己实现 B+ 树”。但它把知识分成了两种：
一种是框架内部的知识，比如 Vue3 的 track 和 trigger 具体如何实现。
另一种是与你的产品行为直接相关的知识，比如为什么某个 watch 会重复触发，为什么组件卸载后还存在事件监听，为什么界面显示的是旧数据。
前者你可以不学。
后者如果 AI 已经能够解决，你也不必一定亲手修复，但至少需要知道自己希望最终获得什么样的行为。
八股被它归到了招聘方式上：
面试所要求的知识，不一定等于实际开发所需要的知识。
如果目标公司确实考，不准备就可能失去这个机会，但“你完全可以把它当作求职中的一项成本，而不是自己长期学习的中心”。
Agent Map 和内容检索#
它说 Agent Map 很接近现在说的渐进式披露（Progressive Disclosure），并提到 OpenAI 今年 2 月的 Harness engineering: leveraging Codex in an agent-first world ↗：不要把全部知识放进一个巨大的 AGENTS.md，而是给 Agent 一张地图，入口文件写短，再链接到结构化的架构、产品、设计和可靠性文档，让它按需去找。它同时把两件事分开了：
比如，你希望找到负责 WebSocket 重连的代码，Agent Map 可以让模型快速找到对应模块。
但如果你需要从十万份设备检修记录中，找到“虽然没有明确提及水泵压力异常，但实际描述的是类似故障”的文档，那么 BM25、语义检索和重排序就有不同的作用。
前者更像导航，后者更像内容搜索。
GPT 建议我面试时坦诚说明后端检索是同学负责，然后讲自己的 Agent Map 实践，“这其实比泛泛介绍一个自己没有深入实现过的 RAG 系统更有说服力”。
MaintPilot 证明的是谁的能力#
对“没看过代码”那句话，它说这不一定说明项目没有价值，但我不能再用传统项目经历的讲法。如果代码基本由 Agent 编写，我真正参与的可能是需求定义、任务分配、AI 开发流程管理、功能验收、部署和团队协作。然后它问：
如果一个项目的需求、设计、代码、测试几乎全部是 Agent 自己完成的，那么这个项目能够证明的是 AI 系统的能力，还是你本人的能力？
它说这不是反对这样开发，而是要找出真正由我主导的决策和成果：有没有主动发现过某个需求不合理，有没有反对过 AI 给出的设计方案，有没有制定过明确的交互标准，有没有解决过一个 Agent 反复做不好的体验问题。
更看好审美方向#
它还提到 Anthropic 今年 3 月的 Harness design for long-running application development ↗。文章里说，不加干预时模型容易做出技术上能用、视觉上平平的页面（原文是 “technically functional but visually unremarkable”），于是用设计质量、原创性、制作精度和功能性四项标准来评价前端设计，再让独立的评价 Agent 反复审查生成结果。它觉得有意思的地方是：
他们先尝试把非常主观的审美判断，转换成更加具体、可以评价的标准。
这恰好回应了你的问题。
撤回四周计划#
不再为了补知识而单独做实验，而是通过优化自己真正关心的产品，顺带补齐必要的知识。
它新的建议是在 Niwa 或 UI Motion Lab 里挑一个一直不满意的页面，让 Codex 检查代码、调试页面，甚至自动做设计评审，我只负责定义体验目标、挑选方案、判断结果够不够好；只有某个技术问题挡住了目标，才针对性地研究它。面试单独处理，投特定岗位前花少量时间熟悉简历里容易被追问的内容。
它还比较了三个方向：传统前端技术深度仍有招聘价值，但不一定要以研究框架底层为目标；AI Agent 工程化我已经有实践，但工具能力正在快速普及；产品审美与交互体验更符合我的兴趣，值得深入，但需要形成独特、可证明的成果。它倾向第三个。它也说，如果未来 AI 真能完成大部分软件设计与实现，行业可能不再需要那么多纯粹实现功能的工程师，但不建议我因此放弃找实习，真实团队里的用户、需求、协作和交付约束，是个人项目给不了的。
这一轮最后，它问了我一个问题：
假如从明天起，AI 可以帮你把任何想做的网站都完成到技术上几乎无可挑剔的程度，你最想继续亲自参与的部分是什么？
我当时没有回答，接着聊的是下篇里的事。现在的回答写在下篇最后。
我现在怎么想#
这两轮里 GPT 的修正，我大部分接受，但有几处到现在我的想法也和它不一样。
WebSocketClient 那段代码其实是我自己写的，只是写完以后很久没再用，细节就忘了。写这篇时我回头看了一眼现在留下的那份代码，才发现它和我印象里的不太一样：消息按类型分发给订阅的组件，断线后固定等 3 秒重连，没连上时要发的消息每隔 1 秒重试一次；之前的版本好像有心跳，这一份里已经没有了。现在和 AI 聊几句，我确实能重新捡起来。但这种程度的理解，非科班的人多问 AI 几句也能做到，所以我不觉得它说明我过度依赖 AI，也不觉得它能算竞争力。
八股我还是不太想准备。按目标公司少量准备、当作求职成本，我可以接受。网上 24、25 年的文章大多说八股必考，我这几个月面下来，真正考八股的只有一次，其他基本是聊天。
MaintPilot 我还会写在简历上，也会照实说代码基本是 Codex 写的，我没怎么看过。我不觉得这有什么问题：现在这样开发的项目，本来就很少有人逐行去看代码，都是让 AI 自己迭代、自己验证。所以这个项目能说明的，是我和同学协作的能力，以及用 AI 开发的经验；真问到技术细节，我答不出来。这又回到了第一轮的问题：如果大部分代码由 AI 写、由 AI 验证，该怎么衡量一个程序员的开发能力？这两轮没有回答它，我现在也回答不了。
“人负责判断”这件事，我的想法也在变。之前排查一个异步任务重复扣费的问题，我只给 AI 描述了现象，给了客户的外部 ID 和客户信息，它就自己去查数据库，找到了原因。“知道该查什么”这一步，用自然语言描述就能交给 AI。剩下的似乎只有“有人先发现了问题”，但以后用户发现问题，直接在群里 @ 一个机器人，机器人自己去查、去修，也不难想象。我现在还不放心这样做：它修好一个 bug 之后，可能没经过详细的测试，就直接把新版本部署上线、替换旧版本，带出更多问题。但如果模型能力和 Agent 的工作编排再强一些，改出来的东西更好，一次就改对，我就会更放心。到那时，离用户最近的也许就是这个机器人。