我发现自己代码几乎都由 AI 实现了，整体提效却只有 30% 左右。而这一年，市面上很多独立的前端部门正在被撤销，团队并进后端或 AI 全栈。带着这两件事，我在 VueConf 2026 当面请教了尤雨溪。
过年那阵我在读比尔·盖茨的《源代码》。计算机的出现、互联网的普及，每一次都有新的机会涌现——有人抓住了，有人错过了。所以我在想：AI 这次，我能不能抓住？年后开始做 Agent Platform，就是从这个念头来的。
紧接着是另一件事：不少大厂开始动前端的组织架构——独立的大前端部门被撤销，前端团队并进后端或 AI 全栈部门，岗位重新叫「全栈」，甚至叫「Agent 工程师」。我身边就有朋友真实地经历了这些。那段时间我确实很急迫。
一边是想抓住的机会，一边是怕被淘汰。所以参加 VueConf 2026 时，我带着一个很现实的困惑：当 AI 接手越来越多实现工作，我们过去积累的前端能力还有多少价值？接下来应该继续深挖前端，还是沿着 AI 向其他领域走？
从早餐桌上的闲聊，到大会现场、晚宴，再到会后的交流，我主动找沈老师、dw、e0、soda 讨论。最后，我把这个问题当面问了 Vue 作者尤大——他的回答只有两个方向，却把我这一年零散的实践串了起来。
本文以 VueConf 当天的交流为起点，也补入了会后的讨论和个人实践。这一篇记的主要是聊了些什么、我从中得到了什么；技术细节留到系列后续文章展开。
现场对话根据当天记录与事后回忆整理，并非逐字记录：他人观点多为转述，引用块用于标出各自说过的话及其大意。
VueConf 2026，演讲结束后与尤大合影。文章开头那个问题，是当天晚宴上才问出口的。
0. 我问尤大：前端该怎么适应 AI，又能抓住什么机会？
晚宴吃得差不多后，我终于找到机会开口：
尤大，有个问题想和您请教一下，不知道您方便吗？
他答得很干脆：
ok，当然没问题。
于是我把那个憋了很久的问题问了出来：
AI 对前端的冲击很直接，很多人都在担心前端会不会被做掉，尤其是中高级前端会不会被替代。您觉得我们该怎么适应 AI，又能抓住什么机会？
我原本只准备听一个简短回答，他却讲得很完整。
他没绕弯子：
你说的没错，AI 会缩小经验年限带来的一部分差距。一个刚入行的人借助 AI 也能做出不错的东西，离五年经验的人没那么远了。
但他紧接着把这件事翻了过来。他讲得很投入，边说边比划着：AI 是加速器，它不只让后面的人更快接近你——你同样可以用它变强、快速提升自己，去追上原本远远走在你前面的人。
我愣了一下：
对啊，我光担心被追，没想过自己也能追。
他说对。既然每个人手里都有同一个加速器，优势就不再来自你比别人多走了几年：
真正的优势，是看你能不能比别人更会用它。
那过去那些年积累的东西还算什么？他的意思是，它们不会凭空消失：你的工程经验、项目经验、认知和判断力依然很有价值，关键是要主动用 AI 去放大它们，而不是让它们闲置。
说到这里，他反过来问我：
你现在对 AI 掌握得怎么样？
我提到自己在公司推进 AI 落地，也去新加坡做过一次关于 Agent Platform 的路演。他说这个方向没问题，更值得继续想的是 AI 对业务开发和个人成长意味着什么，以及怎样主动把控方向。
前面提到的那些变化，不是个例——有朋友所在的前端团队被并进了 AI 或全栈方向，原本的前端架构组也做了调整。所以他给出第二个方向时，我听得格外仔细：
不要把自己限定成前端。AI 时代，其实没有「前端工程师」，只有工程师。你要尽量扩大自己的能力圈，向全栈发展。
我当时的理解还停在工程范围里，于是追问了一句：
全栈？您是说向后端、测试、运维这些部分发展吗？
不只是后端服务，还包括数据库、测试这些，甚至设计和产品，你都可以尝试去做。除了各领域真正高深的部分，很多基础和常规能力，你都能在 AI 的辅助下更快理解、学习和实践。
他把范围划得比我问的更宽——我以为「全栈」还是在工程里打转，他直接把设计和产品也放了进来。
听完后，我把自己的理解复述了一遍：
我这样理解，对吗？
没问题。
我当场把这两句话记进了微信。
晚宴现场。画面后方正在比划的就是尤大，上面那段对话就发生在这个时候。图源：VueConf 2026 官方摄影。
方向听起来很清楚，真正做起来仍有几个绕不开的问题：AI 到底提高了什么效率？把大量代码交给它以后，人靠什么保持掌控？如果前端只是起点，我们下一步究竟应该向哪里走？
1. 代码快了 90%，为什么我只快了 30%？
VueConf 现场，我和沈老师、dw、e0、soda 都聊到了各自的提效体感，判断很接近：AI 显著提高了代码生成速度，复杂项目的总成本却没有按相同比例下降。
沈老师正在做一个给团队提效的 Agent，聊到进展：
已经打磨了三四版，每一版都有收获，但离真正稳定落地还需要时间。
我们几个手里都有正在推进的 AI 项目。这一年很多公司在 AI 上的投入越来越大，而真正把它用进工程的人，做法反而越来越克制。
Vue 核心团队成员、曾主导 Vue CLI 维护的 soda（蒋豪群） 提到了一个反差很大的体感：
现在可能只需要原来 10% 的时间生成代码，却需要原来 2～3 倍的精力复核。
AI 在 Demo 和边界清晰的任务上表现很好，进入复杂工程以后，如果开发者自己缺少相关知识，就很难判断它究竟做对了没有。
Agent 写下了我 90% 的代码，但只看 Coding 阶段，我自己的提效体感大约只有 30%。 剩下那部分卡在哪儿？
把 soda 的体感和我自己的经历放在一起，我后来才意识到，我们谈论“AI 提效”时，经常混用了三种不同的效率：
- 代码生成效率
- 个人任务效率
- 组织交付效率
分清这三层，前面那个 90% 和 30% 的差额也就有了去处：它并没有消失，而是从第一层转移到了第二、三层——代码生成变快了，设计、判断、验收和团队共识并没有跟着变快；会议、沟通和对齐这些真正吃掉时间的环节，AI 目前一点也帮不上。
最容易被看见的是第一层，企业真正关心的却是第三层——产品有没有更快更稳地交付。
2. 不写代码，就等于失去掌控吗？
现场聊到各自怎样使用 AI 时，我才发现，自己的 90% 并不算激进。
Vue 组织成员、前端开源开发者 e0（Justineo） 说得最直接：
我已经不再使用传统编辑器，代码 100% 交给 Codex 完成。
soda 还保留着编辑器，但也已经很少手写代码：
我正在刻意训练自己别太早看代码，免得一上来就陷进实现细节。
我听到后很惊讶：如果连代码都不看，自己会不会失去对细节的控制？
soda 强调的是介入的时机。过早进入局部细节，容易让人忘掉真正要解决的问题——但在权限、资金、数据迁移这类高风险改动里，读代码依然必要。
Vue Vine 作者、同样在重度使用 Agent 的 沈老师（沈青川） 把话题落到了责任上：
AI 可以生成代码，结果出了问题，责任还是得由人承担。
Vue 与 VueUse 核心团队成员 dw（Doctor Wu） 的关注点更靠前：代码生成已经很快了，关键是 AI 拿到的信息够不够、最后的结果靠不靠谱。
几个人的工具、习惯和交出去的比例都不相同，方向却一致：实现交给 AI，问题定义、设计和验收自己守住。
回头看，自己经历了三个阶段：先是不信任 AI，再是过度信任 AI——做 mo-code（我从零实现的一个 mini Claude Code）时虽然前期有过设计，一次堆进去的功能还是太多；东西确实做出来了，我却很难说清里面的每个决定。
现在是第三阶段，有保留地信任 AI：先把需求和设计想清楚，再让 AI 实现。一个任务对应一个提交，提交前认真检查和验收。AI 可以负责实现，目标和关键决定仍由我确认，最终结果也由我承担。
“有保留地信任”需要把人的判断放到实现之前——沈老师现场提到的 Grill Me、体系化和决策树就是一套具体做法。
真正的掌控不在写下多少代码，而在：
- 问题定义
- 关键决策
- 边界设计
- 偏离感知
- 结果验收
真正的风险，是人在交出实现的同时，也交出了判断。
3. 代码之外，我们还需要掌握什么？
当人的工作向决策和验收移动，我开始反过来想：实现之外，我们真正需要保留和继续培养的是什么？VueConf 当天的三段对话给了我一些答案。
我把“怎样保证 Skill 稳定执行”这个问题抛给 e0、沈老师和 soda。他们的回答几乎一致：
Skill 没办法像程序一样稳定执行。
沈老师后来又补了一句：
如果追求绝对稳定，就应该使用程序。
不能出错的逻辑，仍然要由代码和流程控制——这也与 Anthropic 对 Agent Skill 中确定性操作的建议一致。这条边界具体怎么划，是下一篇的事。
这种对边界的判断，在后来的微前端讨论里落到了一个很具体的问题上。此前公司微前端从调研到落地主要由我牵头，核心方案采用 micro-app 和 Module Federation。e0 突然问我：
你做的微前端，弹窗能居中显示吗？
弹窗居中本身不难，难的是它背后牵着基座与子应用的依赖方向。e0 只用一句话，就从一个视觉结果问到了架构边界。
早餐时，沈老师提到他现在经常要提醒 AI 不要写没有意义的“花瓶测试”。这和我正在做的组件库测试直接相关，我顺口说：
确实，我们用 AI 给组件库写了很多测试，真正抓到问题的却很少 😂
沈老师马上接了一句：
你这句话非常关键。是的，这就是 AI 安全的问题所在。
这三段交流指向了同一件事：AI 越能快速实现，人越需要提前说清哪些功能必须成立、哪些边界最危险、怎样才算真正完成。
而这些问题，没有一个是 AI 提醒我的——它们都是在和人聊的过程里冒出来的。
4. 前端只是起点，我们可以怎样继续探索？
把全天的讨论连起来以后，我发现“不要把自己限定成前端”其实有三个不同的走法。
- 向上，从实现走向决策与验收：先定义什么算完成，再用测试和 Eval 验证。
- 向外，沿交付链多走一层，缺哪一环补哪一环。
- 向内，从会用工具走到理解 Agent 到底怎么运转。
第三条我在会上就走了一次。聊到 Coding Agent 的实现时，e0 提到手写文件可能会破坏 AI 的缓存。我当场追问：
这是 Agent 真实的实现机制，还是一种感觉？
只是我的感觉。
他答得很干脆。会后我对照自己的实现，又查了一份 Claude Code 编辑机制的逆向分析，最后把这个问题拆成了两个：LLM 的上下文里有没有最新的文件，以及 Agent 的编辑工具怎样基于当前文件校验修改目标。带着这两个问题，我又找 e0 聊了一轮。
我自己的路径没有预先规划好的路线图，是在真实项目里一步步长出来的：
- 企业知识要按权限和时效喂给模型，于是从 RAG 起步；
- 重复出现的工作方式需要沉淀，推着我走向 Skill；
- 单个 Skill 撑不住复杂业务流程，问题又延伸到 Agent Platform 和工作流；
- 最近对 Coding Agent 的探索走回了工具内部——又回到了 mo-code。
每一步都来自上一个真实问题。所以这件事并不要求先选一个更时髦的职业标签，更有用的问题是：
我正在解决的真实问题，下一步要求我理解什么？
回到开头：当 AI 写完 90% 的代码，前端还剩什么？ 我的答案是——理解 AI 的能力、机制和边界，把目标、关键决策和验收责任留在自己手里。前端可以是起点，不必是围栏。
你现在会把多少代码交给 AI？交出去以后，又靠什么保持对结果的掌控？
下一篇
本文是「交给 AI 之后」系列的第一篇。
现场我把“怎样保证 Skill 稳定执行”抛给几个人时，得到的回答几乎一致：Skill 没办法稳定执行。 那么，一个天生不稳定的东西，要怎样进入生产环境？
下一篇聊这件事。
