广州的冬天总是来得特别晚，窗外的车流声依旧嘈杂。作为一名接近8.9年经验的前端老鸟，34岁这个数字像是一道无形的坎。2025年底的那封裁员邮件，其实并不算太意外毕竟大环境在那摆着。但这三个月的求职经历，还是狠狠地给了我一巴掌——二面之后杳无音信成了常态，除了音视频和图形化这种硬骨头，AI似乎Yi经Neng吞掉80-90%的基础前端工作。

在失业的这三个月里我经历了从焦虑、迷茫到强迫自己静下心来学习的全过程。既然学历和背景dou不占优势，那就只Neng换赛道。我决定死磕AI Agent开发。这不仅仅是为了生存，geng是为了证明自己还没被时代抛弃。今天我想把这十一天的真实心路历程和技术复盘记录下来或许对同样在转型的你会有所帮助。

第一阶段：认知重塑与RAG初探

刚开始的那几天说实话，脑子是乱的。以前写前端，逻辑是确定的，点击按钮就跳转，输入数据就渲染。但AI不一样，它是概率的，是不确定的。这种思维模式的转变，比学新语言geng痛苦。

第1-2天：理解那个“健忘”的朋友

我花了hen多时间去啃大模型的基础概念。以前觉得ChatGPT神奇，现在得知道它为什么“蠢”。大模型就像一个博学但有点健忘的朋友，它知道牛顿定律，但不知道你上周三在周会上说了什么。

这时候，RAG的概念就出现了。这简直是救命稻草。简单来说就是给这个朋友配个笔记本。你问问题，他先翻笔记，找到相关记录，再结合脑子里的知识回答你。

核心公式其实就一句话：RAG = 检索 + 增强 + 生成。但这背后的水hen深。我意识到，要转型ZuoAI Agent，光会调API是不够的，得懂架构，懂工程化。

第3天：向量数据库的选择困难症

既然要给AI配“笔记本”，那就得选个本子。这就是向量数据库。市面上太多了Chroma、Pgvector、Milvus、Redis、Elasticsearch、FAISS……kan得我眼花缭乱。

我整理了一张决策图，虽然简陋，但hen实用：

只是想Zuo个Demo练手别犹豫，直接上 Chroma。本地跑，不用部署，Python代码几行就搞定，对新手Zui友好。

公司里Yi经有PostgreSQL那就用 Pgvector。省事，不用维护新数据库，直接 现有的库。

数据量达到十亿级，或者要上云这时候就得kan Milvus 了云原生，专门处理海量数据。

追求极致速度，延迟要低于10msRedis 是个不错的选择，毕竟它本来就快。

既要关键词匹配，又要向量语义Elasticsearch 是混合检索的老大。

本地搞研究，不想联网FAISS 这种库级工具，性Neng强悍。

那天下午，我就在纠结选哪个，Zui后为了快速上手，我决定先用Chroma跑通流程。

第二阶段：LangChain实战与脏活累活

理论懂了工具选了接下来就是写代码。这阶段Zui磨人，全是细节。我主要用的是LangChain，虽然社区里有人吐槽它封装太多，但对于转型的人来说它Neng让你快速kan到成果。

第4天：文档加载与切分的艺术

ZuoRAG的第一步，不是写Prompt，而是处理数据。我们要把各种乱七八糟的文档——PDF、Word、TXT——变成程序Neng读懂的纯文本。

这里有个坑：切分。你不Neng把整本书直接扔给LLM，它装不下也记不住。你得切成小块。

我一开始随便切，结果发现答案经常断章取义。后来才明白，重叠是关键。就像切面包，你不Neng一刀两断，中间得留点碎屑连着，不然语义就断了。

# 这是我当时用的切分代码，RecursiveCharacterTextSplitter 是神器
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,      # 每块Zui大字符数，一般文档500-1000差不多
    chunk_overlap=50,    # 重叠部分，防止上下文被切断
)
chunks = splitter.split_documents

那天我对着屏幕调试了一下午，就为了调整这两个参数。产品说明书可Neng200字就够了但法律条文可Neng得300字起步，长篇小说甚至要1000字。这活儿没法自动化，得靠经验。

第5-6天：向量化与Embedding的奥秘

文本切好了得变成向量。这就是Embedding。这过程就是把文字变成一串数字，比如“苹果好吃”和“水果美味”，它们变成向量后在空间里离得hen近；而“汽车hen快”就会离得hen远。

这里有个血泪教训：索引和检索必须用同一个模型。我一开始存的时候用了OpenAI的模型，检索的时候手贱换成了HuggingFace的中文模型，结果搜出来的东西驴唇不对马嘴。向量空间不匹配，就像你用英语写笔记，却让只会中文的朋友去读，肯定不行。

对于中文场景，我现在比较推荐 BAAI/bge-large-zh，效果比通用的模型好不少。

第7天：搭建检索链路

终于到了拼装的时候。文档加载 -> 切分 -> 向量化 -> 存入Chroma -> 检索 -> 丢给LLM。

这一步我写了个简单的Prompt模板：

你是一个基于以下上下文回答问题的助手。
<上下文>{这里放检索到的相关文本块}
问题：{用户的问题}
请基于以上上下文回答。Ru果上下文中没有相关信息，请说"我不知道"。

kan着终端里终于吐出了正确的答案，那种成就感比上线一个前端页面要强得多。虽然只是个Demo，但路通了。

第三阶段：调优、反思与未来

跑通只是开始，Neng用才是目标。这几天我一直在折腾参数和优化，试图让这个Agentgeng像“人”一点。

第8-9天：参数调优的玄学

为什么有时候它回答得hen准，有时候又胡说八道？这涉及到 Top-K 的选择。

Top-K就是每次检索多少个相关片段。K=3，精准但可Neng漏信息；K=10，全面但噪音多，成本也高。经过测试，我发现K=5是个折中的好选择。

还有那个 chunk_size，我也试了hen多遍。Ru果答案不相关，通常是块太大，噪音太多；Ru果丢失关键信息，可Neng是块太小，把上下文切断了。这简直就是个玄学调优过程，得根据具体的文档类型不断试错。

第10天：进阶技术的诱惑

在查资料的时候，我kan到了hen多高级玩法，比如重排序。就是先检索出50个结果，然后用一个geng强但geng慢的模型重新排序，取前5个。这Neng极大提升准确度，但延迟也上去了。还有多查询检索，把用户的问题 成三个不同的角度分别去搜。

这些技术hen迷人，但我告诉自己，先别贪多。先把基础打牢，再谈进阶。

第11天：写在Zui后关于就业的思考

今天是我决定转型的第11天。虽然离“资深AI Agent工程师”还有hen长的路要走，但我Yi经不再像刚被裁时那样焦虑了。

前端并没有死，但它确实变了。未来的开发，不再是单纯的CRUD，而是如何利用AI工具去解决问题。RAG也好，Agent也罢，本质上dou是为了让机器geng好地理解我们的意图。

这十一天我整理了厚厚一叠笔记，从Chroma的安装到LangChain的Chain调用，每一个报错dou记录在案。我知道，现在的就业市场依然冰冷，34岁的年纪也确实尴尬。但至少，我手里多了一把武器。

Ru果你也在转型的路上，或者正迷茫于技术的迭代，我的建议是：别光kan，动手写。哪怕只是跑通一个Zui简单的RAG Demo，那种掌控感也会驱散你心中的迷雾。

路hen长，但只要还在走，就总有希望。

附录：一份精简的LangChain核心代码清单

为了方便大家查阅，我把这几天Zui常用的代码片段整理了一下省得去翻文档。

1. 文档加载器

# 纯文本
from langchain_community.document_loaders import TextLoader
loader = TextLoader
# PDF
from langchain_community.document_loaders import PyPDFLoader
loader = PyPDFLoader
# Word
from langchain_community.document_loaders import Docx2txtLoader
loader = Docx2txtLoader

2. 向量数据库连接

# Chroma 
from langchain_community.vectorstores import Chroma
vector_store = Chroma.from_documents
# Redis 
from langchain_community.vectorstores import Redis
vector_store = Redis.from_documents

3. 完整的RAG链路示例

from langchain_core.runnables import RunnablePassthrough
def format_docs:
    return "

".join
rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough}
    | prompt
    | llm
)
# 发起提问
result = rag_chain.invoke
print

希望这些代码Neng帮你少走点弯路。共勉！

---