聊《做过前端的人学大模型哪些经验可以直接迁移》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要上个月接了个活帮一个做知识管理的团队搭 AI 助手。业务方开场就说要流式输出要能读文档还要能调内部接口改数据。流式输出前端同学闭着眼都能写。权限隔离说实话我第一次做的时候差点翻车。这篇文章不是教你怎么调 API而是复盘一次真实项目里前端经验怎么用、哪里会踩坑、业务方提需求时你怎么判断优先级。---目录前端的转型优势别只盯着 UIAI 应用交互模式和传统页面不一样流式输出前端最熟但别大意多模态体验前端经验可以直接用权限隔离才是业务方真正在意的作品集方向别只做聊天 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大模型里的哪类内容。