我刚开始听到“AI网站开发”这个词，脑子里冒出的画面是机器自动写好一个网站，人只需要点按钮。真正动手后才发现，AI网站开发更像一种新的协作方式。它没有把基础完全抹掉，而是把建站的门槛降低，把重复劳动压缩。对零基础的人来说，理解这一点很关键。这份AI网站开发教程会从认知、路线、环境、第一个页面和常见坑讲起，帮你把第一步走稳。
1.1 什么是AI网站开发：传统建站、AI辅助与自动化生成
我最早学建站时，用的是传统方式。手写HTML搭结构，CSS调样式，JavaScript做交互，还要买服务器、配数据库、传文件。一个简单页面能折腾好几天。传统建站的好处是掌控感强，每个标签、每条规则都由自己决定。坏处是学习曲线陡，零基础的人容易卡在环境配置和报错里。
AI网站开发把这条路拆成了几种形态。一种叫AI辅助开发，我写代码，AI帮我补全、解释、查错。另一种叫自动化生成，我用自然语言描述需求，AI直接吐出网页代码。还有传统建站和AI工具混用的方式，比如自己搭框架，让AI生成组件。三种方式没有绝对好坏，看阶段用。做原型时自动化生成很快，做正式项目时AI辅助更稳。
从教学角度看，我会把AI网站开发理解成“人负责判断，AI负责产出”。AI能快速给出结构、样式和逻辑，判断代码能不能用、安不安全、符不符合需求，仍然靠人。零基础的人不需要一开始就懂所有原理，但要知道AI生成的内容需要检查。这个认知建立起来，后面学工具和写项目会顺很多。
1.2 零基础学习路线：HTML、CSS、JavaScript与AI工具协同
我零基础时试过跳过HTML和CSS，直接让AI写完整页面。页面确实出来了，我想改个按钮位置却找不到地方。那次经历让我明白，基础不是拦路虎，基础是修改权。HTML管内容结构，CSS管视觉呈现，JavaScript管交互行为。懂一点基础，给AI的描述会更准，改AI代码也更有方向。
我的学习路线很朴素。每天花半小时看HTML标签，用AI出几道小练习。学CSS时，让AI把同一个卡片布局改成Flex和Grid两种版本。学JavaScript时，让AI解释事件监听和DOM操作。我朋友用类似方法，两周做出了一个能看的个人主页。他的做法是先自己写几行，再让AI优化，遇到报错就贴给AI问原因。这种协同比完全依赖AI更扎实。
具体路线可以这样走：HTML重点学常用标签、表单、语义化。CSS重点学盒模型、选择器、Flex、Grid、响应式。JavaScript重点学变量、函数、事件、数组和对象。每学一个点，用AI生成一个小项目练手。AI工具负责加速和答疑，基础负责让你不被工具牵着走。AI网站开发教程的价值在这里，不是替你学，而是陪你练。
1.3 开发环境搭建：浏览器、代码编辑器、AI编程助手与版本控制
我最初用记事本写网页，改完保存，刷新浏览器，效率低得让人想放弃。后来换成VS Code，装了Live Server插件，保存后浏览器自动刷新，体验完全不同。浏览器我推荐Chrome或Edge，开发者工具能看结构、调样式、查网络请求。代码编辑器用VS Code，免费、插件多、对新手友好。AI编程助手可以选ChatGPT、Claude、Cursor或GitHub Copilot，先用一个顺手的。
安装过程不复杂。下载VS Code，装中文包、Live Server、Prettier。AI助手可以开网页版，也可以装插件。版本控制用Git，代码托管用GitHub。我教朋友时，让他新建一个文件夹，里面放index.html，用VS Code打开，右键Live Server启动。Git只需要记住add、commit、push三个动作。环境搭好后，别急着堆工具，够用就行。
环境搭建有个容易忽略的点：API密钥不要写在前端代码里。我见过有人把OpenAI密钥直接放进JavaScript，上传到GitHub后被人扫到，账单暴涨。版本控制也要从第一天用起来，每次改完提交一次。改坏了能回滚，改对了有记录。零基础的人把浏览器、VS Code、一个AI助手、Git配好，就可以开始写第一个页面了。
1.4 第一个AI生成页面：用自然语言描述需求并生成网页
我第一次让AI生成页面时，描述只有一句话：“帮我做一个个人作品集网站，深色主题，圆角卡片，手机也能看。”AI返回了HTML和Tailwind CSS代码。我复制到VS Code，浏览器打开，居然有导航栏、头像区、项目卡片和联系按钮。那一刻我很兴奋，觉得建站原来可以这么快。兴奋过后，我发现页面很通用，像模板，缺少我的个人痕迹。
作为新手，我犯的错是描述太模糊。AI只能猜，猜出来的东西自然大众化。后来我学会把需求拆细：导航栏放哪些链接，英雄区写什么标题，项目卡片放几张，配色用哪几个十六进制色值，移动端断点怎么处理。描述越具体，AI输出越贴近想法。我还会让AI先给布局草图，确认后再写代码。这个习惯省下很多返工时间。
生成之后一定要改。我让AI逐段解释代码，把占位文字换成自己的介绍，把图片链接换成真实图片，调整间距和字号。第一次AI生成页面让我理解了一件事：自然语言就是新的需求文档。你说得清楚，AI就写得清楚。你说得含糊，AI就给你一个能跑但普通的页面。这个练习值得每个零基础的人做三遍以上。
1.5 常见误区与避坑：依赖AI、忽视基础与代码审查
我见过零基础的朋友完全依赖AI，项目能跑起来，但一出问题就束手无策。AI生成的代码会有幻觉，可能调用不存在的库，可能用过时的API，也可能留下安全漏洞。把AI当万能工具，短期省事，长期会卡住。我的做法是让AI写完后，再让另一个AI审查一遍，自己再读关键部分。读不懂的地方，继续问，直到能用自己的话解释。
忽视基础是另一个坑。有人觉得AI都能生成，学HTML和CSS没用。实际改样式时，不知道盒模型就调不好间距。不知道Flex和Grid，就改不动布局。不知道事件和DOM，就做不了交互。基础不是要学到精通，而是学到能看懂、能修改、能提问。代码审查同样重要。AI可能把API密钥写进前端，可能拼接SQL，可能直接渲染用户输入。这些风险需要人来拦。
避坑方法不复杂。小步验证，每生成一段代码就在浏览器跑一次。用Git记录版本，改坏能回退。本地测试表单和交互，不把密钥提交到仓库。读官方文档，AI说的和文档对不上时以文档为准。AI网站开发教程不是让人跳过学习，而是让人用更短路径获得反馈。零基础也能走这条路，前提是保持判断，不把思考完全交给AI。
工具链这事，我踩过不少坑。最开始我以为装一个AI助手就够了，后来发现不同环节需要不同工具。写代码有写代码的助手，搭原型有搭原型的平台，接AI能力又要另外的API。这份AI网站开发教程的第2章，我想把自己用过的工具按场景拆开讲，帮你少走弯路。
2.1 AI编程助手对比：ChatGPT、Claude、Cursor、GitHub Copilot
我用ChatGPT的时间最长。它适合问概念、改代码、解释报错。我经常把一段报错信息贴进去，它给我原因和修法。缺点是要来回复制粘贴，项目大了之后上下文容易丢。Claude给我的感觉是长文本处理更稳，我丢一整份文件进去让它审查，它能记住更多细节。写文档和重构代码时，我会优先找Claude。
Cursor是我近半年用得最多的。它本身是编辑器，内置AI，能读整个项目。我按快捷键让它改某个函数，它知道其他文件怎么调用的。GitHub Copilot补全速度快，写重复代码时很省力。我朋友做前端，习惯Copilot在行内补全，我更喜欢Cursor的对话式修改。四个工具没有谁替代谁，我的组合是Cursor写项目，ChatGPT答疑，Claude审长文，Copilot补琐碎代码。
选工具有个原则：先精通一个。我见过新手同时装四个助手，结果每个都用不深。零基础的人可以从ChatGPT网页版开始，熟悉了再上Cursor。AI网站开发教程里工具对比的意义，不是让你全买，而是让你知道什么场景找什么工具。
2.2 无代码与低代码AI建站：Framer AI、Wix ADI、Durable
我帮一个开咖啡店的朋友做过网站。他不会代码，我也不想从零写。我们试了Durable，输入“咖啡店、手冲、温暖、预约”，几分钟出来一个带首页、菜单、联系表单的站点。速度快得让我有点不真实。Durable适合小商家快速上线，模板感偏强，改细节的空间有限。
Framer AI我用得更多一些，因为它对设计师友好。我用一句话生成布局，再拖拽调整，动效和响应式做得顺。Wix ADI是问答式建站，它会问你行业、风格、功能，然后拼出一个站。我拿它做过活动落地页，够用。三个平台共同的短板是深度定制，想接自己的数据库或者写特殊逻辑时会卡住。无代码工具适合验证想法，不适合做复杂产品。
我现在的做法是先用这类平台出原型，把页面结构和文案定下来。确认方向后再决定要不要转成代码项目。这样做的好处是，花在原型上的时间短，改方向成本低。低代码和无代码不是低端，它们是不同阶段的工具。
2.3 前端框架协作：React、Vue、Tailwind CSS与AI组件生成
我第一个正式项目用React。选它的原因是生态大，AI训练数据多，问问题容易得到靠谱答案。Vue我也用过，模板语法直观，上手快。两个框架都能和AI配合，关键在你怎么描述组件。我通常告诉AI：这是一个卡片组件，接收title、image、link三个props，用Tailwind写样式，移动端垂直排列。描述清楚，AI一次就能给可用的代码。
Tailwind CSS是我用AI写前端时最喜欢的搭配。类名写在HTML里，AI生成和修改都方便，不用在多个文件之间跳。我让AI生成一个响应式导航栏，它直接给出带断点类和hover状态的代码。换成传统CSS，我得手动对应选择器。Tailwind让AI的输出更可直接使用，代价是类名长，初看有点吓人。
AI组件生成有个技巧：让它先输出组件接口，再输出实现。我会问“这个组件需要哪些props，有哪些状态”，确认后再让它写代码。这样生成的组件更容易复用，不会写成一坨。前端框架和AI协作的核心，是把组件边界说清楚。
2.4 后端与数据库：Node.js、Supabase、Firebase的AI集成
后端是我以前最怕的部分。Node.js让我能用JavaScript写服务端，学习成本降下来。我让AI帮我搭Express路由，写接口、处理请求、返回JSON。Supabase和Firebase把数据库、鉴权、存储打包好，省去自己配服务器。Supabase基于Postgres，我喜欢它能写SQL，数据结构清楚。Firebase上手更快，适合实时功能。
AI集成这块，我做过一个用户提交表单存数据库的流程。Supabase建表，Node.js写接口，前端调用。AI帮我生成表结构、接口代码和前端请求。中间出过一次权限问题，Supabase的行级安全策略没配对，AI没提醒我。后来我学会让AI解释每条安全策略的作用，再自己确认。后端和数据库涉及数据安全，AI生成的代码必须逐条检查。
选后端方案有个简单判断：项目小、要快，用Firebase。需要关系型数据和SQL，用Supabase。需要自定义逻辑和完全控制，用Node.js自己搭。三个可以混用，我用Supabase做数据库和鉴权，Node.js做复杂业务接口。
2.5 AI能力接入：OpenAI API、Claude API、文生图、语音与嵌入
让网站真正“AI”起来，要接API。我第一次调OpenAI API时，用Node.js发请求，返回一段文本显示在页面上。流程不复杂：拿密钥、装SDK、发消息、拿回复。Claude API我用得也不少，长文本总结和代码解释表现好。两个API的调用方式接近，学会一个，另一个很快上手。
文生图我用过DALL·E和Stable Diffusion的接口。做作品集网站时，我让用户输入描述，生成配图。语音这块，我用Whisper做语音转文字，用TTS做文字转语音。嵌入向量我用得少一些，但做站内搜索时有用，把文章转成向量存起来，用户搜索时算相似度。这些能力让网站从静态展示变成能交互的工具。
接API有几个坑我提醒你。密钥放服务端，不要写前端。请求加超时和错误处理，AI服务偶尔会慢或者失败。控制调用频率，防止被刷。流式响应能提升体验，让文字像打字一样出来。成本方面，按Token计费，长对话和大量生成会累积。我习惯在开发阶段用小模型测试，上线再按需切换。AI网站开发教程讲工具链，最终目的是让你知道每个环节有什么可选，然后按项目需要组合。
讲完工具链，我想用一个真实项目把前面这些串起来。我选作品集网站，因为它够小、够完整，又刚好能覆盖前端、后端、AI能力和部署。零基础的人做完一个，就摸清了整条链路。我自己第一个AI项目就是作品集站，改了三版才满意。这章把过程拆开，你能跟着做一遍。
3.1 项目定位与需求拆解：页面、内容与交互目标
动手写代码前，我习惯先拿张纸把想要的东西列出来。作品集网站要解决一个问题：让访客快速了解我是谁、做过什么、怎么联系我。我把它拆成三块。首页放头像、一句话介绍、技能标签和精选项目卡片。项目详情页展开每个项目的背景、我做的事、用到的技术、最终效果。联系页放表单和社交链接。
内容这块我踩过坑。第一次做的时候项目描述写得像流水账，访客看完不知道我强在哪。后来我改成每个项目只讲三点：问题是什么、我用了什么方法、结果如何。AI在这步能帮上忙。我把项目笔记丢给ChatGPT，让它帮我压缩成三句话，再自己改措辞。它有时的表达太模板化，我会手动调成自己的语气。
交互目标我定得不高。访客能翻项目、能用聊天助手问我问题、能填表单发消息，就够了。我没加评论区、没加登录、没加多语言。零基础做项目最容易犯的错是贪多，功能堆上去，每个都半成品。我建议你也先锁定最小可用版本，上线之后再迭代。
3.2 AI生成UI：布局、配色、响应式与可访问性
UI 我开始用 Framer AI 出的草稿。输入描述时我写得很具体：“个人作品集首页，顶部导航含首页、项目、联系三个链接，中间大标题加一段自我介绍，下方三列项目卡片，移动端单列。”它给的布局基本能用，配色偏灰蓝，我后来自己换了。AI 出布局很快，但配色和字体这种带个人审美的部分，还是得自己调。我把喜欢的几个设计师网站截图丢给 Claude，让它分析配色方案，再应用到我的 Tailwind 配置里。
组件实现我走的是 Cursor 加 React 加 Tailwind 这条路。我让 Cursor 先生成导航栏组件，要求它带移动端汉堡菜单、滚动时背景变实、当前页面高亮。它一次给的代码能用。项目卡片组件我描述得更细：接收 title、cover、tags、link 四个props，卡片 hover 时轻微上浮，封面图用 object-cover 裁切。描述越具体，生成结果越省事。
响应式我靠 Tailwind 的断点类。sm、md、lg 三档基本够用。我会在浏览器里拉窄拉宽反复看，遇到挤在一起的地方就调 flex 方向或者 grid 列数。可访问性以前我完全忽略，后来让 AI 帮我审了一遍。它指出我的图标按钮没有 aria-label，图片缺 alt，颜色对比度在浅色背景下不够。这几条改完，网站对屏幕阅读器友好不少。AI 不能替你决定审美，但能帮你补齐容易漏的基础规范。
3.3 动态功能实现：AI聊天助手、项目摘要与联系表单
聊天助手是我最想做的功能。我在页面右下角放一个悬浮按钮，点开是小窗口，访客能问我项目相关的问题。实现方式是用 Node.js 写一个接口，接收用户消息，带上我的个人资料作为系统提示，再调 OpenAI API 返回回复。系统提示我写的是：“你是我的作品集助理，只回答关于我的项目、技能和经历的问题，其他话题礼貌拒绝。”这样它不会跑偏去聊天气。
项目摘要功能我做得更轻。每个项目详情页底部有个“一句话总结”按钮，点击后前端把项目描述发给接口，让 Claude 压缩成两句话显示。流式响应让文字一个个冒出来，体验好很多。这功能看着简单，访客反馈却不错，有人懒得读长文，直接看总结。
联系表单我接的是 Supabase。前端收集姓名、邮箱、留言，提交到 Node.js 接口，接口写入 Supabase 表。AI 帮我生成表结构和接口代码，也用得顺。我加了两道防线：邮箱格式前端校验，提交频率服务端限制。有次测试时我连点提交，数据库里出现五条重复记录，后来加了防抖和唯一约束才好。表单看起来最没技术含量，实际坑不少，我会单独做一轮测试再上线。
3.4 部署上线：Vercel、Netlify、域名与HTTPS配置
部署我选 Vercel，因为它跟 React 项目贴合，推代码到 GitHub 就自动构建。第一次部署时我忘了配环境变量，聊天助手接口直接报密钥缺失。Vercel 后台加环境变量，重新部署就好。Netlify 我也用过，拖拽文件夹就能上线，适合纯静态站。带后端接口的项目我倾向 Vercel，它的 serverless 函数配置省心。
域名我是在 Namecheap 买的，一年十几美元。解析到 Vercel 有两种方式：改 nameserver，或者加 A 记录和 CNAME。我选改 nameserver，简单。HTTPS 现在基本是自动的，Vercel 和 Netlify 都会签 Let's Encrypt 证书，我不用手动配。上线后我遇到过 www 和非 www 两个版本都能访问的情况，SEO 上算重复内容，我在 DNS 里加了一条重定向解决。
上线前我列了个清单：所有链接可点、图片加载正常、表单能收到消息、手机上看排版不崩、聊天助手回复正常、密钥没暴露在前端。这个清单跑一遍，基本不会出大问题。第一次上线我紧张，点开自己域名看到页面加载出来，那种感觉挺特别。
3.5 项目复盘：零基础常见问题、调试与迭代方向
做完第一版我回头看了下，问题主要在三个地方。AI 生成的代码我直接用了，有一处组件重复渲染，性能不差但看着乱。后来我让 Claude 逐文件审查，它标出几个可以合并的组件。调试这块我用浏览器开发者工具最多，看 Console 报错、Network 请求、Elements 结构。AI 能解释报错，但定位问题还是得靠工具。
迭代方向我想了两个。一是给项目卡片加筛选，按技术栈过滤。二是让聊天助手能读出当前页面内容，访客问“这个项目用了什么”时它能针对性回答。两个都不难，但我不想一次做完，留着慢慢加。作品集网站本来就是活的，有新项目就更新，有新想法就试。
零基础做这个项目，我最想说的是别怕出错。我第一版上线时导航在手机上错位，朋友截图给我看我才发现。改就是了。AI 让做网站的门槛降了很多，但判断哪里不对、怎么改，还是得自己练。做完这一个项目，你手里就有能拿出手的东西，也知道下一个项目该怎么起步。
作品集做完之后，我手痒想做个更实用的东西。平时写文章、整理笔记、发公众号，流程太碎了，我想把AI塞进整个写作链路里。这个项目比作品集复杂，多了用户系统、数据库关系、内容审核。做完之后我对全栈开发的理解上了一个台阶。下面把每一步都摊开讲，你跟着搭一遍，基本能跑通一个能用的内容管理系统。
4.1 系统规划：用户登录、文章生成、编辑与发布流程
我先画了张流程图，从打开网站到文章发布，标出每一步谁在做什么。用户登录后进入后台，左侧是文章列表，右侧是编辑器。编辑器里有个输入框写主题或大纲，点“生成”按钮，AI吐出草稿，用户改完保存，再点发布。发布后文章出现在前台列表页。流程不复杂，但涉及的角色和状态不少。
登录这块我用Supabase Auth，它自带邮箱密码登录和第三方登录。我选邮箱密码加Google登录，省得自己写注册验证那套。用户表Supabase自动建好，我只需要在业务表里存个user_id做关联。权限我分两档：普通用户只能管自己的文章，管理员能看所有文章和审核队列。角色字段放在用户资料表里，登录后前端读一次缓存在状态里。
发布流程我加了一道草稿状态。文章有draft、review、published三种。新建默认draft，用户点提交审核变review，管理员通过后变published。这样前台不会出现半成品内容。我一开始没加review这步，结果测试时误发了一篇半截文章，赶紧补上。状态机听着唬人，其实就是几个if判断加数据库字段。
4.2 数据库设计：用户、文章、标签与AI生成记录
数据库我用的还是Supabase，Postgres底子。表不多，四张就够。users表用Supabase自带的，我只存了个profiles表放昵称、头像、角色。articles表存文章主体，字段有id、user_id、title、slug、content、status、created_at、updated_at。content我用markdown原文存，渲染交给前端。
标签我做成了两张表。tags表存标签名和slug，article_tags是中间表，存article_id和tag_id。多对多关系，一篇文章挂多个标签，一个标签关联多篇文章。AI帮我生成了建表SQL和关联查询，我改了两处字段名就用了。查询文章带标签时我用Supabase的嵌套select，一次请求把文章和它的标签数组都拿回来。
AI生成记录这张表我犹豫过要不要加，后来还是加了。表名叫generations，存user_id、prompt、response、model、tokens_used、created_at。加它的原因有两个。一是排查问题时能看到某篇文章是怎么生成的，二是统计token消耗方便控制成本。有次我发现某个用户一天生成上百次，一查generations表就知道他在刷，后来加了速率限制。这张表看着不起眼，运营阶段帮了大忙。
4.3 前端交互：表单、Markdown预览、一键生成与历史版本
前端我用React加Tailwind，编辑器这块花的时间最多。左边是markdown输入区，右边是实时预览区，用react-markdown渲染。输入区我用textarea起步，后来换成了CodeMirror，有语法高亮和行号，写起来舒服。两边滚动我做了同步，滚动一边另一边跟着走，改长文时不用来回找位置。
一键生成功能我设计成弹窗。点“AI生成”按钮，弹出一个框，让用户填主题、关键词、字数要求、语气风格。提交后调后端接口，流式返回内容，一个字一个字往输入区里填。流式响应体验好很多，用户看着文字冒出来，不会觉得卡死。生成完用户可以接着改，改完点保存。
历史版本我做了个简单方案。每次保存文章时，把上一版content存进article_versions表，带时间戳。编辑器顶部有个“历史”按钮，点开侧边栏列出所有版本，点某个版本能预览，也能回滚。我没做diff对比，太复杂了。但版本回滚这个功能救过我一次，有次改文章时误删了一大段，直接从历史版本捞回来。
4.4 后端API：鉴权、速率限制、错误处理与流式响应
后端我用Node.js写API路由，部署在Vercel的serverless函数上。鉴权这块我用Supabase的JWT，前端每次请求带token，后端用Supabase的SDK校验用户身份。校验通过后拿到user_id，所有数据库操作都带上这个id做过滤，确保用户只能碰自己的数据。有次我忘了加过滤条件，测试时能用别人的id查到文章，赶紧补上。
速率限制我做了两层。一层是基于用户的，每个用户每分钟最多调10次AI生成。另一层是基于IP的，防止有人注册多个账号刷。实现方式是用内存缓存记请求计数，简单够用。生产环境我换成了Redis，但原理一样。超过限制返回429状态码，前端提示用户稍后再试。这个功能上线后，AI接口的异常调用量降了八成。
错误处理我踩过坑。最开始所有错误都返回500加一句“服务器错误”，用户不知道哪里出了问题。后来我分了类：参数错误返回400带具体字段，未登录返回401，无权限返回403，资源不存在返回404，AI接口超时返回504。前端根据状态码显示不同提示。流式响应这块我用Server-Sent Events，后端设置好header，逐块发送数据，前端用EventSource接收。中间断线会自动重连，体验比WebSocket轻量。
4.5 上线运营：SEO、分析监控、备份与内容审核
上线后我开始关注SEO。每篇文章生成时自动带一个slug，用标题转拼音或英文，存进数据库。前台文章页用Next.js的服务端渲染，保证搜索引擎能抓到完整内容。meta标签我让AI根据文章内容生成description，用户也能手动改。sitemap我写了个接口动态生成，提交给Google Search Console。做了这些之后，自然搜索流量慢慢起来了。
分析监控我接了两个工具。Vercel Analytics看页面访问和性能指标，Sentry看后端报错。有次Sentry报警说AI接口错误率飙升，我查了下是OpenAI那边限流了，加了个重试机制就好了。备份我用Supabase自带的每日备份，另外每周手动导出一次数据库快照存到本地。内容审核这块我做了个简单方案：AI生成的内容先过一遍敏感词过滤，命中就标黄让管理员人工看。用户提交的文章进审核队列，管理员一键通过或打回。完全自动审核我试过，误判率太高，还是得人机结合。
这个项目做完，我对内容型产品的理解深了不少。技术只是骨架，运营才是血肉。SEO、审核、备份这些事看着琐碎，缺一个都可能出问题。你要是跟着做到这里，手里已经有个能跑的内容管理系统了。下一步可以想想怎么把它变成自己的产品，或者接着做更复杂的AI Agent项目。
内容管理系统上线那天我挺兴奋，觉得万事大吉了。用了两周发现一堆问题：首页加载要四秒多，有用户用我的AI接口刷了三千多次token，还有一篇文章被搜索引擎判定为低质量内容。这一章讲的东西，都是我在这些坑里爬出来之后才真正理解的。优化、安全、成本、趋势，四件事看着独立，实际是一根绳上的蚂蚱。
5.1 性能优化：AI生成代码审查、重构与加载速度提升
AI写代码快，快到一个页面几百行代码三分钟就吐出来了。问题在于它只顾实现功能，不管性能。我那个文章列表页，AI生成的代码把每篇文章的标签、作者、评论都单独发了一次请求，五十篇文章就是两百次请求。页面转圈转到用户以为卡死了。我后来打开浏览器Network面板一看，密密麻麻全是fetch，脸都绿了。
重构的过程我用了笨办法：逐个页面过Network，超过三个请求的页面全部重写。文章列表改成一次查询带出关联数据，标签用Postgres的聚合函数拼成数组返回。图片加载我上了懒加载和WebP格式，用AI生成图片时直接指定输出webp。有个细节容易被忽略：AI生成的代码里经常有没用的import和没引用的变量，我装了个eslint插件自动清理，bundle体积少了将近三分之一。
代码审查这件事我现在形成了条件反射。AI每生成一段代码，我会问自己三个问题：这段代码在什么情况下会变慢？有没有多余的请求或渲染？边界条件处理了吗？比如AI给我写了个搜索功能，输入框每敲一个字符就发一次请求，我没注意的话上线就是灾难。后来改成防抖加缓存，同一个关键词只查一次。AI不会主动告诉你这些，得自己盯着。
5.2 安全合规：API密钥管理、用户隐私与内容安全
说个丢人的事。项目初期我把OpenAI的API密钥硬编码在前端代码里，部署到Vercel之后第二天收到邮件，说我密钥被盗刷了四十多美元。当时我脑子嗡的一下。密钥在前端等于把家门钥匙挂在大门上，任何人打开开发者工具都能看到。后来我把所有AI调用挪到后端，前端只跟自己的API说话，密钥存在环境变量里，这才算堵上。
环境变量管理我踩了第二个坑。本地开发用的.env文件，我忘了加进.gitignore，推到GitHub上去了。好在是个私有仓库，发现得早。现在我所有项目初始化第一件事就是配.gitignore，密钥、数据库连接串、第三方服务的token，一个都不能出现在代码仓库里。生产环境的变量在Vercel后台单独配，跟本地完全隔离。
用户隐私这块我是被一封用户邮件点醒的。有个用户问：“你们存不存我跟AI的对话记录？”我当时确实存了，在generations表里，包括完整的prompt和response。虽然没拿去做别的用途，但用户不知道啊。我后来在隐私政策里写清楚了数据用途，加了删除账号时级联清除所有生成记录的功能。GDPR那些条款我研究了两天，核心就一句话：用户的数据用户做主，你要用就得说明白。
内容安全比技术安全更棘手。AI生成的东西你没法百分百控制，它可能输出偏见、虚假信息或者擦边内容。我做了三层过滤：第一层是关键词黑名单，命中直接拦截；第二层是AI自己审核，让模型判断生成内容是否合规；第三层是用户举报入口，被举报的内容进人工审核队列。三层下来误放率降了很多，但没到零。内容安全这件事没有一劳永逸的方案，只能持续盯着。
5.3 成本控制：Token计费、缓存策略与模型选择
收到第一张OpenAI账单时我盯着那个数字看了很久。八十九美元，对于一个刚上线两周、日活不到一百的小网站来说太贵了。我打开用量面板分析，发现百分之七十的token花在了两件事上：重复的system prompt和用户反复生成相似内容。这两个都是可以优化的。
System prompt我原来每次请求都完整发送，后来改成用OpenAI的prompt缓存功能，重复部分只计一次费。用户生成内容这块我加了个语义缓存：用户输入的主题如果跟之前生成过的相似度超过阈值，直接返回缓存结果，不调API。实现方式是用embedding算余弦相似度，存进Postgres的vector扩展里。这一招把AI调用量砍了将近一半。有些用户没注意到返回的是缓存，还夸我响应快。
模型选择是个动态决策。不是所有任务都需要最贵的模型。文章摘要、标签提取这种简单任务我用GPT-3.5或者Claude Haiku，成本是旗舰模型的十分之一，效果差不了太多。长文生成、复杂推理才上GPT-4或Claude Sonnet。我在后端做了个路由层，根据任务类型自动选模型。用户也可以在设置里手动切换，默认用性价比最高的。一个月下来账单从八十九降到了二十三美元，体验几乎没变。
还有个隐形成本容易被忽略：失败重试。AI接口偶尔超时或返回错误，代码如果无脑重试，一次失败可能变成三次调用。我加了指数退避和最大重试次数，超过两次就放弃并告诉用户稍后再试。流式响应中断的情况我也做了处理，已经生成的部分内容照样计费，所以我在前端加了“停止生成”按钮，用户觉得不对可以随时掐断，少花冤枉钱。
5.4 多模态与Agent：让网站自主完成搜索、生成与任务编排
多模态这块我是从一个需求开始的。有用户反馈说想上传一张产品图，让AI自动写商品描述。这个需求用纯文本模型做不了，得让模型看图。我接了GPT-4V的API，用户上传图片后转成base64传给模型，模型返回描述文本。第一次跑通的时候我盯着屏幕笑了半天，觉得这东西真神奇。后来我又加了语音输入，用户说话转文字再走生成流程，用Whisper做转录。
Agent是我最近才认真玩的东西。之前我理解的Agent就是“AI自动干活”，真做起来才发现核心是任务编排。我做了个实验：让Agent自主完成“搜索最新AI新闻、总结要点、生成一篇公众号草稿”这个流程。Agent先调搜索API拿结果，再把结果喂给模型做摘要，最后走内容生成接口。中间不用人干预。跑通那一刻我意识到，网站的角色在变，从“用户操作的工具”变成“帮用户完成目标的代理”。
但Agent的坑也多。最大的问题是它会“跑偏”。你让它搜新闻，它可能搜着搜着去干别的了。我加了步骤限制和状态检查，每一步完成之后验证结果是否符合预期，不符合就回退重来。另一个问题是成本和延迟，Agent一次任务可能调五六次模型，比单次生成贵得多。我的做法是把Agent任务放进队列异步执行，完成后通知用户，不让用户干等。Agent适合复杂任务，简单任务还是直接调API划算。
5.5 持续学习：从教程到独立产品与作品集沉淀
教程跟着做到这里，你手里应该有两三个能跑的项目了。作品集网站、内容管理系统，再加上这一章讲的优化和安全实践。这些东西放在GitHub上就是作品集，比简历上写“熟悉React”有说服力得多。我面过几个开发者，简历写得很漂亮，一问项目细节就卡壳。你自己从零搭过一遍，每个坑都踩过，面试时讲起来底气完全不一样。
从教程到产品中间隔着一道鸿沟。教程里跑通就行，产品要考虑用户量、稳定性、盈利模式。我第一个正式产品是个AI写作辅助工具，上线第一个月只有二十个用户，其中三个是我朋友。但我坚持迭代，每周看用户反馈改一点。第三个月开始有自然流量进来，第六个月有了第一笔付费订阅。收入不多，但那种“有人愿意为我的东西付钱”的感觉，比拿工资爽多了。
持续学习这件事没有捷径。AI领域三天一小变五天一大变，今天好用的模型明天可能就被超越了。我的习惯是每周花两个小时看新产品和论文摘要，不追求全懂，保持手感就行。更重要的是动手试，看到新工具新API，花半小时搭个demo跑一跑。知识看再多不实践，过两周就忘了。你手里这些项目就是你最好的练习场，想到什么功能就往上加，加着加着你就从“学教程的人”变成“做产品的人”了。
回头看这一路，从零基础到能独立做产品，我花了大概八个月。不算快，但每一步都走得踏实。AI工具帮我省了很多查文档和写样板代码的时间，但真正让我进步的是那些踩坑和填坑的夜晚。教程会结束，学习不会。你接下来要做的，就是打开编辑器，开始写下一个项目。
