聊《大模型岗位变了前端工程师该补的还是算法吗》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要先把这篇文章的目标说清楚看完之后你应该能判断这件事值不值得做以及从哪里动手。很多前端同学最近问我同一个问题“我想转大模型应用开发是不是得去补 Transformer 原理是不是要刷 LeetCode 的 Hard 题”我的回答通常很直接如果你只会调 API 写个聊天框那确实不用补算法但你也根本进不了真正的 AI 工程团队。现在的招聘风向变了。2024 年初只要你能用 LangChain 搭个 RAG Demo随便找个向量数据库就能忽悠住面试官。但到了今天企业关注的重心已经从“能不能跑通”变成了“敢不敢上线”。当 AI 应用开始接触真实用户权限隔离RBAC、全链路日志和可观测性就成了横在前端转行者面前的一道高墙。我也曾以为前端擅长的是“渲染”和“状态管理”而后端擅长的是“逻辑”和“数据”。但在构建 Agent 应用时我发现这两者的界限正在模糊。一个优秀的 AI 产品经理型前端不仅要能把大模型的流式输出渲染得丝般顺滑更要懂得如何在客户端拦截敏感信息如何配合后端追踪每一次 Token 消耗的来龙去脉。目录前端的转型优势从“画页面”到“定义交互边界”从 Demo 到工程化权限与日志的真实拷问作品集方向别再放“天气查询”Bot 了总结补齐“工程边界感”前端的转型优势从“画页面”到“定义交互边界”前端最大的误区是把自己定位为“切图的”。在大模型时代前端其实是用户体验的第一道防线也是系统安全的第一道闸门。以流式输出为例这不仅是前端的技术活更是产品设计活。传统的 Web 开发接口返回 JSON你解析后渲染。AI 应用接口返回 SSEServer-Sent Events你需要处理分片、光标闪烁、打字机效果还要处理网络抖动导致的断连重试。更重要的是前端决定了 Agent 的“行为边界”。在后端你可以配置复杂的权限逻辑但如果前端没有做好“所见即所得”的反馈用户就会觉得 AI 很蠢。比如一个需要调用内部 CRM 系统的 Agent如果前端在用户点击“生成报告”后没有明确的状态指示加载中、权限校验中、生成中用户会疯狂点击按钮导致后端重复请求甚至触发限流。我之前负责的一个内部知识库项目后端权限做得滴水不漏但前端因为没处理好“无权限”时的 UI 降级导致普通员工看到的是白屏而不是友好的提示。这在面试中是个很好的反面案例你不仅关注 API 的连通性更关注异常状态下的用户体验和安全性。从 Demo 到工程化权限与日志的真实拷问这是我最想强调的部分。很多面试者拿着一个跑通的 Jupyter Notebook 去应聘结果被问到“如果用户 A 通过前端接口查询了数据如何确保他看不到用户 B 的数据”在 Demo 阶段你可能直接用openai.ChatCompletion传入用户的 query。在生产环境这个 query 往往带有上下文Context。如果你的前端直接把所有历史对话传给后端而后端又没做严格的会话隔离这就存在巨大的隐私泄露风险。1. 权限隔离RBAC在前端的体现前端虽然不直接执行数据库查询但前端必须传递正确的身份凭证和作用域Scope。// 典型的错误做法依赖前端传来的 role 字段 async function callAI(query: string, role: string) { const response await fetch(/api/chat, { method: POST, body: JSON.stringify({ query, role, // 危险前端可篡改 context: history }) }); } // 正确的工程化做法前端只传 token后端解析权限 async function callAIWithAuth(query: string) { const token await getValidAccessToken(); // 从 Auth0/AWS Cognito 获取 const response await fetch(/api/chat, { method: POST, headers: { Authorization: Bearer ${token}, Content-Type: application/json }, body: JSON.stringify({ query }) }); return response.json(); }在面试中如果你能主动提到“我会确保前端不信任任何来自客户端的角色信息所有的权限校验都在 Gateway 层或后端 Service 层完成并通过 JWT 中的 Claims 传递最小必要信息”这比你会写 100 种 Prompt 都要加分。2. 可观测性与日志追踪前端是大模型应用的“眼睛”。当 AI 回答错误时后端可能需要几分钟才能排查出是哪条 Prompt 出了问题或者哪个向量检索失败了。前端需要做两件事1. 唯一追踪 IDTraceID每个请求生成一个 UUID贯穿整个调用链。2. 关键指标上报不仅记录“成功/失败”还要记录“首字延迟TTFT”、“总耗时”、“Token 数量”。interface MetricLog { traceId: string; userId: string; event: start | stream_chunk | end; timestamp: number; metadata?: Recordstring, any; } function logMetric(log: MetricLog) { // 实际项目中这里应发送到 Prometheus/Grafana 或 ELK 栈 console.log([Trace:${log.traceId}], log.event, log.timestamp); } // 在流式处理中使用 const traceId crypto.randomUUID(); logMetric({ traceId, userId: currentUser.id, event: start, timestamp: Date.now() }); // ... 接收 SSE 数据 ... onStreamChunk((chunk) { logMetric({ traceId, userId: currentUser.id, event: stream_chunk, timestamp: Date.now(), metadata: { tokens: chunk.length } }); });如果你能在简历里写出“我引入了基于 TraceID 的全链路监控将 AI 响应异常的定位时间从小时级降低到分钟级”这就是真正的工程化思维。作品集方向别再放“天气查询”Bot 了如果你想转行你的 GitHub 作品集应该反映上述的工程能力。以下是几个建议的方向1. 带权限控制的内部知识库助手* 实现一个前端界面模拟登录不同角色Admin/Viewer。* Admin 可以看到所有文档的引用链接Viewer 只能看到脱敏后的摘要。* 关键点展示你是如何处理 SSE 流中断连重连以及如何确保权限校验在前后端的一致性。2. AI 性能监控仪表盘* 做一个专门用于观察 LLM 请求状态的 Dashboard。* 展示不同 ProviderOpenAI, Claude, Local Model的首字延迟对比。* 包含一个“错误率趋势图”展示在 Prompt 注入攻击下的系统稳定性。3. 可配置的 Agent 工作流编辑器* 类似 Dify 或 Coze 的简化版。* 前端使用 Canvas 或 SVG 绘制节点实现拖拽连线。* 重点在于如何将前端复杂的拓扑结构序列化为后端可执行的 DAG有向无环图JSON并确保在执行过程中的状态同步。总结补齐“工程边界感”前端转大模型核心不是去学怎么训练模型而是学会如何在不确定性的 AI 系统中建立确定性的工程规范。面试官不再关心你是否背熟了 BERT 的架构他们关心的是当 LLM 产生幻觉时你的前端如何优雅地提示用户当用户输入敏感信息时你的前端是否做了过滤或脱敏当服务超时或报错时你的前端是否有完善的降级策略和日志上报Demo 只是入场券权限与日志才是护城河。 从今天开始把你写的每一个 AI 功能模块都当成一个小型的微服务去设计考虑它的输入输出、错误处理和监控指标。这才是从“页面开发”迈向“AI 产品工程师”的关键一步。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。