你的RAG还在用"一刀切"分块？别让粗粒度文档切碎了大模型的智商——父子切块策略，才是让检索精准度与生成完整性双赢的终极答案！本文将带你穿透RAG文档切块的进阶迷雾，从问题本质到工程落地，手把手教你如何用"小块检索、大块生成"的黄金组合拳，彻底告别检索不准、生成断片的噩梦，让你的大模型应用真正实现"指哪打哪，弹药充足"。

文字目录：

1. 切了又切还是不准？父子切块到底在解决什么
2. 子块切多小才算"恰到好处"
3. 父块边界怎么画，才能不让上下文"断片"
4. 索引怎么建，才能让小块"认祖归宗"
5. 那些藏在工程细节里的"魔鬼"
6. 怎么证明你的父子切块真的有效

嗨，大家好呀，我是你的老朋友精通代码大仙。接下来我们一起学习 《大模型RAG生成式AI开发实战》130.[第13章 文档切块进阶] 父子切块策略：小块检索大块生成。

俗话说得好：“又要马儿跑，又要马儿不吃草。” 放在RAG开发里，这话简直扎心到不行。你是不是也经常陷入这种抓狂：文档块切大了，向量检索回来一堆无关信息，大模型生成时直接被噪声带偏；块切小了，检索倒是精准了，可关键上下文被拦腰斩断，大模型只能对着残句瞎猜，生成出来的内容前言不搭后语。老板问你"为什么AI这么蠢"，你只能尴尬地摸摸后脑勺。

很多新手同学一碰到这个问题，第一反应就是调参数——“那把chunk_size改成800试试？不行再改成600？” 兄弟，如果你还在用这把"屠龙刀"一刀切所有文档，那今天这篇文章就是专门为你写的。父子切块策略，不是什么花拳绣腿，而是RAG从"能用"迈向"好用"的关键一跃。焦虑吗？别怕，跟紧我，咱们一步一步把这个硬骨头啃下来。

---

1. 切了又切还是不准？父子切块到底在解决什么

RAG系统的核心矛盾，从来都不是"怎么切"，而是"切完之后谁去干活"。传统策略里，一个块既要负责被检索（匹配用户问题），又要负责被生成（提供给LLM当上下文）。这就好比让一个员工既当狙击手又当火力手——远了瞄不准，近了火力覆盖又不够。

父子切块策略的核心思想是"专业分工"：把文档切成**小块（子块）专门做向量检索，切分成大块（父块）**专门给LLM当生成素材。检索阶段用小颗粒度精准匹配，生成阶段用大颗粒度保证上下文完整。

新手最容易犯的错，就是试图用"一个块"解决所有问题。我见过太多这样的代码：

# 错误示范：一刀切的典型做法
text_splitter = CharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200
)
chunks = text_splitter.split_documents(docs)

看起来没问题？问题大了！假设你有一篇讲"Spring Boot事务管理"的文档，里面有一个小节的标题是"Propagation.REQUIRES_NEW的陷阱"，下面跟着三段解释和一个代码示例。如果你按1000字符一刀切，很可能标题和前半段解释在一个块里，代码示例和后半段解释在下一个块里。用户问：“REQUIRES_NEW在什么场景下会失效？”

向量检索可能精准地找到了包含"失效场景"的那1000字符块，但那个块里刚好没有下面的代码示例——而那个示例恰恰展示了失效的具体写法。LLM拿到这个块，看了半天文字描述，没有代码佐证，只能含糊其辞地"编"一个答案。

更惨的是，如果你把chunk_size调到300，试图让检索更精准，那上下文碎得更厉害。用户问的是一个需要跨段落理解的问题，你的块里却只有两句话，LLM连前因后果都摸不着。

这就是典型的"既要又要"困境。你想让检索精准（需要小块），又想让生成有完整上下文（需要大块），但传统策略逼你做单选题。

父子切块策略就是这道单选题的正确解法——我全都要。

具体怎么做？先按较大的语义边界（比如一个Markdown小节、一个自然段组）切成父块；然后在每个父块内部，再细切成适合向量检索的子块。

子块负责"找人"——它小，所以和用户问题的向量相似度高，能精准定位。父块负责"讲故事"——它大，包含了完整的背景、示例和逻辑，能让LLM生成有依据的回答。

还是上面那个Spring Boot的例子。父块是整个"Propagation.REQUIRES_NEW的陷阱"小节（约1500字）。在这个父块里，你再切成3个子块：子块A是概念解释（200字），子块B是失效场景描述（250字），子块C是代码示例和总结（300字）。

用户问"REQUIRES_NEW在什么场景下会失效"，向量检索锁定子块B。但系统不会直接把子块B扔给LLM，而是根据子块B的metadata找到它的父块，把整个1500字的小节送给LLM。LLM既有精准定位的"失效场景"描述，又有前后的概念铺垫和代码示例，生成的答案自然又准又全。

这样做的好处显而易见：

• 检索精度↑：子块小，语义聚焦，和用户问题匹配度高。
• 生成质量↑：父块大，信息完整，LLM不会断章取义。
• 抗噪声能力↑：即使检索到一点点相关子块，也能拉回完整的干净上下文。

别再让一个块既当检索员又当分析师，分工明确才是高效团队的样子。

---

2. 子块切多小才算"恰到好处"

子块是父子切块策略里的"前锋"，它的粒度直接决定了检索能不能"一击即中"。但"小"是相对的，不是越小越好。

新手在子块粒度上，往往走向两个极端。

极端一：子块太大。 有些同学听说小块检索准，就把子块切到300 token，但一看内容，一个子块里塞了三个知识点。比如讲Python异常处理的文档，一个子块里同时包含try-except语法、finally用法和raise自定义异常。用户问"finally块什么时候执行"，向量检索可能因为这个子块里"异常"出现次数多而把它排前面，但子块里大部分内容是try-except的语法细节，噪声极高。

极端二：子块太小。 有同学矫枉过正，按50 token或一句话来切。结果把"数据库连接池的最大线程数应该根据CPU核心数设置"这样一句话拦腰切成两半：“数据库连接池的最大线程数应该"和"根据CPU核心数设置”。向量化的语义完全被破坏，检索时前半句和后半句都变成了无意义的片段。

更隐蔽的错误是割裂依赖关系。比如技术文档里常见"如上文所述"、"详见下一节"这样的指代。如果你按固定长度切，刚好把指代和被指代的内容切开，子块的语义就不再自包含。

我看过一个真实案例：某新手切分某中间件文档，把"该参数默认值为true，但在高并发场景下建议设为false（详见性能调优章节）“切成了两半。前半段进了子块1，后半段"详见性能调优章节"进了子块2。用户搜索"高并发下这个参数该设多少”，检索到了子块1，但子块1里只有"默认值为true"，后面的建议被切走了！LLM一看，只能回答"默认是true"，用户拿到答案上线后系统直接崩了。

子块的设计原则是：语义自包含，主题单一化。

具体操作建议：

第一，按语义边界切，别按字符数硬切。 优先使用RecursiveCharacterTextSplitter，并且把分隔符设置成语义边界：\n\n（段落）、\n（换行）、.（句号）、 （空格）。让切分先尝试在段落边界断开，实在不行再在句子边界断。这样能最大程度保证子块是一个完整的语义单元。

第二，控制子块在1-3个自然句或100-300 token之间。 这不是死规定，但有个经验值：太短则语义破碎，太长则主题混杂。对于技术文档，一个子块讲清楚一个"点"就够了——要么是一个概念定义，要么是一个参数说明，要么是一个代码示例。

第三，确保子块能独立回答"是什么"或"怎么做"中的一个方面。 检验标准很简单：单独看这个子块，你能不能看懂它在说什么？如果离开了前后文就完全懵圈，那这个子块就切失败了。

修正后的代码思路：

# 正确示范：语义化切分子块
text_splitter = RecursiveCharacterTextSplitter(
    separators=["\n\n", "\n", ". ", " "],  # 优先按段落和句子切
    chunk_size=250,
    chunk_overlap=20,  # 轻微重叠，防止语义断裂
    length_function=len
)
# 注意：这里是对父块进行二次切分，不是对全文直接切
sub_chunks = text_splitter.split_documents(parent_chunk)

这样做，前面那个"数据库连接池"的例子就会完整地落在一个子块里。用户搜索时，向量匹配能精准命中，而且拿到的语义是完整的。

子块不是越大越好，也不是越小越好，而是越"语义完整"越好。它得像一枚精确制导的子弹，虽然小，但弹头里装的得是实心货。

---

3. 父块边界怎么画，才能不让上下文"断片"

如果说子块是子弹，那父块就是弹药箱。子弹打中了目标，你得有足够的弹药去覆盖它。父块的边界定义，决定了LLM最终能拿到多完整的"故事"。

新手在定义父块时，常常犯三个错误。

错误一：父块=整篇文档。 有人觉得，既然父块是给LLM用的，那干脆整章或整篇文档当父块得了。结果呢？检索到一个相关子块，召回的父块是5000字的整章内容。LLM的上下文窗口虽然是128K起步，但噪声多了照样干扰注意力。用户问一个具体API的参数，你把整个"用户手册"章塞进去，LLM看得眼花缭乱，生成时反而容易忽略重点，甚至开始 hallucinate。

错误二：父块大小机械固定，不顾语义边界。 比如强行规定父块必须是1500 token。刚好一个Markdown小节是1600 token，它一刀切下去，把最后的代码示例切给了下一个父块。子块检索命中了这个小节的文字描述，召回的父块里却没有那个关键的代码示例——上下文还是断的。

错误三：父块之间高度重叠。 有同学为了"保险"，让父块之间重叠50%。结果一个子块可能同时属于两个父块，召回时带回来大量重复内容。LLM生成的答案里就会反复念叨同一个例子，显得特别啰嗦且浪费token。

父块的设计核心是自然边界与完整上下文。

第一，优先按文档的天然结构划分父块。 如果你的文档是Markdown，按H2或H3标题划分父块。如果是Word文档，按"标题1/标题2"划分。如果是API文档，按"接口地址"或"功能模块"划分。天然结构是作者已经帮你整理好的语义边界，尊重它，比你按字符数硬切要靠谱一百倍。

第二，父块要包含"完整论证闭环"。 一个父块里，应该有"是什么、为什么、怎么做"的完整信息，至少不能因为切分而丢失关键依赖。如果一个小节里既有概念解释又有代码示例，它们必须在同一个父块里。宁可父块大一点（比如800-2000 token），也不要把相互依赖的内容拆开。

第三，父块之间尽量不重叠，保持独立。 子块之间可以有轻微重叠（防止句子被切断），但父块应该是互斥的。一个子块只能属于一个父块，这样才能保证召回时的确定性。如果你发现两个父块需要共享同一段内容，那说明你的父块划分粒度需要调整。

第四，给父块预留"自描述"空间。 在父块开头保留标题信息。比如父块内容以"## 3.2 异常处理机制\n\n"开头。这样即使LLM拿到的是父块中间的一部分（通过 sliding window 或其他方式），也能通过标题知道自己在看什么。

实际操作中，你可以先用文档解析器（如LangChain的MarkdownHeaderTextSplitter）按标题切出父块，然后再对每个父块用前文提到的方法切子块。这种"先粗后细"的两阶段切分，就是父子切块的标准工业化流程。

父块是LLM的"作战地图"，地图必须完整，不能缺角少边。按天然结构划分，让上下文自然流动，别用蛮力去切割。

---

4. 索引怎么建，才能让小块"认祖归宗"

有了好的切块策略，还得有靠谱的"档案系统"。子块负责站岗放哨（被检索），父块负责深度支援（被生成），中间的桥梁就是索引结构。

新手在建索引时，脑子最容易短路。我总结了几种典型错误：

错误一：只给子块建向量索引，父块没存。 这是最常见的翻车现场。代码里把子块全部向量化入库了，metadata里空空如也。检索到子块后，系统傻了——父块呢？没存啊！最后只能拿子块那几百字去生成，父子切块名存实亡。

错误二：父子块各建各的索引，没有关联ID。 有人把父块存一张表，子块向量存另一张库，但两张表之间没有外键或关联ID。检索到子块A后，你得靠"内容相似度"去父块库里 fuzzy search，这不仅慢，而且可能找错爹。

错误三：父块存进去了，但检索时把子块当父块用。 有些同学建了正确的关联，但代码逻辑写错了：检索返回子块后，直接拿子块的content去拼接prompt，完全忘了走"通过parent_id找父块"这一步。这种属于"架构设计对了，代码实现掉链子"。

我看过一个令人窒息的代码片段：

# 错误示范：检索后直接用子块生成
results = vectorstore.similarity_search(query, k=3)
context = "\n".join([doc.page_content for doc in results])  # 这里全是子块！
prompt = f"基于以下内容回答问题：{context}\n问题：{query}"

这段代码的问题在于，results里全是小子块，每个可能就200字。三个子块加起来600字，看着不少，但很可能来自同一个父块的不同角落，或者三个不同父块的碎片，上下文是断裂的。LLM拿到这600字，比拿到一个完整的1800字父块要懵逼得多。

正确的索引与召回机制，核心就一句话：子块携带父块ID，检索后做父块召回。

具体实现步骤：

第一步，定义父块，生成唯一parent_id。 每个父块在创建时，分配一个全局唯一ID，比如parent_001、parent_002。

第二步，在父块内部切子块，子块metadata绑定parent_id。 子块不只是一个字符串，它是一个带有丰富metadata的Document对象。

# 正确示范：建立父子关联
parent_chunks = split_by_headers(raw_docs)  # 按标题切父块

all_sub_chunks = []
for parent in parent_chunks:
    parent_id = generate_uuid()
    parent.metadata["parent_id"] = parent_id
    parent.metadata["role"] = "parent"
    
    # 对当前父块切子块
    sub_chunks = small_splitter.split_documents([parent])
    for sub in sub_chunks:
        sub.metadata["parent_id"] = parent_id
        sub.metadata["role"] = "child"
        all_sub_chunks.append(sub)

第三步，只把子块向量化入库。 父块可以存在普通数据库（如Redis、PostgreSQL），甚至也可以存在向量库的另一个collection里，但检索查询只针对子块的向量索引。

第四步，检索时，先捞子块，再换父块。 这是关键的业务逻辑：

# 正确示范：子块检索，父块生成
sub_results = vectorstore.similarity_search(query, k=10)

# 提取parent_id并去重，按相似度排序
parent_ids = []
seen = set()
for sub in sub_results:
    pid = sub.metadata["parent_id"]
    if pid not in seen:
        parent_ids.append(pid)
        seen.add(pid)

# 限制召回父块数量，防止超出LLM上下文
top_parent_ids = parent_ids[:3]

# 根据ID取出完整父块
parent_docs = parent_store.get_documents_by_ids(top_parent_ids)

# 父块拼接成上下文
context = "\n\n".join([p.page_content for p in parent_docs])
prompt = build_prompt(context, query)

这个流程里有个细节要注意：去重。因为你检索Top 10个子块，这10个子块可能来自同一个父块（如果那个父块特别相关）。如果不做去重，你会把同一个父块反复塞给LLM，浪费token。去重后一般取Top 3到Top 5个父块，既能保证多样性，又不至于上下文爆炸。

另一个细节是父块的存储格式。建议父块内容以原始文本形式存储，不要向量化（或者即使向量化也不要用于检索）。父块的目标是给LLM"读"的，所以要保留完整的格式——Markdown标题、代码块、列表，统统保留。子块则可以适当清洗，比如去掉多余的换行，让向量化的语义更聚焦。

技术实现不复杂，关键是脑子清醒——检索时子块是"引路人"，生成时父块是"发言人"。代码里一定要把这条血缘关系链打通，别让它们在数据库里失散了。

---

5. 那些藏在工程细节里的"魔鬼"

demo能跑只是开始，生产环境才是真正的考场。父子切块策略在落地时，有几个特别隐蔽的坑，一旦踩中，轻则效果回退，重则系统故障。

坑一：父子比例失衡。 有些同学把一个只有300字的父块切成了20个子块，平均每个子块15个字。这纯属过度设计。子块太小会导致向量化语义丧失，而且检索时召回的parent_id几乎全来自同一个父块，失去了多父块召回的意义。反过来，一个父块只切了1个子块，那父子切块退化成普通切块，毫无价值。

坑二：子块跨父块边界。 这通常发生在使用全局滑动窗口切分的时候。比如你的父块已经按标题切好了，但你在切子块时，不是"在每个父块内部单独切"，而是"把全文拼接起来统一切"。结果一个子块的内容横跨了两个父块，前半句属于父块A，后半句属于父块B。这个子块的metadata挂哪个parent_id？挂了A，召回时丢了B的后半句；挂了B，A的前半句没了。左右为难。

坑三：动态更新时的索引不一致。 生产环境文档是会更新的。某新手团队上线后，文档内容变了，他们只重新切了子块并更新了向量库，但忘了更新父块存储。结果检索到的新子块，按parent_id找回的却是旧版父块，LLM看到的上下文是"新问题的老答案"，生成内容自相矛盾。

坑四：忽视边界处的语义重叠。 完全不重叠，可能导致恰好在边界处的句子被一刀两断；重叠太多，又会导致检索冗余。父子块之间的重叠策略怎么设？很多人凭感觉设个200 token，结果在代码块中间重叠，把一段完整的代码切得支离破碎。

针对这些工程陷阱，我有几条实战建议：

第一，保持合理的父子块数量比。 建议一个父块内部切出5到15个子块。如果父块内容太少（比如不到500字），干脆别切了，这个父块 itself 就是一个子块（退化但合理）。如果父块内容极多（超过3000字），考虑你的父块粒度是否太粗了，应该先拆分父块。

第二，严格遵守"父块内切子块"的原则。 代码实现上，必须是双层循环：外层遍历每个父块，内层对当前父块调用splitter。千万别图省事，先把所有父块的文本抽出来拼成一个大字符串，再统一切分。

# 正确示范：父块内切子块，不跨边界
for parent in parent_chunks:
    sub_chunks = splitter.split_documents([parent])  # 只传当前父块
    for sub in sub_chunks:
        sub.metadata["parent_id"] = parent.metadata["parent_id"]

第三，文档更新时，父子块必须原子性重建。 建立文档版本管理机制。当源文档变更时，重新执行完整的两阶段切分流程（切父块→切子块→存父块→存子块向量），并标记旧版本为失效。不要只更新一半。可以用文档的hash值作为版本标识，检测到hash变化就触发全量重建。

第四，智能重叠策略：按语义单元重叠。 如果子块之间需要重叠（建议 overlap 控制在10%-20%），确保重叠点落在自然边界，比如段落之间或句子之间，而不是代码行中间。使用RecursiveCharacterTextSplitter时，合理设置chunk_overlap，并配合语义分隔符，它能尽量保证在边界处重叠。

第五，给父块加"摘要头"。 在把父块塞给LLM之前，可以在父块开头加一个自动生成的摘要或标题强化。比如用更小的模型给父块生成一句话摘要，放在父块最前面。这样即使LLM扫描长上下文，也能先通过摘要判断这个父块的相关性。当然，这属于进阶优化了。

能跑通demo只是幼儿园毕业，能扛住生产环境的魔鬼细节，才是真的工程师。父子切块策略的优雅，藏在每一个边界处理和更新逻辑里。

---

6. 怎么证明你的父子切块真的有效

优化不能靠拍脑袋，得有数据说话。父子切块策略上了之后，怎么知道它真的比传统切块强？你需要一套评估体系。

很多新手的评估方式极其"玄学"。上线后问了一圈同事"感觉答案好点了吗"，有人说好有人说没区别，最后不了了之。或者只看最终的"用户满意度"，但这指标太滞后，而且受LLM本身能力、Prompt工程、甚至前端UI的多重影响，根本分不清是切块的功劳还是锅。

更离谱的是，有人拿单个case的"惊艳效果"当普遍结论。“你看这个问题回答得多好！”——但可能只是因为刚好那个问题的答案在父块开头，LLM容易看到。换一个答案藏在父块中间的问题，效果可能断崖式下跌。这种"幸存者偏差"会误导你长期维护一个有缺陷的策略。

建立分层评估体系，从检索到生成，层层把关。

第一层：检索层评估（Recall & MRR）
准备一套测试集，包含50-100个你业务场景里的真实问题，并标注每个问题的"黄金父块"（正确答案所在的父块ID）。

• Recall@K：在Top K个子块中，是否至少有一个子块能关联到黄金父块。父子切块应该比传统大块切分有更高的Recall，因为子块更精准。
• MRR（平均倒数秩）：第一个关联到黄金父块的子块，平均排在第几位。越靠前越好。

第二层：生成层评估（Faithfulness & Answer Relevance）
用LLM-as-a-Judge或传统NLP指标评估生成质量。

• Faithfulness（忠实度）：生成的答案是否能在父块中找到依据。可以用专门的评估模型（如RAGAS框架）来打分。父子切块理论上Faithfulness应该更高，因为上下文更完整。
• Answer Relevance：答案是否切题。如果召回的父块噪声少，这个指标会提升。

第三层：对比实验（A/B Test）
在评估集上跑两组实验：

• 基线组：传统固定窗口切分（如1000 token）。
• 实验组：父子切块策略。

保持其他变量完全一致（同样的Embedding模型、同样的LLM、同样的Prompt模板）。最后对比两组的平均Faithfulness、平均token消耗、平均响应延迟。

此外，还要关注负面指标：

• 父块冗余度：召回的父块中，无关内容占比多少？如果父块定义太大，这个指标会恶化。
• token消耗：父子切块因为召回父块，单次请求的上下文通常更长，要监控token成本是否在可接受范围。如果成本高了三倍但质量只提升了5%，那可能得调整父块粒度。

评估时要特别注意边界case：

• 问题答案跨越多个父块的情况（需要多跳召回）。
• 问题非常具体（只需要子块即可回答）vs 问题很宽泛（需要大范围上下文）。
• 文档中存在大量相似章节时的区分度。

没有评估的优化是盲飞。给父子切块策略搭好仪表盘，你才知道自己飞得更高了，还是只是在原地扑腾。

---

写在最后

咱们今天从头到尾，把父子切块策略这六个关键要点捋了一遍。从"为什么要这么做"的本质思考，到"子块切多小、父块画多宽"的粒度设计；从索引里那根不能断的parent_id血缘链，到生产环境里让人头大的更新与边界陷阱；最后再到怎么用数据证明你真的做对了——这一整套组合拳打下来，你的RAG系统才算真正迈过了"玩具级"的门槛。

说实话，RAG开发里的门道太多了。文档分块只是冰山一角，但就是这一角，决定了大模型是"巧妇难为无米之炊"，还是"粮草充足、指哪打哪"。很多新手总觉得大模型效果不好是模型不够强，急着去换更贵的API、更猛的参数，却没想到问题可能出在文档怎么切上。就像做菜，食材都没切对，再好的厨子也炒不出好味道。

编程这条路，从来都是细节里见真章。父子切块策略教会我们的不只是技术，更是一种工程思维：别指望一个组件解决所有问题，专业分工、各司其职，系统才能高效运转。 小块去做它擅长的事——精准匹配；大块去做它擅长的事——完整表达。它们配合好了，大模型才能发挥出真正的威力。

我知道，看到这里的你，可能已经在脑子里回顾自己项目的分块逻辑了。如果发现了问题，别慌，改就是了。没有谁的架构一开始就是完美的，重要的是我们一直在思考、在迭代。保持好奇，持续学习，你写的每一行代码、踩的每一个坑，都会变成你技术生涯里的厚实家底。

加油，下个章节见！

关注私信备注：“资料代找获取”，全网计算机学习资料代找：例如:
《课程：2026 年多模态大模型实战训练营》
《课程：AI 大模型工程师系统课程 (22 章完整版 持续更新)》
《课程：AI 大模型系统实战课第四期 (2026 年开课 持续更新)》
《课程：2026 年 AGI 大模型系统课 23 期》
《课程：2026 年 AGI 大模型系统课 21 期》
《课程：AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》
《课程：AI 大模型系统实战课三期》
《课程：AI 大模型系统课程 (2026 年 2 月开课 持续更新)》
《课程：AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》
《课程：AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》
《课程：2026 年最新大模型 Agent 开发系统课 (持续更新)》
《课程：LLM 多模态视觉大模型系统课》
《课程：大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》
《课程：大模型智能体线上速成班 V2.0》
《课程：Java+AI 大模型智能应用开发全阶课》
《课程：Python+AI 大模型实战视频教程》
《书籍：软件工程 3.0: 大模型驱动的研发新范式.pdf》
《课程：人工智能大模型系统课 (2026 年 1 月底完结版)》
《课程：AI 大模型零基础到商业实战全栈课第五期》
《课程：Vue3.5+Electron + 大模型跨平台 AI 桌面聊天应用实战 (2025)》
《课程：AI 大模型实战训练营 从入门到实战轻松上手》
《课程：2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》
《课程：大模型训练营配套补充资料》