（来源：图灵人工智能）

转自51CTO技术栈，仅用于学术分享，如有侵权留言删除

编辑 | 姜篇

　　肯特：我仍然认为开发者有很多东西要学，但框架已经不是最重要的了。

　　肯特：练习编程时，不要为了“学得扎实”就关掉AI助手。你将来就是这样工作的；工具写完之后，你还得弄懂它做了什么。

　　肯特：代码生成得更快，不代表用户体验会跟着变好。软件仍然需要真正在乎用户体验的开发者。

　　肯特谈起自己的变化：过去花一年打磨一门课，发布后能教很久；现在Agent的用法几周就换一次，课程还没做完，部分内容可能已经过时。他甚至认真想过，接下来到底该教开发者什么。

　　说这些话的，是Epic React课程作者肯特·C·多兹。

　　现在Agent的用法几周就可能变一次。他开始担心，课程还没录完，讲工具操作的部分已经过时了。一个教React多年的人，为什么开始说“框架不是重点”？

　　肯特并没有说React不用学，也没有劝新人跳过编程基础。

　　主持人问，初学者练习时是不是该关掉AI，自己把代码一行行敲出来。肯特说不必：开发者在真实工作中已经在用AI，练习也该接近真实工作。难处在后面。Agent交出一个能运行的页面，你是否看得懂它怎样处理状态、哪里可能出错，需求变了又该从哪儿改起？

　　访谈中还有一个让开发者无法回避的例子。主持人用过一款点餐应用，页面卡住，最后连订单都没下成。他问肯特：写代码的工具越来越快，为什么用户用到的软件没有同步变好？

　　肯特也没有把故障归咎于AI。他说，团队写完页面，还得有人把整条流程走通。用户下不了单，再漂亮的组件也交不了差。

　　这也是肯特如今更想教“产品工程”的原因。他所说的产品工程，是把想让用户完成的事，和软件具体怎样实现、怎样验证连起来。

　　访谈的最后，话题走到了前端更远的地方。如果Agent能替人操作软件，网页还要不要做？肯特的回答是要。有些任务交给Agent方便，但有些时候，人就是想看清有哪些选择，或者直接按下一个停止按钮。

　　从学React、用AI写代码，到用户能不能下单、界面要不要保留，肯特谈的是同一份工作的不同环节：生成页面只是其中一步。当这一步越来越快，开发者仍得知道页面为什么这样工作，以及用户能不能靠它把事情办成。

　　以下根据访谈整理。

　　教React的人，先被自己的课程问住了

　　肯特做技术教育多年，习惯用很长时间准备一门质量高的课程。Agent起来后，这种节奏首先让他难受：工具变得太快，讲某个版本、某种操作流程，可能刚录完就要重录。

　　肯特：我可能花一年准备课程，等发布时，它已经过时了。我得想想，有什么东西能让开发者学会以后，过一年仍然有用。

　　主持人说，自己以前常听肯特讲React、Hooks和`useEffect`，现在这些话题少多了。

　　肯特接过话：我仍在做教育，也相信开发者还要学习，但自己不想把下一个重点继续放在框架上。

　　他把方向转向“产品工程”：从用户想得到的结果出发，设计能实现这个结果的系统。

　　肯特：产品工程要连接两件事：产品希望达成什么结果，以及技术上怎样把它做出来。只把实现交给Agent，还不等于把这两件事接上了。

　　“产品工程”

　　工程师还得决定订单状态什么时候更新、支付失败怎样返回、重复点击会不会多扣钱，以及该用什么测试确认这些路径。

　　学React时要不要关掉AI？肯特说不要

　　主持人接着问到新人学习：练习时该不该关掉AI助手，逼自己把每行代码写出来？肯特的答案是不要。他认为练习应接近以后真实工作的样子，而真实工作已经在用这些工具。

　　肯特：不要关掉AI助手。你将来就是这样编程的，练习时也该用它。但它替你写完之后，你仍要弄明白发生了什么。

　　他回忆，早期的代码补全会直接把练习题写出来，他还能要求学生停下来读懂。后来工具变成对话式Agent，甚至开发者自己也不再逐行看代码，原来的教学方法就不好用了。

　　肯特：新人成长为资深工程师，并不是因为把语法敲了足够多遍，而是因为开始处理资深工程师处理的问题。

　　但他紧接着说：碰到架构和技术取舍时，仍要思考，弄懂底层为什么这样工作。

　　对前端开发者来说，这个区别并不抽象。Agent会替你写一个带搜索框的React组件；你仍要知道搜索请求何时发出、旧请求回来会不会覆盖新结果、页面重载后状态是否丢失。不会背出每个Hook的API，和完全看不懂页面行为，是两回事。

　　代码快了，为什么用户还是点不了餐

　　主持人讲了自己的经历：在一款点餐应用里，页面卡住，他没法完成下单。他问肯特，工程师有了更强的AI，为什么用户体验没跟着变好？

　　肯特：代码能很快生成，不代表好的用户体验也能很快产生。团队仍然需要真正在乎用户体验的开发者。

　　他没有把这次故障归咎于“AI写错了代码”。他的意思是，写代码这一步快了，团队也不能跳过用户真正走的那条路径。肯特给了一个很具体的办法：让Agent定期像用户一样下单，或者把这条检查放进发布流程。下不了单，就别发布。

　　下次让Agent改一个页面，除了检查组件能否渲染，团队还可以拿真实任务走一遍：网络慢时能不能继续操作，提交失败后能不能重试，用户按回退键会不会丢掉刚填的内容。页面在开发环境里看着正常，不等于这条路走得通。

　　别等AI写完，再临时找另一个AI挑错

　　主持人继续追问：AI能产出更多代码，质量是不是更难守住？肯特把问题往代码库里推了一步。一个老项目如果到处是过时写法和不清晰的边界，Agent会照着现有代码继续写。之后再加一道AI审查，可能只能反复清理同一种问题。

　　肯特：让AI审查员拦住烂代码是一回事；让Agent从一开始就不产出这些代码，是另一回事。后者需要把它工作的环境先整理好。

　　“事后审查”与“从源头减少烂代码”

　　他把这套基础叫作`primitives`。

　　通俗讲，就是Agent在项目里现成可用、也容易用对的东西：稳定的组件和接口、清楚的错误处理方式、能跑起来的测试，以及一眼可见的代码惯例。整理这些东西很花工夫，但同一个项目里的下一次改动也会受益。

　　前端团队可以先挑一条高频流程来测试：例如登录或下单。让Agent照仓库现有方式改一处，然后记录它在哪一步猜错了状态、复用了哪个坏模式。修掉那处公共做法，比每次都在提示词里解释“这次千万别再犯”更有用。这是我们从访谈延伸出的实践建议，不是肯特给出的统一实施清单。

　　Agent能替人操作软件，界面还要不要做

　　聊到未来的前端，主持人担心：如果用户只需开口让Agent办事，网页会不会越来越不重要？肯特否认“界面已死”。

　　肯特：界面仍然重要。有时我就想按一个停止按钮，不想先对Agent说一句“现在停”。但查数据、执行一些重复操作，自然语言可能比一层层点页面方便。

　　他设想，有些软件会同时提供两种入口：人可以直接看和操作界面，Agent也能通过API或MCP调用功能。

　　做前端的人不能只问“这个页面用什么框架写”，还要问用户什么时候需要看见、比较和控制，什么时候只想把事情交代出去。这是他谈界面去向时留下的一个具体问题，不等于所有产品都该把页面改成聊天框。

　　写在最后

　　肯特在访谈里说“框架不是重点”，并不是让开发者扔掉React。眼前的项目照样要维护，页面照样要有人做。他担心的是，工程师把“会写某套语法”当成工作的终点，等Agent也会写了，却没想过用户到底能不能把事办成。

　　访谈结束后，我记住的是那个没法完成的订单。代码生成得再快，用户如果仍卡在提交按钮前，前端工作就还没做完。