文章指出当Agent频繁错误调用Skill时问题往往出在Skill的设计上。作者详细解释了Skill被系统消费的底层机制即LLM仅通过Skill.md中的name和description字段做触发决策而忽略正文内容。文章分析了导致Skill调用混乱的三大原因Skill description边界模糊、SKILL.md信息过载、Skill description相似度高。接着提出了三条设计规则单一职责、关注点分离、信息精炼并介绍了四种常用的设计范式Operator、Scout、Partner、Navigator。最后强调Skill设计不仅要关注能否跑通更要关注调用的精准度、执行稳定性和定义成功标准。你肯定遇到过这种情况用户说帮我翻译这段话Agent 跑去给他总结了一份文档摘要。用户说分析一下这份报告的风险Agent 触发了文档总结 Skill输出了一堆要点提炼。更离谱的明明写了详细的 SkillAgent 执行时完全视而不见自己凭空编了一套流程出来。你开始怀疑是不是模型不够聪明或者是不是自己哪里配置错了。找了半天没发现问题。其实问题很简单但藏得很深——你的 Skill 设计在底层机制上就已经错了。一、先搞懂底层Agent 是怎么认识你的 Skill 的在讲怎么写之前得先搞清楚 Skill 是怎么被系统消费的。不理解这个后面所有的设计建议都是在空中楼阁上盖房子。Skill 的感知链路整个流程其实就四步SKILL.md → 扫描器提取摘要 → 注入 System Prompt 最前端 → LLM 做触发决策但关键在于第二步——扫描器从你的 SKILL.md 里只提取两个字段name 和 description。不是全文。就这两个字段。然后把这些摘要拼成一份 XML 格式的技能快照塞到 System Prompt 的最前面每次对话开始前都会注入给 LLM。这意味着什么LLM 在决定要不要触发这个 Skill的时候眼前只有 name 和 description。它根本看不到你在 SKILL.md 正文里写的那一大堆执行步骤、注意事项、代码示例。触发决策完全基于这两个字段。触发之后发生什么触发决策做完之后Agent 才会去读完整的 SKILL.md获取具体的执行步骤。所以 SKILL.md 实际上承担了两件完全不同的事摘要部分name description——决定触不触发正文部分——决定怎么执行这两件事的设计逻辑截然不同但大多数人写 Skill 的时候根本没意识到这个区别把两件事混在一起写结果两件事都没做好。二、乱调用的三个根本原因搞清楚底层之后再看那些翻车案例原因就很清楚了。原因一description 划定的边界太宽触发污染整个系统有一类 Skill 的 description 大概长这样“帮助开发者完成各种软件开发任务包括代码审查、Bug 修复、代码重构、单元测试、技术文档编写、性能优化……”写这个 description 的人出发点很好——想做一个全能开发助手。但从 LLM 的视角看这个描述几乎能匹配任何跟开发沾边的请求。用户说帮我看看这段代码触发它。用户说这个函数报错了触发它。用户说这段代码跑得太慢了还是触发它。最后的结果是不管用户说什么Agent 都优先跑去调用这个 Skill其他 Skills 被完全压制。这就是触发污染——一个边界模糊的 Skill会扰乱整个系统的触发逻辑。根本问题设计者把 Skill 当成了工具箱一个 Skill 里塞了五六个独立的职责。原因二SKILL.md 信息过载执行指令被淹没另一类错误更隐蔽。Skill 能触发但触发之后 Agent 的表现很奇怪——有时候会原封不动地输出文档内容有时候在执行到一半的时候突然偏航不知道在做什么。这种情况多半是因为 SKILL.md 里塞了太多不该在那里的东西。有人觉得给 Agent 的信息越多越好于是把第三方 API 的官方文档、完整的代码示例、各种参数说明全部复制粘贴进 SKILL.md。一个文件写到两三千行。LLM 读这个文件的时候面对的是一堆混在一起的指令和背景资料。它没有办法稳定地区分哪些是我应该执行的步骤哪些是参考文档。于是有时候它会把文档内容当成任务输出有时候会陷在背景知识里出不来。根本问题把 SKILL.md 当知识库用了而不是当执行指令用。原因三多个 Skill 的 description 过于相似触发冲突这个问题在 Skills 数量增多之后特别容易出现。系统里有三个 Skill文档总结、文档翻译、文档改写。它们的 description 都提到了处理文档措辞大同小异。用户说帮我处理一下这篇文章LLM 面对三个相似的 description触发哪个说实话很随机。同样的请求第一次触发总结第二次触发翻译第三次可能触发改写。这类问题的根源不是 LLM 不够聪明而是设计者从来没有想过去定义这个 Skill 不做什么。关键认知一个好的 description不只说我能做什么还要通过措辞上的精确性隐含地传递我不做什么。两个 Skill 的 description 如果高度相似LLM 就没有办法稳定区分它们。三、三条设计规则——从机制推导不是拍脑袋知道了原因规则就是自然推导出来的不需要死记。规则一单一职责——为触发决策服务description 要让 LLM 做出清晰判断前提是 Skill 本身的边界足够精准。判断一个 Skill 是否符合单一职责有个很简单的测试能否用一句话不包含和“或”“以及”描述它“将长文档压缩成结构化摘要” ✓“处理文档相关的各种任务” ✗“初始化项目目录结构” ✓“创建项目并生成文档以及运行测试” ✗如果一句话说不清楚说明这个 Skill 承担了不止一个职责需要拆。还有个更实用的自测方法把你的 description 给一个不了解这个 Skill 的同事看让他说出三个应该触发、三个不应该触发的例子。如果他说不准那 LLM 也说不准。规则二关注点分离——为执行逻辑服务SKILL.md 正文只写一件事Agent 执行时需要知道的步骤和判断逻辑。其他的东西各回各家SKILL.md → 执行流程Agent 读scripts/ → 可执行代码Python 解释器用references/ → 策略和知识按需引用assets/ → 输出模板复用结构你写的代码示例、API 参数说明、背景知识Agent 在执行时其实并不需要一次性全部读完。把这些东西从 SKILL.md 里剥离出去放到 references/ 或 scripts/ 目录下SKILL.md 只保留先做什么、再做什么、遇到什么情况怎么处理——执行效率会明显提升。规则三信息精炼——防止注意力被稀释LLM 的注意力是有限的。SKILL.md 越长执行步骤被淹没的可能性就越高。经验值核心 Skill 控制在 60~100 行复杂 Skill 不超过 200 行。内容构成公式执行步骤 关键参数 异常处理 外部引用详细文档给链接不做嵌入。代码示例超过 20 行就挪到 scripts/ 里SKILL.md 里只写调用哪个脚本、传什么参数。这三条规则的执行顺序也有讲究先用单一职责确定边界再用关注点分离组织结构最后用信息精炼优化内容。跳过前面直接做后面往往没有意义。四、选对结构四种最常用的设计范式规则解决的是不能犯哪些错范式解决的是该用什么结构。不同任务天然适合不同的组织方式。大多数场景落在这四种里面Operator工具链封装操作步骤是确定的涉及工具调用结果可以被验证——用这个。文档转换、数据处理、代码部署都是典型场景。重点是把每个步骤脚本化确保重复执行结果一致。Scout环境侦察不知道环境长什么样需要先探测再决定怎么做——用这个。代码库分析、系统诊断、Bug 定位都属于这类。核心逻辑是轻量探测 → 提出假设 → 验证 → 结论不要一上来就猛干。Partner人机协作需求模糊或者涉及主观判断或者有不可逆的风险操作——用这个。这类任务的难点不是执行而是在关键节点让用户参与决策。设计重点是定义清楚哪些节点需要人工确认而不是把所有步骤都做成交互。Navigator条件路由同一个入口根据不同条件走不同的处理路径——用这个。多阶段搜索、任务分发、条件执行都是这类。核心是把分支条件设计得足够清晰和互斥避免走错路径之后越跑越偏。选范式只需要回答一个问题这个任务的主要矛盾是什么——确定性执行、环境探索、主观判断还是条件路由第一个匹配的就是答案不要过度设计。五、一个容易被忽视的真相写完 SKILL.md 不等于 Skill 好用。很多人验证 Skill 的方式是跑一下没报错输出看起来还行完事。但这种验证方式遗漏了几个真正重要的问题误触发率和漏触发率各是多少你测过吗同样的请求执行 3 次结果稳定吗SKILL.md 行数是多少信息有没有超载有没有定义怎样算执行成功最后这个问题是很多人从来没想过的。没有定义失败就没有办法改进。一个没有验证标准的 Skill每次出问题你都不知道是触发错了、执行错了还是输出格式不对。01什么是AI大模型应用开发工程师如果说AI大模型是蕴藏着巨大能量的“后台超级能力”那么AI大模型应用开发工程师就是将这种能量转化为实用工具的执行者。AI大模型应用开发工程师是基于AI大模型设计开发落地业务的应用工程师。这个职业的核心价值在于打破技术与用户之间的壁垒把普通人难以理解的算法逻辑、模型参数转化为人人都能轻松操作的产品形态。无论是日常写作时用到的AI文案生成器、修图软件里的智能美化功能还是办公场景中的自动记账工具、会议记录用的语音转文字APP这些看似简单的应用背后都是应用开发工程师在默默搭建技术与需求之间的桥梁。他们不追求创造全新的大模型而是专注于让已有的大模型“听懂”业务需求“学会”解决具体问题最终形成可落地、可使用的产品。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】02AI大模型应用开发工程师的核心职责需求分析与拆解是工作的起点也是确保开发不偏离方向的关键。应用开发工程师需要直接对接业务方深入理解其核心诉求——不仅要明确“要做什么”更要厘清“为什么要做”以及“做到什么程度算合格”。在此基础上他们会将模糊的业务需求拆解为具体的技术任务明确每个环节的执行标准并评估技术实现的可行性同时定义清晰的核心指标为后续开发、测试提供依据。这一步就像建筑前的图纸设计若出现偏差后续所有工作都可能白费。技术选型与适配是衔接需求与开发的核心环节。工程师需要根据业务场景的特点选择合适的基础大模型、开发框架和工具——不同的业务对模型的响应速度、精度、成本要求不同选型的合理性直接影响最终产品的表现。同时他们还要对行业相关数据进行预处理通过提示词工程优化模型输出或在必要时进行轻量化微调让基础模型更好地适配具体业务。此外设计合理的上下文管理规则确保模型理解连贯需求建立敏感信息过滤机制保障数据安全也是这一环节的重要内容。应用开发与对接则是将方案转化为产品的实操阶段。工程师会利用选定的开发框架构建应用的核心功能同时联动各类外部系统——比如将AI模型与企业现有的客户管理系统、数据存储系统打通确保数据流转顺畅。在这一过程中他们还需要配合设计团队打磨前端交互界面让技术功能以简洁易懂的方式呈现给用户实现从技术方案到产品形态的转化。测试与优化是保障产品质量的关键步骤。工程师会开展全面的功能测试找出并修复开发过程中出现的漏洞同时针对模型的响应速度、稳定性等性能指标进行优化。安全合规性也是测试的重点需要确保应用符合数据保护、隐私安全等相关规定。此外他们还会收集用户反馈通过调整模型参数、优化提示词等方式持续提升产品体验让应用更贴合用户实际使用需求。部署运维与迭代则贯穿产品的整个生命周期。工程师会通过云服务器或私有服务器将应用部署上线并实时监控运行状态及时处理突发故障确保应用稳定运行。随着业务需求的变化他们还需要对应用功能进行迭代更新同时编写完善的开发文档和使用手册为后续的维护和交接提供支持。03薪资情况与职业价值市场对这一职业的高度认可直接体现在薪资待遇上。据猎聘最新在招岗位数据显示AI大模型应用开发工程师的月薪最高可达60k。在AI技术加速落地的当下这种“技术业务”的复合型能力尤为稀缺让该职业成为当下极具吸引力的就业选择。AI大模型应用开发工程师是AI技术落地的关键桥梁。他们用专业能力将抽象的技术转化为具体的产品让大模型的价值真正渗透到各行各业。随着AI场景化应用的不断深化这一职业的重要性将更加凸显也必将吸引更多人才投身其中推动AI技术更好地服务于社会发展。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】
Agent乱调用Skill的真相：你的Skill设计到底哪里错了？
发布时间：2026/6/5 5:01:13
文章指出当Agent频繁错误调用Skill时问题往往出在Skill的设计上。作者详细解释了Skill被系统消费的底层机制即LLM仅通过Skill.md中的name和description字段做触发决策而忽略正文内容。文章分析了导致Skill调用混乱的三大原因Skill description边界模糊、SKILL.md信息过载、Skill description相似度高。接着提出了三条设计规则单一职责、关注点分离、信息精炼并介绍了四种常用的设计范式Operator、Scout、Partner、Navigator。最后强调Skill设计不仅要关注能否跑通更要关注调用的精准度、执行稳定性和定义成功标准。你肯定遇到过这种情况用户说帮我翻译这段话Agent 跑去给他总结了一份文档摘要。用户说分析一下这份报告的风险Agent 触发了文档总结 Skill输出了一堆要点提炼。更离谱的明明写了详细的 SkillAgent 执行时完全视而不见自己凭空编了一套流程出来。你开始怀疑是不是模型不够聪明或者是不是自己哪里配置错了。找了半天没发现问题。其实问题很简单但藏得很深——你的 Skill 设计在底层机制上就已经错了。一、先搞懂底层Agent 是怎么认识你的 Skill 的在讲怎么写之前得先搞清楚 Skill 是怎么被系统消费的。不理解这个后面所有的设计建议都是在空中楼阁上盖房子。Skill 的感知链路整个流程其实就四步SKILL.md → 扫描器提取摘要 → 注入 System Prompt 最前端 → LLM 做触发决策但关键在于第二步——扫描器从你的 SKILL.md 里只提取两个字段name 和 description。不是全文。就这两个字段。然后把这些摘要拼成一份 XML 格式的技能快照塞到 System Prompt 的最前面每次对话开始前都会注入给 LLM。这意味着什么LLM 在决定要不要触发这个 Skill的时候眼前只有 name 和 description。它根本看不到你在 SKILL.md 正文里写的那一大堆执行步骤、注意事项、代码示例。触发决策完全基于这两个字段。触发之后发生什么触发决策做完之后Agent 才会去读完整的 SKILL.md获取具体的执行步骤。所以 SKILL.md 实际上承担了两件完全不同的事摘要部分name description——决定触不触发正文部分——决定怎么执行这两件事的设计逻辑截然不同但大多数人写 Skill 的时候根本没意识到这个区别把两件事混在一起写结果两件事都没做好。二、乱调用的三个根本原因搞清楚底层之后再看那些翻车案例原因就很清楚了。原因一description 划定的边界太宽触发污染整个系统有一类 Skill 的 description 大概长这样“帮助开发者完成各种软件开发任务包括代码审查、Bug 修复、代码重构、单元测试、技术文档编写、性能优化……”写这个 description 的人出发点很好——想做一个全能开发助手。但从 LLM 的视角看这个描述几乎能匹配任何跟开发沾边的请求。用户说帮我看看这段代码触发它。用户说这个函数报错了触发它。用户说这段代码跑得太慢了还是触发它。最后的结果是不管用户说什么Agent 都优先跑去调用这个 Skill其他 Skills 被完全压制。这就是触发污染——一个边界模糊的 Skill会扰乱整个系统的触发逻辑。根本问题设计者把 Skill 当成了工具箱一个 Skill 里塞了五六个独立的职责。原因二SKILL.md 信息过载执行指令被淹没另一类错误更隐蔽。Skill 能触发但触发之后 Agent 的表现很奇怪——有时候会原封不动地输出文档内容有时候在执行到一半的时候突然偏航不知道在做什么。这种情况多半是因为 SKILL.md 里塞了太多不该在那里的东西。有人觉得给 Agent 的信息越多越好于是把第三方 API 的官方文档、完整的代码示例、各种参数说明全部复制粘贴进 SKILL.md。一个文件写到两三千行。LLM 读这个文件的时候面对的是一堆混在一起的指令和背景资料。它没有办法稳定地区分哪些是我应该执行的步骤哪些是参考文档。于是有时候它会把文档内容当成任务输出有时候会陷在背景知识里出不来。根本问题把 SKILL.md 当知识库用了而不是当执行指令用。原因三多个 Skill 的 description 过于相似触发冲突这个问题在 Skills 数量增多之后特别容易出现。系统里有三个 Skill文档总结、文档翻译、文档改写。它们的 description 都提到了处理文档措辞大同小异。用户说帮我处理一下这篇文章LLM 面对三个相似的 description触发哪个说实话很随机。同样的请求第一次触发总结第二次触发翻译第三次可能触发改写。这类问题的根源不是 LLM 不够聪明而是设计者从来没有想过去定义这个 Skill 不做什么。关键认知一个好的 description不只说我能做什么还要通过措辞上的精确性隐含地传递我不做什么。两个 Skill 的 description 如果高度相似LLM 就没有办法稳定区分它们。三、三条设计规则——从机制推导不是拍脑袋知道了原因规则就是自然推导出来的不需要死记。规则一单一职责——为触发决策服务description 要让 LLM 做出清晰判断前提是 Skill 本身的边界足够精准。判断一个 Skill 是否符合单一职责有个很简单的测试能否用一句话不包含和“或”“以及”描述它“将长文档压缩成结构化摘要” ✓“处理文档相关的各种任务” ✗“初始化项目目录结构” ✓“创建项目并生成文档以及运行测试” ✗如果一句话说不清楚说明这个 Skill 承担了不止一个职责需要拆。还有个更实用的自测方法把你的 description 给一个不了解这个 Skill 的同事看让他说出三个应该触发、三个不应该触发的例子。如果他说不准那 LLM 也说不准。规则二关注点分离——为执行逻辑服务SKILL.md 正文只写一件事Agent 执行时需要知道的步骤和判断逻辑。其他的东西各回各家SKILL.md → 执行流程Agent 读scripts/ → 可执行代码Python 解释器用references/ → 策略和知识按需引用assets/ → 输出模板复用结构你写的代码示例、API 参数说明、背景知识Agent 在执行时其实并不需要一次性全部读完。把这些东西从 SKILL.md 里剥离出去放到 references/ 或 scripts/ 目录下SKILL.md 只保留先做什么、再做什么、遇到什么情况怎么处理——执行效率会明显提升。规则三信息精炼——防止注意力被稀释LLM 的注意力是有限的。SKILL.md 越长执行步骤被淹没的可能性就越高。经验值核心 Skill 控制在 60~100 行复杂 Skill 不超过 200 行。内容构成公式执行步骤 关键参数 异常处理 外部引用详细文档给链接不做嵌入。代码示例超过 20 行就挪到 scripts/ 里SKILL.md 里只写调用哪个脚本、传什么参数。这三条规则的执行顺序也有讲究先用单一职责确定边界再用关注点分离组织结构最后用信息精炼优化内容。跳过前面直接做后面往往没有意义。四、选对结构四种最常用的设计范式规则解决的是不能犯哪些错范式解决的是该用什么结构。不同任务天然适合不同的组织方式。大多数场景落在这四种里面Operator工具链封装操作步骤是确定的涉及工具调用结果可以被验证——用这个。文档转换、数据处理、代码部署都是典型场景。重点是把每个步骤脚本化确保重复执行结果一致。Scout环境侦察不知道环境长什么样需要先探测再决定怎么做——用这个。代码库分析、系统诊断、Bug 定位都属于这类。核心逻辑是轻量探测 → 提出假设 → 验证 → 结论不要一上来就猛干。Partner人机协作需求模糊或者涉及主观判断或者有不可逆的风险操作——用这个。这类任务的难点不是执行而是在关键节点让用户参与决策。设计重点是定义清楚哪些节点需要人工确认而不是把所有步骤都做成交互。Navigator条件路由同一个入口根据不同条件走不同的处理路径——用这个。多阶段搜索、任务分发、条件执行都是这类。核心是把分支条件设计得足够清晰和互斥避免走错路径之后越跑越偏。选范式只需要回答一个问题这个任务的主要矛盾是什么——确定性执行、环境探索、主观判断还是条件路由第一个匹配的就是答案不要过度设计。五、一个容易被忽视的真相写完 SKILL.md 不等于 Skill 好用。很多人验证 Skill 的方式是跑一下没报错输出看起来还行完事。但这种验证方式遗漏了几个真正重要的问题误触发率和漏触发率各是多少你测过吗同样的请求执行 3 次结果稳定吗SKILL.md 行数是多少信息有没有超载有没有定义怎样算执行成功最后这个问题是很多人从来没想过的。没有定义失败就没有办法改进。一个没有验证标准的 Skill每次出问题你都不知道是触发错了、执行错了还是输出格式不对。01什么是AI大模型应用开发工程师如果说AI大模型是蕴藏着巨大能量的“后台超级能力”那么AI大模型应用开发工程师就是将这种能量转化为实用工具的执行者。AI大模型应用开发工程师是基于AI大模型设计开发落地业务的应用工程师。这个职业的核心价值在于打破技术与用户之间的壁垒把普通人难以理解的算法逻辑、模型参数转化为人人都能轻松操作的产品形态。无论是日常写作时用到的AI文案生成器、修图软件里的智能美化功能还是办公场景中的自动记账工具、会议记录用的语音转文字APP这些看似简单的应用背后都是应用开发工程师在默默搭建技术与需求之间的桥梁。他们不追求创造全新的大模型而是专注于让已有的大模型“听懂”业务需求“学会”解决具体问题最终形成可落地、可使用的产品。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】02AI大模型应用开发工程师的核心职责需求分析与拆解是工作的起点也是确保开发不偏离方向的关键。应用开发工程师需要直接对接业务方深入理解其核心诉求——不仅要明确“要做什么”更要厘清“为什么要做”以及“做到什么程度算合格”。在此基础上他们会将模糊的业务需求拆解为具体的技术任务明确每个环节的执行标准并评估技术实现的可行性同时定义清晰的核心指标为后续开发、测试提供依据。这一步就像建筑前的图纸设计若出现偏差后续所有工作都可能白费。技术选型与适配是衔接需求与开发的核心环节。工程师需要根据业务场景的特点选择合适的基础大模型、开发框架和工具——不同的业务对模型的响应速度、精度、成本要求不同选型的合理性直接影响最终产品的表现。同时他们还要对行业相关数据进行预处理通过提示词工程优化模型输出或在必要时进行轻量化微调让基础模型更好地适配具体业务。此外设计合理的上下文管理规则确保模型理解连贯需求建立敏感信息过滤机制保障数据安全也是这一环节的重要内容。应用开发与对接则是将方案转化为产品的实操阶段。工程师会利用选定的开发框架构建应用的核心功能同时联动各类外部系统——比如将AI模型与企业现有的客户管理系统、数据存储系统打通确保数据流转顺畅。在这一过程中他们还需要配合设计团队打磨前端交互界面让技术功能以简洁易懂的方式呈现给用户实现从技术方案到产品形态的转化。测试与优化是保障产品质量的关键步骤。工程师会开展全面的功能测试找出并修复开发过程中出现的漏洞同时针对模型的响应速度、稳定性等性能指标进行优化。安全合规性也是测试的重点需要确保应用符合数据保护、隐私安全等相关规定。此外他们还会收集用户反馈通过调整模型参数、优化提示词等方式持续提升产品体验让应用更贴合用户实际使用需求。部署运维与迭代则贯穿产品的整个生命周期。工程师会通过云服务器或私有服务器将应用部署上线并实时监控运行状态及时处理突发故障确保应用稳定运行。随着业务需求的变化他们还需要对应用功能进行迭代更新同时编写完善的开发文档和使用手册为后续的维护和交接提供支持。03薪资情况与职业价值市场对这一职业的高度认可直接体现在薪资待遇上。据猎聘最新在招岗位数据显示AI大模型应用开发工程师的月薪最高可达60k。在AI技术加速落地的当下这种“技术业务”的复合型能力尤为稀缺让该职业成为当下极具吸引力的就业选择。AI大模型应用开发工程师是AI技术落地的关键桥梁。他们用专业能力将抽象的技术转化为具体的产品让大模型的价值真正渗透到各行各业。随着AI场景化应用的不断深化这一职业的重要性将更加凸显也必将吸引更多人才投身其中推动AI技术更好地服务于社会发展。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】
