1. 三个月学习计划的设计逻辑与目标拆解1.1 为什么是“三个月”而不是更长或更短我带过不少从传统前端转 AI 应用方向的朋友也见过很多自学的人卡在“学不完”和“学完不会用”这两个极端上。三个月这个周期不是拍脑袋定的它刚好对应一个完整的能力闭环第一个月建立认知和基础调用能力第二个月进入 RAG 和 Agent 的实战第三个月做完整项目并补齐工程化短板。再短你只能停留在调 API 的层面简历上写不出有说服力的东西再长大部分人会在第二个月中段失去节奏因为没有阶段性产出动力会断。从招聘方的角度看一个前端背景的人转 AI 应用方向他们最关心的不是你懂多少模型原理而是你能不能把 LLM 的能力稳定地接进一个真实产品里。这包括流式输出怎么处理、上下文怎么管理、RAG 的召回质量怎么调、Agent 的工具调用怎么兜底。这些东西没有两三个月的持续动手是练不出来的。1.2 这个计划适合谁不适合谁适合的人有 JavaScript/TypeScript 基础写过 React 或 Vue 项目对前端工程化构建、状态管理、接口封装有实际经验想往 AI 应用方向靠拢的人。你不需要会训练模型也不需要懂反向传播但你需要能读懂 API 文档能自己排查网络请求问题。不适合的人完全没有编程基础的人。这个计划里大量内容涉及异步编程、流式数据处理、向量检索的调试没有前端基础会非常吃力。另外如果你只是想“了解一下 AI”那也不需要三个月花一个周末看看文档就够了。这个计划的目标是让你能独立交付一个可演示、可讲清楚的 AI 应用项目。1.3 三个月的能力地图我把三个月拆成三条主线每条主线对应一个核心产出阶段时间核心能力产出物第一阶段第 1-4 周LLM 调用、流式输出、Prompt 工程一个可对话的 Web 界面第二阶段第 5-8 周RAG 知识库、向量检索、Agent 工具调用一个带知识库的问答应用第三阶段第 9-12 周工程化、性能优化、项目包装一个完整可演示的项目这三条主线不是割裂的第一阶段写的对话界面会在第二阶段被改造成知识库问答的前端第三阶段则是在前两个阶段的基础上做优化和收尾。这样安排的好处是你始终在同一个项目上迭代不会出现“学一个丢一个”的情况。2. 第一阶段LLM 调用与对话界面实战2.1 先搞清楚 LLM 调用的本质是什么很多人一上来就去看 LangChain 的文档结果被各种概念绕晕。我的建议是先用最原始的方式调一次模型 API把请求和响应的结构看清楚。LLM 的调用本质上就是一次 HTTP 请求你发一段文本过去它返回一段文本。所谓“流式输出”就是服务端不一次性返回完整结果而是分块返回前端逐块渲染。这里有一个关键概念需要理解token。模型处理文本不是按字处理的而是按 token。一个中文汉字大约对应 1-2 个 token英文单词大约 1-1.5 个 token。为什么这个重要因为计费按 token 算上下文长度限制也按 token 算。你在设计 Prompt 的时候如果塞了太多历史对话很容易超出模型的上下文窗口导致请求失败。我通常建议在第一周就动手写一个最小的调用示例不要用任何框架直接用 fetch 或 axios 发请求。这样你能清楚地看到请求体里有什么model 名称、messages 数组、temperature、max_tokens 这些参数分别控制什么。等你把这一层搞明白了再去用框架就不会被抽象层遮住眼睛。2.2 流式输出在前端怎么落地流式输出是 AI 应用前端和传统前端差异最大的地方。传统前端请求接口等一个完整响应回来再渲染。但 LLM 的响应可能长达几千字如果等全部生成完再显示用户会以为页面卡死了。所以必须用流式。实现流式输出的核心技术是 Server-Sent Events 或者 ReadableStream。如果你用 fetch可以通过 response.body.getReader() 拿到一个 reader然后循环读取 chunk。每个 chunk 是一段二进制数据需要解码成文本再按 SSE 格式解析出实际内容。这里有几个坑我踩过第一chunk 的边界不一定和消息边界对齐也就是说一个完整的 SSE 消息可能被拆到两个 chunk 里你需要维护一个缓冲区来拼接。第二不同服务端返回的 SSE 格式可能略有差异有的用data:前缀有的直接返回 JSON 行。第三流式输出过程中如果用户刷新页面你需要决定是中断请求还是让服务端继续生成。这些细节在文档里通常不会写但实际做的时候一定会遇到。我的做法是封装一个通用的流式请求函数把缓冲区管理、错误重试、中断控制都放在里面业务组件只负责调用和渲染。这样后续换模型或换服务商时只需要改这一个函数。2.3 Prompt 工程不是玄学是结构化表达Prompt 工程经常被说得神乎其神但我的经验是它本质上就是把你想要的东西用结构化的方式说清楚。一个好的 Prompt 通常包含这几个部分角色设定、任务描述、输入数据、输出格式要求、约束条件。举个例子如果你想让模型帮你从一段文本里提取关键信息不要只说“帮我提取一下”而是要说清楚你是一个信息提取助手请从下面的文本中提取出人名、公司名和职位以 JSON 格式返回如果某个字段不存在则填 null。这样模型输出的稳定性会高很多。在第一阶段我建议你花时间练习写不同风格的 Prompt然后观察模型的输出变化。特别是 temperature 这个参数调高会让输出更随机调低会更确定。对于需要稳定输出的场景比如结构化提取temperature 设成 0 或 0.1 比较合适对于创意写作类场景可以调到 0.7 以上。2.4 对话界面的状态管理怎么做一个对话界面看起来简单但状态管理比想象中复杂。你需要管理消息列表、当前输入、加载状态、流式输出中的临时消息、错误状态、历史会话切换。如果用 React我建议把消息列表和流式状态分开管理因为流式输出时消息内容在不停变化如果和消息列表放在同一个 state 里会导致整个列表频繁重渲染。一个实用的做法是流式输出中的消息用一个单独的 state 存等流式结束后再合并到消息列表里。这样渲染性能会好很多。另外消息列表的滚动行为也需要处理新消息进来时自动滚到底部但如果用户手动往上翻了就不要强制滚动。这个细节直接影响用户体验。3. 第二阶段RAG 知识库与 Agent 工具调用3.1 RAG 到底解决了什么问题RAG 是 Retrieval-Augmented Generation 的缩写翻译过来就是“检索增强生成”。它的核心思路是模型本身的知识是有限的而且可能过时那我在回答问题之前先去一个知识库里检索相关内容把检索到的内容作为上下文一起发给模型这样模型就能基于最新、最准确的信息来回答。为什么前端工程师要懂 RAG因为 RAG 应用的体验很大程度上取决于前端。检索结果怎么展示、引用来源怎么标注、用户怎么反馈检索质量这些都是前端要处理的。而且 RAG 的调试过程中前端是最直观的观察窗口。RAG 的流程可以拆成三步索引、检索、生成。索引阶段把文档切块、向量化、存入向量数据库检索阶段把用户问题向量化在数据库里找最相似的块生成阶段把检索到的块和用户问题一起发给 LLM让它基于这些内容回答。3.2 文档切块的策略与参数选择文档切块是 RAG 里最容易被忽视但影响最大的环节。切得太碎每个块缺少上下文检索出来的内容不完整切得太粗一个块里混了多个主题检索精度会下降。我的经验是对于技术文档类内容块大小设在 500-800 个 token 比较合适块之间保留 100-150 token 的重叠。重叠的目的是防止一个完整的语义单元被切断。比如一段代码示例如果刚好从中间切开检索出来就没法用。切块的方式也有讲究。最简单的是按固定长度切但更好的方式是按语义切比如按段落、按标题层级切。如果你用的是 Markdown 文档可以按标题切每个二级标题下的内容作为一个块。这样每个块的主题比较集中检索效果会更好。还有一个细节每个块最好带上一些元数据比如来源文件名、标题路径、块序号。这样在展示检索结果时可以告诉用户“这段内容来自某某文档的某某章节”增加可信度。3.3 向量检索的召回质量怎么调向量检索的核心是相似度计算。用户问题向量化之后和数据库里每个块的向量算相似度取 top-k 个最相似的。这里有几个参数可以调k 值、相似度阈值、是否做重排序。k 值一般设 3-5 比较合适。太小可能漏掉关键信息太大则会引入噪声而且会增加 token 消耗。相似度阈值用来过滤掉明显不相关的结果一般设在 0.7 左右但具体值要看你的向量模型和数据类型需要实际测试。如果召回质量不理想可以考虑加一个重排序步骤。重排序是用一个专门的模型对检索结果重新打分把最相关的排到前面。这个步骤会增加延迟但对精度提升很明显。我通常建议在检索结果超过 5 条时启用重排序。还有一个容易被忽视的点用户问题的改写。用户问“这个功能怎么用”直接拿这句话去检索可能效果不好。可以先用 LLM 把问题改写成更具体的查询比如“XX 功能的配置步骤是什么”再去检索。这个技巧叫“查询改写”对提升召回率很有效。3.4 Agent 工具调用的基本模式Agent 的核心是让模型能够调用外部工具。比如用户问“今天天气怎么样”模型本身不知道实时天气但它可以调用一个天气查询工具拿到结果后再回答。工具调用的实现方式通常是你在请求里定义好可用的工具列表每个工具包含名称、描述、参数 schema。模型在生成回复时如果判断需要调用工具会返回一个工具调用请求包含工具名和参数。你的后端执行这个工具把结果再发给模型模型基于结果生成最终回复。这里的关键是工具描述要写清楚。模型是根据描述来判断什么时候该用哪个工具的。如果描述模糊模型可能该调用的时候不调用或者调用了错误的工具。我的经验是工具描述里要明确说明这个工具做什么、什么时候用、参数是什么意思、返回什么格式。前端在 Agent 场景下的职责是展示工具调用的过程。用户需要知道模型正在做什么而不是干等。可以展示“正在查询天气...”、“正在搜索知识库...”这样的状态提示让整个过程透明化。4. 第三阶段工程化收尾与项目包装4.1 性能优化的几个关键点AI 应用的性能瓶颈通常不在前端渲染而在网络请求和模型推理。前端能做的优化主要有请求缓存、并发控制、懒加载、流式渲染优化。请求缓存方面对于相同的问题可以缓存模型回复避免重复请求。但要注意如果知识库更新了缓存需要失效。并发控制方面如果页面同时发起多个 LLM 请求可能会导致限流或超时需要加一个请求队列。流式渲染优化方面不要每收到一个 chunk 就触发一次 React 重渲染。可以用 requestAnimationFrame 做节流或者用一个 ref 直接操作 DOM 更新文本内容等流式结束后再同步到 state。这个优化在长文本输出时效果很明显。4.2 错误处理与降级策略LLM 应用的不确定性比传统应用高很多。模型可能超时、可能返回格式错误的内容、可能触发内容过滤。你需要为这些情况设计降级策略。比如如果模型调用失败可以重试一次如果重试还失败给用户一个友好的提示而不是白屏。如果模型返回的 JSON 格式不对可以尝试用正则提取或者让模型重新生成。如果流式输出中途断了可以保留已生成的内容并提示用户“回复未完成”。还有一个重要的点超时设置。LLM 的响应时间可能从几百毫秒到几十秒不等你需要设置一个合理的超时时间并在超时后给用户反馈。我通常设 30 秒作为默认超时对于复杂任务可以延长到 60 秒。4.3 项目包装与简历表达三个月结束后你需要一个能拿得出手的项目。这个项目不需要多复杂但需要完整有明确的用户场景、有可演示的界面、有可讲清楚的技术方案。在简历上不要只写“使用了 LLM 和 RAG”而要写清楚你解决了什么问题。比如“针对内部文档检索效率低的问题设计并实现了一个基于 RAG 的问答系统将平均查找时间从 5 分钟降低到 30 秒”。这样的表达比罗列技术栈有说服力得多。面试时面试官通常会问你为什么选择这个切块大小检索效果不好时你怎么排查流式输出中断了怎么处理这些问题都需要你有实际的调试经验才能回答。所以我在前面强调每个环节都要动手做不要只看文档。4.4 持续迭代的方向三个月只是一个起点。做完第一个项目后你可以往几个方向深入一是多模态把图片、音频也纳入 RAG 的范围二是 Agent 的复杂编排让多个 Agent 协作完成一个任务三是性能优化比如用本地模型替代 API 调用降低成本。但我的建议是不要急着铺开先把一个方向做深。比如你选择了 RAG 方向就把检索质量优化到极致尝试不同的向量模型、不同的切块策略、不同的重排序方案把每个参数的影响都摸清楚。这种深度经验比广度更有价值。5. 常见问题与排查技巧实录5.1 流式输出相关的问题问题一流式输出时文字闪烁或跳动。这通常是因为每次 chunk 更新都触发了整个消息列表的重渲染。解决方法是把流式消息单独管理或者用 ref 直接更新 DOM。问题二流式输出中途停止没有错误提示。检查网络连接和服务端日志。常见原因是服务端超时或触发了内容过滤。前端需要监听流的关闭事件如果流在没有正常结束标记的情况下关闭要提示用户。问题三中文乱码。这通常是解码问题。确保用 TextDecoder 解码时指定了正确的编码格式一般是 utf-8。如果服务端返回的是二进制流需要确认是否用了正确的解码方式。5.2 RAG 检索相关的问题问题一检索结果不相关。先检查切块是否合理然后检查向量模型是否适合你的语言和领域。中文内容建议用支持中文的向量模型。还可以尝试查询改写和重排序。问题二检索速度慢。向量数据库的索引类型会影响检索速度。如果数据量不大可以用暴力检索如果数据量大需要建 ANN 索引。另外向量维度也会影响速度高维向量检索更慢。问题三相同问题每次回答不一样。这是 LLM 的随机性导致的。如果希望回答稳定把 temperature 设为 0并在 Prompt 里明确要求基于检索内容回答不要编造。5.3 Agent 工具调用相关的问题问题一模型不调用工具。检查工具描述是否清晰是否说明了使用场景。可以在 Prompt 里明确提示“如果需要查询实时信息请调用相关工具”。问题二工具调用参数错误。检查参数的 schema 定义是否准确类型是否匹配。可以在工具执行前加一层参数校验如果参数不合法返回错误信息给模型让它重新调用。问题三工具调用死循环。模型可能反复调用同一个工具。需要设置最大调用次数超过后强制终止并返回当前结果。5.4 常见问题速查表问题现象可能原因排查方向流式输出卡顿重渲染过于频繁检查 state 更新频率加节流检索结果不相关切块不合理或向量模型不匹配调整切块大小换向量模型模型不调用工具工具描述不清晰补充使用场景说明请求超时模型响应慢或网络问题增加超时时间加重试机制输出格式错误Prompt 约束不够在 Prompt 里明确输出格式上下文超限历史消息太长截断历史或做摘要压缩6. 我在实际带人过程中的几点体会带过几轮之后我发现最容易卡住的地方不是技术难度而是节奏。很多人在第一阶段就花了一个多月反复调界面样式结果后面 RAG 和 Agent 的时间被压缩。我的建议是第一阶段不要追求界面完美能跑通就行把时间留给后面的核心能力。另一个体会是一定要动手写不要只看。RAG 的切块参数、检索的 k 值、Prompt 的措辞这些东西看别人的经验只能有个大概方向具体到你的数据和场景必须自己试。我见过有人把教程里的参数原封不动搬过来结果效果很差就是因为没有根据自己的数据做调整。最后分享一个小技巧在开发过程中把每次请求的 Prompt、检索结果、模型回复都打到日志里。这样出问题的时候你可以回溯整个链路快速定位是哪一步出了问题。这个习惯在调试 RAG 和 Agent 时特别有用因为这两个环节的中间状态比较多不记日志很难排查。
