企业官网建设流程全解析

1. 这个三个月计划到底在解决什么问题

先把话说在前头：市面上讲“AI 应用前端”的课程和路线图，我翻过的没有一百也有八十，绝大多数犯的是同一个毛病——把“学 AI”和“学前端”当成两件事，要么让你先去啃三个月深度学习数学，要么让你背一堆 LangChain 的 API 名字，学完还是不知道一个能上线的 AI 应用长什么样。这份“三个月学习计划”的价值恰恰在于它把落点定在了前端工程师这个身份上，而不是“算法工程师”或者“全栈 AI 工程师”。

我先把核心关键词摆出来，后面所有内容都围绕它们转：AI、前端工程师、LLM、Agent、RAG。这五个词不是并列关系，而是有层次的。LLM 是底座能力，RAG 是让 LLM 接上你私有知识的手段，Agent 是让 LLM 能自己决定调用什么工具、走几步流程的编排方式，而前端工程师要做的事情，是把这三层能力包装成用户真正愿意用的界面和交互。换句话说，你不需要会训练模型，但你必须懂模型的能力边界在哪、什么时候会胡说、流式输出怎么接、上下文怎么管、工具调用怎么在前端可视化。

那这个计划适合谁？我的判断是三类人。第一类是有 1-3 年前端经验、会 React 或 Vue、想往 AI 方向转但不想丢掉前端积累的人；第二类是已经在做传统 B 端或 C 端产品、公司开始要求接大模型能力、被迫要快速上手的人；第三类是想自己做点 AI 小产品、但被“全栈 AI 工程师”这种吓人 title 劝退的独立开发者。如果你属于这三类，这份计划能帮你省掉大量在错误方向上浪费的时间。

反过来，如果你连 JavaScript 的异步、Promise、事件循环都还没搞明白，那我建议你先补这一块，因为 AI 应用前端 90% 的坑都和流式、并发、状态管理有关，基础不牢会非常痛苦。这不是劝退，是省你时间。

接下来我会把这三个月的路径拆成四个部分讲：整体设计思路、每个阶段的核心细节和实操要点、完整落地流程、以及踩坑排查。每一部分我都会告诉你“为什么这么安排”，而不是只丢给你一个清单。

2. 三个月路径的整体设计与取舍逻辑

2.1 为什么是三个月，而不是六周或半年

先回答一个很多人没问但心里在想的问题：三个月这个长度是怎么来的。我的经验是，一个前端工程师从零到能独立交付一个带 RAG 和 Agent 能力的 AI 应用，最短的“有效学习时间”大概在 250 到 350 小时之间。按每天投入 3 小时算，差不多就是三个月。六周的话，你只能学到“能跑通 demo”的程度，一旦遇到流式断连、上下文超长、工具调用失败这些真实问题就抓瞎；半年的话，边际收益递减得厉害，因为 AI 应用前端这个领域变化太快，你花三个月学的东西可能第四个月就有新范式了，不如早点上手做真实项目。

所以三个月的定位是：前一个半月打地基和跑通最小闭环，后一个半月做两个有真实复杂度的项目。注意，是“有真实复杂度”，不是跟着教程抄一个聊天框。复杂度来自哪里？来自多轮对话的状态管理、来自 RAG 的检索质量调优、来自 Agent 的多步工具调用和错误恢复。这些才是面试和实际工作里真正被问的东西。

2.2 为什么把 LLM 基础放在最前面而不是最后

我见过太多人一上来就去学 Agent 框架，结果连 token 是什么、上下文窗口怎么算、temperature 调高调低有什么区别都说不清，写出来的 Agent 一遇到模型返回格式不对就崩。所以第一个阶段必须是 LLM 基础认知，但注意——是认知，不是训练。你要搞清楚的东西包括：

• token 是怎么切的，为什么中文和英文的 token 数差这么多，这直接关系到你的成本估算和上下文裁剪策略；
• 上下文窗口的硬限制，以及超出之后会发生什么（不是简单报错，很多模型是静默截断，这个坑后面会细讲）；
• temperature、top_p、max_tokens 这些参数对输出的实际影响，尤其是做结构化输出时 temperature 该设多少；
• 流式输出（streaming）的协议长什么样，SSE 和 WebSocket 在这个场景下怎么选。

这些内容看起来基础，但它们是后面所有工作的前提。你不需要知道 Transformer 的注意力公式怎么推导，但你必须知道“为什么模型会一本正经地胡说”，因为你的前端要做兜底和提示。

2.3 RAG 和 Agent 的先后顺序为什么不能反

这是整个计划里我最坚持的一点：先 RAG，后 Agent。原因很实在。RAG 的本质是“检索 + 拼接上下文 + 生成”，它是一个相对确定的流程，你能清楚地看到每一步的输入输出，调试起来有抓手。而 Agent 是“让模型自己决定下一步做什么”，不确定性高得多，一旦出问题，你很难判断是检索错了、工具描述写错了、还是模型本身推理跑偏了。

如果你先学 Agent，遇到问题时会习惯性地去调 prompt，但很多问题的根因其实在检索质量。反过来，先把 RAG 做扎实，你会建立起一个重要的直觉：模型输出的质量，八成取决于你喂给它的上下文质量。这个直觉会让你在做 Agent 时少走很多弯路。

2.4 前端工程师的差异化优势在哪里

这一点我想单独强调，因为它决定了你这三个月的投入方向。纯算法背景的人做 AI 应用，往往把界面做得极其简陋，一个 textarea 加一个按钮就完事。但真实用户要的是什么？是流式打字机效果、是引用来源可点击、是工具调用过程可视化、是对话历史可搜索可分享、是失败时能优雅重试。这些全是前端的活。

所以你的学习重点不是“怎么调模型”，而是“怎么把模型能力变成好用的产品”。具体来说，你要在三个月里刻意练习这几件事：流式渲染的性能优化（长对话不能卡）、乐观更新和错误回滚（用户发了消息但请求失败怎么办）、多轮对话的上下文管理（什么时候裁剪、什么时候摘要）、以及工具调用过程的可视化（让用户知道 Agent 在干什么，而不是干等）。

3. 第一阶段：LLM 基础与最小对话闭环（第 1-4 周）

3.1 第一周该建立哪些核心认知

第一周不要写复杂代码，先把认知打牢。我建议你按这个顺序过一遍：

先搞清楚一次完整的模型调用到底发生了什么。从你在前端点下发送按钮，到屏幕上出现第一个字，中间经过了：请求组装、网络传输、服务端鉴权、模型推理、流式返回、前端渲染。这条链路上每一环都可能出问题，你要能大致定位问题出在哪一环。

然后动手算一次 token。找个在线的 tokenizer 工具，把你平时写的一段中文和一段英文分别丢进去，看看 token 数差多少。我的实测经验是，同样意思的一段话，中文的 token 数通常是英文的 1.5 到 2 倍。这个数字直接影响你的成本，也影响你后面做上下文裁剪时的策略——中文场景下你得更激进地裁剪。

接着把 temperature 玩明白。同一个 prompt，temperature 设 0、0.7、1.5 各跑几次，观察输出的稳定性。你会发现做结构化输出（比如让模型返回 JSON）时，temperature 必须设得很低，否则它会在 JSON 外面加一堆解释性文字，让你的 parser 直接崩。

提示：第一周不要碰任何框架。直接用 fetch 调一次接口，把流式返回的原始数据打印出来看。很多人用了半年框架都没见过原始的 SSE 数据长什么样，出了问题完全无从下手。

3.2 第二到三周：手写一个流式对话界面

这两周的目标是：不借助任何 AI 专用框架，用原生 fetch 加 React（或 Vue）做一个能流式输出的对话界面。为什么强调“不借助框架”？因为框架会帮你隐藏太多细节，而恰恰是这些细节决定了你能不能做出好产品。

具体要做的事情包括：

• 用 fetch 的 ReadableStream 读取流式响应，手动解析 SSE 格式（data:前缀、[DONE]结束标记这些）；
• 处理流式过程中的边界情况：一个 chunk 可能包含半条消息，需要缓冲拼接；
• 实现打字机效果，但要注意不能每个字符都触发一次 React 重渲染，否则长回复会卡到爆；
• 加上“停止生成”按钮，这需要用到 AbortController；
• 处理网络中断，给出可重试的提示。

这里有个性能坑我必须提前说：很多人实现打字机效果时，把整个回复字符串放在 state 里，每来一个 chunk 就 setState 一次。短回复没问题，一旦回复超过两千字，页面就开始掉帧。正确的做法是用 ref 累积内容，然后用 requestAnimationFrame 节流更新，或者干脆把流式内容渲染到一个独立的 DOM 节点上，绕开 React 的 diff。

3.3 第四周：上下文管理与成本意识

第四周要解决一个真实产品一定会遇到的问题：对话越来越长，上下文超了怎么办。这时候你需要理解几个策略：

我的建议是先用滑动窗口，把最近 10 轮完整保留，更早的做摘要。这个组合在大多数场景下够用，实现成本也可控。

同时这两周要建立成本意识。你要能估算出：一次对话大概花多少 token、按当前价格折合多少钱、如果日活一千人每天聊十轮成本是多少。这个数字会直接影响你的产品设计，比如你会不会给免费用户限制轮数、会不会对长文档做预处理压缩。

4. 第二阶段：RAG 从能跑到好用（第 5-8 周）

4.1 RAG 的本质：别被名词吓到

RAG 这个词被讲得太玄了，其实它的核心逻辑就三步：把用户的问题拿去检索相关文档，把检索到的文档拼进 prompt，让模型基于这些文档回答。就这么简单。难的不是这个流程，而是每一步的“质量”。

我常用一个类比来解释 RAG 的瓶颈：你去图书馆找资料回答一个问题，RAG 的检索环节就是“图书管理员帮你找书”。如果管理员找错了书，你再聪明也答不对。所以 RAG 的 hit rate（命中率）是核心指标，而不是模型有多强。

4.2 文档切分：最容易被低估的环节

很多人做 RAG 效果差，根因就在切分。我见过有人把一整份 PDF 直接丢进去当一个大 chunk，也见过有人按固定 500 字硬切，把一句话从中间劈开。这两种都会毁掉检索质量。

我的实操经验是这样的：切分要按语义边界来，优先按标题、段落、列表项切，其次才考虑固定长度。chunk 大小控制在 300 到 800 字之间，并且相邻 chunk 之间要有 10% 到 20% 的重叠，避免关键信息正好卡在边界上被切断。

还有一个细节：每个 chunk 最好带上它所属的章节标题作为元数据。检索时把标题也纳入匹配范围，命中率会明显提升。这个技巧在技术文档和制度文件上效果特别明显。

4.3 检索策略：从关键词到混合检索

最简单的检索是向量相似度，但它在两种情况下会翻车：一是用户用了文档里没有的同义词，二是用户问的是精确的编号、名称。前者需要语义理解，后者需要关键词精确匹配。

所以成熟的做法是混合检索：向量检索负责语义召回，关键词检索（比如 BM25）负责精确匹配，两路结果合并后重排。这个方案实现起来不算复杂，但效果提升很明显。我实测下来，在技术文档场景，混合检索比纯向量检索的命中率能高出 20 到 30 个百分点。

重排（rerank）这一步也值得做。初步召回 20 条，用重排模型选出最相关的 5 条喂给模型，既省 token 又提质量。

4.4 引用溯源：前端工程师的主场

RAG 应用里最能体现前端价值的功能就是引用溯源。用户看到答案的同时，能看到这个答案来自哪几个文档片段，点击能跳转原文。这个功能看起来简单，做起来有一堆细节：

• 模型返回的引用标记怎么和实际文档片段对应上，需要你在 prompt 里约定好格式，并在前端做解析；
• 引用要能高亮定位到原文的具体位置，这要求你在切分时就记录好每个 chunk 的原文偏移量；
• 如果模型引用了不存在的片段编号，前端要能识别并降级处理，不能直接崩。

注意：不要完全相信模型返回的引用编号。我踩过的坑是模型会“编造”引用，指向一个根本不相关的片段。稳妥的做法是前端做一次校验，把引用编号和实际检索结果比对，对不上的就标记为“来源存疑”。

4.5 本地知识库的搭建思路

热词里出现了“ollama + 简易本地 RAG 知识库”这类内容，说明很多人有本地化、私有化的需求。我的建议是：学习阶段完全可以用本地模型跑通流程，成本低、隐私好、断网也能用。但要注意本地小模型在指令遵循和结构化输出上明显弱于大模型，所以你的 prompt 要写得更明确，解析逻辑要更宽容。

搭建顺序建议是：先用本地模型跑通“文档入库 → 检索 → 生成”的完整链路，确认流程没问题后，再把生成环节换成更强的模型对比效果。这样你能清楚地知道，效果差异到底是检索的问题还是模型的问题。

5. 第三阶段：Agent 与工具调用（第 9-12 周）

5.1 Agent 到底是什么，别神化它

Agent 这个词现在被用得很泛，我的定义很朴素：Agent 就是让模型在回答之前，能自己决定调用哪些工具、调用几次、按什么顺序调用。它和普通对话的区别在于，普通对话是“一问一答”，Agent 是“一问 → 模型决定查天气 → 拿到结果 → 模型决定再查日程 → 拿到结果 → 综合回答”。

理解了这个本质，你就知道 Agent 的难点在哪了：模型要能稳定地输出“我要调用哪个工具、参数是什么”这种结构化信息，你的代码要能解析、执行、把结果喂回去，然后循环。任何一环不稳定，整个 Agent 就崩。

5.2 工具调用的实现细节

工具调用（tool calling / function calling）是 Agent 的基础能力。实现时要注意几个点：

工具的描述要写得极其清楚，包括它做什么、参数是什么类型、什么情况下该用。模型判断要不要调用工具，全靠这段描述。我见过太多人工具描述写得含糊，然后抱怨模型不调用，其实问题在描述上。

参数校验必须做。模型可能返回缺参数、类型不对、甚至编造参数的情况。你的代码要在执行前校验，校验失败就把错误信息返回给模型，让它重新生成。这个“错误回传”机制是 Agent 稳定性的关键。

循环要有上限。模型可能陷入“调用工具 → 结果不满意 → 再调用”的死循环，必须设置最大步数，比如 10 步，超过就强制结束并给出当前最好的结果。

5.3 让 Agent 过程可视化

这是前端工程师在 Agent 场景下最该发力的地方。用户不关心你内部怎么循环，但用户会焦虑“为什么还没出结果”。所以你要把 Agent 的每一步都展示出来：正在调用什么工具、参数是什么、返回了什么、下一步准备做什么。

实现上，这要求你的后端把 Agent 的中间步骤通过流式推给前端，前端用时间线或步骤条的形式渲染。这个功能做得好，用户对等待的容忍度会大幅提升，因为它把“黑盒等待”变成了“可见的进展”。

5.4 错误恢复：Agent 最容易翻车的地方

Agent 出错是常态，不是异常。工具超时、返回格式不对、模型输出解析失败，这些每天都会遇到。所以你的设计里必须有错误恢复机制：

• 工具调用失败时，把错误信息结构化后回传给模型，让它决定是重试还是换工具；
• 模型输出无法解析时，用一次“修复 prompt”让它重新输出，而不是直接报错；
• 整个流程超时或步数超限时，返回已完成的部分结果，并明确告诉用户哪一步没完成。

我个人的经验是，一个能上线的 Agent，错误处理代码的量往往和主流程代码差不多。别指望一次跑通，把精力放在“出错后怎么优雅降级”上。

6. 常见问题与排查速查表

6.1 流式输出相关

6.2 RAG 相关

6.3 Agent 相关

6.4 几条独家避坑心得

第一，永远不要相信模型返回的结构化数据是合法的。哪怕你用了 JSON mode，也要做 try-catch。我遇到过模型在 JSON 里塞了注释导致解析失败的情况。

第二，上下文裁剪要留“安全边距”。你以为上下文窗口是 128k 就能塞满 128k，实际上要留出输出空间和系统 prompt 的空间，实际可用可能只有 100k 左右。

第三，做 RAG 时先做评测集。准备 20 到 30 个真实问题，每次调整切分或检索策略后跑一遍，看命中率变化。没有评测集，你的优化就是盲调。

第四，Agent 的工具数量不要超过 10 个。工具太多，模型选择困难，准确率会明显下降。如果确实需要很多工具，做分层，先让模型选类别，再选具体工具。

7. 三个月之后你该达到什么水平

我不想给你画大饼，说学完就能拿高薪。我只说可验证的标准：三个月结束时，你应该能独立完成一个带 RAG 检索、支持流式输出、有引用溯源、能调用至少三个工具的 AI 应用，并且这个应用在真实使用中不会因为网络抖动、模型输出异常、上下文超长而崩溃。你能清楚地解释每一个技术选型背后的原因，能定位一个效果问题到底出在检索、prompt 还是模型本身。

达到这个水平，你在团队里就是那个“能把 AI 能力落地成产品”的人，这个定位比“会调 API 的前端”值钱得多。剩下的就是持续做真实项目，因为 AI 应用这个领域，真正的经验都来自踩坑，而不是看教程。

我个人在实际操作中的体会是，前两个月最痛苦，因为你要同时消化模型的不确定性和前端的复杂度，经常一个 bug 查半天发现是 prompt 里少了个约束。但一旦跨过那个坎，你会发现后面做新功能的效率越来越高，因为你已经建立起了一套“遇到问题先看上下文质量”的直觉。这个直觉，才是这三个月真正要练出来的东西。