这篇我按“先跑起来、再讲取舍”的方式写《一个前端项目改成 AI 流程后，最难的部分完全变了》。概念会讲，但重点放在代码怎么组织、哪里容易踩坑。
摘要
去年我帮一个前端朋友搭了一个简单的对话产品，Demo 跑起来那天他特别兴奋。三个月后他问我：为什么这个功能上线后，用户抱怨比 Demo 里多十倍？
我说：因为 Demo 里没人会越权操作，没人会批量刷接口，也没人会在日志里查问题。
前端转大模型，最大的坑不在模型调用，而在权限、日志和可观测性。这些是页面开发里很少碰的东西，却是 AI 产品上线后最致命的地方。
目录
- 前端转型的优势，其实比你想象的硬
- AI 应用的交互模式，和页面开发完全不同
- 流式输出：别只学会 SSE，要会处理失败和边界
- 多模态体验：前端最容易忽略的"感知层"
- 小团队如何避免过度设计
- 作品集方向：别只放 Demo，放证据
- 总结
前端转型的优势，其实比你想象的硬
很多人觉得前端转大模型要从零开始学 Python、学 LangChain、学 RAG。这没错，但不对。
前端真正稀缺的是两样东西：一是产品化思维，二是用户交互直觉。
大模型应用现在最大的问题是 Demo 和产品的割裂。后端工程师写的 Agent，Prompt 调得再好，用户用着别扭。前端工程师写出来的东西，用户愿意点、愿意用、愿意反馈。
我之前带过一个项目，后端调了两周的 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大模型里的哪类内容。