本文介绍了一种名为 verify-data 的端到端数据验证 Agent Skill它通过自然语言交互自动完成从表结构获取、基准表发现、代码逻辑分析、验数 SQL 生成、执行到报告发布的全流程将传统手工验数方式升级为高效、智能的自动化流程。文章详细阐述了其背景痛点、核心架构与能力、实战场景、设计原则、踩坑经验、当前优势与挑战并探讨了未来演进方向旨在为数据质量保障和 Agent 工具落地的开发者提供宝贵的参考经验。前置说明什么是 Agent SkillAgent Skill 是一种给 AI Agent 定义的可复用能力包——你可以把它理解为Agent 的 SOP。一个 Skill 定义了 Agent 在特定场景下应该做什么、怎么做、有哪些约束和红线。当用户用自然语言触发后Agent 会按照 Skill 定义的流程自动执行而不是靠模型临时发挥。本文介绍的 verify-data 就是这样一个 Skill它把数据验数的全部流程——从信息收集、SQL 生成、执行到报告产出——编码成了一套可复用、可迭代的 Agent 能力。技术栈与适用范围本方案基于以下技术栈实现读者可以参考其中的设计思路将类似方案适配到自己的环境计算引擎MaxComputeODPS云端大数据计算服务数据开发平台DataWorks提供表结构查询、节点代码获取、数据血缘追溯、SQL 执行等 API 能力协作平台钉钉文档报告发布载体可替换为其他文档协作平台Agent 运行时支持 Skill 定义和自然语言交互的 Agent 框架核心设计思路标准化模板、基准表发现策略、降级验数策略等与具体平台无关适用于任何有元数据 API 和 SQL 执行能力的大数据环境。术语速查术语含义ADSApplication Data Store应用数据层面向业务场景的宽表/CUBE 表DWSData Warehouse Summary汇总数据层按主题域轻度聚合DWDData Warehouse Detail明细数据层清洗后的事实明细表DIMDimension维度表描述业务实体属性的参照表CUBE 表使用 GROUPING SETS / CUBE 语法做多维聚合的宽表基准表已验证可信的参照表用来和研发表做数据对比验数数据验证即通过 SQL 比对确认数据准确性的过程血缘Data Lineage数据表之间的上下游依赖关系一、背景与痛点1 数据开发的验数困境在业务数据团队日常主要在多个项目空间中开发各层数据表ADS 应用层、DWS 汇总层、DWD 明细层、DIM 维度层。每张表上线前或迭代后都需要回答业务方的一个核心问题“你这个表/指标的数据到底准不准”这里所说的验数是指数据表上线前的人工 review 环节——评审人员需要看到完整的验证证据确认数据逻辑正确、口径一致、无异常后才允许发布上线。这是数据质量的最后一道防线。传统的手工验数方式存在几个典型痛点覆盖度不够大多数开发者只跑了总量对比 SQL漏掉了维度逐项对比、汇总行一致性、CUBE 完整性检查、关联膨胀检测等关键验证项。一张表如果有 5 个维度组合、7 个指标只跑一条总量对比等于只检查了冰山一角。基准表选错很多时候凭感觉选一张名字差不多的表做基准结果两张表口径完全不同比如基准表按买家维度去重研发表按访客维度去重验了半天结论无效。代码理解偏差没看懂研发代码的 JOIN 膨胀逻辑验数 SQL 复刻了同样的 bug。最典型的情况是研发表里有个 LEFT JOIN 会导致行数膨胀但验数 SQL 也跟着做了同样的 JOIN结果两边数据一致但都是错的。结论无依据业务方问数据准不准回答我跑了几条 SQL应该没问题。这种主观判断缺乏评审级的证据链业务方不信评审也过不去。沉淀成本高每张表的验数 SQL 散落各处换个分区、换个人又要从头来。验数过程没有形成可复用的资产。2 Agent Skill 的机会2025 年以来Agent 工具在代码生成、运维自动化等场景已经有了大量落地。但在数据开发领域尤其是验数这个高频、标准化程度高但痛点明确的场景还缺乏系统化的 Agent 解决方案。我们开始思考能不能做一个 Agent Skill让数据开发者只需要说一句话就能自动完成从取数、跑 SQL、写报告到消息推送的全流程这就是 verify-data 的出发点。二、verify-data 是什么1 一句话定义verify-data 是一个端到端的数据验数 Agent Skill。你只需要给它一张研发表名它就能自动发现基准表、生成验数 SQL、在计算引擎上执行、分析结果、组装评审级报告并发布到协作文档。整个过程通过自然语言对话完成不需要手写一行 SQL除非你想主动干预。2 核心价值经过多轮迭代和实战验证verify-data 在以下方面建立了明显优势效率提升从 2-4 小时到 30 分钟。传统手工验数的流程是手写 5-6 条 SQL → 逐条执行 → 肉眼比对结果 → 写验数文档 → 发给评审通常需要 2-4 小时。verify-data 将这一切压缩到 30 分钟以内一句话触发后Agent 自动完成取数、跑 SQL、写报告、推送通知数据开发者只需要看结论、做决策。覆盖度从冰山一角到全面体检。10 类标准化 SQL 模板确保验证覆盖度特别是 SQL 9关联膨胀检测和 SQL 10日期维度关联校验这两项是数据评审最高频退回原因手工验数时极易忽略。智能决策基准表自动发现与降级策略。通过血缘 维度/指标精排的两阶段策略自动选基准表支持多基准表联合覆盖找不到基准表时有 4 种降级策略兜底确保任何表都能给出有意义的结论。证据链从我觉得没问题到评审级报告。产出结构化的评审级报告7 节标准格式、三档结论判定PASS/WARNING/FAIL、完整可执行的 SQL 附录、自动归档到协作文档可直接交给评审人员。资产沉淀验数知识不再散落。每份报告自动归档SQL 和报告成对保存在本地verify-sql/目录下19 条踩坑记录沉淀在lessons-learned.md中Agent 不会重复犯已知错误。风险管控强制红线防止翻车。4 条不可逾越的红线从机制上防止 Agent 在边缘场景犯错这些不是建议而是强制到了关键节点如果不满足条件就不会继续。3 整体架构下图展示了 verify-data 的整体技术架构包括用户交互层、核心引擎层、外部依赖和输出产物4 7-9 步工作流verify-data 的核心是一个条件触发流程主流程约 7-9 步但加上条件触发的子步骤后实际可达 17 步Step 1 收集信息 → [Step 1.5 基准表自动发现]Step 2 获取表结构 → [Step 2.5 分区元数据预检]Step 3 获取研发表代码逻辑 → [Step 3.5 Code Diff 结构化分析]S2 强制触发 → [Step 3.6 基准表适用性预检]用户指定基准表时触发 → [Step 3.7 维表 CUBE 检测]有 JOIN 维表时自动触发Step 4 分析维度/指标映射 → [Step 4.5 维度组合匹配]基准表确定后触发 → Step 4.8 基准表与研发表主要逻辑对照有基准表时强制Step 5 生成验数 SQL10 类模板按需组合 → [Step 5.5 降级验数策略]无基准表/部分覆盖时触发Step 6 执行跑数三批次执行策略Step 7 组装本地报告Step 8 发布协作文档Step 9 [上游追溯根因分析]结论 FAIL 时触发带 [] 的条件步骤不是每次都会执行而是由对应的触发条件自动决定是否激活。其中 Step 3.6、3.7、4.8 是容易被忽略但非常重要的强制/自动触发步骤。5 5 种验数场景Agent 会根据用户输入自动识别验数场景场景名称触发条件S1新模型上线单研发表无基准表S2迭代验数双表对比DEV vs PROD或含迭代关键词S3日常监控最近数据异常类描述S4业务质疑xx 指标对不对类问题S5口径迁移口径变了类变更其中 S2 迭代验数是最复杂的场景——Agent 会强制触发 Code Diff 分析扫描 8 类风险信号数据源变更、JOIN 关系变更、聚合方式变更、过滤条件变更等并为每个高风险信号生成定量证实 SQL不仅告诉你差了多少还能告诉你为什么差。三、核心能力拆解1 基准表自动发现这是 verify-data 最核心的能力之一。当用户没有提供基准表名时Agent 会通过两阶段策略自动发现第一阶段血缘发现候选集通过数据开发平台的血缘 API追溯研发表的上游依赖找出所有可能存在血缘关系的表构建候选集。第二阶段指标/维度精排对候选集中的每张表计算综合评分score 血缘亲和度 × 0.5 维度重合度 × 0.3 指标重合度 × 0.2Top-1 得分 ≥ 0.7 时直接选为基准表Top-1 0.7 但多张表联合可覆盖全部指标时触发分路指标对比策略多基准表联合覆盖Top-5 最高得分 30% 时进入降级验数策略。这个设计解决了一个实际问题一张新的 CUBE 表可能同时依赖用户行为表、转化事件表、交易明细表三张 DWD 表没有任何一张单独的基准表能覆盖所有指标但三张表联合就能完整验证。2 10 类验数 SQL 模板verify-data 不会凭感觉手写 SQL而是基于 10 类标准化模板按需组合编号模板名称校验目标必选1总量对比基准表重算 vs 研发表汇总是2数据质量检测空值率、零值率、维度合法性是3按维度逐项对比有基准表且维度可匹配时条件4维表分区校验有维表 JOIN 时条件5CUBE 完整性检查有 CUBE/GROUPING SETS 时条件6汇总行一致性有 ‘all’ 汇总行时条件7逻辑关系校验指标间有业务逻辑关系时条件8历史趋势对比有历史数据时条件9关联膨胀检测有 JOIN 操作时是10日期维度关联校验有日期维度时是其中 SQL 9关联膨胀检测和 SQL 10日期维度关联校验是我们从实际评审退回经验中总结出来的最高频退回原因。很多表总量对比没问题但 JOIN 膨胀导致某些维度组合行数翻倍或者日期维度关联时区错位这些问题只有专项检测才能发现。3 Code Diff 驱动的风险扫描在 S2 迭代验数场景中Agent 会分别获取 DEV 和 PROD 的运行态代码执行结构化 Diff 分析扫描以下 8 类风险信号每命中一个风险信号Agent 就会生成对应的定量证实 SQL用数据来证明或证伪该风险的实际影响。这是知道差了多少到知道为什么差的关键跨越。4 降级验数策略无基准表或者部分覆盖维度和指标时verify-data 不会放弃验证而是自动选择 4 种降级策略之一降级策略的特殊耦合判定强制卡点除了执行 D 类一致性检查SQL另外必须对原代码进行风险审查并针对 Top-3 风险点生成定量证实 V 类 SQL逻辑性校验。审查时需逐项扫描以下 8 类风险信号风险类型典型信号字符串比较陷阱status 1等按字符串比较数字字典序10 1为 TrueNULL/默认值假设CASE WHEN x IS NOT NULL、COALESCE(x, 未知)跨维度复用日期窗口定义BETWEEN ${bizdate}-6 AND ${bizdate}含/不含锚点日、T-0 vs T-1 错位bizdate为业务日期分区参数类似 Hive 中的${hiveconf:dt}UNION ALL 各路命中量某一路长期命中 0 条冗余或长期 100%其他路形同虚设JOIN 膨胀LEFT JOIN 维表关联键非维表主键、多路 JOIN 累积膨胀字段口径 vs 字段名amount在明细层和汇总层可能对应不同的计算口径名字相似但语义不同EXPLODE/Cube 可加性手动LATERAL VIEW EXPLODE单列 cube、同一默认值跨维度合并浮点精度累加DOUBLE 类型大量 SUM 后出现 1e-6 ~ 1e-11 级误差这是因为如果 DWD 重算 SQL 直接复制了 ADS 代码逻辑只能证明执行一致无法发现 ADS 本身的逻辑错误。这一部分使用的 AI 代码审查Code Review能力是基于强规则加上历史验数的错误记录总结。5 分区预检与执行策略分区预检在跑 SQL 之前Agent 会通过元数据 API秒级完成确认目标分区是否存在、实例状态是否成功。避免白跑几十分钟的 SQL 后发现分区还没产出。这个设计解决了大数据计算引擎执行的一个实际问题含 SET 语句的 SQL 如果并行执行会互相覆盖会话状态必须串行而纯 SELECT 可以并行以节省时间。6 三个容易被忽略但关键的强制/自动步骤在 verify-data 的 17 步流程中以下三个步骤常被忽略但它们对验数质量至关重要Step 3.6 基准表适用性预检用户指定基准表时强制触发当用户主动指定基准表时Agent 不会直接信任而是先计算维度相似性similarity 重合维度数 / max(研发表维度数, 基准表维度数)。若相似性 50% 且基准表多余维度无 CUBE 聚合会主动建议降级策略避免选错基准表导致结论无效。Step 3.7 维表 CUBE 检测代码中有 JOIN 维表时自动触发检测维表是否存在一对多关系CUBE 聚合这是关联膨胀的源头。如果维表有 CUBE研发表指标会按维度拆分重复计算不能直接跟汇总表对比总量。检测方法对维表按关联键 GROUP BYHAVING COUNT(1) 1。Step 4.8 基准表与研发表主要逻辑对照有基准表时强制在生成验数 SQL 前强制对比研发表和基准表在数据来源、JOIN3 场景三全新口径无基准表S1.c背景业务想看某营销活动后 7 天的阅读/成交转化这是一张全新分析口径的 CUBE 表线上没有任何表能直接对。Agent 行为尝试自动发现基准表 → Top-5 评分均 0.3 → 触发降级自动选择策略 [1]CUBE 表CUBE 层级自洽性校验 DWD 上游比对 数据质量校验强制启动代码逻辑审查降级前置环节8 类风险信号扫描针对膨胀维表 JOIN 生成 V1 定量证实 SQL结论PASS。CUBE 层级自洽性验证 3 个核心指标差异均 0.01%DWD 重算与研发表 100% 一致。4 场景四维表验证DIM背景新建了一张维表dim_xxx_tag业务标签维表维表没有传统意义的指标怎么验Agent 行为自动识别为维表从dim_前缀和无指标列特征走策略 [3] 静态逻辑校验主键唯一性主键字段不能重复关键字段 NULL 率标签字段不能为 NULL业务规则一致性如actual_ratio base_ratio * 0.9标签分布合理性数据完整性结论WARNING有条件通过。静态校验全过但动态数据验证因源表权限不足受阻。建议申请权限后复验。五、关键设计原则与红线1 4 条关键红线在 verify-data 的设计中有 4 条不可逾越的红线禁止跳过 SQL 生成直接手写跑数所有验数 SQL 必须从模板生成确保覆盖度和可追溯性禁止靠字段名猜映射必须读运行态代码 查 schema凭经验猜字段是最常见的验数错误来源禁止降级策略 [1] 仅跑 D 类 SQL 就出报告必须追加代码审查和 V 类定量证实否则只能自证执行一致必须对所有 JOIN 做膨胀率验证、对所有日期维度做日期关联校验这是评审最高频退回原因2 结论判定体系结论判定的完整决策流程如下结论条件能否上线PASS通过所有 SQL 通过无风险可以WARNING有条件通过主要项通过但有外部阻塞或非关键差异消除条件后FAIL不通过关键 SQL 失败或差异无法解释必须修复降级策略的特殊耦合判定D 类数据一致性V 类逻辑合理性总体结论全部 PASS全部 PASS 或仅口径建议PASS全部 PASS发现真 bug 但当前分区无损WARNING附修复建议全部 PASS发现真 bug 且已实际影响数据WARNING 或 FAIL任一 FAIL—FAIL高频退回判定速查检查项PASSWARNINGFAIL关联膨胀率 1.001.00~1.01 1.01日期关联格式/时区对齐 T-1 存在格式可转换格式不一致/T-1 缺失差异非 S2 1e-61e-6 ~ 0.1% 0.1%S2 差异全部 [预期内]非预期但 0.1% 可解释非预期且 0.1%六、踩坑经验1 踩坑一CUBE 汇总行 NULL 不是 BugGROUPING SETS 生成的汇总行中某些维度的值为 NULL 或 ‘all’某些指标为 NULL 是正常行为。曾经有人误判为数据缺失反复排查后才发现是 GROUPING SETS 的标准行为。verify-data 在报告生成时会专门标注这一点避免误判。2 踩坑二浮点精度不要较真浮点类型金额字段在多次累加后会产生~10^-10级的精度差异。verify-data 内置了浮点精度容忍度判定差异 1e-6 视为实质为 0避免在无关紧要的精度上浪费时间。3 踩坑三DWD 重算同构只能自证执行一致如果降级策略中 DWD 重算 SQL 直接复制了 ADS 代码的 JOIN 和聚合逻辑即使结果 100% 一致也只能证明我写的 SQL 和我写的 ADS 代码执行结果一致无法证明ADS 代码本身是对的。典型案例DWD 重算与 ADS 汇总行四个指标完全一致差异 1e-11初判 PASS。但追问代码本身有没有错后审代码发现两个真 bug某退款流程的refund_stage 1在当前分区命中 0 条该分区全部refund_stage1——退款路径事实失效但 DWD 重算同样跳过这些行两侧照样一致某计数指标用trade_id IS NOT NULL作判据——当前 DWD 数据质量好所以无损但一旦脏数据出现就会产生幽灵金额统计值凭空多出来这就是为什么降级策略 [1] 强制要求代码审查 独立构造 V 类证实 SQL——V 类 SQL 必须从 DWD 源头独立构造。七、架构与协同1 模块化依赖设计verify-data 不是独立工作的它采用模块化架构依赖以下能力模块的协同能力模块提供的能力必需表结构与元数据服务获取表 schema、节点代码、数据血缘、执行 SQL是文档协作服务报告发布到协作文档如企业文档平台、Wiki 等是备选元数据接口表结构获取的冗余方案可选这种设计的好处是核心验数逻辑与具体的平台实现解耦。如果你的环境使用了不同的计算引擎和数据开发平台只需要替换表结构与元数据服务模块的实现核心验数流程无需改动。2 14 个 References 文档verify-data 的主文件是流程路由骨架每步的执行细节都在references/目录的 14 个文档中场景识别规则、基准表自动发现策略、分区预检逻辑代码分析清单、Code Diff 分析规范、维度匹配决策树10 类 SQL 模板、4 种降级策略、执行策略与硬约束报告模板、文档发布规范、根因分析流程、踩坑记录这种设计让 Agent 在执行时能够按需加载细节保持主流程清晰的同时不丢失边缘场景的处理能力。3 在数据链路中的位置verify-data 是完整数据链路中的一环八、当前挑战在实际推广中verify-data 仍存在一些待解决的挑战执行效率与交互体验完整 9 步流程通常耗时 15-30 分钟且中间多个节点需要用户确认基准表选择、降级策略、发布确认等对高频使用的开发者来说交互成本偏高。权限与环境依赖验数常涉及多个项目空间dev / prod / cdm 等跨项目 SELECT 权限不齐全会导致流程中断同时 verify-data 依赖完整的元数据 SQL 执行 文档发布链路任一环节故障都会阻塞全流程。降级结论的信任成本当走降级策略时WARNING有条件通过的结论需要向评审人额外解释可信度增加了沟通成本。新用户上手门槛首次配置涉及多个模块安装和参数配置对不熟悉 Agent 生态的开发者有一定门槛。九、总结verify-data 从一个能不能让 Agent 帮我验数的想法发展到现在覆盖 5 类场景、10 类 SQL 模板、14 个参考文档、19 条踩坑记录的生产级工具核心经验可以归纳为以下几点从最高频场景开始不要试图一开始就覆盖所有场景。我们先做了 S1 新表上线和 S2 迭代对比这两个场景占了 80% 的验数需求。先让 80% 的需求跑通再逐步补齐长尾。标准化比智能化更重要验数最关键的是覆盖度和可重复性10 类标准化模板比让 AI 自由发挥可靠得多。AI 的能力放在理解代码逻辑、选择模板组合和解读结果上而不是临时发挥写 SQL。踩坑记录是核心资产lessons-learned.md里记录的 19 条实战经验每一条都是真实踩过的坑。没有这些Agent 就会重复犯同样的错误。每次生产事故都是一次 Skill 升级的契机。红线要硬关键红线在流程层面做了约束不是建议而是强制。没有红线的 Agent 工具很容易在边缘场景翻车——尤其是在降级场景和 Code Diff 场景没有强制约束的 Agent 会倾向于走捷径。用户体验和工程可靠性并重优势再大如果用户等 30 分钟还要反复确认推广就会受阻。接下来的优化方向异步执行、一键到底、权限预检本质上都是在可靠性的基础上提升体验。我们相信数据验证这个场景天然适合 Agent 化——它高频、标准化程度高、涉及多系统协同、结果需要结构化沉淀。verify-data 的实践证明了这条路是可行的也希望这些经验能给在做类似工具的开发者一些参考。十、未来思考与展望基于实践经验和团队反馈我们对 verify-data 的下一阶段演进有以下几个方向的思考1 方向一极致体验——从等 30 分钟到无感验数当前验数流程的最大摩擦在于执行耗时和中间交互。我们的目标是让验数变成一件无感的事情用户触发后即可离开Agent 全程异步执行完成后通过消息通知主动推送结论。具体来说计划引入异步执行 主动通知机制让 SQL 提交后用户不再需要等待同时提供一键到底的静默模式对高频常规场景如每日分区切换、回归验数跳过所有确认环节只在异常时打断。此外通过历史缓存复用表结构和基准表选择结果将同表复验的耗时大幅缩短。最终目标是让验数从主动操作退化为被动通知——用户只需要看结论不需要参与过程。2 方向二平台融合——从独立工具到研发流程必经环节verify-data 目前是一个独立的 Agent Skill与数据研发流程是松耦合关系。但验数的最大价值不是事后补做而是嵌入流程、自动拦截。我们正在探索与数据开发平台发布流水线的深度集成表推到生产环境前自动触发验数验数不通过则自动阻断发布。同时支持多表批量验数适配大版本发布前的回归场景。在权限层面计划在流程早期就完成全链路权限预检并生成一键申请引导避免跑到一半才发现没权限的问题。长远来看verify-data 应该像单元测试之于代码一样成为数据上线的标准质量门禁。3 方向三智能进化——从执行验证到理解数据当前 verify-data 的核心能力是按模板执行验证并输出结论但在理解为什么数据会这样方面还有很大提升空间。未来的智能进化方向包括增强根因定位能力从当前的上游追溯升级为全链路根因定位结合代码变更历史和数据血缘做到一键定位到具体代码行引入降级结论的可信度量化评分基于验证覆盖维度和 V 类证实 SQL 通过率综合计算让评审人员无需理解策略细节也能直观判断结论可靠程度探索增量验数模式对日常监控场景只验证变化数据而非全量重跑。最终愿景是让 verify-data 不仅能回答数据准不准还能回答为什么不准和怎么修。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取