开篇当 AI 开始计算框架税过去三年有无数文章分析Next.js的好处更好的SEO更快的首屏更全栈的能力但没人计算过一件事使用Next.js的隐性成本。学习成本新成员上手要多久调试成本一个水合错误要花多少小时升级成本major版本迁移要几个sprint工具成本AI写错的代码要人工改几次这些成本在人类开发者主导的时代被当做不可避免的工程开销默默承受了。但在AI时代这些成本突然被放大了10倍。因为AI会加速一切包括你的错误。你用AI生成代码速度翻倍 → 生成错误代码的速度也翻倍你用AI调试效率提升 → 发现环境问题的效率也提升你用AI重构的频次增加 → 遇到破坏性变更的频次也增加AI是一面放大镜把Next.js所有隐性问题照得清清楚楚。今天我们就来盘点那些在AI时代变得格外扎眼的Next.js新槽点。槽点一Token 税——每个 Next.js 特性都在烧你的钱在AI时代Token就是金钱。你用Cursor、Copilot、ChatGPT每一次对话都在消耗Token。Token消耗越多你的时间成本、API费用、订阅费就越高。现在我们来算一笔账让AI理解一个Next.js项目需要多少Token1. 上下文污染要让AI正确生成Next.js代码你需要给它提供text- next.config.js 配置至少200行 - tsconfig.json 配置至少50行 - .env 变量列表至少20个变量 - 项目路由结构几十个文件路径 - 用的什么RouterPages还是App - 版本号12、13还是14 - 用了哪些额外库tRPC、Prisma、NextAuth...这些信息塞进AI上下文至少消耗2000-5000 Token。每次对话都要重复。2. 反复纠错的轮回税普通框架AI生成代码 → 跑通1-2轮对话Next.jsAI生成代码 → 报错 → 贴错误 → AI修改 → 报另一个错 → 贴错误 → AI再修改 → 又报错 → 发现是环境问题 → 手动改 → 勉强跑通5-10轮对话每轮对话都是Token。Token就是时间。时间就是钱。我们做个保守估算场景普通框架Next.jsToken浪费倍率生成一个列表页500 tokens2000 tokens4x修复一个数据获取bug300 tokens1500 tokens5x升级依赖版本100 tokens3000 tokens30x新人上手第一个功能1000 tokens8000 tokens8x你用Next.js就等于在AI时代主动给自己加了一个消费升级的buff。你的Token账单比人家贵3-5倍效率还更低。这不是全栈这是全贵。槽点二文档分散——AI 的训练数据落后于版本大模型的知识截止日期是它的天花板。GPT-4的知识截止到2023年10月。Claude 3.5到2024年4月。而Next.js呢2022年10月Next.js 13 发布App Router来了2023年5月Next.js 13.4Server Actions稳定2023年10月Next.js 14Turbopack推进2024年5月Next.js 15React 19 集成…Next.js的迭代速度超过了AI模型的更新速度。这意味着什么场景一AI给你生成了不存在的API“用next/router的useRouter来处理App Router的动态路由。”——错。App Router要用next/navigation的useRouter。“用getServerSideProps在Server Component里获取数据。”——错。Server Component里直接async function就行。“用next/head来设置页面标题。”——错。App Router用export const metadata。AI的训练数据里塞满了老版本的信息它分不清哪个API属于哪个版本。你让AI帮你写代码结果它把考古的工作甩给了你。场景二AI给你跨版本混搭这是一个真实案例。我让AI把一段Pages Router代码迁到App RouterAI给出的代码里同时出现了getStaticPropsPages Router语法export const metadataApp Router语法import { useRouter } from next/routerPages Router语法一个用了use client的组件App Router语法它把两个世界的写法熔合在了一起。然后我告诉AI“这是一个App Router项目不要用Pages Router的API。”AI回答“抱歉我混淆了。下面是修正后的版本…”然后它又引入了第三个版本的写法。AI不是笨是Next.js的版本碎片化把AI搞分裂了。场景三AI的版本选择恐惧症你问AI“Next.js里怎么设置动态路由”AI会给你列出Pages Router方式pages/[slug].jsgetStaticPathsgetStaticPropsApp Router方式app/[slug]/page.jsgenerateStaticParamsgenerateMetadata还有一种古老的方式pages/[slug].jsgetServerSideProps在Pages Router里然后AI说“请根据你的项目版本选择合适的方案。”你在用一个AI诊断你的版本而不是写代码。这不叫AI辅助编程这叫AI帮你做选择题——还是多选题。槽点三Prompt 复杂度爆炸——你要先成为Next.js架构师才能用好AI在普通框架里你给AI的prompt可以很简单“帮我写一个展示商品列表的页面”AI就能生成。在Next.js里你的prompt必须武装到牙齿“帮我写一个展示商品列表的页面。用的是Next.js 14App RouterServer Component模式。不需要’use client’数据从Prisma读取用async函数获取。不要用getServerSideProps那些是Pages Router的写法。路由在app/products/page.tsx。页面SEO用export const metadata来配置不要用next/head。如果有加载状态用Suspense处理…”你看到了吗一个简单的页面你要在prompt里写清楚框架版本14路由模式App Router组件类型Server Component数据来源Prisma获取方式async函数废弃API避免getServerSideProps文件路径app/products/page.tsxSEO方式export const metadata加载状态Suspense你的认知负载没有降低反而从自己写代码变成了指导AI写代码——而指导本身需要同样的知识。你问“那我不写这么多让AI自己判断呢”AI会给你一个大杂烩代码包含所有版本的写法然后你需要自己去筛选哪个能用。这等于你把写代码变成了审代码——后者可能更累。槽点四AI Code Review 失效——连工具都不知道正确是什么在现代软件开发里AI Code Review代码审查已经越来越重要。工具会自动检查你的代码有没有安全隐患有没有性能问题有没有违反最佳实践但面对Next.js的代码AI Code Review工具基本瞎了。为什么因为正确的Next.js写法取决于太多变量这个文件是用Pages Router还是App Router这个组件是Server Component还是Client Component这段代码在哪个版本里是正确的这个模式是在新版本里推荐还是在旧版本里必须AI Review工具没有版本感知也没有路由模式感知。它会给你一个通用的建议比如“不建议在getServerSideProps里使用客户端Hook。”——如果这是App Router项目根本没有getServerSideProps。建议无效。“建议使用Image组件替代img标签。”——但如果是在一个Server Component里Image组件的某些用法已经变了。你收到的最佳实践建议有一半是错的。这导致开发者开始忽视AI Review工具的建议“每次都不准”团队内部的约定超过工具的建议“我们按自己习惯来”最终回到人工Review时代效率倒退AI时代的Code Review自动化在Next.js面前形同虚设。槽点五代码生成的质量退化——AI 的平均化趋势在伤害你大模型的训练数据来自全世界的开源代码。它生成的不是最优代码而是最常见的代码average code。在普通React生态里最常见和最优相差不大。因为范式简单大家都那么写。但在Next.js生态里由于版本和模式的碎片化——最常见的写法往往是最安全的写法而不是最优的写法。AI倾向于生成什么用use client把所有组件都变成客户端组件因为这样不会出错用useEffect fetch代替getServerSideProps因为这样不会涉及服务端环境问题用any类型代替精确的类型因为这样不会触发类型冲突用typeof window ! undefined到处添加判断因为这样能防止水合报错这些写法安全吗安全。这些写法正确吗正确。这些写法高效吗——不高效。它们抹掉了SSR的所有好处把Next.js用成了一个更慢的React。AI在教你如何绕过Next.js而不是用好Next.js。因为绕过在训练数据里更多用好的训练数据太少不同的版本、不同的模式很难形成统一的模式。AI的平均化特性会让你的Next.js代码变得越来越平庸越来越凡俗越来越像普通的React甚至不如普通React。槽点六自动化测试的噩梦——AI生成的测试永远在挂科在AI时代自动生成单元测试和集成测试已经是标配。但面对Next.js的代码AI生成的测试用例失败率极高。为什么原因一组件需要环境模拟tsx// 这个组件里哪些逻辑在服务端跑哪些在客户端跑 // 测试用例要在哪个环境里跑 export default function Profile({ user }) { // 这个useEffect里访问了window useEffect(() { localStorage.setItem(lastVisit, Date.now()); }, []); // 这个函数在客户端执行 const handleClick () { fetch(/api/profile); }; // 这段JSX在服务端和客户端都执行 return div{user.name}/div; }AI生成的测试用例如果用了jsdom模拟浏览器环境那么在测试getServerSideProps时会失败因为那里没有window。如果用了node环境那么测试useEffect时会失败因为那里没有localStorage。AI不知道应该在哪个环境里跑哪个测试。普通框架测试全在jsdom里跑一直正确。Next.js测试要在不同环境里分片跑AI完全搞不定。原因二路由依赖难以模拟AI生成的测试经常依赖next/router或next/navigation的useRouter。但测试框架里怎么模拟useRouter怎么模拟getServerSideProps的context参数怎么模拟redirect和notFoundAI生成的模拟代码往往不完整导致测试报错。原因三API路由测试的连坐效应Next.js的pages/api或app/api里的代码依赖了前端项目的配置和依赖。AI想为API路由生成测试时它需要模拟整个Next.js的请求上下文设置正确的环境变量初始化数据库连接处理前端配置一个API路由的测试要拉起半个项目。AI不会做这些。它只会生成一个简单的调用这个函数检查返回值的测试——然后失败。结果AI测试生成在Next.js里几乎不可用。你只能人工写测试。AI生成的10个测试有8个需要你大幅修改。AI在提升其他框架的测试覆盖率在Next.js这里AI在浪费你的时间。槽点七Coding Agent 的任务断裂最新的AI开发范式是自主编码Agent——给AI一个需求它会自动拆解任务生成代码运行测试修复错误提交代码这种Agent在Next.js项目里表现极差。为什么因为Next.js的环境跳跃导致Agent的任务链频繁断裂。一个典型场景Agent任务“给商品详情页添加一个’加入购物车’按钮。”步骤1Agent修改了app/product/[id]/page.tsxServer Component添加了一个按钮。步骤2但按钮需要useState来管理状态所以Agent把这个按钮拆成了一个Client Component加了use client。步骤3但Client Component不能直接用getServerSideProps获取数据所以Agent改成useEffect获取。步骤4但useEffect获取需要API端点所以Agent去app/api/cart/route.ts写了一个API。步骤5但API需要鉴权所以Agent去改了中间件Middleware。步骤6改了中间件后发现它影响了其他路由Agent需要回溯修改…Agent的任务链从加一个按钮分裂成Server Component修改Client Component创建API路由创建中间件修改回归测试一个简单的需求引发了5-6个文件的改动跨越了3-4种代码环境。Agent在不断的环境切换中丢失了任务的主目标。它会频繁卡住需要人工介入。普通框架纯ViteReactAgent加一个按钮 → 改一个文件 → 完成。Next.jsAgent加一个按钮 → 改5个文件 → 失败 → 你手动收拾残局。这哪里是AI替我写代码分明是AI给我制造了一堆新bug我来修。槽点八Vercel AI SDK——用AI掩盖问题的黑色幽默Vercel自己也意识到了AI的重要性。他们推出了Vercel AI SDK一个辅助开发AI应用的官方库。但我读他们的文档时看到了一个讽刺的现实“Vercel AI SDK is designed to work seamlessly with Next.js App Router, Server Components, and Server Actions.”翻译“我们的AI工具专门优化了Next.js最复杂的那些特性。”我理解他们想卖AINext.js的捆绑套餐。但这里有一个黑色幽默Vercel在用一个AI辅助库来帮助开发者跨越Next.js自身复杂性这座大山。你用一个工具去对付另一个工具制造的麻烦——而麻烦本来就不该存在。如果没有Server Components的复杂数据流为什么需要AI来优化数据获取如果没有App Router的混乱路由为什么需要AI来辅助路由管理如果没有SSR的环境分裂为什么需要AI来解析哪个代码在哪跑Vercel AI SDK的存在本质上就是一个补丁。他们在用AI来弥补Next.js在AI时代暴露的缺陷。“新AI工具解决旧框架问题”——这个逻辑本身就是对框架的控诉。总结Next.js的AI税清单最后我们来列一张清晰的AI税清单。你在Next.js项目里每用一次AI工具就要支付这些隐性成本税种描述成本等级Token通胀税上下文更大对话轮次更多⭐⭐⭐⭐⭐版本考古税AI的知识过时你负责版本校验⭐⭐⭐⭐⭐Prompt膨胀税每个需求都要写超长prompt来防呆⭐⭐⭐⭐代码平庸税AI生成安全但低效的写法⭐⭐⭐⭐测试失效税AI生成的测试大多没法用⭐⭐⭐⭐Agent断裂税AI Agent频繁卡住需要人工介入⭐⭐⭐⭐⭐工具失效税Code Review、自动重构全部打折⭐⭐⭐⭐这七项加起来AI给你带来的效率提升被税收抵消了50%-70%。你花着AI的订阅费用着AI的算力结果效率只提升了30%。而隔壁用ViteReact的团队AI把他们的效率提升了200%。这不是AI时代的问题这是在AI时代还用Next.js的问题。最后的最后AI的投票我们会继续看到AI的发展。但我们不需要靠预测来判断未来——看AI自己怎么说就行了。如果你问一个AI编程助手“推荐一个前端框架。”它的推荐会受到训练数据的影响。但如果Next.js真的那么好它应该天然地被AI推荐。实际上你如果问一个AI我现在用Next.js有什么更好的方案“它会给出ViteReact或Astro”。这不是AI在吐槽Next.js这是“AI在分析所有公开代码后的统计结果”。而统计学不会撒谎在AI时代代码越来越被AI生成和维护。一个框架如果能被AI轻易理解、生成、调试它就有长期的生命力。如果它让AI感到困惑它就会被逐渐边缘化。Next.js走在边缘化的斜坡上。不是因为人类不喜欢它而是因为机器不喜欢它。而在AI时代机器的意见权重越来越大。
狠狠吐槽一下SSR/Next.js(四):Next.js 的隐性成本正在被大模型掀翻
发布时间:2026/7/8 9:57:49
开篇当 AI 开始计算框架税过去三年有无数文章分析Next.js的好处更好的SEO更快的首屏更全栈的能力但没人计算过一件事使用Next.js的隐性成本。学习成本新成员上手要多久调试成本一个水合错误要花多少小时升级成本major版本迁移要几个sprint工具成本AI写错的代码要人工改几次这些成本在人类开发者主导的时代被当做不可避免的工程开销默默承受了。但在AI时代这些成本突然被放大了10倍。因为AI会加速一切包括你的错误。你用AI生成代码速度翻倍 → 生成错误代码的速度也翻倍你用AI调试效率提升 → 发现环境问题的效率也提升你用AI重构的频次增加 → 遇到破坏性变更的频次也增加AI是一面放大镜把Next.js所有隐性问题照得清清楚楚。今天我们就来盘点那些在AI时代变得格外扎眼的Next.js新槽点。槽点一Token 税——每个 Next.js 特性都在烧你的钱在AI时代Token就是金钱。你用Cursor、Copilot、ChatGPT每一次对话都在消耗Token。Token消耗越多你的时间成本、API费用、订阅费就越高。现在我们来算一笔账让AI理解一个Next.js项目需要多少Token1. 上下文污染要让AI正确生成Next.js代码你需要给它提供text- next.config.js 配置至少200行 - tsconfig.json 配置至少50行 - .env 变量列表至少20个变量 - 项目路由结构几十个文件路径 - 用的什么RouterPages还是App - 版本号12、13还是14 - 用了哪些额外库tRPC、Prisma、NextAuth...这些信息塞进AI上下文至少消耗2000-5000 Token。每次对话都要重复。2. 反复纠错的轮回税普通框架AI生成代码 → 跑通1-2轮对话Next.jsAI生成代码 → 报错 → 贴错误 → AI修改 → 报另一个错 → 贴错误 → AI再修改 → 又报错 → 发现是环境问题 → 手动改 → 勉强跑通5-10轮对话每轮对话都是Token。Token就是时间。时间就是钱。我们做个保守估算场景普通框架Next.jsToken浪费倍率生成一个列表页500 tokens2000 tokens4x修复一个数据获取bug300 tokens1500 tokens5x升级依赖版本100 tokens3000 tokens30x新人上手第一个功能1000 tokens8000 tokens8x你用Next.js就等于在AI时代主动给自己加了一个消费升级的buff。你的Token账单比人家贵3-5倍效率还更低。这不是全栈这是全贵。槽点二文档分散——AI 的训练数据落后于版本大模型的知识截止日期是它的天花板。GPT-4的知识截止到2023年10月。Claude 3.5到2024年4月。而Next.js呢2022年10月Next.js 13 发布App Router来了2023年5月Next.js 13.4Server Actions稳定2023年10月Next.js 14Turbopack推进2024年5月Next.js 15React 19 集成…Next.js的迭代速度超过了AI模型的更新速度。这意味着什么场景一AI给你生成了不存在的API“用next/router的useRouter来处理App Router的动态路由。”——错。App Router要用next/navigation的useRouter。“用getServerSideProps在Server Component里获取数据。”——错。Server Component里直接async function就行。“用next/head来设置页面标题。”——错。App Router用export const metadata。AI的训练数据里塞满了老版本的信息它分不清哪个API属于哪个版本。你让AI帮你写代码结果它把考古的工作甩给了你。场景二AI给你跨版本混搭这是一个真实案例。我让AI把一段Pages Router代码迁到App RouterAI给出的代码里同时出现了getStaticPropsPages Router语法export const metadataApp Router语法import { useRouter } from next/routerPages Router语法一个用了use client的组件App Router语法它把两个世界的写法熔合在了一起。然后我告诉AI“这是一个App Router项目不要用Pages Router的API。”AI回答“抱歉我混淆了。下面是修正后的版本…”然后它又引入了第三个版本的写法。AI不是笨是Next.js的版本碎片化把AI搞分裂了。场景三AI的版本选择恐惧症你问AI“Next.js里怎么设置动态路由”AI会给你列出Pages Router方式pages/[slug].jsgetStaticPathsgetStaticPropsApp Router方式app/[slug]/page.jsgenerateStaticParamsgenerateMetadata还有一种古老的方式pages/[slug].jsgetServerSideProps在Pages Router里然后AI说“请根据你的项目版本选择合适的方案。”你在用一个AI诊断你的版本而不是写代码。这不叫AI辅助编程这叫AI帮你做选择题——还是多选题。槽点三Prompt 复杂度爆炸——你要先成为Next.js架构师才能用好AI在普通框架里你给AI的prompt可以很简单“帮我写一个展示商品列表的页面”AI就能生成。在Next.js里你的prompt必须武装到牙齿“帮我写一个展示商品列表的页面。用的是Next.js 14App RouterServer Component模式。不需要’use client’数据从Prisma读取用async函数获取。不要用getServerSideProps那些是Pages Router的写法。路由在app/products/page.tsx。页面SEO用export const metadata来配置不要用next/head。如果有加载状态用Suspense处理…”你看到了吗一个简单的页面你要在prompt里写清楚框架版本14路由模式App Router组件类型Server Component数据来源Prisma获取方式async函数废弃API避免getServerSideProps文件路径app/products/page.tsxSEO方式export const metadata加载状态Suspense你的认知负载没有降低反而从自己写代码变成了指导AI写代码——而指导本身需要同样的知识。你问“那我不写这么多让AI自己判断呢”AI会给你一个大杂烩代码包含所有版本的写法然后你需要自己去筛选哪个能用。这等于你把写代码变成了审代码——后者可能更累。槽点四AI Code Review 失效——连工具都不知道正确是什么在现代软件开发里AI Code Review代码审查已经越来越重要。工具会自动检查你的代码有没有安全隐患有没有性能问题有没有违反最佳实践但面对Next.js的代码AI Code Review工具基本瞎了。为什么因为正确的Next.js写法取决于太多变量这个文件是用Pages Router还是App Router这个组件是Server Component还是Client Component这段代码在哪个版本里是正确的这个模式是在新版本里推荐还是在旧版本里必须AI Review工具没有版本感知也没有路由模式感知。它会给你一个通用的建议比如“不建议在getServerSideProps里使用客户端Hook。”——如果这是App Router项目根本没有getServerSideProps。建议无效。“建议使用Image组件替代img标签。”——但如果是在一个Server Component里Image组件的某些用法已经变了。你收到的最佳实践建议有一半是错的。这导致开发者开始忽视AI Review工具的建议“每次都不准”团队内部的约定超过工具的建议“我们按自己习惯来”最终回到人工Review时代效率倒退AI时代的Code Review自动化在Next.js面前形同虚设。槽点五代码生成的质量退化——AI 的平均化趋势在伤害你大模型的训练数据来自全世界的开源代码。它生成的不是最优代码而是最常见的代码average code。在普通React生态里最常见和最优相差不大。因为范式简单大家都那么写。但在Next.js生态里由于版本和模式的碎片化——最常见的写法往往是最安全的写法而不是最优的写法。AI倾向于生成什么用use client把所有组件都变成客户端组件因为这样不会出错用useEffect fetch代替getServerSideProps因为这样不会涉及服务端环境问题用any类型代替精确的类型因为这样不会触发类型冲突用typeof window ! undefined到处添加判断因为这样能防止水合报错这些写法安全吗安全。这些写法正确吗正确。这些写法高效吗——不高效。它们抹掉了SSR的所有好处把Next.js用成了一个更慢的React。AI在教你如何绕过Next.js而不是用好Next.js。因为绕过在训练数据里更多用好的训练数据太少不同的版本、不同的模式很难形成统一的模式。AI的平均化特性会让你的Next.js代码变得越来越平庸越来越凡俗越来越像普通的React甚至不如普通React。槽点六自动化测试的噩梦——AI生成的测试永远在挂科在AI时代自动生成单元测试和集成测试已经是标配。但面对Next.js的代码AI生成的测试用例失败率极高。为什么原因一组件需要环境模拟tsx// 这个组件里哪些逻辑在服务端跑哪些在客户端跑 // 测试用例要在哪个环境里跑 export default function Profile({ user }) { // 这个useEffect里访问了window useEffect(() { localStorage.setItem(lastVisit, Date.now()); }, []); // 这个函数在客户端执行 const handleClick () { fetch(/api/profile); }; // 这段JSX在服务端和客户端都执行 return div{user.name}/div; }AI生成的测试用例如果用了jsdom模拟浏览器环境那么在测试getServerSideProps时会失败因为那里没有window。如果用了node环境那么测试useEffect时会失败因为那里没有localStorage。AI不知道应该在哪个环境里跑哪个测试。普通框架测试全在jsdom里跑一直正确。Next.js测试要在不同环境里分片跑AI完全搞不定。原因二路由依赖难以模拟AI生成的测试经常依赖next/router或next/navigation的useRouter。但测试框架里怎么模拟useRouter怎么模拟getServerSideProps的context参数怎么模拟redirect和notFoundAI生成的模拟代码往往不完整导致测试报错。原因三API路由测试的连坐效应Next.js的pages/api或app/api里的代码依赖了前端项目的配置和依赖。AI想为API路由生成测试时它需要模拟整个Next.js的请求上下文设置正确的环境变量初始化数据库连接处理前端配置一个API路由的测试要拉起半个项目。AI不会做这些。它只会生成一个简单的调用这个函数检查返回值的测试——然后失败。结果AI测试生成在Next.js里几乎不可用。你只能人工写测试。AI生成的10个测试有8个需要你大幅修改。AI在提升其他框架的测试覆盖率在Next.js这里AI在浪费你的时间。槽点七Coding Agent 的任务断裂最新的AI开发范式是自主编码Agent——给AI一个需求它会自动拆解任务生成代码运行测试修复错误提交代码这种Agent在Next.js项目里表现极差。为什么因为Next.js的环境跳跃导致Agent的任务链频繁断裂。一个典型场景Agent任务“给商品详情页添加一个’加入购物车’按钮。”步骤1Agent修改了app/product/[id]/page.tsxServer Component添加了一个按钮。步骤2但按钮需要useState来管理状态所以Agent把这个按钮拆成了一个Client Component加了use client。步骤3但Client Component不能直接用getServerSideProps获取数据所以Agent改成useEffect获取。步骤4但useEffect获取需要API端点所以Agent去app/api/cart/route.ts写了一个API。步骤5但API需要鉴权所以Agent去改了中间件Middleware。步骤6改了中间件后发现它影响了其他路由Agent需要回溯修改…Agent的任务链从加一个按钮分裂成Server Component修改Client Component创建API路由创建中间件修改回归测试一个简单的需求引发了5-6个文件的改动跨越了3-4种代码环境。Agent在不断的环境切换中丢失了任务的主目标。它会频繁卡住需要人工介入。普通框架纯ViteReactAgent加一个按钮 → 改一个文件 → 完成。Next.jsAgent加一个按钮 → 改5个文件 → 失败 → 你手动收拾残局。这哪里是AI替我写代码分明是AI给我制造了一堆新bug我来修。槽点八Vercel AI SDK——用AI掩盖问题的黑色幽默Vercel自己也意识到了AI的重要性。他们推出了Vercel AI SDK一个辅助开发AI应用的官方库。但我读他们的文档时看到了一个讽刺的现实“Vercel AI SDK is designed to work seamlessly with Next.js App Router, Server Components, and Server Actions.”翻译“我们的AI工具专门优化了Next.js最复杂的那些特性。”我理解他们想卖AINext.js的捆绑套餐。但这里有一个黑色幽默Vercel在用一个AI辅助库来帮助开发者跨越Next.js自身复杂性这座大山。你用一个工具去对付另一个工具制造的麻烦——而麻烦本来就不该存在。如果没有Server Components的复杂数据流为什么需要AI来优化数据获取如果没有App Router的混乱路由为什么需要AI来辅助路由管理如果没有SSR的环境分裂为什么需要AI来解析哪个代码在哪跑Vercel AI SDK的存在本质上就是一个补丁。他们在用AI来弥补Next.js在AI时代暴露的缺陷。“新AI工具解决旧框架问题”——这个逻辑本身就是对框架的控诉。总结Next.js的AI税清单最后我们来列一张清晰的AI税清单。你在Next.js项目里每用一次AI工具就要支付这些隐性成本税种描述成本等级Token通胀税上下文更大对话轮次更多⭐⭐⭐⭐⭐版本考古税AI的知识过时你负责版本校验⭐⭐⭐⭐⭐Prompt膨胀税每个需求都要写超长prompt来防呆⭐⭐⭐⭐代码平庸税AI生成安全但低效的写法⭐⭐⭐⭐测试失效税AI生成的测试大多没法用⭐⭐⭐⭐Agent断裂税AI Agent频繁卡住需要人工介入⭐⭐⭐⭐⭐工具失效税Code Review、自动重构全部打折⭐⭐⭐⭐这七项加起来AI给你带来的效率提升被税收抵消了50%-70%。你花着AI的订阅费用着AI的算力结果效率只提升了30%。而隔壁用ViteReact的团队AI把他们的效率提升了200%。这不是AI时代的问题这是在AI时代还用Next.js的问题。最后的最后AI的投票我们会继续看到AI的发展。但我们不需要靠预测来判断未来——看AI自己怎么说就行了。如果你问一个AI编程助手“推荐一个前端框架。”它的推荐会受到训练数据的影响。但如果Next.js真的那么好它应该天然地被AI推荐。实际上你如果问一个AI我现在用Next.js有什么更好的方案“它会给出ViteReact或Astro”。这不是AI在吐槽Next.js这是“AI在分析所有公开代码后的统计结果”。而统计学不会撒谎在AI时代代码越来越被AI生成和维护。一个框架如果能被AI轻易理解、生成、调试它就有长期的生命力。如果它让AI感到困惑它就会被逐渐边缘化。Next.js走在边缘化的斜坡上。不是因为人类不喜欢它而是因为机器不喜欢它。而在AI时代机器的意见权重越来越大。