狠狠吐槽一下SSR/Next.js（三）：当“全栈”框架遇上“全懵”大模型-北京尧图网络

我们正处在一个“AI 什么都能写”的黄金时代。你让 ChatGPT 写一个贪吃蛇游戏它秒给。你让 Claude 写一个完整的博客系统它分分钟给你整出一个能跑的项目。你让 Copilot 自动补全一个复杂的排序算法它甚至还能给你优化一版。——直到你把这些 AI 工具丢进一个 Next.js 项目里。然后你会发现这些在编程题上呼风唤雨的大模型在 Next.js 面前集体“降智”了。它们开始在 Server Component 里生成useState在 Client Component 里生成getServerSideProps把fs.readFileSync写进了一个会被客户端打包的 util 文件在use client组件顶部 import 了一个只在服务端可用的数据库 ORMAI 不是笨它是真的分不清。因为它面对的不是一段“前端代码”或一段“后端代码”——它面对的是一锅粥。一、为什么 AI 分不清——因为它没有“环境感知”能力让我们先理解一个根本问题AI 是怎么写代码的大模型的工作方式简单来说就是——根据上下文预测下一个 token。它看到一个import { useState } from react根据海量训练数据它会“知道”后面大概率跟着一个函数组件里面会有const [state, setState] useState()。这是一种模式匹配而不是环境理解。在传统的 React 项目里这种模式匹配准确率极高。因为所有代码都跑在同一个环境浏览器里AI 不需要判断“这段代码是在哪里执行的”它只需要判断“这段代码的语法对不对”。但在 Next.js 里这个假设崩溃了。同一个文件里AI 要同时处理构建时执行的getStaticProps请求时执行的getServerSideProps服务端渲染的组件顶层代码客户端水合时的组件首次渲染客户端交互时的onClick、useEffect服务端专用的 API 路由AI 看到了一个.tsx文件它只知道“这是 React 组件”。它不知道——这个组件的顶层console.log会出现在 Node.js 的终端里还是浏览器的 DevTools 里这个import的模块会被打包进客户端的 bundle还是只存在于服务器端这个if (typeof window ! undefined)判断是为了防止报错还是在暗示什么更深层的架构问题AI 没有“执行环境”的概念它只能看到文本。而 Next.js 的文本里混杂着两个世界的代码。二、“看起来能跑”的幻觉AI 最致命的温柔陷阱这是最可怕的一点AI 给 Next.js 生成的代码经常“看起来完全正确”但一跑就崩。比如你让 AI 帮你写一个“从数据库读取文章列表”的页面。AI 非常“贴心”地给你生成了这样的代码tsx// pages/articles.tsx import { useState, useEffect } from react; import db from ../lib/database; // ← 这个 db 用了 Node.js 的 fs 和 path 模块 export default function Articles() { const [articles, setArticles] useState([]); useEffect(() { // 在客户端获取数据 const fetchData async () { const result await db.query(SELECT * FROM articles); setArticles(result); }; fetchData(); }, []); return ( ul {articles.map(article li key{article.id}{article.title}/li)} /ul ); }你看这段代码语法完全正确逻辑完全通顺AI 写得毫无破绽。然后你npm run dev浏览器直接给你一个Module not found: Can’t resolve ‘fs’——因为db模块用了fs.readFileSync而浏览器里根本没有fs这个模块。AI 的问题出在哪它看到useEffect知道这是客户端代码它看到db.query知道这是数据库操作。但它不知道你把数据库操作和客户端 Hooks 写在了一起会导致db模块被客户端打包。AI 生成了一段在“逻辑层面”正确的代码但在“环境层面”完全错误的代码。而最要命的是——你自己可能也没看出来直到编译报错。三、AI 的“补偿策略”绕开 Next.js绕开 SSR随着 AI 被越来越多地用在 Next.js 项目里一种诡异的“进化”正在发生。AI 在学会用 Next.js 之前先学会了“绕过 Next.js”。具体来说当 AI 遇到一个 Next.js 项目时它会倾向于生成“尽量不依赖 Next.js 特性”的代码宁愿用useEffect fetch客户端获取数据也不用getServerSideProps宁愿把所有组件都加上use client也不去区分服务端/客户端宁愿用window.localStorage加typeof判断也不碰 Next.js 的cookies()宁愿写一个/api路由再用客户端fetch去调也不在 Server Component 里直接操作数据库AI 在主动选择“更通用”的写法因为那些写法在训练数据里更常见、更稳定、更不容易出错。翻译成人话就是AI 觉得 Next.js 的那些“独家特性”太难搞了用普通的 React 写法更省事。你掏钱买了 Next.js 的“全栈”能力结果 AI 帮你写出来的代码全是“纯客户端 React 独立 API 路由”。那你的 SSR 呢你的 SEO 优化呢你的首屏性能呢——被 AI 为了“不出错”而默默牺牲掉了。四、“混写”的终极惩罚AI 无法帮你 Debug前面几篇我吐槽过Next.js 的错误信息有多反人类。但更残酷的是当错误来自“服务端/客户端混杂”时AI 几乎无法帮你定位问题。来看一个真实案例。你的 Next.js 项目报了这个错textError: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.你把错误贴给 ChatGPT。AI 的典型回答“这通常是因为你的组件没有正确导出或者 import 路径有误。请检查你的 export default 和 import 语句。”你检查了没问题。你又贴了更多代码给 AI。AI 又猜“可能是循环依赖导致的。请检查你的模块引用关系。”你检查了也没问题。折腾了半小时你终于自己发现了真相你在一个 Server Component 里 import 了一个使用了use client的组件而这个组件的某个依赖库在服务端环境下导入时返回了undefined。这个错误的根源是“执行环境不匹配”而不是“代码语法错误”。而 AI 的思维方式是基于“文本模式”它能看到语法、看到 import/export、看到依赖关系但它看不到“这个变量在 Node.js 环境下是什么值在浏览器环境下又是什么值”。AI 的 Debug 能力在遇到环境相关的问题时基本等于零。五、当 AI 开始“建议”你加use client……然后无限套娃这是我现在最常看到的“AI Debug 鬼打墙”场景。步骤一你写了一个带useState的组件没加use client编译报错。步骤二你问 AI 怎么办。AI 说“在这个文件顶部加上use client。”步骤三你加了但这个组件 import 了另一个组件那个组件里用了fs模块。报错“fsis not available in the browser.”步骤四你问 AI 怎么办。AI 说“把那个用了fs的逻辑移到getServerSideProps或 API 路由里。”步骤五你移了但数据传递方式变了组件接收的 props 类型不匹配。报错。步骤六你问 AI 怎么办。AI 说“调整 props 类型定义……”你发现了吗AI 在带着你做“问题迁移”而不是“解决问题”。每修好一个环境相关的问题就会冒出一个新的环境相关问题。AI 就像是面对一个漏水的破船它帮你堵住了左边的洞水从右边冒出来了堵住右边水从底下冒出来了。因为它没有一个整体的“环境架构图”。它看不到你的代码在不同执行环境之间的流动路径它只能“头痛医头脚痛医脚”。最后AI 会给出那个“终极建议”“如果你遇到持续的环境相关问题可以考虑禁用 SSR使用dynamic(() import(./Component), { ssr: false })。”翻译过来就是“放弃吧别搞 SSR 了。用客户端渲染就行。”——你回到了原点。回到了create-react-app就能搞定的状态。而你为了 Next.js 付出的所有学习成本、调试时间、Token 费用全部打了水漂。六、一个可怕的推论AI 时代复杂的框架会被“降权”这不仅仅是一个技术问题这是一个生态进化的问题。大模型的训练数据本质上是对“人类公开代码”的统计学汇总。AI 更擅长生成什么代码写法统一的代码范式简单的代码环境单一的代码版本稳定的代码Next.js 恰恰在所有这些维度上都表现得很差。所以长期来看会发生什么AI 生成的 Next.js 代码质量越来越低因为混杂的环境让模型难以学到稳定的模式开发者用 AI 辅助 Next.js 开发的体验越来越差因为 AI 频繁出错需要人工反复修正开发者和 AI 都会“用脚投票”逐渐转向更简单、更纯粹的框架你可能会说“那 Vercel 可以专门训练一个 Next.js 专用模型啊”——这就是问题所在。当一个框架需要一个专用 AI 模型才能被“正常使用”时这个框架已经输了。好的工具应该降低人类和机器共同的心智负担。而不是反过来要求人类和机器都为它“特供”一套思维方式。结语给 AI 一条活路也给自己一条活路写到这里我其实有点替 AI 感到委屈。大模型被训练出来本来是为了帮助我们处理“重复性的、模式化的、低级的”编码劳动让我们把精力解放出来去思考真正的业务逻辑和架构设计。结果在 Next.js 项目里AI 把大量的算力消耗在了“判断这段代码到底跑在哪”这个无聊的问题上。它是一个 Server Component 吗它需要use client吗这个 import 在客户端安全吗这个环境变量能暴露给浏览器吗这个 Hook 在服务端会报错吗AI 那几千亿的参数被 Next.js 用在了玩“猜猜我在哪”的游戏上。这不是 AI 的无能这是框架的失败。所以我的最后建议是如果你想让 AI 成为你的得力助手请选择一个它不需要“猜”的框架。让服务端代码待在服务器文件夹里让客户端代码待在浏览器文件夹里。清清楚楚明明白白。AI 一眼就能看懂的代码才是好代码。AI 不用猜就能生成的代码才是未来。

狠狠吐槽一下SSR/Next.js（三）：当“全栈”框架遇上“全懵”大模型

相关推荐

EM3080-W工业级条形码扫描模块与PIC18微控制器集成指南

FFT频谱分析 3 大常见误区解析：从幅值校正到频率混叠

锂离子电池组主动均衡系统设计与实现

更多资讯

房建电工证是什么？外省证怎么转？考前押题帮你拿证快人一步

电工证入国家安监局考试真题与备考技巧，全国通用怎么操作？

在宾阳县有电工证培训多少钱转外地证能通用吗

电工作业许可证考证怎么考通过率揭秘学历不高也能过

电工证过期了不知道怎么复审？凤阳考电工证在哪有真实经历可参考

类乌齐电工证培训机构怎么网上查询报名流程与避坑指南

今日更新

电工证考试及格线你知道多少？值不值得考

南通电工证发证单位考前押题怎么搞？工地太忙根本没时间复习考试

黄陵县高低压电工证怎么考？上岗必备全流程避坑指南

本周精选

安监局电工证分数查询怎么查才能知道含金量高不高

新疆电工作业干活累吗良心建议助你避开考不过的坑

中牟县电工证怎么报名外省证能转吗

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？