企业官网建设流程全解析

这篇我按“先跑起来、再讲取舍”的方式写《一个前端项目改成 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大模型里的哪类内容。