企业官网建设流程全解析

前端圈这两年弥漫着一种情绪：GPT 写代码越来越像样，低代码平台越来越多，初级前端岗位肉眼可见地变少。很多 Vue、React 写得很熟练的人开始焦虑：我的技能还有没有竞争力？要不要转行？往哪里转？

我的判断是：前端不会消失，但“只会写页面”的前端确实会越来越难。另一边，AI 应用开发正在成为整个行业最缺人的环节之一，它恰恰需要前端背景的人来完成从模型能力到用户界面的最后一公里。Vue/React 开发者转向 AI 全栈架构师，不是抛弃前端，而是把前端十几年的交互积累，变成 AI 落地时最稀缺的资产。

这篇文章不承诺速成神话。标题里的“7天”我会拆成一条可执行的入门路线，而不是变成架构师的倒计时；“百万年薪”我会把它还原为能力和市场匹配的结果，而不是报名某个课程的预期收益。全文会用 Vue/React 开发者熟悉的语言，讲清楚 AI 全栈架构师到底做什么、需要哪些技能、怎么从零跑通一个 AI 应用。

1. 为什么前端是转型 AI 全栈架构师的最优起点

先聊一个现象：很多团队做 AI 项目，最卡壳的不是模型选型，而是“没人能把模型输出变成好用的产品”。后端同学熟悉接口和系统，但不擅长设计人机交互；算法同学擅长调模型，但做出来的演示往往只有一个命令行或简陋页面。这时候最需要的，恰恰是理解用户、理解交互、理解组件化和状态管理的开发者——也就是前端工程师。

AI 应用和传统应用的差异在于：它的输出不稳定、有延迟、有格式漂移，甚至会产生幻觉。传统页面是“拿到数据再渲染”，AI 页面是“边生成边渲染、流式更新、状态可能反复变化”。这对前端提出了新的要求：怎么处理流式输出、怎么设计加载和降级状态、怎么让用户感知模型在思考、怎么在上下文窗口有限的情况下管理多轮对话。

这些问题的本质，仍然是组件化、状态管理、异步流处理和用户体验设计。Vue 的响应式状态、React 的 Hooks 和渲染调度，在 AI 应用里依然有用，只是你把“数据源”从后端 REST 接口换成了大模型输出。

所以第一个判断就是：前端不是 AI 的局外人，而是 AI 应用的必要入口。你的 Vue/React 技能不是包袱，是跳板。

2. AI 全栈架构师到底做什么

不要被“架构师”三个字吓住。在这个语境里，AI 全栈架构师的核心工作，是设计并搭建一个完整可用的 AI 应用系统，从模型交互到业务功能再到工程落地全部打通。

具体来说，日常工作通常包含四类。

第一，模型接入与交互设计。你负责把大模型的能力封装成产品可用的接口，比如对话、摘要、结构化信息抽取。这里不再是“调一调 API”，而是要考虑 Prompt 怎么写、输出怎么约束、错误怎么处理。

第二，数据与知识工程。把业务数据变成模型能利用的知识，这就是 RAG（检索增强生成）的范畴。你需要做文档切分、向量化、检索排序，把喂给模型的内容控制在可控范围内。

第三，Agent 与工具调用。当模型需要访问实时数据、查询数据库或操作外部系统时，你要设计工具、定义参数格式、处理模型返回的调用指令并保证执行安全。

第四，系统工程与稳定性。包括鉴权、限流、成本控制、超时处理、日志可观测、灰度上线。这些原本是后端和运维同学的工作，但 AI 应用里它们和业务耦合得特别紧，架构师必须有全局理解。

下面用一张表说明传统全栈和 AI 全栈的区别：

这里顺便解释一个高频术语：SSE（Server-Sent Events，服务器推送事件）。它是一种基于 HTTP 的服务端向客户端单向推送数据的协议，和 WebSocket 不同，SSE 不需要双向通道，只需浏览器用EventSource或fetch读取流式数据即可。大模型输出正好是单向的文本流，所以 SSE 成了 AI 应用最常用的流式方案。

对前端开发者来说，你以前把后端返回的 JSON 渲染到页面；现在你只是把“后端返回”这个动作替换成“模型生成”，其他大部分技能是相通的。真正的增量在于：你还要懂 Prompt、懂向量检索、懂 Agent 的基本原理。

3. 技术栈：你其实已经会了一半

先说结论：Vue/React 开发的组件、状态、异步、工程化经验可以全部复用。你真正需要补的是下面四层。

第一层：AI 接入层。你需要掌握大模型 API 的标准调用方式，包括 Completion（补全）和 Chat Completions（对话），以及流式响应（SSE）的处理。前端可以用 EventSource 或 fetch 的 ReadableStream 来读取流式输出，这对做过 WebSocket 或长连接的人来说并不陌生。

第二层：应用编排层。你需要学习怎么用代码组织多轮对话上下文、怎么限制输出格式（比如 JSON 模式）、怎么把业务数据和模型输出一起编排成用户需要的答案。这层还涉及 Prompt 管理与模板化。

第三层：数据增强层（RAG）。你要理解 Embedding 是什么：它把文本转换成一串数字向量，语义相近的文本在向量空间中距离更近。检索时可以用向量距离找到最相关的内容，再把这些内容拼进 Prompt 交给模型。理解原理后用现成工具即可，不需要从零实现向量索引。

第四层：Agent 与工具层。你要理解“模型决定做什么，代码负责执行”的协作模式。模型根据用户的请求生成结构化指令（比如调用某个工具并传入参数），你的程序负责鉴权、执行、返回结果给模型，模型再生成最终回答。这个循环就是 Agent 的基本形态。

推荐的落地技术栈可以这样选：

这里给一个实用建议：不要一上来就学一堆 Agent 场景的抽象框架。先用最朴素的方式手动调通一个工具调用循环，你会发现原理比框架简单得多。

4. 7 天路线：把焦虑换成一次完整的项目破冰

“7天”听起来夸张，但如果你把它当作“每天花 2 到 4 小时，跑通一个 AI 全栈项目的最小闭环”，它是完全可行的时间盒（timeboxing）安排。目标不是成为架构师，而是亲手完成从模型调用到产品上线的全部环节。

第 1 天：大模型 API 破冰。申请一个可用的模型服务，用 curl 或 Node.js 脚本发送第一次对话请求。不需要页面，只验证你能在本地代码里拿到模型回复。

第 2 天：实现流式输出。把普通请求改成流式请求，观察 Token 一个接一个回来的过程。用一个小脚本把输出短暂地打印到控制台，理解 SSE 的结构。

第 3 天：做页面。用你熟悉的 Vue 或 React，搭一个最简单的对话界面，把流式输出接到页面上，做到打字机效果。这天你会体会到“边生成边渲染”和传统接口的区别。

第 4 天：加一个后端服务。不要把模型 API Key 直接暴露在页面里。用 Node.js 或 Python 写一个转发接口，前端请求你的后端，后端再请求模型，实现鉴权、密钥保护和日志记录。

第 5 天：做 RAG。找一份 PDF 或 Markdown 文档，把内容切分成段落，向量化后存进本地向量索引。用户提问时，先检索最相关段落，再把段落拼进 Prompt 发送给模型。

第 6 天：做 Agent。给模型配置一个工具，比如“根据城市名查天气”或“计算两个日期相差天数”。模型输出工具调用指令，你的代码执行对应函数，再把结果返回给模型生成最终回答。

第 7 天：项目整合与复盘。把前六天的模块拼成一个完整应用：用户打开页面，提问，先做知识库检索，需要时调用工具，最后用流式输出展示答案。整理一份文档说明架构、技术选型和踩过的坑，这就是你转型作品集的第一块拼图。

这套路线最大的价值不是让你 7 天变架构师，而是让你在 7 天内快速确认：你是否真的对 AI 应用开发感兴趣，项目的哪些环节最让你兴奋，哪些环节是你的短板。这比买课囤资料有用得多。

5. 跑通代码：从后端流式转发到前端渲染

下面给出一套最小可用实现。环境假设：本地已安装 Node.js 18+，使用一个模型服务商提供的兼容接口。具体的模型服务地址、API Key、模型名称需要你按实际可用的服务配置，没有把握时用环境变量隔离。

5.1 后端：Node.js 流式转发

创建一个项目目录，初始化后安装依赖：

mkdir ai-fullstack-demo cd ai-fullstack-demo npm init -y npm install express cors dotenv

创建.env文件，内容如下：

LLM_API_BASE=https://your-model-provider.example/v1 LLM_API_KEY=sk-your-key LLM_MODEL=your-model-name PORT=3001

创建server.js：

// 文件路径：ai-fullstack-demo/server.js require('dotenv').config(); const express = require('express'); const cors = require('cors'); const app = express(); app.use(cors()); app.use(express.json()); app.post('/api/chat', async (req, res) => { const { messages } = req.body; if (!Array.isArray(messages) || messages.length === 0) { return res.status(400).json({ error: 'messages 参数不合法' }); } // 设置 SSE 响应头 res.setHeader('Content-Type', 'text/event-stream; charset=utf-8'); res.setHeader('Cache-Control', 'no-cache'); res.setHeader('Connection', 'keep-alive'); try { const upstream = await fetch(`${process.env.LLM_API_BASE}/chat/completions`, { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${process.env.LLM_API_KEY}` }, body: JSON.stringify({ model: process.env.LLM_MODEL, messages, stream: true }) }); if (!upstream.ok || !upstream.body) { throw new Error(`上游请求失败: ${upstream.status}`); } const reader = upstream.body.getReader(); const decoder = new TextDecoder(); while (true) { const { done, value } = await reader.read(); if (done) break; const chunk = decoder.decode(value, { stream: true }); // 把上游的 SSE 数据原样转发给前端 res.write(chunk); } res.end(); } catch (err) { console.error('代理出错:', err); res.write(`data: ${JSON.stringify({ error: err.message })}\n\n`); res.end(); } }); app.listen(process.env.PORT || 3001, () => { console.log(`后端服务已启动: http://localhost:${process.env.PORT || 3001}`); });

关键点有三个：一是用 fetch 请求上游模型接口并开启stream: true；二是把上游响应头设置为 SSE；三是通过reader.read()逐个读取数据块，然后原样写入客户端的响应对象。这里不做任何数据拼接，是为了最大程度保证流式体验。

注意，LLM_API_BASE、LLM_API_KEY、LLM_MODEL是占位符。不同的模型服务商地址和模型命名差异很大，你需要替换成实际可用的服务配置。如果外部模型服务在你的环境中不可用，请选择符合合规要求的服务提供方，或使用企业内部部署的模型服务。

5.2 前端：React 页面接收流式输出

这里以 React 为例。用 Vite 快速创建项目，然后写一个对话组件。Vue 版本的思路完全一致，区别只是响应式 API。

npm create vite@latest ai-chat-front -- --template react cd ai-chat-front npm install

把src/App.jsx替换为：

// 文件路径：ai-chat-front/src/App.jsx import { useState, useRef } from 'react'; const BACKEND_URL = 'http://localhost:3001'; function App() { const [messages, setMessages] = useState([]); const [input, setInput] = useState(''); const [loading, setLoading] = useState(false); const abortRef = useRef(null); const sendMessage = async () => { if (!input.trim() || loading) return; const userMessage = { role: 'user', content: input }; const nextMessages = [...messages, userMessage]; setMessages([...nextMessages, { role: 'assistant', content: '' }]); setInput(''); setLoading(true); try { const response = await fetch(`${BACKEND_URL}/api/chat`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ messages: nextMessages }) }); if (!response.ok || !response.body) { throw new Error('请求失败'); } const reader = response.body.getReader(); const decoder = new TextDecoder(); let assistantContent = ''; while (true) { const { done, value } = await reader.read(); if (done) break; const chunk = decoder.decode(value, { stream: true }); const lines = chunk.split('\n'); for (const line of lines) { if (!line.startsWith('data: ')) continue; const dataStr = line.slice(6).trim(); if (!dataStr) continue; if (dataStr === '[DONE]') continue; try { const parsed = JSON.parse(dataStr); const delta = parsed.choices?.[0]?.delta?.content || ''; assistantContent += delta; setMessages((prev) => { const cloned = [...prev]; cloned[cloned.length - 1] = { role: 'assistant', content: assistantContent }; return cloned; }); } catch (err) { console.error('解析SSE数据失败:', err); } } } } catch (err) { console.error('对话请求出错:', err); } finally { setLoading(false); abortRef.current = null; } }; return ( <div className="app"> <div className="chat-box"> {messages.map((msg, index) => ( <div key={index} className={`message ${msg.role}`}> <strong>{msg.role === 'user' ? '你' : 'AI'}:</strong> <p>{msg.content}</p> </div> ))} </div> <div className="input-bar"> <input value={input} onChange={(e) => setInput(e.target.value)} onKeyDown={(e) => e.key === 'Enter' && sendMessage()} placeholder="输入你的问题" /> <button onClick={sendMessage} disabled={loading}> {loading ? '生成中...' : '发送'} </button> </div> </div> ); } export default App;

这段代码的核心是使用fetch读取一个可读流（ReadableStream），把每次读到的 SSE 数据解析出来，再通过setMessages增量更新页面上的助手消息。与传统接口“一次返回完整 JSON”不同，你看到的效果是模型输出的文字一个片段一个片段地出现。

如果你用 Vue 3，核心逻辑完全对应：useState换成ref，setMessages换成对ref的赋值，其余解析 SSE 的部分可以直接复用。这里不再重复贴代码，重点是理解“后端转发流、前端逐块读取”这个链路。

在真实项目中，你还需要处理用户点击停止按钮后中断请求的情况，可以用AbortController控制 fetch 的终止；页面卸载时也要清理未完成的请求，避免内存泄漏。

启动顺序：先启动后端node server.js，再启动前端npm run dev，浏览器打开 Vite 提示的地址，在输入框里输入“你好，请用一句话介绍你自己”，观察页面是否出现打字机效果。

5.3 RAG 最小实现

RAG 是 AI 应用里最常见的数据增强方式。下面用一个极简示例说明思路：给定几段文档，用户提问时先检索最相关的段落，再把段落拼进 Prompt 交给模型。

// 文件路径：ai-fullstack-demo/rag-demo.js require('dotenv').config(); const documents = [ 'Vue 3 是一种渐进式 JavaScript 框架，适合构建用户界面。', 'React 18 引入了并发特性，并改进了批处理机制。', 'AI 全栈架构师需要同时理解前端、后端和大模型接入。', 'RAG 是检索增强生成，它能够让模型基于外部知识回答问题。' ]; // 简单的关键词重叠计分，仅用于演示 function simpleSearch(query, docs) { const queryWords = query.split(/[\s,，。！？]+/).filter(Boolean); return docs .map((doc, index) => { const score = queryWords.reduce((sum, word) => { return sum + (doc.includes(word) ? 1 : 0); }, 0); return { index, doc, score }; }) .sort((a, b) => b.score - a.score); } async function chatWithRag(question) { const topDocs = simpleSearch(question, documents); const context = topDocs.slice(0, 2).map((item) => item.doc).join('\n'); const messages = [ { role: 'system', content: '你是一个技术顾问。请严格基于以下资料回答问题，资料不足时明确说明。\n\n资料：\n' + context }, { role: 'user', content: question } ]; const response = await fetch(`${process.env.LLM_API_BASE}/chat/completions`, { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${process.env.LLM_API_KEY}` }, body: JSON.stringify({ model: process.env.LLM_MODEL, messages, stream: false }) }); const data = await response.json(); return data.choices[0].message.content; } chatWithRag('Vue 3 是什么？') .then((answer) => console.log('回答:', answer)) .catch((err) => console.error(err));

运行：

node rag-demo.js

这个示例没有使用真正的向量数据库，核心目的是演示 RAG 的完整链路：切分文档、检索相关片段、拼装上下文、请求模型、得到回答。在生产环境中，你会把simpleSearch换成基于 Embedding 的向量检索，并借助向量数据库支持更大规模的文档集合。但理解这个最小闭环，比一开始就引入复杂工具更重要。

6. 验证标准：你的第一个 AI 项目合格了吗

很多人跑通 demo 之后不知道怎样才算“真的会了”。下面给出一组可自测的验收标准。

第一，流式体验合格。页面中模型的回答应当逐字出现，首 Token 延迟在一个可接受的范围内。如果用户要等很久才看到第一个字，通常是后端缓冲未关闭或网络链路过长，排查方向是确认上游 stream 已开启、中间层没有做缓冲合并。

第二，密钥安全合格。前端代码中不出现任何 API Key 和模型服务地址，所有敏感信息只存在于后端环境变量中。检查方式是把前端代码里的关键字sk-或Authorization搜索一遍。

第三，错误处理合格。当上游模型服务不可用、限流或超时时，前端不会白屏，也不会出现无意义的堆栈报错。用户看到的应该是一句明确的提示和重试按钮。

第四，上下文管理合格。在多轮对话中，请求体里的messages不能无限增长。需要实现一个简单的策略：超出一定长度时裁剪最早的消息，或者用摘要替换历史，防止 Token 成本失控。

第五，成本可观测。一个真实项目至少要记录每一次请求的模型名称、Token 用量和耗时，最好能按用户维度统计。如果没有日志，你根本不知道一个 AI 功能的真实成本是多少。

这五项每一项都有对应的面试讲故事价值。当你把这些工程细节带进作品集，面试官看到的就不是“我调过 API”，而是“我做过可上线的 AI 应用”。

7. 常见问题与排查思路

从前端转向 AI 全栈的项目实践看，问题高度集中。整理成一张排查表：

这里给一条通用排查建议：任何问题先分两类。一类是“链路问题”，用 curl 逐层请求，确认哪一层断了；另一类是“模型问题”，换一个固定 prompt 在模型平台控制台直接调试，排除代码干扰。这个习惯能帮你省掉大量排查时间。

8. 工程建议：别只做 demo，要做能上线的项目

如果你的目标是从 Vue/React 开发者变成 AI 全栈架构师，那必须用工程标准要求自己。以下几点最容易被忽略，也最值得提前养成。

第一，成本意识要前置。AI 应用的成本主要来自 Token 消耗。同一个功能，Prompt 设计得好，成本可能相差几十倍。建议每次请求都记录 model、prompt_tokens、completion_tokens，按天聚合看趋势。上线前先估算单用户会话成本，再决定上下文保留策略。

第二，Prompt 要模板化管理。不要把 Prompt 写死在业务代码里。抽成配置文件或数据库记录，让产品和运营同学也能参与调优。同时记录版本号，方便回滚比对。

第三，安全边界要划清楚。模型如果被允许调用工具，必须校验每一个入参。比如一个“查询订单”工具，不能接受用户直接传入的 SQL 片段或任意对象字段。工具的执行范围永远小于模型的理解范围，这是 Agent 系统的第一原则。

第四，流式接口要可观测。生产环境的 AI 接口必须有完整的链路日志，包括请求时间、上游响应时间、首 Token 延迟、总 Token 数、错误码。否则你的问答功能一旦变慢或失败，你根本无法定位是模型问题、网络问题还是业务问题。

第五，保持前端基本功。不要因为学了 AI 就丢掉组件设计、性能优化、可访问性这些老本行。AI 应用最终拼的是用户体验，而这一块正是前端工程师的护城河。市面上大多数 AI 产品界面还非常粗糙，一个能做出细腻交互体验的 AI 全栈工程师，在未来几年内都会非常抢手。

第六，做作品要选对场景。面试时最有说服力的项目，是那种“用户愿意每天打开”的实用工具，而不是又一个聊天机器人。比如一个基于 RAG 的团队知识问答、一个辅助生成测试用例的 Agent、一个结合内部数据的报表助手。这些项目能展示你理解业务、理解数据、理解工程。

9. 写在最后：7 天之后

回到标题。7 天做完上面那条路线，你可能掌握了大模型 API 调用