里小咸前端+AI这个方向，最近真的是被问爆了。不管是社区里晒的AI编程工具测评，还是各路面试题里突然冒出来的“你用过哪些AI辅助开发方式”，都能感觉到前端和AI之间那道墙正在被快速拆掉。我自己从第一天开始折腾这个项目，到今天进入第二天，最大的感受是：前端+AI不再是“调一个接口那么单薄”，而是从交互形态、数据流、组件设计到调试方式，整个链路都被重构了。这篇笔记我就把今天实际动手验证过的东西，连同踩到的坑一起记录下来，给同样走在这条路上的朋友做个参考。
1. AI项目前端的整体架构到底该怎么拆
1.1 我理解的“AI应用前端”包含三个层面
今天动手之前，我先把前端+AI项目的技术栈重新捋了一遍。很多人一提到AI应用，第一反应就是“在页面上加个聊天窗口”，这个理解实在过于表面。我现在更倾向把AI项目的前端拆成三个层面：
第一层是交互承载层，也就是用户直接看到和操作的部分。聊天窗口只是其中一种形式，还有表单式的参数配置界面、可视化的工作流编排界面、对话式报表、AI辅助写作的富文本编辑器等等。这一层的核心问题是：如何在原来的业务界面里优雅地嵌入AI能力，而不是把AI功能做成一个孤岛。
第二层是连接与协议层，负责前端和AI服务端的数据交换。这里包含了大模型API的调用鉴权、流式输出的接收与解析、取消与重连、消息上下文的组织方式。这一层最容易被初学者忽略，但实际做起来，坑最多、也最影响体验。我下面会详细写今天实操中的几个关键点。
第三层是前端工程化层，包括AI组件的封装、类型定义、状态管理、多轮对话的消息数据结构设计，以及IDE里的AI辅助开发工具链。这个层面决定了项目能不能规模化地加功能，而不是越写越乱。
把这三层分清楚之后，再看那些热门技术词就容易多了。比如“前端AI工具”“AI编程提示词”“JSON.stringify前端性能优化”，其实都分属于不同层面，不要混为一谈。
1.2 为什么前端在今天突然变得这么重要
一个很直观的现象：大模型的能力再强，如果交互界面做得反人类，用户照样不买账。前几年大家还在比模型参数，一年内赛道就卷到应用层了。而那些真正让用户觉得“AI懂我”的产品，恰恰是在前端交互上下了功夫的——比如打字机式的流式输出、可中止生成、上下文可视化、预设Prompt模板等等。
所以前端工程师在AI项目里的角色不是“画页面”，而是要解决“人如何跟AI高效协作”这个问题。这个定位比传统前端要高很多，也因此前端+AI相关的面试题越来越偏重应用场景和工程落地。我在准备这个项目时，给自己定的原则就是：不讨论模型怎么训练，只看怎么把已有能力用扎实。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三种交互形态与我的取舍思路
2.1 普通业务页面嵌入AI能力
第一种形态是在普通业务系统中嵌入AI功能，比如管理后台里的“一键生成周报”、表单里的“智能填写提示”。这种形态的特点是保留原有业务界面为主，AI只是配角。
做成这种形态，前端通常需要封装一个“AI气泡助手”或者“右键唤起AI”的交互组件。我当时调研了两种做法：一种是在指定输入框旁加触发按钮，点开后弹一个小浮层展示AI返回内容；另一种是把AI能力绑定到选区或右键菜单上，比如用户选中一段文本，就出现“润色”“翻译”“总结”等操作项。
从工程实现上看，第二种要比第一种复杂很多，需要处理选区位置、动态定位、文本替换后的光标恢复等问题。但如果目标是AI辅助写作类的场景，第二种体验确实更好。我的决定是：第一阶段先做第一种，因为好调试、能快速出效果；后续再迭代第二种。
2.2 独立AI对话界面的信息架构
第二种形态是独立的AI对话界面，对应热搜词里反复出现的“ai无禁词聊天网页版”“无限制聊天AI”等。这里要特别说一句：做产品时千万别去碰那些打着“无限制”“无审核”旗号的噱头，合规底线不能动。真正值得关心的是：在合规前提下，为了让对话体验接近自然交流，前端需要做些什么。
我实际做下来，一个完整可用的对话界面需要这些模块：会话列表（管理多个历史对话）、消息区（正确展示角色区分和渲染富内容）、输入区（支持发送、停止生成、多行输入）、还有设置区（模型选择、参数调整）。别小看这个架子，每块都有细节。
最让我花时间的是消息区的数据结构设计。前后端约定消息对象时，不能只放一个“content”字符串，因为你会在里面遇到工具调用结果、引用来源、思考过程、多模态附件等多种类型。建议从一开始就引入消息类型字段，比如“text”“tool_call”“image”“system_notice”，前端根据类型做不同渲染。这块如果前期设计得不清晰，后面加功能会非常痛苦。
2.3 AI Agent类产品前端的特殊性
第三种形态是AI Agent类产品，对应热搜词里的“ai agent”。这类产品前端和普通聊天AI最大的区别在于：用户不止看得到文字回复，还要看到AI在“做什么”。比如Agent在读取文件、在查询数据、在执行代码生成操作的时候，前端需要实时展示这些中间步骤。
我做了一个简单的运行日志面板，用类似终端的形式把每一步的状态打印出来。数据是通过WebSocket实时推送的，状态包括“开始执行”“执行中”“成功/失败”等。这个面板在调试时救了我很多次，因为Agent的逻辑链路长时，出问题你根本不知道卡在哪一步。
相比之下，给Agent配置外部工具（比如搜索、绘图）后，前端还要能展示结构化的工具调用参数和结果，这就更偏向工作台形态了。我后面会重点补这块。
2.4 我的选型结论：三种形态并不是互斥的
实操下来，我发现这三种形态不是非此即彼，更像一个产品的三个成长阶段。刚开始做一个“业务页面+AI助手”，跑通了再升级成独立的“对话工作台”，最后加入Agent能力成为自动化工具。别一上来就搞全套，建议按业务需求逐步演化。我的项目就从独立对话工作台开始切入，因为最容易验证API调用和流式通信链路，等链路稳了再反哺到业务页面上。
3. 今天实操的核心：封装一个可靠的流式请求模块
3.1 为什么流式输出是硬需求
今天花时间最多的是流式输出的实现。Streaming Response