企业官网建设流程全解析

聊《做过前端的人学大模型，哪些经验可以直接迁移？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

上个月接了个活，帮一个做知识管理的团队搭 AI 助手。业务方开场就说：要流式输出，要能读文档，还要能调内部接口改数据。

流式输出，前端同学闭着眼都能写。权限隔离，说实话，我第一次做的时候差点翻车。

这篇文章不是教你怎么调 API，而是复盘一次真实项目里，前端经验怎么用、哪里会踩坑、业务方提需求时你怎么判断优先级。

---

目录

• 前端的转型优势，别只盯着 UI
• AI 应用交互模式，和传统页面不一样
• 流式输出，前端最熟但别大意
• 多模态体验，前端经验可以直接用
• 权限隔离，才是业务方真正在意的
• 作品集方向，别只做聊天 Demo
• 总结

前端的转型优势，别只盯着 UI

前端做 AI 应用，优势在三个方面：

事件驱动思维。 大模型调用本质是异步请求，和前端处理用户交互、网络响应是一个逻辑。你能写 React 的 useEffect 处理副作用，就能写 agent 的工具调用和状态管理。

状态管理熟练。 传统前端用 Redux、Zustand 管理复杂状态，AI 应用里 context、memory、tool call 结果也是状态。你只是换了个名词，本质没变。

用户体验敏感。 大模型输出慢、可能出错、结果不确定，这些都需要前端经验来处理。loading 状态、错误兜底、部分结果展示，都是老本行。

劣势也有：后端同学对权限、安全、数据流更敏感。我第一次做项目，用户说"要能读我的文档"，我直接让模型访问了全部文件，没做任何隔离。后来业务方问"怎么证明 AI 只读了它该读的文件"，我答不上来。

---

AI 应用交互模式，和传统页面不一样

传统 Web 应用是"用户操作→确定响应"。AI 应用是"用户输入→模型生成→用户追问→模型调整"。

这个差异导致几个关键变化：

输入更自由。 用户可能说"帮我总结一下"，也可能说"这段代码有问题，帮我改"。前端要处理的不只是表单提交，而是意图识别。

输出不可控。 模型可能答非所问，可能泄露信息，可能拒绝回答。前端不能像传统页面那样假设"按钮点了就一定有结果"。

交互更复杂。 流式输出、工具调用、多轮对话，这些组合起来比一个 CRUD 页面复杂得多。

我的建议：先做一个最简单的流式聊天界面，跑通整个链路，再考虑加功能。不要一上来就搞多模态、搞工具调用、搞记忆，最后什么都做不完整。

---

流式输出，前端最熟但别大意

流式输出用 Server-Sent Events 或 fetch 的 ReadableStream 都能实现。代码不难，但有几个坑：

断线重连。 网络抖动时流中断，前端要能恢复。我第一次没做这个，用户刷新页面，对话历史全丢。

部分渲染。 模型输出是 token 级别的，前端要能逐字展示，而不是等整个响应结束再渲染。

错误处理。 流中断、模型超时、内容被截断，都要有兜底。

async function streamChat(messages, onToken) { const response = await fetch('/api/chat', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ messages }), }); if (!response.ok) throw new Error('请求失败'); if (!response.body) throw new Error('不支持流式响应'); const reader = response.body.getReader(); const decoder = new TextDecoder(); let buffer = ''; while (true) { const { done, value } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); const lines = buffer.split('\n'); buffer = lines.pop() || ''; for (const line of lines) { if (line.startsWith('data: ')) { const data = line.slice(6); if (data === '[DONE]') continue; try { const token = JSON.parse(data).token; onToken(token); } catch (e) { console.warn('解析失败', data); } } } } }

这段代码看着简单，实际项目里要加超时控制、断线重连、token 节流，代码量会翻倍。

---

多模态体验，前端经验可以直接用

图片上传、文件解析、语音输入，这些前端都做熟了。AI 应用的多模态，本质是把模型能力封装成前端组件。

但要注意：模型对多模态输入的理解有限。用户上传一张图片，模型可能看不懂细节；上传一个 PDF，模型可能只读取了前几页。前端要做好边界提示，不要让用户以为 AI 什么都懂。

---

权限隔离，才是业务方真正在意的

回到开头的案例。业务方要"调内部接口改数据"，我一开始觉得很简单：让模型调 API 就行。

后来业务方问：怎么证明 AI 只读了它该读的文件？怎么证明它改数据时有权限校验？

我意识到，权限隔离不是技术难题，是信任问题。用户不信任 AI 乱动数据，项目就推不动。

我的解决方案：

1. 接口代理。 所有模型调用的接口都走后端代理，前端不暴露真实 API。
2. 权限预校验。 工具调用前，先检查用户是否有权限，而不是让模型自己判断。
3. 操作日志。 每次工具调用记录谁、在什么时间、调了什么接口、传了什么参数。

# 伪代码：工具调用的权限校验 def call_tool(user_id, tool_name, params): # 1. 检查用户是否有该工具的权限 if not permission_service.check(user_id, tool_name): raise PermissionError(f"用户 {user_id} 无权调用 {tool_name}") # 2. 检查参数是否越权 if tool_name == 'update_document': doc_id = params.get('doc_id') if not document_service.is_owner(user_id, doc_id): raise PermissionError("只能修改自己的文档") # 3. 记录操作日志 audit_logger.log(user_id, tool_name, params) # 4. 执行工具 return tool_executor.execute(tool_name, params)

这段代码的核心逻辑不是技术难度，而是业务方关心的"可证明性"。你要有日志、有权限校验、有审计，才能让用户信任 AI。

---

作品集方向，别只做聊天 Demo

前端转大模型，作品集要体现工程能力，不是只会调 API。

推荐方向：

1. 带权限控制的 Agent。 实现工具调用，但加上权限校验和操作日志，能证明"AI 做了什么、谁让它做的"。
2. 流式输出优化。 做断线重连、部分渲染、错误兜底，体现前端工程能力。
3. 多模态应用。 图片理解、文档解析、语音输入，展示前端经验迁移。
4. 可观测性。 接口调用链、性能监控、错误追踪，体现生产级思维。

不要做的：

• 只做一个聊天界面，没有任何工程细节。
• 只做 Demo，没有错误处理、没有权限控制、没有日志。
• 只调 API，没有自己的架构设计。

---

总结

前端转大模型，优势在交互和状态管理，劣势在权限和安全意识。

业务方提需求时，流式输出是基础，权限隔离是信任。你先要能跑通 Demo，才能谈生产级应用。

我的建议：先做一个带权限校验和日志的 Agent 项目，把工具调用、权限预检、操作审计都实现。这个项目的复杂度足够面试时展示，也足够应对真实业务场景。

权限和日志不是大模型工程师的加分项，是必选项。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。