本文详细探讨了在 Agent 项目中Prompt、Context 和 Skill 的作用和相互关系。作者指出这三者并非简单的平级概念而是分别负责任务的指令、模型的可见工作集以及程序性知识的按需加载。文章还分析了工业界和学术界在这三方面的最新进展强调了 Context Engineering 和 Skill 的合理使用对于提升大模型应用效果的重要性。最后作者提供了一套实用的排查方法帮助开发者判断 Agent 出现问题时应该调整 Prompt、Context 还是 Skill。一、先把关系说清楚Prompt、Context、Skill 不是三个平级概念先说一个容易引起争论的地方“Prompt”在不同产品里的口径并不完全一样。有些应用程序编程接口Application Programming InterfaceAPI会把整段模型输入都泛称为 prompt。为了工程讨论不打架本文把 Prompt 理解成模型输入中承担“显式指令”职责的部分它可以来自 System / Developer 层也可以来自当前 User Task后文为了好讲主要用任务级 Prompt 举例。Context 则采用更宽的运行时定义——模型这一次推理时真正拿到的全部 Token词元和可见信息。按这个口径Prompt 是 Context 中承担 instruction role 的那部分信息。除此之外Context 里还可能有历史对话、代码和文档、工具定义、工具返回、检索结果、Memory 摘要以及从当前任务状态中被选择并序列化进模型请求的那部分信息。这里边界要卡住执行状态Execution State本身可以存在数据库、Checkpoint 或 Runtime 里只有真正注入本轮模型请求、对模型可见的表示才属于 Context。Anthropic 讨论上下文工程Context Engineering时关注的也正是每次推理到底给模型配置了哪一组信息。Skill 的位置又不一样。开放 Agent Skills 规范里一个 Skill 可以包含SKILL.md、scripts、references、assets。Agent 启动时通常只看到 name 和 description任务匹配以后才读取完整说明需要时再执行脚本、读取参考资料。也就是说Skill 并不会天然把整个目录永久塞进 Context。只有当前决策真正需要的说明、资料或者执行结果才会逐步进入模型可见的工作集。先把地图钉住Prompt 是 Context 里的“任务指令”Context 是模型当前的“工作集”Skill 是按需向这个工作集提供程序性知识和资源的一种工程机制。这张图最重要的不是三个框而是三者并不平级Prompt 在 Context 里承担显式指令职责Skill 则按需把程序性知识和资源带进当前 Context。二、Prompt从“怎么问模型”走到“怎么定义任务”Prompt 最早给人的感觉很像一门“怎么把问题问漂亮”的手艺角色怎么设、措辞怎么写、要不要加少样本示例few-shot、要不要把任务拆得更明确。今天这些技巧当然没消失但在真实 Agent 里Prompt 最核心的价值已经越来越像一个任务契约Contract。真落到项目里一个 Prompt 至少有几件事得说清楚目标Goal是什么约束Constraints有哪些什么叫成功标准Success Criteria输出要满足什么契约Output Contract哪些事情模型可以自己判断、哪些必须停下来问人失败以后怎么处理以及有没有真正有区分度的正反例。最麻烦的不是 Prompt 不够长而是把它写成一份巨型“操作手册”试图提前把每种分支都写死。模型一升级、业务一变化这种 Prompt 很快就会变成维护债。前沿模型的工业指导其实也在往这个方向收敛。OpenAI 对 GPT-5.6 的当前建议是模型的意图理解更强不必把每一步都规定得死死的但领域上下文Domain Context、硬约束Hard Constraints、审批边界Approval Boundaries和成功标准Success Criteria仍然要明确。Anthropic 在 Context Engineering 里也强调系统提示词System Prompt要处在“合适的高度”——太细会脆太虚又没有约束。Prompt 已经不是“越长越专业”。模型该自由判断的地方别硬写成 if/else真正不能越过的边界也别指望它自己猜该说清楚的是目标、约束、验收和什么时候必须停下来。Prompt 的学术前沿正在从“人工调词”走向自动优化学术界最近几年一个很明确的方向是自动提示词优化Automatic Prompt OptimizationAPOPrompt 不再完全靠人一遍遍改而是把评测结果、奖励Reward或失败样本交给优化器让系统自动搜索更好的 Prompt。早期的“通过提示进行优化”Optimization by PROmptingOPRO已经展示了让大语言模型Large Language ModelLLM充当优化器的思路2026 年的工作则继续往按查询自适应、降低优化成本和跨任务复用推进。例如 2026 年的因果提示词优化Causal Prompt OptimizationCPO把 Prompt 选择进一步写成因果估计问题不只看“某个 Prompt 和高分同时出现”而是估计 Prompt 变化对不同 Query 的因果效果再为具体 Query 选择更合适的 Prompt。另一项 MemAPOGeneralizable Self-Evolving Memory for Automatic Prompt Optimization可泛化自演化记忆提示优化框架则把成功策略和反复出现的错误模式沉淀成可复用 Memory让 Prompt Optimization 不必每个任务都从零开始。这类研究已经把 Prompt 从“个人经验活”往可评测、可优化的工程对象推进了一大步但自动优化也不是在炼一条万能 Prompt。2026 年的机制研究已经看到很明显的任务差异同一种改法在逻辑推理上有效换到数学或多跳任务未必还好用。Prompt Optimization 的收益越来越像“看任务吃饭”而不是找到一条放之四海而皆准的咒语。这件事放到工业里很好理解Prompt 优化如果没有真实任务集和回归评测最后很容易变成“这个版本我感觉更顺”。优化器能自动改文字不代表它替你定义了正确的业务目标。工业界更现实的一步Prompt 开始像代码一样被管理工业落地里比自动优化更先发生的是提示词软件工程Prompt Software Engineering。2026 年 Google 公开了一套模块化提示词转译modular prompt transpilation的思路把巨大的 System Prompt 拆成模块检查依赖、变量、循环引用和黄金文件golden file再通过持续集成/持续交付Continuous Integration / Continuous DeliveryCI/CD构建出最终可部署的 Prompt artifact。Prompt 一旦被多个 Agent、多个版本共用问题就出来了改一条安全规则可能同时影响三条工作流同一段指令被复制到五个地方半年后已经漂成五个版本。做到生产环境Prompt 也得像代码一样管——有版本、有评测、有回归变更能追出问题能退。所以 Prompt 的下一阶段与其说是继续研究“神奇句式”不如说是把提示词管理、评测EvaluationEval、自动优化和 CI/CD 接成一条工程链。三、Context窗口装得下多少和模型真正用得好多少是两回事如果 Prompt 管的是“这次任务怎么说”Context 管的就是“这一刻模型到底看见了什么”。这也是 Agent 里最容易被一个数字带偏的地方Context Window 越来越大于是很多人下意识觉得只要窗口够大历史、文档、工具结果、标准作业流程Standard Operating ProcedureSOP全塞进去就完事了。截至 2026 年 8 月多家前沿商用模型已经进入百万 Token 级OpenAI GPT-5.6 Sol 的 Context Window 是 1.05M TokenClaude Opus 5 和 Sonnet 5 是 1MGoogle 当前的 Gemini 3.6 Flash 输入上限是 1,048,576 Token。这个数字首先表达的是单次模型调用可使用的上下文空间规模具体输入、输出以及 reasoning / thinking token 如何计入总预算要按各家接口定义来看。它绝不等于“模型拥有 1M Token 的无损工作记忆”。1M Context到底应该怎么看为了工程排查方便我把 Context 临时拆成四层上下文容量Context Capacity、上下文占用Context Occupancy、上下文质量Context Quality和有效上下文Effective Context。这不是行业统一分类而是一套用来定位问题的工程理解框架。层次看什么工程含义上下文容量Context Capacity理论上最多装多少模型 / API 的物理窗口上限上下文占用Context Occupancy本轮输入工作集占了多少System / User、History、Tools、Docs、Skill 等输入占用还要给输出和 reasoning / thinking 留余量上下文质量Context Quality装进去的东西是否值得看关注噪声、重复、过期信息和超长 Tool Result有效上下文Effective Context模型最后可靠用好了多少真正参与当前判断、长期依赖和执行的那部分信息ℹ️备注所以1M Context ≠ 1M Effective Context。窗口容量是硬指标模型最后能稳定利用多少是另一回事。实际工程里也不能把窗口按输入塞到 100%还得给输出以及模型可能产生的 reasoning / thinking 留出余量具体计数口径按各家 API 来。这也是为什么“窗口够大就不需要 Context Engineering”一直没有发生。长任务里的问题已经从单纯“塞不下”变成“哪些东西该留、什么时候该删、删了以后还能不能找回来”。2026 年的研究开始把这件事做得更主动主动反思驱动的上下文管理Active and Reflection-driven Context ManagementARC让 Agent 持续检查并修正内部工作上下文智能体式上下文管理Agentic Context ManagementACM让 Agent 自己决定何时压缩、把什么卸载到外部 Memory、什么时候再取回上下文窗口生命周期Context Window LifecycleCWL则按语义和依赖关系做结构化淘汰而不是简单“最老的先删”。CWL 有一个很容易被误读的结果论文展示了单个 Agent Session 跨 89 个顺序任务、累计处理约 8000 万 Token。注意这不是“模型有 80M Context Window”而是通过持续外部化、淘汰和恢复把有限窗口滚动成更长的工作生命周期。长任务真正需要管理的是 Context Lifecycle不是只盯着窗口上限。再往前一步2026 年 6 月的 VISTAVisible Internal State for Tool Agents面向工具智能体的可见内部状态提出了一个挺工程化的问题既然要让 Agent 自己管 Context它至少得知道每个 Context block 有多大、多久没访问、还剩多少预算。VISTA 把 token usage、recency、access history 和 budget 做成运行时可见状态让模型基于这些信号决定 keep、archive 或 recover。这个方向说明 Context Engineering 正从“系统替模型做压缩”继续往“Agent 能感知自己的 Working Set”走。Context Engineering工业界到底在做什么工业界常见的做法其实很朴素该查的时候再查也就是即时检索Just-in-time Retrieval长历史该压缩就做压缩Compaction已经没价值、又能重建的工具结果及时清理Tool Result Clearing真正需要长期保留的东西放到结构化笔记或 Memory再配合上下文缓存Context Caching、相关性过滤Relevance Filtering和阶段性切换。像文件路径、索引、标识符IdentifierID这类轻量线索可以常驻几十页原文没必要每轮都背着走。这里别把 Caching 和“腾窗口”混在一起缓存主要省重复计算的成本和延迟Cached Token 依然属于 Context真正给窗口减压还是得靠 Retrieval、Clearing、Compaction 和 Externalization。Claude Code 是一个很典型的例子。官方文档明确说CLAUDE.md和 Auto Memory 会作为 Context 被模型读取但它们不是系统强制配置如果某个动作必须无条件阻止需要用确定性的执行约束而不是只写一句“不要做”。工程上得把两件事分开模型看到了规则不代表系统强制执行了规则。大代码仓库也一样不会因为窗口变大就全量灌进去真正有用的还是按需读取、搜索、压缩和清理。如果硬要找个传统系统里的类比Context Window 更像内存容量Context Engineering 管的是工作集Working Set——当前真正应该留在内存里的那一小撮高价值信息。Context 不是一个越堆越大的静态仓库而是一套持续选择、清理、压缩、外置和恢复的工作集生命周期。四、Skill为什么 Agent 需要一种“按需加载的做事方法”理解完 ContextSkill 为什么会出现就顺了。一个企业 Agent 可能有几十套 SOP代码 Review 怎么做、合同怎么审、PPT 怎么排、上线前检查什么、某类故障怎么处理。如果这些东西全部永久塞进 System PromptContext 很快又会变成一锅粥。开放 Agent Skills 规范给出的工程答案是把程序性知识做成可复用目录核心是SKILL.md旁边可以带 scripts、references、assets。它不是给模型“训练进了新知识”而是把某类任务需要的做事方法、参考资料甚至可执行脚本包装起来在需要时再让 Agent 使用。Skill 最值得强调的是“程序性知识”这四个字。很多时候它不是告诉模型一个事实而是告诉它这类任务先检查什么、按什么顺序做、失败后怎么办、哪些步骤必须验证、哪些资料应该去哪里找。它更像一份可复用的 SOP再带上一组必要的脚本、参考资料和资源而不是更长的百科知识。渐进式披露Progressive DisclosureSkill 的价值本身就和 Context Engineering 连在一起兼容 Agent Skills 的客户端通常采用三层渐进式加载策略第一层发现Discovery只暴露 name 和 description第二层激活Activation在任务匹配后把完整SKILL.md读进 Context第三层再按需运行脚本、打开 references 或 assets。规范当前还建议把主SKILL.md控制在 500 行、约 5000 Token 以内详细资料继续拆出去按需读取。它解决的一个核心问题就是大量“以后可能会用”的做事方法不要一开始全部占 Context。2026 年 7 月一项针对长文档 Agent 的控制实验给出的结果也很克制Progressive Disclosure 主要买到的是 Context 组织能力不是凭空增加模型智力。单本资料、强运行框架Harness已经能自己定位内容时额外 Skill 路由的收益可能接近零跨很多本资料以后按需披露才明显拉开差距。再多套一层路由也不一定更好论文里更深的第二级路由没有带来收益部分场景还会伤准确率。Skill 的一个关键价值可以说得很朴素它把“什么时候把哪套 SOP 给模型看”这件事工程化了。Skill 的关键不是把所有说明永久塞给模型而是让“需要哪套做事方法就在什么时候加载哪一套”这件事可复用、可管理。Skill 的学术评测已经开始给热度降温Skill 这半年有个好变化终于开始有独立 Benchmark 了。SkillsBench 的最新版本已经扩到 87 个任务、8 个领域和 18 种 model–harness 配置人工整理的 curated Skills 把平均 pass rate 从 33.9% 提高到 50.5%也就是 16.6 个百分点percentage pointspp但 87 个任务里仍有 13 个出现负向变化。数据再往下拆还有个挺反常识的结果Skill 不是越多越好。SkillsBench 里1 个 Skill 平均提升 18.0pp23 个是 19.0pp挂到 4 个以上反而降到 10.1ppcompact / standard 长度的 Skill 明显优于 comprehensive documentation。三组 dedicated harness 上模型自己生成的 Skills 还全部低于 no-Skills baseline。比起“写得全”聚焦、可执行、边界清楚更重要。一个月后的软件工程Software EngineeringSWE评测 SWE-Skills-Bench 把问题拉到真实代码仓库49 个公开 SWE Skills 中39 个没有带来 pass-rate 提升平均增益只有 1.2%只有 7 个专门化 Skill 出现明显正收益另有 3 个因为版本不匹配的指导和项目 Context 冲突而让性能下降Token 开销最高甚至增加 451% 而正确率不动。研究核心结果工程提醒SkillsBench2026-0287 个任务 / 8 个领域 / 18 种配置Curated Skills 平均 16.6pp13/87 任务负收益Skill 有价值但不是无条件正收益聚焦、可执行、适用边界清楚更重要SWE-Skills-Bench2026-0339/49 Skill 无 pass-rate 提升平均 1.2%Token 开销最高 451%真实软件工程里版本和 Context 匹配比“有没有 Skill”更重要⚠️警告Skill 不是外挂。它更像 SOP好 SOP 能显著减少现场发挥但 SOP 写错、过期、套错场景一样能把一个本来会干活的人带沟里。平均结果有用不代表你手头这个 Skill 就一定有用。为什么 Skill 明明存在实际项目里却可能没什么效果这就回到我自己在真实项目里用 Skill 时最有感的一点写了一个 Skill不等于运行时真的获得了同等强度的约束。Benchmark 说 curated Skill 平均有提升可真到项目里为什么有些 Skill 像没装一样要排查这个问题最好别只看“目录里有没有这个文件”而是顺着执行链一层层查。这还不只是个人体感。2026 年 8 月一项针对公开 Agent Skills 生态的研究扫描了 20,556 个代码仓库里的 138,133 份SKILL.md91.8% 至少存在一个可检测缺陷。最常见的问题一点都不玄路由 metadata 写得弱、正文太臃肿或不可执行、resources 组织混乱。很多 Skill 还没高级到“模型能力不够”那一层先在工程包装上就输了。再往运行结果看2026 年 8 月的 skill-induced failure 研究确认了 307 个可以归因到 Skill 的失败或效率回退其中 125 个是功能失败182 个是效率回退。麻烦之处还不是“加载了完全不相关的 Skill”这么简单很多 Skill 看上去明明相关却把 Agent 带进了错误实现、漏掉必要步骤或者把验证和实现流程做得过重。环节先问什么常见问题发现DiscoveryAgent 知不知道这个 Skillname / description 太泛模型没认为相关选择Selection多个 Skill 里选对了吗语义重叠、触发条件模糊挑错或加载太多激活Activation完整 instructions 真加载了吗只发现 metadata没有进入真正执行说明上下文兼容性Context CompatibilitySkill 与任务 / 版本 / Repo / Prompt 冲突吗SOP 过期、版本错位、用户最新要求与 Skill 相反执行能力Execution Ability知道怎么做以后模型和工具真能做吗缺工具、权限、Harness 能力或环境依赖验证Verification有证据证明用了以后更好吗没有 paired Eval只靠主观感觉判断有一类问题特别容易被误修Agent 明明缺执行权限却继续往 Skill 里加“务必完成”测试环境根本起不来又补一句“必须充分测试”。这类文字只会让 Prompt 和 Context 更重不会凭空生成缺失的系统能力。另一类是 Skill 和当前 Context 打架。某个 Skill 两个月前按旧软件开发工具包Software Development KitSDK写的代码仓库RepositoryRepo已经升级Skill 还在要求旧目录结构。模型如果“忠实执行”反而更糟。SWE-Skills-Bench 已经观察到这种 version-mismatched guidance 带来的性能下降。所以“Skill 没效果到底是我用错了还是 Skill 被吹过头了”本身就不该二选一。触发、选择、内容质量、版本和上下文兼容性都会影响结果另一方面如果把 Skill 描述成“装上以后 Agent 自动获得专业能力”确实把中间这条执行链讲得太轻松了。判断 Skill 有没有价值最后还是得回到 Eval同一批真实任务有 Skill 和没 Skill 到底差多少成功率、Token、耗时、人工干预分别怎么变。没有 paired baseline很多“感觉变好了”都不够硬。五、把三者放进同一次 Agent 运行Prompt、Context、Skill 到底怎么一起工作前面三块分别讲清以后再放回同一个 Agent Loop关系就不绕了。假设现在让一个 Coding Agent 给真实项目增加登录能力。第一步用户 Prompt 给出目标增加什么功能、哪些安全约束不能破、验收标准是什么。第二步Context Builder 组装当前工作集System Instructions、用户需求、Repo 里已经找到的相关文件、Git 状态、工具定义、最近几轮历史以及从 Runtime State 中挑出来、真正需要给模型看的那部分信息。第三步Agent 根据 Skill Catalog 发现某个认证开发 Skill 可能相关于是读取SKILL.md再按需要打开安全 checklist 或执行脚本。模型完成一次判断以后去读代码、改文件、跑测试新的 Tool Result 又回到 Context。任务继续变长旧的原始输出开始失去价值就做 clearing、compaction 或 externalize下一轮再把真正重要的状态表示和刚需要的资料带回来。这条链里Prompt 不是一次写完以后永远不变的“总控制器”Context 也不是静态仓库Skill 更不是永久挂载的全文。三者都围绕每一轮 inference 动态工作而 State、工具权限和执行环境仍然属于它们之外的系统问题不能混成 Context。如果只记三句Prompt 决定任务意图和边界Context 决定模型当前的认知工作集Skill 提供可复用、按需加载的程序性知识。一次 Agent 运行里Prompt、Context、Skill 都在动态变化Runtime State 可以向 Context 提供模型可见表示但 State 本身不等于 Context。六、真实项目出了问题到底应该改 Prompt、Context还是 Skill写到这里最实用的已经不是再背一遍定义而是拿它来排障。Agent 出现问题时先判断它属于“指令问题、信息问题还是程序性知识问题”再决定在哪一层动刀。现场现象优先检查为什么输出格式总是不稳定Prompt / Output Contract交付格式没定义清楚或示例不足Agent 不知道什么时候算完成Prompt / Success Criteria目标有了但停止条件和验收标准不清楚关键事实前面说过后面却用不上Context信息被淹没、压缩丢失或没进入当前工作集长任务越跑越偏Context Lifecycle历史、Tool Result、状态表示持续膨胀需要清理 / 压缩 / 外置窗口很大仍被噪声干扰Context QualityCapacity 大不代表 Working Set 质量高同类任务反复漏掉同一套必要步骤Skill / 可复用 SOP需要稳定复用程序性知识若必须 100% 强制就不能只靠 SkillSkill 根本没触发Skill Discovery / Description先解决发现和选择不是继续把正文写长Skill 加了反而更差Skill Compatibility Eval检查版本、任务匹配、过度流程和冲突每次 Prompt 都要贴几十页操作规范Skill Context Strategy程序性知识适合拆出来按需加载Agent 知道步骤但就是执行不了不要继续改三者多半是工具、权限、环境或运行系统问题重要这里再补一条边界Skill 更偏 Guidance不是 Enforcement。如果某一步必须 100% 发生或者某个动作必须 100% 禁止应该把它下沉到确定性的代码、Hook、权限或 Workflow 里。把强制约束只写进 Skill本质上还是在赌模型每次都照做。Prompt、Context、Skill 不是万能三件套。Agent 明明缺一个真正能写数据库的接口Prompt 写得再好也没用环境权限不允许执行命令Skill 里写十遍“必须完成”也不会产生权限。问题不在这三层就别继续往这三层加料。具体实现当然还会变Prompt 可能更短Context 管理会更动态Skill 也会越来越像可测试、可版本化的程序性知识。但任务怎么定义、这一轮该给模型看什么、重复做事方法怎么复用仍然是三类不同的工程决策。以后再遇到一个“Agent 怎么又没按我想的做”的问题我不会第一反应就把 Prompt 再写长一倍。先看它到底是没听懂、没看到还是没有一套合适的方法可复用。把这三层分开很多问题反而好查得多。最后当下AI大模型是当下实打实的优质风口岗位缺口大、发展前景广、薪资待遇突出对比内卷严重、涨薪晋升困难的传统技术岗是普通人转行逆袭的绝佳选择。但很多想要入局大模型领域的朋友都面临无系统学习路径、无实战资源、求职无方向的难题一个人硬啃最容易走弯路、浪费大量时间精力。这里我结合多年一线实战与教学经验整理出一套零基础大模型专属资料包含系统化学习路线图零基础到精通大模型学习书籍 文档电子版2026 最新行业报告项目实战 配套源码大厂面试真题需要的朋友微信扫描下方 CSDN 官方认证二维码免费领取保证 100% 免费。扫码免费领取全部内容下面简单介绍一下资料包含的内容1、大模型系统化学习路线图专属定制从零基础入门到企业级实战的全阶段学习体系划分清晰的四大学习阶段规避碎片化学习弊端适配新手2、0基础到进阶视频教程配套完整高清实操教程覆盖Prompt提示工程、RAG知识库搭建、Agent智能体开发、模型微调、部署落地等核心知识点所有课程搭配实操演示零基础也能轻松看懂、上手实操。3、大模型学习书籍 文档汇总30本行业经典AI、大模型、深度学习精选书籍涵盖理论原理、开发实战、算法基础、AI产品思维等各类内容4、AI大模型最新行业报告整理2024-2026年最新大模型行业白皮书、市场分析报告清晰展现行业发展趋势、技术迭代方向、岗位需求变化帮助学习者精准把握行业风口找准学习和就业方向5、大厂面试真题汇总了常见的AI大模型面试问题、知识点梳理和面经参考方便求职时针对性准备。6、大模型项目实战 配套源码包含GPT应用开发、RAG私有知识库、智能问答系统等多个企业级实战项目配套完整可运行源码从简易Demo到完整商业应用全覆盖帮助学习者将理论转化为落地实战能力积累项目经验。7、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。8、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料