只用JavaScript就能做AI绘画？他用Next.js把Stable Diffusion接进了聊天框

很多人以为接入Stable Diffusion要折腾模型、算力和一堆后端服务，但这个视频给了一个完全反直觉的答案：只用JavaScript，加上Next.js和Vercel AI SDK，就能把AI绘画无缝塞进产品里，而且代码少得离谱。

最反直觉的一点：AI绘画，居然像写业务代码一样简单

视频一上来，作者直接现场演示：在一个聊天框里输入一句“生成博客配图”，几秒钟后，一张Stable Diffusion生成的图片就出来了。没有模型部署，没有GPU调参，甚至没有复杂的Prompt工程。真正反直觉的是——这一切几乎就是“普通JavaScript开发体验”。

核心在两个东西：Vercel AI SDK 的 tool calling 能力，以及 FAL 提供的模型 API。前者负责把“生成图片”当成一个工具函数，让大模型自己决定什么时候调用；后者则把 Stable Diffusion 包装成一个即插即用的服务。作者的原话几乎是在炫耀：“我就是复制了他们的示例代码，粘过来就能用。”对习惯了折腾Diffusers、ComfyUI的人来说，这种轻量级路径本身就很有冲击力。

真正的亮点不在画图，而在“工具调用 + 状态管理”

如果只看生成图片，那这个项目并不稀奇；真正值得AI从业者注意的，是他怎么“产品化”这件事。

在后端，所有AI能力都集中在一个 API route 里，通过 Vercel AI SDK 的 tools 参数注册。生成博客图片只是其中一个工具，输入只有一个 prompt 描述。模型在对话中决定调用这个工具，执行后返回结果。

更关键的是 onFinish 回调：作者会遍历所有 tool results，把生成的图片消息存进数据库。结果是——刷新页面，图片还在，聊天历史完整保留。这一步解决的不是技术炫技，而是一个非常现实的产品问题：AI生成内容如何成为“长期资产”，而不是一次性输出。

很多Demo死在这里：看起来很酷，但一刷新就什么都没了。而这个实现，已经明显是奔着真实应用去的。

前端并不花哨，但每一行都在为体验服务

在客户端，逻辑同样朴素到极致。一个 switch case，根据 tool 名称判断是不是 generate blog image。如果是，就直接用 Next.js 的 Image 组件渲染图片。

图片没加载完怎么办？加一个 skeleton。是不是历史消息？那就从数据库里拿 tool result 再渲染一次。

这里没有炫技式的前端架构，但你能明显感觉到作者在想的是：用户会不会觉得“卡”？刷新后会不会懵？AI生成的结果，能不能像正常内容一样被对待？

这恰恰是现在很多AI应用的短板：模型很强，但体验很糙。而这个项目说明，只要工具选对，体验其实不需要付出很高成本。

一个被低估的趋势：多模态能力，正在被“API化”

视频结尾，作者轻描淡写地提到：FAL 不只是 Stable Diffusion，还有 text-to-video、image-to-video、speech-to-text、video-to-video 等一堆模型。

这句话信息量很大。它意味着，多模态能力正在快速“商品化”：你不需要理解扩散模型、不需要研究语音识别架构，只需要知道“我什么时候该调哪个API”。

对AI应用开发者来说，这正在改变竞争焦点——真正的壁垒不再是“我能不能跑模型”，而是“我能不能设计出好用的工具调用逻辑，把这些能力编排成一个产品”。

总结

这个视频真正的价值，不是教你怎么“生成一张图”，而是展示了一种新的AI应用开发范式：模型能力被平台封装，开发者的核心工作变成了产品逻辑、状态管理和用户体验。

如果你是前端或全栈开发者，这意味着你可以几乎不跨出JavaScript生态，就把Stable Diffusion这样的能力变成业务功能；如果你是AI从业者，这也值得警惕——未来拉开差距的，很可能不是谁模型更懂，而是谁更懂“怎么用”。

一个值得思考的问题是：当文本、图像、视频、语音都变成可调用工具后，你现在做的产品，真的把这些能力用到位了吗？

关键词： Next.js， Vercel AI SDK， Stable Diffusion， 文本生成图像， 多模态AI

事实核查备注： 需要核查：1）视频作者名称 Ras Mic；2）发布时间 2024-07-04；3）项目 GitHub 名称 TFI 及含义；4）FAL 是否官方提供 Stable Diffusion 及多模态模型 API；5）Vercel AI SDK 是否支持 tool calling 功能