企业官网建设流程全解析

做AI产品三年复盘，我看到的变与不变

2021年底我们团队第一次把AI写进立项文档的时候，其实谁都没想清楚产品到底长什么样。三年过去，我作为全程参与的前端工程师，经历了从“画页面”到“设计对话”，从“被AI取代的焦虑”到“和能力边界共存”的完整周期。这三年里，前端在AI产品里的工作方式、技术栈、评价标准都在剧烈变化，但有些东西反而越来越清晰。

这篇文章不聊高深算法，也不做行业预测。我想以一个一线前端工程师的角度，把这三年的真实经历、踩过的坑、观察到的变化，以及那些始终没变的东西，系统性地复盘一遍。如果你正准备转行做AI产品、或者正在AI产品团队里做前端，这篇文章应该能给你一些参考。

1. 三年AI产品之路，从“被取代焦虑”到“客观看待”

1.1 我为什么开始碰AI产品

起因很朴素。2021年底团队做年中规划，数据分析发现核心业务的增速在放缓，管理层提了一个方向：能不能用AI能力做一款新的工具型产品。当时谁都没有相关经验，连模型API都没调过。前端组被拉过去的时候，最初的设想只是“接到一个H5页面需求”。

但需求评审会开到一半就发现不对劲。产品经理拿出来的不是原型图，而是一段“用户说一句话，系统返回一个结果”的流程描述。没有按钮、没有页面跳转、没有表单提交，只有一长串的“如果用户这么说，系统该怎么回应”。前端最熟悉的交互设计方法论突然失效了。

后来我们用了三个月时间，把一个连“流式输出”都不懂的Demo，做到了上线。过程中最大的感受不是技术难，而是“不知道该把代码写在哪一层”。传统的MVC、MVVM思维在AI产品里经常失灵，因为用户和系统的关系不再是“请求—响应”，而变成了“对话—生成—反馈—再对话”。前端不再只是负责渲染层，还要参与设计交互节奏、处理模型输出的不确定性、管理上下文状态。

1.2 前端的“被取代”焦虑是怎么来的

说实话，做AI产品的第一年，团队里弥漫着一种恐慌。GitHub Copilot刚火，ChatGPT还没完全爆发，但“AI能写代码”的论调已经铺天盖地了。加上公司内部开始推“AI赋能全流程”，不少前端同学担心自己的岗位价值会被压缩。

这种焦虑的产生有一部分合理性。因为第一年我们确实发现，很多重复性的页面开发、组件封装、样式调整，AI干得比人快。同一个内部后台系统，以前要三个前端排两周，用AI辅助之后一个前端加一个AI，三天就能把原型推到联调。我第一次在项目里用AI生成前端代码时，内心是拒绝的，但事实摆在那里——它生成的Element Plus表格组件，比我自己手写的bug还少。

后来焦虑逐渐消退，不是因为我们想通了什么大道理，而是因为开始处理AI生成不了的问题。比如AI生成的代码在低端安卓机上渲染崩溃，AI设计的交互在无障碍场景里一塌糊涂，AI优化的首屏方案把埋点体系弄出了大量重复上报。这些问题出现的时候，团队里能解决的还是前端工程师。也就是说，AI夺走的岗位价值，其实是我们本来就应该让出去的重复劳动。而AI暂时碰不到的那部分，才是这个岗位真正的护城河。

1.3 三年之后我看清楚了什么

今年做复盘的时候，我们整理了一份项目档案，发现三年里AI产品的前端需求发生了非常明显的变化。第一年做的页面以“结果展示类”为主：把模型返回的文本、表格、图表渲染出来就行。第二年明显转向“过程交互类”：用户要对AI生成的内容进行编辑、追问、重新生成，前端需要把这种多轮迭代的体验做顺滑。第三年则变成了“多Agent协作类”：页面上同时有多个AI角色在工作，前端要负责让这些并发过程在界面上有序呈现、可控操作。

这个变化让我彻底明白了一件事：前端在AI产品里不是被边缘化，而是被推向了更核心的位置。AI模型负责生成内容，但用户接触到的仍然是一个界面、一段交互、一种感受。把模型能力翻译成用户体验，这件事的复杂度和价值，比我入行时做的后台管理系统高太多了。

2. 变化的部分：前端工作流与能力模型的迁移

2.1 从“画页面”到“设计对话”与“编排智能体”

以前做前端，核心工作是“画页面”。拿到设计稿，切图、布局、适配、联调，流程是确定的。但AI产品不一样，大部分情况下连设计稿都没有，产品经理只会告诉你一句话：“用户问它问题，它要能流利地答出来。”

于是我们的工作重心从“画静态界面”变成了“设计对话节奏”。举个例子：用户问了一个问题，模型可能要两三秒才能生成第一个字。如果前端不做任何处理，用户的感知就是“卡住了”，他会刷新页面、重复提问。我们后来想了很多方案：先返回一个“正在思考”的动效、把历史对话即时渲染到窗口顶部、给流式输出的每个增量块设计平滑的入场动画。这些都不是产品经理要求的，而是前端在理解用户心理之后主动补上的。

到第三年，工作重心又变成了“编排智能体”。所谓智能体，就是在对话里引入多个角色分工协作，比如一个负责找资料，一个负责写初稿，一个负责审核。前端要做的，是在一个页面里同时管理多个流式事件——A智能体在搜索、B智能体在写作、C智能体在等待审核，这个并发过程如果不用可视化手段做清晰编排，用户很快就会迷路。我们当时参考了IDE的调试面板设计，把每个智能体的状态拆成独立的卡片式面板，用户可以随时暂停、恢复、重试任意一个环节。这套交互设计完全是从零开始的，既不是Web开发的传统模式，也找不到现成的组件库可以参考。

2.2 AI编程助手重构了日常开发流

说到变化，就绕不开AI编程工具对日常开发方式的冲击。以前一个前端项目，从技术选型到框架搭建，至少要花半天时间。现在用AI辅助，半小时就能把Vue3项目骨架、路由、状态管理、UI组件库全部配好。我以前从来不写单元测试，觉得那是测试工程师的活。但现在我会认真给核心模块写测试用例，因为AI能帮我把覆盖率冲到90%以上，自己只需要补几个边界场景。

这三年里我们总结了一套比较顺手的“AI辅助开发流程”：

• 先用一句话向AI描述需求，让它生成一个可运行的原型；
• 人工跑一遍，确定交互逻辑和数据结构的问题；
• 把问题反馈给AI，让它修改，但前提是我自己能看懂它的修改逻辑；
• 通过Code Review之后，再把代码合并进主干。

这个流程的关键不是“让AI多写代码”，而是“让AI少写错代码”。前端开发里真正耗时的是排错，而AI代码的排错成本不比手写低。尤其是组件库的按需引入、构建配置、浏览器兼容性这些问题，AI经常想当然。所以我的建议是：把AI当实习生用，活可以安排给它干，但关键节点的检查必须自己来。

2.3 前端工程里的AI能力渗透

三年里另一个显著变化，是AI能力逐步渗透到了前端工程体系内部，不再只是产品层面的一个功能。简单归类的话，大致有三类：

第一类是前端工具链智能化。比如用AI自动生成组件文档、自动识别项目里的重复代码并提示重构、通过历史提交记录预测潜在的样式冲突。我们的设计系统里接了一个AI插件，能直接把设计稿转成Vue代码，虽然生成结果还不能直接上线，但作为初稿能节省40%左右的切图时间。

第二类是前端运行时智能化。比如在页面上实现一个帮助按钮，用户点它的时候，前端采集当前页面状态发给大模型，模型给出操作建议。还有一个经典场景是客服系统里的“智能填单”：用户描述完问题，前端自动提取关键字段填充工单表单。这类功能不复杂，但需要前端对业务上下文有足够的理解才能定义好Prompt。

第三类是前端基础设施智能化。我们的监控平台接入了一个AI异常分析模块，前端上报的报错信息会先经过大模型归类，自动标注“是代码bug还是用户操作异常”，再转给对应的人。以前每天要花半小时过滤报警，现在只需要看一眼AI的分类结论。

这里顺便提一下大模型本地部署。业务里有一类场景比较敏感——用户数据不能出内网。于是我们调研了私有化部署方案，在内部服务器上跑了一个小参数模型做基础处理，前端通过局域网接口调用。这类项目对前端的要求很直接：你要懂模型服务是怎么暴露HTTP接口的，要了解Token限制、批量处理超时、流式输出的EventSource协议怎么对接。

3. 变化背后的技术逻辑：AI产品对前端的三次冲击

3.1 交互范式：从GUI到CUI，再从CUI回到GUI

AI产品带来的第一次冲击，是交互范式从图形界面（GUI）变成了对话界面（CUI）。用户不再通过“按钮—跳转”的路径导航产品，而是直接打字、说话。前端做的工作从“设计信息架构”变成了“设计对话流程”。如果你从来没做过，我打个比方：以前你在马路上画斑马线、设红绿灯，现在你是跟司机对话的交警，得随时随地根据来车方向和速度做出判断。

但做了两年之后，我们又发现一个反直觉的现象：AI产品不仅没有消灭图形界面，反而让图形界面变得更加重要。因为纯对话式交互在处理复杂任务时效率很低——你可以用文字描述“我想看上个月华东区的数据”，但没法用文字让一个复杂图表在一句话里完美呈现布局。所以现在的AI产品，普遍采用了“CUI+GUI混合交互”的模式：对话负责意图输入，图形界面负责结果呈现和细节操作。

前端在这套模式里的职责变得更加立体：对话窗口负责与模型交互，图表区域负责可视化模型输出，表单面板负责让用户对结果进行微调。我们用一个页面把这三个区域组织在一起，本质上是在搭建一个“人类与AI的协作工作台”。这个趋势对我来说是最大的变化——前端不再是“功能的展示层”，而是“人机协作图形的载体”。

3.2 前端框架与工程架构的边界拓展

第二次冲击来自工程架构。AI产品的前端页面天然有“长会话”和“多状态并发”的特征，这对框架选型和架构设计都产生了直接影响。

我们团队最开始用的传统Vue2单页应用架构，在遇到AI长会话场景时出现了不少问题。比如用户在对话中滚动历史记录，每次浏览器回收内存时，旧的DOM节点被销毁，用户再往上翻就得重新渲染一遍，整个页面会卡顿几秒。后来我试过用虚拟滚动来解决，但对话内容的长度不定、图片和代码块混排，虚拟滚动的坑非常多。

最终我们切换到Vue3，配合组合式API把对话状态机单独抽出来管理，页面渲染层只做轻量订阅，情况才好起来。在做技术选型对比的时候，我们列过一个表，记录了三个方案在“长会话场景”下的表现：

另外，AI产品往往不是单一应用，而是由多个子应用组合成的“AI工作台”。我们内部用qiankun搭了微前端架构，把算法团队的工具、业务团队的管理后台、用户端的对话界面拆成独立子应用。这套架构带来的好处是各团队可以独立发版，不用等整体排期。但微前端同样有代价：子应用之间的通信方式、公共依赖的版本管理、样式隔离策略都要提前设计，否则AI能力一旦多起来，整个平台的复杂度会指数级上升。

3.3 性能与体验边界：流式输出与Web Worker的回归

第三次冲击藏得比较深，但实际踩坑最多——性能。AI模型的推理结果几乎都是边生成边返回的，所以前端必须处理流式输出。而流式输出带来的问题，一开始完全超出了我们的预期：用户看到的文字每秒刷新几十次，如果每次刷新都触发一次Vue的响应式更新，页面会在低端设备上卡到无法操作。

后来我们针对这个问题做了重构，核心思路是把流式内容渲染从主业务渲染链路里隔离出去。方案是前端使用Web Worker来处理复杂的实时计算任务，Worker负责把流式数据切成增量块，主线程只负责接收已经解析好的纯文本并追加到DOM上。如果数据块是带格式的Markdown，我们就在Worker里做预处理，而不是在主线程里反复parse。这个优化做完，在同样一台低端安卓机上，页面的白屏阻塞时间从3秒降到了300毫秒以内。

除流式输出之外，AI产品里还有一种常见的性能重灾区——批量上传文件做知识库解析。最多的时候用户一次传了200个PDF，浏览器直接把主线程跑死了。我们的解法是前端使用Worker上传大文件，把文件切片、请求发送、进度计算全部放到Worker线程里，用户界面完全不受影响。这三个场景加起来逼我养成一个习惯：凡涉及AI产品的数据密集型交互，优先考虑多线程方案，而不是先写完了再说，否则后期重构成本非常高。

4. 不变的内核：前端在AI产品里的真正价值

4.1 “最后一公里”的体验仍然不能自动化

说了那么多变化，接下来聊聊那些三年下来几乎没变的东西。

第一件事，是“从模型能力到用户体验之间，还隔着一条最后一公里”。不管底层模型多强大，它输出的内容如果不经过前端的设计、加工、呈现，用户是不会认可的。模型可能给你一大段文字，但用户需要的是结构化的回答、可点击的按钮、可操作的表格。模型可能告诉你“根据数据，建议调整定价策略”，但用户需要的是一张清晰的比价图表，还需要能一键导出PDF。

我们项目里有个特别典型的案例。算法团队优化了一版摘要模型，在离线评测集上分数很高，但上线后用户反馈摘要“太长了，得下滑好几屏”。前端做的事情很简单：把摘要按关键信息点拆成卡片，首屏只显示结论，想看论据再展开。模型没变，用户满意度却提升了将近二十个百分点。这个案例让我深刻意识到，AI的能力半径再大，仍然需要前端来“接住”并翻译成人类友好的体验。这就是“最后一公里”，它不会因为AI变强就自动消失。

4.2 工程化、稳定性、可维护性依然是一道分水岭

第二件没变的事情，是工程化能力。哪怕AI能帮你生成大量代码，一个前端项目的工程化水平依然是决定成败的关键。

我见过不少AI生成的代码，跑Demo的时候效果惊艳，但一旦进入生产环境就暴露问题：没有埋点、没有异常处理、没有性能监控、目录结构混乱、依赖包来回冲突。这些问题的本质不是AI写得不好，而是缺少一层“工程性约束”。一个成熟的前端工程师，会在一开始就定义清楚项目的代码规范、目录结构、错误上报体系、单元测试策略。这些工作没有太多创造性，但它们是软件能不能长期演进的基础，任何一项缺失都会让项目在半年后变得寸步难行。

举个最简单的例子。AI生成的组件经常会直接操作状态来修改样式，这在功能上没问题，但它破坏了单向数据流约束，导致后面追踪bug极其困难。如果我们工程规范里规定“所有样式状态必须由脚本状态驱动”，那么AI生成的代码就必须经过改造才能合入。这个检查工作，AI自己不会做，必须前端来完成。

4.3 人机协作链路里，前端理解业务与用户的能力依然稀缺

最后一件没变的事，是前端对业务和用户的理解能力。这一点在AI时代不仅没有贬值，反而变得更稀缺了。

原因很简单：AI产品的不确定性比传统产品高得多。传统产品里，用户点击“删除”按钮，系统弹窗确认，行为是可预测的。但在AI产品里，用户输入千变万化，模型输出无法完全预知，产品体验的稳定性需要前端在代码层多下功夫。你得预判用户可能问什么、模型可能答错什么、错的时候界面该怎么给补救路径。这种预判能力，其实就来自对业务的理解和对用户心理的把握。

我们前端团队现在每个人都会参与业务需求的前置讨论，而不是只等产品经理出原型。因为一个对话机器人的产品经理很可能自己也说不清楚“用户会怎么措辞”“用户想要什么粒度的反馈”。前端如果懂业务，就能比算法工程师更早发现问题，比产品经理更早提出解决方案。这个优势在AI产品团队里特别明显，也是我三年里最深刻的职场体会。

5. 给准备入局AI产品的前端同学的建议

5.1 算法能力不是必需的，但AI常识是

很多前端同学想转做AI产品，第一反应是去学机器学习、深度学习，买一堆数学书从头啃。实际做了三年之后，我的看法是：对于前端工程师来说，系统性的算法能力不一定是必需项，但对AI的基本运行机制、能力边界、训练推理流程的常识性理解，是完完全全的加分项。

我合作过的几个前端同事，他们对AI的理解分成两种。一种只知道“调用接口拿结果”，遇到模型输出异常就甩给算法团队；另一种知道Prompt是什么、温度参数影响什么、模型为什么会“幻觉”、Token超限是什么问题。后一种同事在工作中几乎不用额外沟通成本，他们能自己定合理的界面降级方案，不会把AI的能力想得过于完美。

我给的建议是：不用去啃梯度下降，但至少要自己动手跑通一个大模型的本地部署，通读一遍模型服务的接口文档，理解流式输出的数据格式。这些常识不需要数学基础，花一两个周末就能掌握，但它在实际项目中的回报率非常高。另外，现在市面上也有spring AI这类后端框架，多少了解一下能让前后端协作更顺畅。

5.2 学会用“业务场景”倒推技术选型

前端圈子的技术风向变化极快，AI时代更是如此。今年流行这个框架，明年流行那个方案，如果跟着热度走，很容易疲于奔命。我的经验是：别从技术出发选技术，要从业务场景出发倒推。

比如我们接“AI产品大屏展示”这个需求的时候，第一反应不是“我要用大屏模板套一套”，而是先想清楚：用户是在什么场景里看这块大屏，是盯着实时监控还是做汇报，数据更新的频率是秒级还是分钟级，大屏的终端是投屏还是固定分辨率屏。这些问题想清楚之后，才会去选vue3加element plus这类组件库做自适应大屏方案。技术选型更像是在给业务场景配一个最合脚的容器，而不是让业务去迁就一个“最流行”的容器。

三年里我把这个原则记在本子上，收获非常大。它不仅能帮你避开大量无意义的框架争论，还能让你在技术评审会上跟其他后端、算法同事对齐语言——大家都聊业务问题，技术方案只是解决问题的工具。

5.3 少追新框架，多追“不变的需求”

最后一条建议，也是我特别想对所有前端同学说的：在这个时代，学习新框架的速度不如理解“不变需求”的速度值钱。

所谓不变的需求，就是用户需要流畅的操作、清晰的信息、及时的正反馈、安全可靠的数据处理。不管界面是对话框、面板，还是多Agent工作台，这些底层需求永远不会变。只要你能稳定地满足这些需求，任何新框架、新工具对你来说都只是“换个工具箱”而已。

我在复盘三年项目的时候，翻到最初几个月写的代码，发现很多当时觉得很先进的写法，现在看来已经过时了。但那些用户反馈最好、复用率最高的模块，都遵循着最质朴的原则：状态清晰、交互及时、错误有兜底。所以我把这篇文章取名叫做“变与不变”，变的永远是工具层和交互层的具体形态，不变的是前端工程师用代码连接人与计算能力的职责本质。

如果你正准备进入AI产品领域，我的态度是：放心来，但别只盯着那些炫酷的AI效果，真正让你站稳脚跟的，还是把一条流式消息渲染得行云流水、把一个复杂对话流程管理得井井有条的“基本功”。这三年的经历让我相信，AI改变的是前端的工作方式，而不是前端的价值本身。