1. RAG 到底在解决什么问题
1.1 大模型的两个“天生缺陷”与知识割裂
做 AI Agent 的人应该都有过这种体会：你把一个 Agent 接到业务里，它聊得头头是道，一落到具体数据上就开始胡编。比如我问它“我们公司去年 Q3 华东区的退货率是多少”，它没有这个数据，但它绝不会说“我不知道”，它会编一个看起来非常合理的数字给你。这就是大模型的第一个天生缺陷——知识截止与幻觉。
第二个缺陷更隐蔽：私有知识进不去。我把几十份产品手册、运维工单、客服话术扔给它，它从参数上就学不进去，因为模型训练的时候压根没见过这些文档。微调倒是可以，但成本高、更新慢、每次新文档还要重新训，根本跟不上业务节奏。
所以 RAG（Retrieval-Augmented Generation，检索增强生成）的本质很简单：不把知识硬塞进模型，而是把知识放在外面，需要时由检索系统取回来，再喂给模型做回答。它解决的就是大模型“不知道”和“记不住”的问题，也顺带缓解了“知识割裂”——业务知识散落在 ERP、Wiki、工单系统、产品手册里，RAG 把它们统一接进来，变成模型能用的上下文。
我见过太多团队一上来就追“Agent 工作流”，结果发现 Agent 的核心决策质量完全取决于它拿到的上下文质量。这才是 RAG 在 Agent 体系里被叫做“知识获取管道”的原因——它是 Agent 的输入层，不是可选项。
1.2 RAG 在 Agent 里的定位：不是辅助，是基础设施
很多人把 RAG 当成“做个问答机器人”的附属品，这是认知上的误区。在一个完整的 AI Agent 架构里，知识获取管道决定了 Agent 的上限。
你可以把 Agent 理解为“大脑 + 手脚 + 资料库”。大脑是大模型，负责推理和决策；手脚是工具调用（搜索、计算、操作业务系统）；资料库就是 RAG。大脑再强，如果资料库里的资料查不到、查不准，决策必然跑偏。
结合我们实际做智能体产品的经验，RAG 承担的工作包括：
- 知识接入：把非结构化文档（PDF、Word、Markdown、工单记录）和结构化数据（ERP 产品信息、数据库记录）统一接入。
- 知识切片：把长文档切成模型上下文能容纳的片段，同时保持语义完整。
- 知识召回：根据用户问题，从海量切片中快速找出最相关的几段。
- 知识融合：把召回的片段和用户问题组装成高质量的 Prompt，喂给生成模型。
热词里有“解决了知识割裂 RAG”，这正是 RAG 在 Agent 里的核心价值——它把原来散落在各个系统里的知识通过统一管道汇入 Agent 的决策上下文。后面我会用一个本地 ERP 产品检索的实战案例来具体展开。
2. RAG 管道五步拆解：从原始文档到可用知识
RAG 基础阶段的管道可以拆成五个环节，每一步都有讲究。我按真实开发顺序讲，每步都会说到我之前踩过的坑。
2.1 文档加载与清洗：脏数据进，脏结果出
管道的第一步是加载文档。听起来简单，实际做起来最烦。一个典型的企业知识库里有 PDF（扫描件、电子版都有）、Word、Excel、网页和工单文本，格式五花八门。
PDF 是最难处理的。电子版 PDF 还好，用 PyPDF 或 pdfplumber 就能抽文字；扫描件必须走 OCR，否则抽出来全是乱码。我当时处理一批设备手册，前 30 页是扫描图片，直接抽出了大量空行和错字，导致后面检索效果惨不忍睹。后来加了 OCR 环节，但 OCR 结果质量取决于扫描质量，倾斜、反光都会影响识别率，需要做图像预处理。
清洗阶段要处理的是：空行、页眉页脚、表格错乱、多余换行。很多团队忽略清洗，直接把抽取的文本按字符切分，结果切出来的 chunk 里全是页眉和页码，检索命中率自然上不去。
提示：加载与清洗阶段，务必核对“进库内容的可读性”。如果抽出来的文本人眼都读不通，后面所有环节的效果都会打折。这一条再怎么强调都不为过。
2.2 切分策略：chunk size 不只是数值选择
文档清洗完，下一步是切分。切分的目的是把长文档切成适合嵌入模型和 LLM 上下文窗口的“语义单元”。
先看 chunk size。常见的做法是固定长度切分，比如 embed 模型支持 512 token，就把文本按 500 token 左右切。但是固定长度切分有个致命问题——它会把一个完整的段落或表格从中砍断。比如一段介绍产品保修政策的文字被切成两半，一半进 chunk A，一半进 chunk B，用户问保修政策时，检索只能召回 chunk A，信息不完整。
更靠谱的做法是“递归切分 + 分隔符优先级”。LangChain 的 RecursiveCharacterTextSplitter 就是这个思路：先按段落分隔符（\n\n）切，如果切出来的块还是太长，再按句号、逗号、空格往下切。这样可以尽可能保持语义完整。
切分时还要考虑chunk_overlap（重叠长度）。为什么需要重叠？因为如果一句关键描述恰好落在两个 chunk 的交界处，没有重叠的话它可能被切碎，两个 chunk 里都是半个信息。我一般把 overlap 设为 chunk size 的 10%~15%。比如 chunk 512 token，overlap 设 50~80 token。这个比例不高不低，既能保证交界信息的完整，又不会让 index 膨胀太多。
产品文档里我遇到过更复杂的情况：一个 markdown 表格，切成 token 块后丢失了表头。解决思路是切分前先把表格转成“字段: 值”的文本形式，再走通用切分流程。
实操心得：切分不能“一刀切”。同一个知识库里可能有产品规格文档（表格密集）和操作手册（段落密集），建议按文档类型配置不同的切分策略。用 LangChain 的话，就是给每种 loader 绑定不同的 splitter。别偷懒写一个全局 splitter，检索质量会告诉你代价。
2.3 向量化与索引构建：选对 embedding 模型
切完的 chunk 要变成向量才能被检索。这里的关键是选 embedding 模型。
市面上常见的方案有三类，我做了个对比：
| 方案 | 特点 | 适合场景 |
|---|---|---|
| OpenAI text-embedding-3-small/large | 效果稳，API 调用，数据出本地 | 对数据脱敏要求不高的项目，快速验证 |
| 开源模型（BGE / m3e / text2vec） | 可本地部署，数据不出去，中文效果不错 | 企业私有化部署，数据敏感，不能走外部 API |
| 商业化向量化服务（阿里、腾讯、百度等） | 国内网络友好，中文效果好，有免费额度 | 不想自己维护模型，对国内云依赖接受度高 |
选型逻辑不复杂：本地私有化就选开源 BGE 系，业务快速上线且数据允许出网就选 API 型。我目前倾向开源 BGE 配本地部署，理由是中国企业项目里“数据不出内网”是硬门槛，API 型模型再好，过不了信息安全评审就等于零。
向量索引选什么？中小规模（几万到几十万 chunk）用 FAISS 就够了，简单、内存型、速度快。规模更大再上 Milvus 或 Qdrant。别一上来就上分布式向量库——运维复杂度会吃掉你的开发效率。FAISS 在千万级以内完全能打。
索引构建阶段有个细节：metadata 一定要存。每个向量关联的 chunk 原文、来源文档、页码、更新时间都要写入索引元数据。后面做结果过滤、引用溯源、增量更新都靠它。
2.4 检索召回：相似度不等于相关性
检索环节最容易踩的误区是：用户问了个问题，embedding 相似度最高的一批 chunk 就一定是最有用的吗？实测结果往往不是。
举个真实场景：用户问“这台设备的保修期是多久”，知识库里有一篇文章讲“设备常见参数”，里面包含保修期；另一篇文章标题是“保修政策常见问题”，内容也很相关。embedding 相似度排序时，前者的向量可能更接近用户问题，因为它整体都在讲参数，而后者可能因为措辞差异排到了后面。但真实的答案其实在后者的内容里更权威。
所以基础版 RAG 的检索召回，要组合两种方式：
- 向量检索：负责语义召回，解决“关键词不同但意思相近”的问题。
- 关键词检索：负责精确命中，解决专有名词、型号、编号这类问题。比如“设备型号 XYZ-T100”这种字符串，向量检索的效果可能反而不如 BM25 精确匹配。
这就是所谓的混合检索（Hybrid Search）。先各自召回一批候选，再做融合排序。LangChain 里的 EnsembleRetriever 就是干这个的，可以把 BM25 和向量检索按权重合并。
召回参数也要说明白：
- top_k：取回多少个候选片段。基础场景 4~6 个即可，多了会把不相关内容塞进上下文，反而干扰生成。
- score_threshold：相似度阈值，低于阈值的直接丢弃。这个值要调试，设高了会漏掉正确答案，设低了会混入大量噪声。我一般先用测试集跑一遍，看召回分布在 0.3~0.8 之间，然后取 0.4~0.5 为阈值。
2.5 重排与生成融合：让模型看到“对的内容”
检索完之后，所有候选片段直接拼进 Prompt 是最粗放的做法。更好的思路是先做一个Rerank（重排）环节：用专门的重排模型（比如开源 BGE-reranker，或 API 型 rerank 服务）对候选片段做精排，把相关性最高的排到最前面。
为什么需要重排？因为初检用的 embedding 模型擅长做“召回”，不擅长做“精排”。召回阶段讲究的是“宁可多召回，不要漏”，精确度可以低一点；重排阶段是拿一个更强的模型，在更小的候选集上做精确判断。简单说，召回求全，重排求准。
生成融合环节，Prompt 的组装有一些经验性规范。我常用的模板结构是：
- 系统指令：明确“你是企业知识助手，仅基于提供的资料回答，资料不够时直接说明不知道”。
- 知识片段：用清晰的标识符区分每个片段，标注来源文档编号。
- 用户问题：放在最后。
其中关键的一条是“资料不够时直接说不知道”。不写这条，模型会强行把片段拼凑成答案，编造细节。写了之后，幻觉会大幅减少。
实操心得：把“没有检索到相关内容时，请明确回答‘知识库中未找到相关信息’”写进指令，比任何参数调优都更直接地降低幻觉率。这是我实验中效果最明显的一个改动。
3. 实战：基于 LangChain 快速搭起一个能跑的 RAG 管道
3.1 框架与工具选型：LangChain 还是 Spring AI？
做 Java 后端出身的朋友可能更关心 Spring AI；做 Python 项目的则绕不开 LangChain。热词里同时出现了 “spring ai rag”“langchain4j rag” 和 “semantic kernel”，我们实际团队三个都接触过，简要说下结论：
| 框架 | 语言 | 特点 | 适合团队 |
|---|---|---|---|
| LangChain | Python | 生态最全，RAG 组件最丰富，文档多 | 以 Python 为主的技术团队 |
| LangChain4j | Java | 把 LangChain 的设计移植到 Java 生态 | 传统 Java 服务端团队 |
| Spring AI | Java | 主打 Spring Boot 原生集成，和现有应用无缝接 | 深度绑定 Spring 技术栈的团队 |
| Semantic Kernel | C# / Python | 微软出品，企业级集成能力不错，适合 .NET 场景 | 微软技术栈团队 |
对我来说，做 RAG 原型验证首选 LangChain——组件之间可以灵活组合，Debug 生态也成熟。Java 团队如果业务系统已经跑在 Spring Boot 上，用 Spring AI 会省掉跨语言通信的麻烦，从数据源到向量库可以一条链路下来。
下面的实操演示用 LangChain + OpenAI 兼容接口 + FAISS 做示例。考虑到很多企业在国内部署，需要本地化大模型，OpenAI 接口这块我会提到“兼容接口”的通用做法。
3.2 五步管道代码实现
第一步，初始化向量存储并构建文档加载器：
from langchain_community.document_loaders import PyPDFLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 加载 PDF 和 TXT loaders = [ PyPDFLoader("docs/product_manual.pdf"), TextLoader("docs/faq.txt", encoding="utf-8"), ] docs = [] for loader in loaders: docs.extend(loader.load()) # 切分 splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""], ) chunks = splitter.split_documents(docs) print(f"切分成 {len(chunks)} 个片段")这里我把分隔符按中文语序做了调整：先按段落分离，再按句号等句末标点分离。保留标点符号的效果比纯按 \n 切分更好，因为中文语义往往在一句话内才完整。
第二步，定义本地 embedding 和向量库：
from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS embedding = HuggingFaceEmbeddings(model_name="BAAI/bge-large-zh-v1.5") vectorstore = FAISS.from_documents(chunks, embedding) vectorstore.save_local("faiss_index")提示：BGE 系列的查询指令（query instruction）通常会提升检索效果。以
bge-large-zh-v1.5为例，构建查询向量时建议在问题前面加“为这个句子生成表示以用于检索相关文章”。每个模型的要求不同，具体看模型卡片。这个小技巧能让 top_k 命中率提升几个点。
第三步，构建混合检索 + 重排 + 生成问答链：
from langchain.retrievers import EnsembleRetriever from langchain_community.retrievers import BM25Retriever from langchain_community.cross_encoders import HuggingFaceCrossEncoder from langchain.retrievers.document_compressors import CrossEncoderReranker from langchain.chains.combine_documents import create_stuff_documents_chain from langchain.chains import create_retrieval_chain from langchain_openai import ChatOpenAI # 双路召回 bm25_retriever = BM25Retriever.from_documents(chunks) bm25_retriever.k = 8 vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 8}) ensemble = EnsembleRetriever( retrievers=[bm25_retriever, vector_retriever], weights=[0.3, 0.7], ) # 重排，精排到 top 4 compressor = CrossEncoderReranker( model=HuggingFaceCrossEncoder(model_name="BAAI/bge-reranker-large"), top_n=4, ) rerank_retriever = ensemble | compressor # 生成模型 llm = ChatOpenAI( model="qwen-max", api_key="your-api-key", base_url="https://dashscope.aliyuncs.com/compatible-mode/v1", )双路召回的权重配比 0.3/0.7，是我按照“向量为主要召回手段，关键词为补充”的原则定的。如果你的知识库中型号、编号类查询占比高，可以适度调高 BM25 的权重。
第四步，组装提示词链：
from langchain_core.prompts import ChatPromptTemplate prompt = ChatPromptTemplate.from_messages([ ("system", """你是一个企业内部知识助手。请依据以下资料回答问题。 规则： 1. 只使用资料提供的信息，不要自行编造。 2. 如果资料中没有相关信息，明确回答“知识库中未找到相关信息”。 3. 回答时请标注信息来源，格式为【来源：文档名】。 资料： {context}"""), ("human", "{input}"), ]) document_chain = create_stuff_documents_chain(llm, prompt) rag_chain = create_retrieval_chain(rerank_retriever, document_chain) answer = rag_chain.invoke({"input": "这台设备的保修期是多久？"}) print(answer["answer"])这四步流程跑通后，一个基础 RAG 管道就成型了。实际以“本地 ERP + RAG + LLM 产品检索”为场景的做法也可以照搬：ERP 中的产品信息导出为结构化文本，每一行产品的属性描述当成一个文档，走同一套切分、索引、检索流程。
3.3 核心参数速查与调优建议
基础 RAG 调优时，最该盯的参数我整理成一个表格：
| 参数 | 建议初始值 | 影响 | 排查方向 |
|---|---|---|---|
| chunk_size | 300~500 token | 越大上下文越完整，但噪声越多；越小越精准，但信息易不完整 | 看召回片段是否频繁“半句话没说完” |
| chunk_overlap | chunk_size 的 10%~15% | 影响交界信息的完整性 | 手动检查切分结果中是否出现句子被硬切断 |
| top_k | 初检 8~10，精排 4~6 | 影响候选集宽度与最终上下文长度 | 观察答案所需关键信息是否总在候选之外 |
| score_threshold | 0.4~0.5 | 过滤噪声片段 | 在测试集上统计未命中问题的阈值分布 |
| 混合检索权重 | BM25 0.3 / 向量 0.7 | 精确匹配与语义匹配的平衡 | 专有名词查询偏多则上调 BM25 权重 |
| rerank top_n | 4 | 最终进入 Prompt 的片段数 | 答案质量不达标时先试加大到 5~6 |
这些参数没有“最优解”，必须依赖自己的测试集来调。后面第四节我会讲具体怎么评估。
4. 从 RAG 到 Agentic RAG：瓶颈与进化方向
4.1 为什么基础 RAG 的 hit rate 上不去
热词里有个“rag hit rate”，中文叫“命中率”，指的是检索系统召回的片段中真正包含答案的比例。这是 RAG 项目里最让人揪心的指标——大部分团队卡在 60%~70% 上不去，就开始怀疑模型，怀疑向量库，怀疑一切。但根因往往在管道设计上。
我总结最常见的三个瓶颈：
第一，查询和文档的表达错位。用户问的是口语化问题，文档里是书面语表述，embedding 模型如果够强能跨过去，但常见的开源中文 embedding 模型，对这种跨度比较大的语义匹配效果并不理想。解决方案不是盲目换更大的模型，而是做查询改写——在检索之前，用一个 LLM 把用户问题改写成更贴近文档表述的查询词。比如用户问“这个能质保多久”，改写为“产品保修期时长，保修政策覆盖范围”。
第二，切分破坏了答案上下文。前面反复强调 chunk 切分，这里不重复，只强调一句话——检查你的召回片段，看看答案是不是经常被切成了两半。
第三，单轮检索的局限。对简单问题，一轮检索就够了；但复杂问题（比如“对比一下 A 设备和 B 设备在保修政策上的差异”），需要先检索出两个设备的资料，再综合回答。基础 RAG 的一次检索只能拿到最相似的片段，缺少这种多步推理能力。
4.2 Agentic RAG：让检索成为一项 Agent 能力
热词里“agentic rag”已经是当前大热的方向。它和基础 RAG 的区别在哪？基础 RAG 是固定的“检索-生成”流水线；Agentic RAG 把检索权交给了 Agent，让它自己决定何时检索、检索什么、要不要多次检索、用不用工具。
举个例子。我们做过一个运维知识助手，基础 RAG 版本只能回答“某设备参数是什么”这种直接问题。但用户经常问的是“这台设备的告警日志里出现了 A 错误码，可能是什么原因”。这个问题需要两步检索：先查错误码对应的常见故障，再查该故障的处理步骤。基础 RAG 一步检索根本拿不全信息，Agentic RAG 则会拆成多个检索动作依次执行，甚至中间还会结合知识库里的故障树表。
从工程实现看，Agentic RAG 也不是什么玄学，就是在 Agent 的 ReAct 循环里注册一个“知识检索工具”，由 LLM 决定工具调用参数。基于 LangChain，核心代码变得非常精简：
from langchain.tools import tool from langchain.agents import create_tool_calling_agent, AgentExecutor @tool def search_knowledge(query: str) -> str: """当回答需要产品知识时，调用此工具检索产品文档和FAQ。""" docs = rerank_retriever.invoke(query) return "\n\n".join(doc.page_content for doc in docs) agent = create_tool_calling_agent(llm, [search_knowledge], prompt) executor = AgentExecutor(agent=agent, tools=[search_knowledge])Agent 会在需要知识时自动调用search_knowledge，而且它可以调用多次，每次用一个新查询词。这天然解决了基础 RAG 单轮检索的瓶颈。
4.3 效果评估：用测试集约束迭代方向
说到评估，很多人直接“凭感觉”，觉得回答还行就上线了。这在演示阶段没问题，上线后发现问题就麻烦了。我在项目中推行的做法是：建一个 50~100 条的最小评估集，每条包含“用户问题、标准答案片段、期望召回的文档名”。
用这个测试集，每改一次参数或重构管道，就跑一遍，记录两个核心指标：
- Hit rate（召回命中率）：标准答案片段是否出现在召回的 top-k 中。基础 RAG 先盯这个指标。
- Answer correctness（回答正确率）：由 LLM 作为裁判，把 Agent 的回答与标准答案做对比，打分或判定是否一致。
我自己实测下来的体会是：先把 hit rate 调到 90% 以上，再谈回答正确率。如果 hit rate 只有 70%，你调 Prompt、换生成模型都是白费——答案源头的信息都没拿到，生成模型巧妇难为无米之炊。
实操心得：不要一开始就追求用 LLM 做自动评估。先用 20 条测试数据，人工看检索日志，精确定位是哪个环节丢了答案。人工看十轮之后，你对管道的直觉会大幅提升，之后再上自动评估体系才有意义。
5. 常见问题与排查速查
这一节整理项目中出现频率最高的问题，按“现象-原因-处置”格式记录，方便直接按图索骥。
5.1 检索不到答案：先查数据再查代码
现象：用户问题明明在知识库里有答案，但回答是“未找到”。排查顺序有讲究：
| 排查步骤 | 操作 | 说明 |
|---|---|---|
| 1 | 直接在原始文档里搜答案关键词 | 排除“文档里根本没有”的误会 |
| 2 | 查看检索日志中命中的 chunk 内容 | 用 debug 模式打印检索结果，看召回片段是否包含答案 |
| 3 | 检查 chunk 切分点 | 答案是否被切到两个 chunk 里，各剩一半 |
| 4 | 检查 embedding 模型 | 换更强的模型试试，或加查询改写 |
| 5 | 检查重排环节 | 初检命中了，精排把正确片段排到了后面被截断 |
其中第二步最有价值——我建议开发阶段一定要给检索链路加日志，把每个请求的初检前 10 和后重排 top 4 都打出来。这样问题定位往往只需要几分钟。
5.2 回答质量差：上下文太长还是指令不清
现象：检索到了答案，但模型回答得东扯西拉。这时候排查方向有两个。
第一个方向是上下文过长。模型上下文里塞了 4 段相关性不一的片段，干扰信息过多。处置方式：降低 top_n 到 3，提高 score_threshold，把弱相关片段过滤掉。
第二个方向是系统指令没有约束生成行为。尤其是没写“资料不足时拒绝回答”和“引用来源”这两条，模型容易放飞自我。处置方式：把这两条规则强制写进 Prompt，并在评估集上重新跑分。
5.3 增量更新：知识变了,旧答案还在
问题：企业知识库是动态的，新文档要加进来，旧文档要下架。但向量库里的旧 chunk 不会自动失效。
我推荐的做法是“按文档粒度管理索引”：每个 chunk 都带上 metadata 中的document_id和updated_at，更新时先删除该 document_id 下所有 chunk 再写入新 chunk，避免旧数据残留。
还有一个实际观察到的怪问题：更新文档后，向量库索引膨胀，检索变慢。这是因为 FAISS 的增删操作会留下无效空间，定期做一次索引重建（比如每晚触发）能明显改善检索速度。
5.4 成本与性能的平衡：必要的优化时机
基础 RAG 阶段，性能瓶颈主要在 embedding 的批量耗时和重排模型的推理耗时。实测下来，chunk 数量达到 10 万级后，单次检索的耗时明显上升。
优化方向按性价比排序：
- 缓存：相同或相似的用户问题直接走缓存，不重复检索。这是最省成本的一项。
- doc_id 过滤：通过业务属性（如“仅查华东区”）先做 metadata 过滤，缩小检索范围。
- 重排模型换轻量版：从 large 换到 small，牺牲一点精排效果换速度。
- 索引分段：按文档目录维度拆分成多个小索引，先路由再检索。
这些优化在项目初期不需要做，但当响应时间超过 3 秒或同时在线用户明显增长时，就要认真考虑了。
6. 写在最后的经验之谈
说句实话，RAG 基础阶段的核心工作，不是写多少代码，而是对“每一步都在干什么、为什么这么干”有清晰认知。我在带团队的过程中发现，能跑通 RAG 代码的人不少，能把 chunk 切分逻辑讲清楚、能把 hit rate 数据背后的问题定位准确的人很稀缺。
如果让我给正在搭 RAG 管道的朋友三条最接地气的建议，我会说：
第一，先手工验证再自动化。别急着写评估框架，先用 20 条数据人工看检索质量，建立对管道的手感。
第二，参数记录成表格。每次调整 chunk size、overlap、top_k，都记下对应的 hit rate 变化。我见过太多人调了两周参数，最后说不清哪个改动带来了提升——这在项目复盘时非常被动。
第三，把 Agent 和 RAG 当成一个整体来设计。RAG 不是独立的问答接口，它是 Agent 的知识来源。Agent 的规划、工具调用、多轮对话都会和 RAG 深度耦合，基础阶段把管道质量做扎实，后面接 Agentic 能力时会顺畅很多。
RAG 这个方向远没到“已经过时”的阶段。即便有了更长的上下文窗口、更聪明的模型，RAG 在可信度、知识可更新、业务可控性上的优势依然无法被替代。把管道基础打牢，后面的路会越走越宽敞。
