AI Agent重构数据科学工作流：从编码到自然语言交互的范式转变

1. 项目概述当数据科学遇上AI Agent“从写代码到问问题”这句话精准地戳中了当下数据科学从业者的痛点。过去十年我们的工作流核心是“构建”构建ETL管道清洗数据构建复杂的SQL查询来提取洞察构建统计模型或机器学习流水线来预测未来。每一个环节都离不开手写代码、调试脚本和反复验证。但到了2026年这个范式正在发生根本性的转变。AI特别是具备自主推理和工具调用能力的AI Agent不再仅仅是辅助编程的Copilot而是逐渐成为工作流中的“协作者”甚至“执行者”。这意味着数据科学家的工作重心将从具体的代码实现上移到更高阶的问题定义、逻辑设计、结果解读与决策支持上。这个转变的核心驱动力是AI模型在代码生成、自然语言理解、上下文学习以及工具链集成能力上的突破。我们不再需要记忆所有Pandas函数的精确语法或者为了一段复杂的窗口函数SQL而绞尽脑汁。相反我们可以用自然语言描述需求“帮我找出上季度每个区域销售额环比下降超过10%的产品线并关联一下当时的营销活动数据。”一个集成了AI Agent的工作流系统能够自动理解这个意图将其分解为数据连接、SQL查询、关联分析和可视化呈现等一系列子任务并调用相应的工具如连接数据库的驱动、SQL执行引擎、图表库来完成。数据科学家则更像一个“指挥官”和“质检员”负责审核AI生成的逻辑是否正确结果是否合理并基于更深的业务知识做出最终判断。这种重构的影响是深远的。它极大地降低了数据分析和探索的门槛让业务分析师甚至领域专家能更直接地参与数据工作流。同时它也迫使专业数据科学家进行角色升级将更多精力投入到更具创造性和战略性的工作中比如设计更健壮的AI-Agent协作框架、建立可信的数据与AI评估体系以及解决那些模糊的、非常规的复杂问题。接下来我将结合当前的技术趋势和我的实践经验拆解这一工作流重构的具体环节、关键技术选型以及我们必须面对的挑战。2. 工作流重构的核心环节与范式转变传统的数据科学工作流无论是遵循CRISP-DM还是其他方法论大体可以线性地划分为几个阶段业务理解、数据获取与清洗ETL、探索性数据分析EDA、建模与验证、部署与监控。AI的渗透正在将这些阶段从“串行手工流水线”改造为“智能交互式网络”。2.1 自然语言作为新的“编程接口”最直观的变化发生在人机交互层。SQL和Python依然是底层执行语言但面向用户的接口正在变成自然语言。这不仅仅是“用ChatGPT写一段SQL”那么简单而是一个系统性的工程。场景示例从需求到可执行代码的自动翻译假设我们需要分析用户流失。传统方式下数据科学家需要与业务方开会将模糊的“分析流失”转化为具体指标如“过去30天未登录且此前为活跃用户的群体”。在脑海中或纸上设计数据提取逻辑需要users表含last_login_date,user_id、activity_log表等。编写SQL可能涉及子查询、窗口函数来计算用户活跃期。执行、检查结果、调整SQL。在AI重构的工作流中你可以直接对集成了AI Agent的数据平台说“分析一下我们平台最近一个月的用户流失情况重点看流失前他们的核心行为特征比如访问频率、功能使用深度和付费情况。”AI Agent的工作流程如下意图解析与任务分解Agent理解“用户流失”、“最近一个月”、“行为特征”等核心概念并自动将其分解为子任务定义流失用户、获取行为数据、进行特征关联分析。元数据感知与SQL生成Agent查询平台的元数据目录了解有哪些表如user_profiles,login_events,feature_usage,payment_records各表字段含义及关联关系。然后它根据你的意图和数据结构生成一组或多组候选SQL查询。例如它会生成一个SQL先通过login_events表筛选出超过30天未登录的用户ID集合再LEFT JOIN其他表获取这些用户在流失前的行为聚合指标如周均登录次数、最后10次会话平均使用功能数、最近一笔付费金额等。安全与合规性检查生成的SQL在执行前会经过一层安全规则校验例如是否访问了未经授权的敏感表查询是否可能过于消耗资源如缺少限制条件的SELECT *。执行与初步解释执行查询后Agent不仅返回数据表格还会附上一段自然语言解释“本次查询共识别出12,458名符合流失定义的用户。他们的平均最后登录时间为37天前。在流失前一周他们的平均日活相比再前一周下降了约45%。有68%的流失用户在流失前一个月内没有产生付费行为。”实操心得提示词工程成为新技能与AI Agent有效对话需要技巧。模糊的指令会产生模糊甚至错误的结果。你需要学习如何为Agent提供清晰的上下文。例如与其说“分析销售数据”不如说“基于sales_fact表和product_dim表计算2024年Q2每个产品类别的月度销售额环比增长率排除销售额低于1万元的边缘品类。结果按增长率从高到低排序。” 后者明确了数据源、时间范围、计算逻辑、过滤条件和排序方式极大提高了AI生成准确代码的概率。这本质上是一种新的“需求规格说明书”撰写能力。2.2 ETL流程的智能化与自适应ETL抽取、转换、加载是数据工程的基石也是历来最繁琐、最易出错的环节。AI的引入使其从“预设脚本”走向“感知-适应”模式。传统ETL痛点数据源结构变更如API字段增减、数据库表新增列会导致ETL作业失败需要人工介入修改脚本脏数据处理规则如处理NULL值、格式转换需要预先硬编码难以应对复杂多变的实际情况。AI增强的ETL工作流结构变更自动检测与同步AI Agent可以定期扫描数据源的元数据Schema。当检测到新增列时它可以自动评估该列的重要性例如通过列名、样例数据推断并提示你是否将其纳入下游宽表。对于删除或重命名的列Agent能追溯依赖该列的所有下游作业和报表发出影响范围告警并建议修改方案或提供数据回填的选项。智能数据清洗与映射面对杂乱的数据AI可以辅助完成以往需要大量规则的工作。例如异常值检测不仅能用统计方法如3σ原则还能结合业务上下文。Agent可以学习历史数据中“订单金额”的分布当出现一个远超历史范围的数值时它会标记并尝试从日志中寻找原因如测试订单、系统错误。非标准值标准化将“北京市”、“北京”、“Beijing”统一映射为“北京”。传统方法依赖关键词库而AI可以通过语义理解处理更模糊的匹配。数据补全对于缺失的“产品类别”字段AI可以根据产品描述文本预测其最可能的类别并提供置信度供人工审核。工作流编排的智能化像n8n、Apache Airflow这样的工具负责调度。AI可以优化其执行。例如监控作业执行历史和资源消耗预测下一个作业的运行时间动态调整执行队列以优化整体资源利用率和SLA服务水平协议。当某个作业频繁失败时AI能分析日志定位是网络问题、资源不足还是代码逻辑错误并尝试执行预定义的修复操作如重试、重启容器。2.3 探索性数据分析EDA的自动化与深度化EDA是发现数据故事的关键步骤。AI能将数据科学家从重复性的图表生成中解放出来直接指向潜在的洞察。AI驱动的自动化EDA流程一键全景扫描接入一个新数据集后AI Agent可以自动生成一份远超df.describe()的综合性报告。这包括基础统计均值、中位数、分布、缺失率、唯一值数量。可视化矩阵自动绘制数值型变量之间的散点图矩阵、相关性热图。高级模式发现自动检测时间序列的周期性、趋势性识别分类变量中的重要类别发现潜在的聚类结构。异常报告高亮显示数据质量问题如“列‘年龄’中有2%的值为负数”“列‘注册日期’与‘最后登录日期’存在逻辑矛盾后者早于前者的记录有150条”。假设驱动的深度探索你可以与AI进行交互式探索。例如你问“销售额下降和用户平均会话时长缩短有关系吗”AI会立即计算两者的相关系数分时段进行对比分析并生成可视化图表如双轴折线图同时给出统计显著性检验结果如p-value。它甚至能进一步提出建议“数据显示在会话时长缩短的群体中新用户的占比上升了15%。是否因为新用户不熟悉产品导致平均时长被拉低建议进一步细分新老用户进行分析。”特征工程的协作创建有效的特征Feature Engineering是建模成功的核心。AI可以根据目标变量如“是否流失”自动评估现有特征的预测能力如通过计算IV值或特征重要性并尝试生成新的候选特征。例如它可能建议“可以将‘登录次数’和‘使用天数’组合成‘日均登录频率’特征初步分析显示该特征与目标变量的相关性比单独使用两个原始特征更高。”3. 关键技术栈与工具选型解析要实现上述愿景并非依赖单一模型而是需要一个分层的技术栈。这个栈融合了云原生基础设施、数据平台、AI模型服务和工作流引擎。3.1 AI Agent框架与模型层这是工作流的“大脑”负责理解意图、规划任务、调用工具。框架选择当前主要有两类路径。通用AI Agent框架如LangChain、LlamaIndex。它们提供了与各种大模型LLM交互、管理对话历史、连接工具Tools和数据库的基础能力。优势是灵活、生态丰富适合研发能力较强的团队进行深度定制。例如你可以用LangChain轻松构建一个能查询数据库、生成图表并写分析报告的链Chain。一体化AI应用平台如Dify、Coze扣子。它们提供了更开箱即用的体验通过图形化界面编排工作流Workflow集成了知识库、多种模型和常见工具如网络搜索、数据库查询、代码执行。优势是开发效率高适合快速构建面向业务用户的AI数据分析助手。例如在Coze中你可以拖拽组件构建一个工作流用户输入问题 - LLM解析意图 - 调用插件查询数据库 - LLM解读结果并生成图文回答。模型选型模型是Agent的“智力”来源。云端大模型APIOpenAI的GPT-4系列、Anthropic的Claude系列、国内如文心一言、通义千问等。它们能力强大尤其擅长复杂逻辑推理和代码生成但涉及数据出域的安全和成本考量。本地部署的开源模型如Llama 3、Qwen系列、DeepSeek等。通过Ollama、vLLM等工具部署在内部服务器。优势是数据完全可控长期成本可能更低但需要一定的运维和GPU资源且在复杂任务上的表现可能略逊于顶级闭源模型。混合策略这是目前许多企业的务实选择。将敏感的数据查询、处理任务放在内部环境使用开源模型或小型专用模型将需要强大推理和创意生成的任务如报告润色、复杂逻辑规划通过安全网关调用云端大模型。注意事项模型并非万能上下文窗口是关键约束大模型有上下文窗口限制如128K tokens。这意味着它无法一次性“阅读”超长的数据库Schema文档或巨大的数据样本。因此设计Agent时必须有“摘要”和“检索”思维。例如先让Agent查询元数据索引只获取与当前问题相关的表结构信息而不是一股脑塞给它所有信息。这就是RAG检索增强生成思想在数据工作流中的应用。3.2 数据与工具连接层这是工作流的“手和脚”让AI能实际操作数据系统。SQL生成与执行这是核心中的核心。需要为Agent提供数据库连接能力通过标准驱动如psycopg2for PostgreSQL,pymysqlfor MySQL或ODBC/JDBC。Schema知识一个实时、准确的元数据仓库至关重要。它应包含表名、列名、列数据类型、列描述注释、表间关系主外键、数据样例等。Agent在生成SQL前先查询此元数据。工具如Apache Atlas、DataHub或开源的Amundsen可以用于构建元数据目录。安全查询执行绝不能允许Agent直接执行任意生成的SQL。必须通过一个安全的“沙箱”或“代理”层。这个层应具备权限控制以最小权限账户执行、查询审计记录所有生成的SQL和执行结果、资源限制防止SELECT * FROM huge_table这类拖垮数据库的查询、结果行数限制默认只返回前1000行和敏感数据脱敏功能。Python执行环境对于更复杂的数据处理、建模和可视化需要让Agent能生成并执行Python代码。同样必须在安全的沙箱环境中进行如Docker容器严格限制其可访问的文件系统、网络和计算资源。像pandas、numpy、scikit-learn、matplotlib等常用库需要预先安装。API与工作流工具集成Agent需要能触发下游流程。例如当分析完成并确认后Agent可以调用n8n或Airflow的API启动一个模型训练流水线或者调用企业微信/钉钉的API将分析报告发送到指定群组。3.3 工作流编排与协同层这是工作流的“调度中枢”和“协作空间”。可视化工作流编排n8n、Apache Airflow、Prefect等工具将继续扮演重要角色但它们的触发条件将更加智能。一个AI分析任务本身就可以被编排成一个工作流节点。例如一个每周运行的销售报告工作流节点1AI Agent根据本周日期自动生成分析SQL并执行节点2Python脚本对结果进行二次加工节点3AI Agent将加工后的数据撰写成图文并茂的Markdown报告节点4工具将报告发布到Confluence或发送邮件。人机协同界面未来的数据平台界面可能更像一个对话式的数据分析工作室。左侧是聊天窗口你可以与AI对话中间是画布实时展示AI生成的可视化图表、SQL代码和DataFrame预览右侧是数据目录和工具面板。所有的交互历史、生成的代码、得出的结论都被完整记录形成可追溯、可复现的分析链路。4. 新工作流下的角色进化与能力要求工作流的重构必然带来角色的重塑。数据科学家、数据分析师、数据工程师的职责边界将变得模糊并共同向“数据策展人”和“AI训练师/审核师”方向进化。4.1 数据科学家从编码者到战略家与审核者传统的数据科学家可能将70%的时间花在数据清洗、特征工程和调参上。在新的范式下这些耗时的工作被大量自动化他们的核心价值将体现在定义复杂问题与评估框架提出正确的问题比解决问题更重要。数据科学家需要更深入地理解业务设计出能够被AI有效执行的、结构化的分析框架。例如如何量化“用户体验”需要拆解为哪些可观测、可度量的指标这些指标之间有何关联审核与纠偏AI输出AI可能会生成看似合理但逻辑错误的SQL或者做出有偏见的结论。数据科学家必须具备强大的逻辑批判性思维和统计学功底去审视AI的“思考过程”。例如AI说“A产品销量下降是因为价格上调”数据科学家需要追问你是如何定义‘因为’的是否控制了竞争对手降价、季节性因素等其他变量相关性能否等同于因果设计并管理“数据-AI”飞轮将AI分析中发现的规律、创建的有效特征反哺到数据仓库和指标体系中形成闭环。例如AI在探索中发现“用户首次付费后7日内的客服接触频率”是预测长期留存的关键特征数据科学家应推动数据工程团队将此特征固化为一个常驻的衍生字段供所有后续分析使用。解决“边角案例”和开创性工作AI擅长处理常见、有模式的问题。但对于前所未有的、极其复杂模糊的问题依然需要人类专家的直觉、创造力和跨领域知识。4.2 数据分析师与业务人员成为直接的数据使用者低代码/无代码的BI工具已经让业务人员能够自己拉报表。AI的加入将这一能力提升到新高度。自然语言交互市场经理可以直接问“对比一下我们和竞争对手X在社交媒体上的声量趋势重点看过去三个月关于‘可持续性’话题的讨论。”AI Agent能自动从品牌监测平台获取数据进行对比分析并生成简报。假设的快速验证“如果我们把优惠券门槛从满100元降到满80元预计对订单量和毛利率的影响会是怎样”AI可以调用历史数据基于简单的弹性模型或机器学习模型快速给出一个模拟预测区间辅助决策。能力要求变化业务人员需要提升的是“数据素养”和“提问能力”。他们需要知道数据能回答什么问题以及如何清晰、无歧义地描述自己的需求。同时他们也需要对AI生成的结果保持基本的质疑态度理解其局限性。4.3 数据工程师聚焦于高可靠性与架构数据工程师的角色不会消失反而更加关键。他们的工作重点将从编写大量的ETL脚本转向构建和维护一个稳定、高效、能被AI可靠使用的“数据供给层”。构建“AI就绪”的数据平台这包括建立高质量、文档完善的元数据系统设计易于理解和查询的数据模型如维度建模确保数据的时效性、一致性和准确性。AI Agent的效能极度依赖于输入数据的质量。开发与管理“工具函数”库将常用的、复杂的业务逻辑封装成标准的、可供AI调用的函数或API。例如一个名为calculate_customer_lifetime_value(customer_id, end_date)的标准化函数远比让AI每次去临时编写复杂的SQL和业务逻辑要可靠和高效。保障系统安全与性能设计并执行严格的Agent权限模型监控和优化AI生成查询的性能避免其对生产数据库造成冲击建立数据血缘追踪当AI使用的某个数据源发生变更时能快速定位所有受影响的下游分析。5. 面临的挑战与应对策略实录理想很丰满但迈向2026年的路上布满荆棘。以下是我在实践中遇到或预见的主要挑战及思考。5.1 幻觉与可靠性问题这是目前AI应用在数据领域最大的风险。大模型可能会“自信地”生成一段语法完全正确但逻辑错误的SQL例如错误地JOIN了表导致数据笛卡尔积膨胀或者对分析结果做出毫无根据的解读。应对策略代码执行前强制审核与解释对于重要的、影响范围广的分析任务设置“人机协同”环节。要求AI在生成SQL或代码后必须用自然语言逐步解释其逻辑“第一步我将从orders表中选择2024年的数据第二步关联customers表以获取客户所在区域第三步按区域和月份分组计算销售额总和...”。人类审核者通过审视这段解释比直接看代码更容易发现逻辑谬误。结果合理性校验建立一套自动化的“常识性”校验规则。例如如果AI计算出的某品类月销售额超过了公司历史总营收系统应自动触发警告。或者对于百分比变化如果绝对值异常大如增长10000%也需要重点审核。采用“分步执行与验证”模式不让AI一次性生成一个庞大的、包含多级子查询的SQL。而是引导它分步骤进行先生成一个简单的查询获取样本数据人类确认数据结构和含义正确后再让它基于此进行下一步的更复杂操作。这类似于结对编程Pair Programming。5.2 数据安全与隐私合规让AI直接访问生产数据库无异于给了它一把“万能钥匙”。如何防止数据泄露、越权访问和误操作应对策略最小权限原则与虚拟视图为AI Agent创建专用的数据库账户其权限被严格限制在只读某些特定的视图View上。这些视图可以预先对敏感字段如手机号、身份证号进行脱敏或者已经完成了必要的聚合只暴露分析所需的最小粒度数据。查询审计与动态脱敏所有由AI生成并执行的查询都必须被完整记录日志包括查询语句、执行时间、返回行数、执行用户AI Agent。对于查询结果在返回给前端或AI进行下一步解读前可再次通过动态脱敏规则过滤一遍。私有化部署与数据隔离对于高敏感数据考虑完全私有化的部署方案。AI模型、Agent框架和数据源全部部署在内网环境与公网隔离。使用开源模型进行内部微调确保数据不出域。5.3 成本控制与性能优化频繁调用大模型API尤其是GPT-4这类高级模型成本不菲。同时AI生成复杂查询可能导致数据库性能问题。应对策略任务分级与模型路由建立智能路由机制。简单的数据查询、描述统计任务由较小的、成本低的开源模型如7B参数的模型处理。只有复杂的逻辑推理、代码生成、报告撰写等任务才路由到能力更强、成本也更高的大模型。缓存与复用对于常见问题如“昨天的日活是多少”可以缓存AI生成的SQL和查询结果。当类似问题再次被提出时系统可以先检查缓存直接返回结果或略作调整避免重复调用AI和查询数据库。查询优化提示在给AI的提示词Prompt中明确加入性能约束。例如“请生成一个高效的SQL查询避免使用SELECT *确保在WHERE子句中使用索引列如果涉及大表关联请考虑使用EXISTS或IN子查询的优化形式。” 同时数据库层面也需要对AI账户的查询设置执行时间上限和资源消耗上限。5.4 技能断层与组织变革技术易得思维难转。团队能否接受从“掌控者”到“审核者”的角色转变业务方是否愿意且能够学习与AI协作应对策略渐进式推广与文化培育不要试图一夜之间替换所有旧流程。从一个小的、非核心的场景开始试点例如用AI助手自动生成日常的周报数据图表。让团队成员亲身体验其便利与局限逐步建立信任。内部培训与知识库建设系统性地培训员工如何与AI有效协作。编写内部的“最佳提示词手册”分享成功的和失败的案例。建立关于AI生成结果的审核清单Checklist。调整考核与激励机制传统的考核可能看重代码行数、模型精度。在新的范式下应更看重解决的问题价值、发现的业务洞察深度、以及构建的自动化分析流程的健壮性和复用性。鼓励员工成为“AI工作流的设计师”。6. 一个实战构想搭建你的第一个AI数据分析助手理论说了很多我们来看一个具体的、简化的实战构想。假设我们想为一个电商团队搭建一个能回答基础业务问题的AI助手。目标让运营人员通过自然语言提问快速获取销售、用户相关的数据。技术栈选型后端框架使用FastAPI构建轻量级Web API。AI层使用LangChain框架连接开源模型例如通过Ollama本地部署的Qwen-7B模型成本可控。数据层连接一个只读的MySQL从库包含orders订单、users用户、products产品等表。工具层为LangChain Agent自定义一个QueryDatabaseTool工具用于安全执行SQL。核心步骤拆解元数据准备编写一个脚本从数据库INFORMATION_SCHEMA中提取所有表的名称、列名、数据类型和字段注释并生成一份结构化的JSON或向量数据库文档。这是AI的“数据字典”。为关键字段添加业务含义说明。例如orders.status字段注释不仅是“订单状态”而是“订单状态1-待支付2-已支付3-已发货4-已完成5-已取消”。构建提示词模板# 这是一个简化的提示词模板 SYSTEM_PROMPT 你是一个专业的电商数据分析助手。你的任务是帮助用户通过自然语言问题查询数据库。 以下是数据库Schema信息 {schema_info} 请遵循以下规则 1. 只生成标准的MySQL SQL语句不要有任何额外解释。 2. 只查询orders, users, products这三张表。 3. 如果用户的问题模糊请基于常识做出合理假设并在生成的SQL中用注释说明你的假设。 4. 确保查询是高效的避免SELECT *使用明确的列名。 5. 如果问题无法通过SQL回答请回复“我无法通过查询数据库回答这个问题”。 用户问题{user_question} 这个模板将{schema_info}元数据和{user_question}用户问题作为变量输入给模型。创建安全查询工具from langchain.tools import Tool import pymysql def query_database(sql_query: str) - str: 执行SQL查询并返回结果字符串。 # 1. 安全校验示例检查是否包含危险关键字如 DROP, DELETE, UPDATE 等。 if any(keyword in sql_query.upper() for keyword in [DROP, DELETE, UPDATE, INSERT, ALTER]): return 错误查询包含不被允许的操作。 # 2. 连接数据库使用只读账号 connection pymysql.connect(host..., userreadonly_user, password..., databaseecommerce) try: with connection.cursor() as cursor: cursor.execute(sql_query) # 限制返回行数防止数据过量 result cursor.fetchmany(100) # 将结果转换为易读的字符串格式 return str(result) finally: connection.close() db_tool Tool( nameQueryDatabase, funcquery_database, description用于执行MySQL查询并返回结果。输入必须是一个标准的MySQL SELECT语句。 )组装Agent并创建APIfrom langchain.agents import initialize_agent, AgentType from langchain_community.llms import Ollama # 假设使用Ollama llm Ollama(modelqwen:7b) agent initialize_agent( tools[db_tool], llmllm, agentAgentType.ZERO_SHOT_REACT_DESCRIPTION, # 一种简单的Agent类型 verboseTrue # 打印思考过程便于调试 ) # FastAPI 端点 from fastapi import FastAPI app FastAPI() app.post(/ask) async def ask_question(question: str): # 将系统提示词和用户问题组合成完整的提示 full_prompt SYSTEM_PROMPT.format(schema_infoget_schema_info(), user_questionquestion) response agent.run(full_prompt) return {answer: response}测试与迭代提问“上周的订单总额是多少”Agent的思考链ReAct可能是“用户需要上周订单总额。我需要查询orders表筛选create_time在上周对total_amount求和。生成SQLSELECT SUM(total_amount) FROM orders WHERE create_time 2024-xx-xx AND create_time 2024-xx-xx;”工具执行SQL返回结果如“150000.00”。Agent将结果包装成自然语言回复“上周X月X日至X月X日的订单总额为150,000元。”实操心得从简单开始重视评估不要一开始就追求处理所有复杂问题。先从范围明确、Schema清晰的简单查询开始。建立一套测试集包含各种类型的问题简单聚合、多表关联、时间过滤、模糊问题等定期运行测试评估AI生成SQL的准确率。准确率是衡量助手可用性的核心指标。同时必须建立人工审核通道对于重要的、或AI置信度不高的查询强制转交人工处理。这个系统的价值不在于完全取代人而在于处理掉80%的简单、重复性问题让人能聚焦于那20%的复杂分析。这个简单的示例勾勒出了AI增强型数据工作流的雏形。展望2026年随着多模态能力的发展AI或许不仅能处理数字和文本还能直接分析图表中的趋势甚至根据数据自动生成一段解释性的视频简报。数据科学的工作流将变得更加动态、交互和智能化。但无论如何演进人的判断力、创造力和对业务本质的理解依然是这个智能工作流中最不可替代的核心。我们的角色不是被替代而是在AI的赋能下向价值链的更顶端攀登。