这篇我按“先跑起来、再讲取舍”的方式写《一个前端项目改成 AI 流程后最难的部分完全变了》。概念会讲但重点放在代码怎么组织、哪里容易踩坑。摘要去年我帮一个前端朋友搭了一个简单的对话产品Demo 跑起来那天他特别兴奋。三个月后他问我为什么这个功能上线后用户抱怨比 Demo 里多十倍我说因为 Demo 里没人会越权操作没人会批量刷接口也没人会在日志里查问题。前端转大模型最大的坑不在模型调用而在权限、日志和可观测性。这些是页面开发里很少碰的东西却是 AI 产品上线后最致命的地方。目录前端转型的优势其实比你想象的硬AI 应用的交互模式和页面开发完全不同流式输出别只学会 SSE要会处理失败和边界多模态体验前端最容易忽略的感知层小团队如何避免过度设计作品集方向别只放 Demo放证据总结前端转型的优势其实比你想象的硬很多人觉得前端转大模型要从零开始学 Python、学 LangChain、学 RAG。这没错但不对。前端真正稀缺的是两样东西一是产品化思维二是用户交互直觉。大模型应用现在最大的问题是 Demo 和产品的割裂。后端工程师写的 AgentPrompt 调得再好用户用着别扭。前端工程师写出来的东西用户愿意点、愿意用、愿意反馈。我之前带过一个项目后端调了两周的 Prompt准确率从 60% 提到 78%。我一个前端同学加了个交互引导把问题拆成三步准确率直接跳到 91%。用户不知道模型内部发生了什么但知道该点什么。所以转型的第一步不是学框架而是把你的产品直觉迁移过来。AI 应用的交互模式和页面开发完全不同传统页面开发是请求-响应用户点按钮服务器返回结果结束。AI 应用是流式的、异步的、不确定的。用户发一个问题模型可能在想可能在查工具可能在调用多个 API然后慢慢吐出答案。这个差异直接决定了交互设计思路。传统页面可以等结果再展示AI 应用必须边生成边展示。这就是流式输出的意义。流式输出别只学会 SSE要会处理失败和边界流式输出现在几乎是标配了。大多数教程教你怎么用EventSource或者 fetch 流式读取但没教你怎么处理中途失败、怎么处理网络抖动、怎么处理模型输出截断。我见过的翻车场景用户网络断了流式连接没断开页面一直转圈模型生成到一半超时前端只展示了半句话用户以为这就是最终答案流式数据太大内存爆了页面卡死代码层面一个基本的流式读取应该是这样的async function callModelStream(prompt) { const response await fetch(/api/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ prompt }), }); if (!response.ok) { throw new Error(HTTP ${response.status}); } const reader response.body.getReader(); const decoder new TextDecoder(); let fullText ; let isComplete false; while (!isComplete) { const { done, value } await reader.read(); if (done) { isComplete true; break; } const chunk decoder.decode(value, { stream: true }); const lines chunk.split(\n); for (const line of lines) { if (line.startsWith(data: )) { const data line.slice(6); if (data [DONE]) { isComplete true; break; } try { const parsed JSON.parse(data); fullText parsed.choices?.[0]?.delta?.content || ; onUpdate(fullText); // 更新UI } catch (e) { console.warn(解析流式数据失败, e); } } } } return fullText; }这段代码看着简单但有几个坑必须注意1. 解码要用stream: true否则中文字符会乱码2. 要处理[DONE]信号否则循环不会退出3. 要加 try-catch 解析 JSON流式数据中间可能有脏数据4. 要处理网络中断上面这段代码没有 AbortController实际项目必须加多模态体验前端最容易忽略的感知层大模型现在不止能输出文字还能输出图片、表格、代码块、交互组件。但很多前端同学在做 AI 产品时还是把模型输出当纯文本处理。模型明明返回了 Markdown你直接 innerHTML 渲染代码块没有高亮表格没有样式图片没有懒加载。这不是技术难点是产品意识问题。我建议前端转型的同学把重点放在渲染层的能力建设上。一个能正确处理 Markdown、代码高亮、表格、图片的多模态渲染器比你会调十个 Prompt 模板更有价值。小团队如何避免过度设计现在 Agent 框架满天飞LangGraph、AutoGen、CrewAI、Dify、Coze……每个都在说能解决什么问题。但小团队资源有限我的建议是先跑通权限和日志再考虑 Agent 编排。一个最简单的权限控制方案# 伪代码示例 def execute_with_permission(user_id, action, resource_id): # 1. 检查用户权限 if not check_permission(user_id, action, resource_id): log_event(permission_denied, user_id, action, resource_id) raise PermissionError(无权操作) # 2. 执行操作 result do_action(user_id, action, resource_id) # 3. 记录日志 log_event(action_success, user_id, action, resource_id, result) return result日志记录什么谁user_id做了什么action对什么资源resource_id结果是什么花了多少 token成本可观测响应时间性能可观测这些东西在 Demo 阶段不需要但上线后每一天都需要。用户投诉了你能查到是哪一步出的问题。成本超了你能定位是哪个接口在烧钱。作品集方向别只放 Demo放证据很多前端同学转型时作品集里放的是我能调用 API 做对话。这不够。建议放这些1. 一个有完整权限控制的 AI 应用展示你怎么防止越权操作2. 一个带可观测性的项目展示你的日志体系、成本监控、性能追踪3. 一个处理过真实失败场景的项目展示你如何处理网络中断、模型超时、输出截断这些东西在面试时比我调了 Claude API有说服力得多。总结前端转大模型最大的优势是产品化和交互直觉最大的坑是权限、日志和可观测性。不要一上来就卷 Agent 框架先把基础打牢。一个小团队一个能跑的权限系统一套完整的日志体系比十个 Demo 更有价值。模型会迭代框架会更新但工程化的底线不会变。守住底线再谈创新。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。