当老百姓在政务大厅排了2小时队只为问一句"社保怎么转移"时，你的RAG系统能不能在三秒内给出一个带红头文件出处、像窗口公务员一样严谨的标准答案？本文把"政策法规智能问答"从文档治理到国产化落地的全链路踩坑实录一次性讲透，手把手教你搭一个领导敢签字、群众能信服的政务大模型。

文字目录

• 一、政务知识库构建：别让扫描件和PDF毁了你的向量库
• 二、RAG检索链路设计：从"关键词撞大运"到"语义精准召回"
• 三、Prompt工程与角色约束：让大模型学会"打官腔"
• 四、幻觉防控与溯源机制：每一条回答都要"有据可查"
• 五、系统落地与国产化适配：信创环境里的最后一公里
• 六、持续运营与反馈迭代：RAG上线只是开始
• 写在最后

嗨，大家好呀，我是你的老朋友精通代码大仙。接下来我们一起学习 《大模型RAG生成式AI开发实战》200.[第20章 行业应用案例] 政务服务系统：政策法规智能问答

都说"代码能跑就别动"，但在政务系统里，你的RAG要是敢胡言乱语，那可比生产环境删库跑路还刺激——毕竟老百姓是真拿着你的回答去办事的。很多新手同学刚学会LangChain调个API，就觉得自己能上手企业项目了，结果一头扎进政务场景，直接被红头文件、信创适配、幻觉防控三座大山压得喘不过气。别慌，今天咱就把这一章的坑挨个儿趟一遍，让你少走半年弯路。

一、政务知识库构建：别让扫描件和PDF毁了你的向量库

先说点题。政务服务系统的知识载体，80%都是PDF、扫描件、甚至是红头文件的图片。这些东西直接往向量库里一扔，等于给后面的检索和生成埋了一颗大雷。文档治理这事儿，看着像苦力活，实则是整个RAG系统的地基。地基歪了，楼盖再高也得塌。

你是不是也这样？拿到几百份政策文件，两眼一抹黑，写个Python脚本直接调PyPDF2，按每页或者每512字符一刀切，切完就往Milvus里塞。觉得只要字都在库里，检索总能召回来？太天真了。

坑就在这里。举个例子，某市的《住房公积金提取管理办法》，第三条本来是一段完整的提取情形说明：“第三条 职工有下列情形之一的，可以申请提取本人住房公积金账户内的存储余额：（一）购买、建造、翻建、大修自住住房的；（二）离休、退休的；（三）完全丧失劳动能力，并与单位终止劳动关系的……” 你倒好，固定长度一刀切，把第三条的前半段切进了chunk A，后半段切进了chunk B。老百姓问"哪些情况能提公积金"，向量检索可能只召回chunk B，大模型看到chunk B开头就是"（二）离休、退休的"，以为只有退休才能提，直接把（一）（三）给漏了。这回答要是放出去，群众跑到窗口质问"凭什么网上说只有退休能提"，你这系统就算社死了。

还有更离谱的。政务文件里一大堆红色公章，OCR软件识别时，公章直接把正文文字盖住了，识别出来一堆星号或者乱码。再比如表格，PDF里的表格直接提文本，列全乱了，"税率"和"征收对象"对不上号。你切片的时候不处理版面，大模型读到的就是一锅粥。

那咋办？得建立一条正经的文档预处理流水线。

第一步，解析别偷懒。别用那种只读纯文本的库，得上能识别版面的工具，比如基于视觉模型的PDF解析器，或者像Marker、MinerU这类专门干这活的。把标题、正文、表格、页眉页脚、公章区域分开。标题层级得保留，"第一章 总则"和"第一条"之间的父子关系，就是后面语义切片的依据。

第二步，切片按"政策逻辑"走，别按字符数。最小粒度建议到"条"级别。一条政策就是一个完整语义单元，宁可chunk大一点，也别把一条切开。如果某一条实在太长，再考虑按"款"或"项"二次切，但要在元数据里标注"本段属于第X条第X款，完整条文见链接"。表格怎么办？整张表打包成一个chunk，前面加一段描述文字说明这张表出自哪个文件第几条。

第三步，元数据必须丰富。每个chunk入库时，带上"发文机关"、“文号”、“施行日期”、“时效性状态（现行有效/已废止/部分修订）”。这玩意在后面的检索过滤里能救命。比如用户问的是2024年的新政策，你直接把2021年已废止的旧文件过滤掉，召回质量立马上去。

给你看看正确姿势下的效果。同样是那份公积金办法，解析后得到树状结构：章→节→条。第三条作为一个完整chunk入库，用户问提取情形，系统召回的就是完完整整的第三条，一二三四五款都在。大模型想漏都漏不掉。

所以记住，政务知识库不是"扔进向量库就完事"的无脑操作。前期文档治理占整个项目70%的精力，这一步踏实了，后面的检索和生成才能稳扎稳打。

二、RAG检索链路设计：从"关键词撞大运"到"语义精准召回"

点题。用户站在政务大厅或者手机小程序前，敲下来的问题可能是：“我退休了，医保咋整？”、“外地人在你们这买房要交多久社保？” 这种口语化、甚至带点方言味的表达，和你知识库里那些文绉绉的政策条文之间，隔着十万八千里。检索链路设计不好，要么召不回，要么召回一堆八竿子打不着的干扰项。

新手最容易犯的错，就是"单线程思维"。要么只搞个向量数据库，指望Embedding能把"医保咋整"和"城镇职工基本医疗保险退休人员待遇"自动对上；要么只搞个Elasticsearch，用户打个错别字"公基金"就直接查无此词。更常见的是，召回了一堆结果，真正相关的排在第四第五，大模型上下文窗口就那么长，前面被垃圾信息占满了，后面的金子根本看不见。

来看个真实踩坑现场。用户问：“外地人在本市买房需要什么社保条件？” 你的系统如果只走向量通道，Embedding模型觉得"买房"和"住房保障"挺像，召回的全是"公租房申请指南"。如果只走关键词通道，“社保"这个词在太多文件里出现了，召回了一堆"社会保险法总则”、“社保费征缴暂行条例”，就是没召回到那个限制购房资格的"关于进一步加强房地产市场调控的通知"。最后大模型拿着这些跑偏的上下文，开始现场编限购政策——几环内能买、要交几年社保、个税算不算，全给你编一套。这要是放出去，第二天就能上新闻。

解法其实不难，核心就四个字：多路召回，精排兜底。

第一路，稠密向量召回。用好的Embedding模型（比如BGE-large-zh），把政策条文和用户问题都变成向量，找语义相近的。这负责抓那些"换了个说法但意思一样"的情况。

第二路，稀疏关键词召回。用BM25或者倒排索引，抓那些专有名词。比如"住房公积金"、“契税”、“增值税”，这些词在政务场景里精准度极高，向量反而可能丢。

两路召回的结果，别直接简单去重。得用一个融合策略，比如RRF（Reciprocal Rank Fusion），把两路列表的排序分数归一化后加权求和，得到一个统一的候选池。

但到这还不够。候选池里有20条，谁排前面？得上Reranker。用一个Cross-Encoder或者专门的Rerank模型（比如bge-reranker-large），对每条候选和问题的相关性重新打分。这步虽然耗点算力，但能把最相关的chunk硬推到第一屏。

还有一个大杀器：查询改写（Query Rewriting）。在召回之前，先用一个小模型或者规则引擎，把老百姓的口语化问题改写成政策文档风格。比如"医保咋整"→"职工退休后基本医疗保险待遇享受条件及办理流程"；“买房要交多久社保"→"非本地户籍居民家庭购房社会保险缴纳年限要求”。改写后的Query再去走检索，召回准确率能翻一倍。

最后，召回的TopK别贪多。政务问答讲究精准，一般Top5-Top8足够了。要把这些chunk做摘要压缩，只保留和问题是相关的段落，把宝贵的上下文token留给系统Prompt和大模型的推理空间。

你看，当检索链路跑通了，还是那个"外地人买房"的问题。Query改写后命中"非本地户籍购房社保年限"，向量通道召回到了调控通知的第五条，关键词通道命中了"社会保险缴纳证明"，Rerank之后两条精准政策排在最前。大模型拿到手的，全是干货，想编都没机会。

检索是RAG的命根子。召回不准，后面的大模型再聪明，也是巧妇难为无米之炊。

三、Prompt工程与角色约束：让大模型学会"打官腔"

点题。大模型原生的话风，要么像知乎大V，要么像贴心客服，放到政务窗口，一句"我觉得你可以试试"或者"亲，建议你去咨询一下哦"，直接就能引发投诉。政务问答的回答，必须严谨、中立、有据、结论先行。Prompt就是你的编制约束，让AI时刻记着自己是在代表政府说话。

很多同学刚接触RAG，Prompt写得特别草率。就一句：“请根据以下内容回答问题：{context}。问题：{question}。” 这哪够啊？上下文里如果有多个文件，模型直接给你张冠李戴，把A市的政策套到B市头上。语气更是飘忽不定，今天给你来段Markdown列表，明天给你写个小作文，后天来个"综上所述"。老百姓要的是标准答复，不是阅读理解。

来，看看错误示范。系统Prompt几乎为空，上下文里塞了三份不同年份的社保文件。用户问"养老保险交满15年还需要再交吗"。模型回答：“根据上面这些材料，我觉得吧，交满15年应该是可以不用再交了，但也不一定，因为后面好像还有个什么延长缴费的规定。建议你最好还是去当地社保局问问哈～” 好家伙，“我觉得”、“也不一定”、“建议你去问问”，政务场景的三宗罪全占了。群众看了这回答，是信还是不信？窗口工作人员看了，想不想顺着网线过来打你？

正确做法，Prompt得层层设卡。

第一层，角色固化。别写什么"你是一个有帮助的AI助手"。要写：“你是一位严谨的政策法规咨询专员。回答风格参照政府公开答复：准确、客观、无歧义。禁止使用’我认为’、‘可能’、‘建议’、'大概’等主观或模糊表述。回答应使用规范书面语，不使用网络流行语和口语化表达。”

第二层，上下文隔离与强制引用。给每个chunk打上清晰的来源标签，比如：
【来源1：《XX市城镇职工基本养老保险规定》（X府令〔2023〕12号）第十二条】
【来源2：《XX市社会保险费征缴办法》（X人社发〔2022〕45号）第八条】
然后在Prompt里命令模型：“回答时必须注明所依据的具体文件名称和条款编号。若多个来源信息冲突，以发文日期最新的为准，并说明旧条款已被修订。”

第三层，输出模板化。用Few-shot给模型看标准答案长什么样。比如：
示例问题：达到法定退休年龄但缴费不足15年怎么办？
示例回答：
结论：可以延长缴费至满15年。
依据：《实施〈中华人民共和国社会保险法〉若干规定》（人社部令第13号）第二条。
条款原文：“参加职工基本养老保险的个人达到法定退休年龄时，累计缴费不足十五年的，可以延长缴费至满十五年…”
适用说明：该规定适用于2011年7月1日后参保的人员。

把这个示例往Prompt里一放，模型就知道该按"结论+依据+条款原文+适用说明"四段式输出，格式稳得一批。

第四层，兜底策略。Prompt里必须加一句：“若提供的政策条款无法直接回答问题，或条款间无明确关联，必须输出’根据现有政策文件，该问题暂无明确对应条款，建议前往XX政务服务中心现场咨询或拨打12345热线。'严禁基于个人经验或外部知识进行推测。”

这么一套组合拳下来，还是那个"交满15年"的问题。模型输出：“无需继续缴纳。依据《XX市城镇职工基本养老保险规定》（X府令〔2023〕12号）第十二条：'参保人员达到法定退休年龄且累计缴费满十五年的，按月领取基本养老金…'适用说明：缴费满15年是领取养老金的必要条件之一，达到后即可依法享受待遇，无需强制继续缴费（但继续缴费可增加养老金水平，属个人自愿行为）。”

看看，结论明确，依据清晰，甚至还主动补充了"自愿继续缴费"的说明，既严谨又完整。

Prompt不是越长越好，但在政务场景，每一个约束词都是一道防火墙。防火墙越密，胡说八道的空间就越小。

四、幻觉防控与溯源机制：每一条回答都要"有据可查"

点题。大模型幻觉，放在写小说、编文案里叫"创意"，放在政务问答里就叫"事故"。一个过时的税率、一条已废止的政策、一个被曲解的办理时限，都可能让群众白跑十趟窗口，甚至引发行政复议。在政务RAG里，"可追溯"比"回答流畅"重要一万倍。

新手往往过度迷信大模型的"聪明"。看着输出像模像样，语句通顺，层次分明，就以为它真懂了。殊不知模型最擅长的就是"一本正经地胡说八道"。它能把"15个工作日"记成"15天"，能把"免征"写成"减按1%征收"，还能给根本不存在的文件编个文号。更可怕的是，如果没有溯源机制，你连它从哪段文字里"学坏"的都找不到。

说个真实的噩梦场景。用户问：“个人所得税赡养老人专项附加扣除标准是每月多少？” 你的知识库里其实有两条：一条是2018年的国发〔2018〕41号，规定2000元/月；另一条是2023年的国发〔2023〕13号，提高到3000元/月，且明确自2023年1月1日起施行。系统检索时，两条都召回了，但大模型在生成时，没注意到时间线，直接给了3000元。用户拿着这个回答去申报2022年度的个税汇算，按3000填了，结果税务稽核不通过，补税加滞纳金。用户勃然大怒，投诉到媒体，问你"你们系统谁给的胆子乱讲？" 你翻遍日志，发现模型根本没标注这话出自哪个文件，想辩解都没证据。

这种坑怎么防？得建立三层防护网。

第一层，溯源绑定。RAG召回的每个chunk，在喂给大模型之前，必须把元数据焊死在文本里。不是偷偷塞给模型看，而是要求模型在回答时显式引用。比如强制要求输出格式包含"【依据：《XXX》（文号）第X条】"。这样用户拿到的每句话，都能倒查回原始文件。前端展示时，甚至可以把引用做成超链接，一点击直接打开PDF原文对应页。

第二层，事实抽取与反向校验。对AI生成的回答，过一个事实校验模块。用正则或者NER模型，把回答里的关键数字实体抓出来：金额、天数、年份、比例、文号。然后拿着这些实体，反向去召回的原文chunk里做字符串匹配或语义相似度校验。如果回答里说"15天"，但原文是"15个工作日"，相似度不够，直接拦截。如果回答里编了一个文号，在原文里找不到，直接拦截。

第三层，时效性检查。在知识库元数据里，必须标注每个文件的"时效性状态"：现行有效、已废止、被修订、征求意见稿。检索阶段就优先召回"现行有效"的文件。如果模型不得不引用已废止的文件（比如用户问的是历史政策），必须在回答开头显著位置提示：“注意，以下引用的《XXX》已于X年X月X日被《XXX》废止，仅供参考。”

第四层，人工审计与兜底。高敏问题（涉及行政处罚、行政许可、涉法涉诉）不走直出，必须进人工审核池。或者设置一个置信度分数，当检索结果和问题的匹配分数低于阈值，或者事实校验不通过时，系统自动降级，输出"该问题涉及复杂情况，建议您携带相关材料至XX窗口现场办理"，而不是勉强给个不确定的答案。

流程上，可以这么设计：

当这套机制跑起来，还是那个赡养老人扣除的问题。模型回答后，事实校验模块扫到"3000元"，在召回原文里匹配到国发〔2023〕13号，同时发现用户问题语境涉及2022年申报。系统自动追加提示：“上述3000元标准自2023年度起执行。如您办理2022年度个税汇算，请按2000元/月标准执行，依据：国发〔2018〕41号。” 既回答了问题，又避免了误用。

在政务领域，宁可让系统答得慢点、笨点，也不能答错。因为信任一旦崩塌，技术再先进也救不回来。

五、系统落地与国产化适配：信创环境里的最后一公里

点题。你在MacBook Pro上用OpenAI的API，配合ChromaDB，一个下午就能跑出Demo。但政务项目的生产环境，往往是国产ARM芯片（鲲鹏/飞腾）、银河麒麟或统信UOS操作系统、达梦或人大金仓数据库，内网物理隔离。从Demo到生产，中间隔着的不是一行代码，而是整个信创生态的适配鸿沟。

新手最容易在哪摔跤？选型时完全按开发顺手来。Embedding用OpenAI的text-embedding-ada-002，大模型用GPT-4，向量库用Pinecone。到交付前一周去甲方机房一看，服务器是鲲鹏920，内网不通外网，操作系统是麒麟V10，当场傻眼。现换国产模型，发现Embedding维度从1536变成了1024，之前基于1536维度建的向量库全废。推理框架更头疼，原先用的vLLM在ARM+昇腾NPU上根本跑不起来，得切到MindIE或者昇腾自己的推理引擎，API全变了，服务层代码得重写。

还有个隐蔽的坑：并发。政务大厅早上9点开门，一瞬间几十个窗口同时调用，或者微信小程序上线后遇到政策热点（比如房产税新政），QPS直接爆表。你Demo阶段只测了单线程，到生产环境模型推理排队、内存溢出、API超时，系统直接摆烂。

那这条信创的坑该怎么填？

第一，国产化选型必须前置，不能事后打补丁。立项第一天就把信创清单敲定：CPU用鲲鹏还是海光？NPU用昇腾还是寒武纪？操作系统是麒麟还是统信？数据库要不要向量扩展？大模型选哪家？（文心一言政企版、通义千问政务版、ChatGLM3/4、Baichuan2，或者昇腾原生适配的模型）。Embedding和Reranker也得找有国产支持的，比如BGE系列、piccolo-base-zh。

第二，模型必须私有化部署。政务数据不出域是铁律，绝对不能走公网API。用国产推理框架把模型布在本地。如果在昇腾上，得提前把PyTorch模型转换成OM格式，或者用MindSpore原生训练/微调的版本。显存和并发要提前压测，用Locust或者JMeter模拟真实QPS，别信"感觉能撑住"。

第三，向量库和中间件适配。Milvus有ARM64版本，可以在信创环境编译部署。但如果甲方指定了国产数据库，要看它有没有向量检索插件，或者自研一个基于Faiss的轻量级向量检索服务，用HTTP封装，解耦底层存储。

第四，工程化兜底。用Docker做信创镜像，基于麒麟V10或统信UOS的基础镜像交叉编译。服务层加限流（Rate Limiting）、熔断（Circuit Breaker）和降级。大模型服务挂了怎么办？自动切到传统FAQ库或者Elasticsearch精确匹配兜底，保证老百姓起码能搜到点有用的，而不是直接报错404。

看看正确姿势：项目启动就确定用ChatGLM3-6B（昇腾Atlas 300I Pro推理卡，MindIE部署）、BGE-large-zh（国产Embedding，1024维）、Milvus 2.3（ARM64编译版）、麒麟V10容器。开发阶段就在信创沙箱环境联调，每天构建ARM镜像跑回归测试。上线前压测到500并发，P99延迟控制在3秒内。

政务项目，一半功夫在技术，另一半在工程。信创适配不是"后期兼容一下"的补丁，而是从架构设计第一天就要考虑的原始需求。别等甲方验收时才想起来问：“你们这玩意，能在国产机上跑吗？”

六、持续运营与反馈迭代：RAG上线只是开始

点题。政策文件不是代码库，不会等你发版更新。国务院、各部委、省市局随时会发新文、废旧文、打补丁。一个没有运营机制的RAG系统，知识保鲜期可能只有三个月。今天上线的系统，明天一份新政出台，后天它就变成了"造谣机器"。

很多团队把RAG当一锤子买卖。上线导入几百份文件，香槟一开，庆祝收工。然后呢？没有然后了。知识库成了死水。2024年房产税新政都出来两周了，系统还在按2023年的旧标准回答。群众问"首套房契税怎么交"，系统给出错误的税率，用户多交了钱，直接投诉到电视台，项目差点被叫停。

再说反馈。前端明明做了"点赞/点踩"按钮，点踩的数据躺在日志里吃灰，没人分析，没人修正。同一个错误回答，日复一日地坑不同的老百姓。团队还在自我安慰：“大模型嘛，有点误差很正常。” 大哥，这是政务，不是聊天机器人！

运营RAG，得建立三条自动化流水线。

第一条，知识自动更新流水线。对接政府公报、政策文件库的RSS或者官方API，每天凌晨爬取最新发文。新文件进来后，自动走解析、切片、向量化、入库流程。旧文件不是直接覆盖，要做版本化管理——标记废止、标记修订、保留历史版本。这样用户问"以前的老政策是什么"也能答。关键政策更新后，最好主动推送摘要给运营人员做一次人工确认，防止爬虫抓错或者解析异常。

第二条，用户反馈闭环。前端每个回答必须配"回答有用/回答无用/我要纠错"三连按钮。点踩的数据自动聚类，把相似问题归为一类。每周生成一份Bad Case报告，运营团队（最好有业务专家参与）逐条审核。如果是知识库缺文件，补文件；如果是检索不准，调Reranker权重或改写规则；如果是Prompt理解偏差，加Few-shot示例。修正后的数据要回灌到测试集，确保同样的问题下次不再错。

第三条，量化评估体系。别再用"感觉还行"糊弄老板。要建指标：

• 检索侧：召回率（Recall）、准确率（Precision）、MRR（平均倒数排名）。
• 生成侧：答案相关性、幻觉率（通过人工抽检+自动事实校验统计）。
• 业务侧：问题覆盖率（多少问题能自动回答）、转人工率（答不上才转人工的比例）、用户满意度。

用这些指标做A/B测试。比如测试Query改写模块V1和V2哪个召回率高，测试Prompt A和Prompt B哪个幻觉率低。用数据驱动迭代，而不是拍脑袋。

举个例子。团队搭建了"政策雷达"，每天凌晨扫描省税务局、市司法局官网。发现《关于调整住房公积金缴存基数的通知》后，2小时内完成解析入库，早晨8点前向量索引重建完毕。9点上班后群众提问，拿到的就是最新缴存上限。同时，上周Top10的Bad Case里，"灵活就业社保补贴"问题因为知识库缺了2024年新业态补充文件，导致回答错误。运营补录文件、调整切片策略后，本周该类问题的准确率从60%干到了98%。

RAG系统像个花园。你不浇水施肥（更新知识）、不除草除虫（清理Bad Case）、不修剪枝丫（迭代模型），三个月就会荒草丛生。只有把运营当成和技术开发同等重要的事，这个系统才能真正活起来，越用越聪明。

写在最后

看到这里，你是不是觉得政务RAG的水，比你想象的深得多？从扫描件里抠文字，到信创服务器上跑模型，再到给AI戴好"不会胡说"的紧箍咒，每一步都是技术和业务的深水区。很多同学一开始被大模型的风头唬住，以为接个API、塞个向量库就能做出产品，结果在政务这个对准确性、合规性、稳定性要求极高的场景里，被现实教做人。

但好在，坑虽多，路是明的。只要你记住今天聊的这几个核心：文档治理做扎实、检索链路多路并举、Prompt带上编制约束、幻觉防控层层设卡、信创适配前置设计、上线之后持续运营，你就能搭出一个真正敢给领导汇报、敢让群众使用的政务智能问答系统。

编程之路不易，做AI应用更难。但每一次把胡说八道的模型调教成靠谱的政策助手，每一次看到群众因为系统少跑一趟窗口，那种成就感，比单纯写个CRUD接口要爽得多。保持好奇，持续迭代，别怕踩坑。你写的每一行代码，都在让这个世界的办事效率变高一点点。

咱们下一章见！

关注私信备注：“资料代找获取”，全网计算机学习资料代找：例如:
《课程：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 智能体项目实战开发课》
《课程：大模型训练营配套补充资料》