活动概览
AI进入数据生产的实践沙龙
- AI进入数据生产的实践分享
- 嘉宾团队AI实践案例
- 数据验证和知识管理
- AI项目投入方向判断
活动信息依据公开来源整理，以主办方最新公告为准。如时间、地点、票价有变动，平台会更新并保留变更记录。报名前请通过原始来源核对。
活动详情
8 月 13 日，首期沙龙在阿里巴巴朝阳科技园举行。本次讨论聚焦“从提效到托付：AI 进入实际生产的门槛有哪些”，35 位参与者围坐在园区内一间氛围很好的小酒馆。
邀请到的嘉宾有：淘宝直播数据专家李建杰、虎鲸文娱数据研发负责人刘杰、高德数据产品专家郭人豪、高德交易增长算法专家王天然、从大厂走入创业团队的研发负责人原禄城。他们分别从可信取数、研发交付、评测迭代和持续经营出发，分享各自团队正在推进的 AI Native 实践。
本文是对本次沙龙的完整复盘。结合分享、现场 QA 和圆桌交流，梳理了嘉宾和观众的核心观点。全文7600字，阅读时长20分钟。也可拆分模块，分期阅读。
读完这篇复盘，你将看到——
这篇文章适合正在建设数据 Agent或研发提效工具的一线data实践者，也适合需要判断 AI 项目投入方向的数据、产品、算法和业务负责人。
四位嘉宾所在的业务和团队阶段不同，却都遇到了一组相似的问题。
一句需求很快变成了 SQL，但没人敢直接使用结果；知识库已经接上了，表结构和指标口径一变，它却仍沿用昨天的答案；Agent 能给出一份完整分析，团队却很难定义“这份分析到底算不算好”；系统甚至能够生成策略动作，但一旦要触碰真实流量、预算和生产环境，人的审批又必须回来。
这些问题看起来分散，其实指向同一件事：当生成能力不再是唯一瓶颈，数据 AI 的竞争开始迁移到验证、知识、评测、反馈和责任。
四场分享没有给出统一路线，反而让同一个问题显出四个侧面——可信、可用、可评、可行动。
在传统的数据需求中，业务提出问题，数据研发理解口径、寻找数据、编写 SQL，再与业务反复验数。AI 首先压缩的是“写”的时间，但写得快，并不意味着交付也会同比变快。
李建杰分享了一个很直观的对照：AI 生码可能只需要 1 分钟，后面的数据验证却可能花掉 2 小时。
原因在于，数据问题与普通软件问题有一个重要区别。代码语法错误通常会报错，业务语义错误却可能安静地运行到底。一个 SQL 可以正常返回结果，但数据源选错了、统计粒度不一致、指标口径理解偏了，或者关联关系引入了重复，结果依然不可信。
李建杰的第一个判断——Data is not software。
当系统服务的对象是缺少代码判断力的业务人员时，不能把关键的正确性判断留在最后，让使用者自己兜底。正确性必须尽可能前移到系统中。李建杰团队的做法，是把“算什么”和“怎么算”拆开。
语义层先沉淀指标、维度、逻辑表和业务口径，决定当前问题究竟在算什么。AI 不直接自由生成最终 SQL，而是先把需求转成结构化 DSL；再由确定性引擎将 DSL 生成可执行代码，决定具体怎么算。遇到口径歧义时，系统应该中断并澄清，而不是让模型自行补全一个看起来合理的答案。
结果交付时，系统还会返回所用口径、执行路径和证据链。对业务人员而言，这不只是“给一个数字”，而是同时回答：这个数字来自哪里、为什么这样算、哪里可以复核。
这套路线背后，是一个从个体提效走向组织赋能的过程。2026 年 2 月，李建杰团队已有 75% 的线上 SQL 代码由 AI 直接生成。到 2026 年 6 月，可信取数覆盖了淘宝直播约 50% 的业务团队。
这些数字的价值不在于证明“人已经退出”，而在于说明：当数据认知被沉淀进语义、规则和证据链以后，业务可以开始直接调用一部分数据能力，数据研发也能退出部分实时响应。但研发责任并没有消失，它只是从每一次手工交付，转移到了底层语义、规则和系统治理中。
第一道门——事实和口径是否可信。
不过，长期建设语义层、DSL 和业务本体并不是一条成本很低的路。当团队此刻最紧迫的问题不是业务自助，而是研发人员正在被大量日常工作打断时，是否还有另一种起点？
刘杰团队面对的是另一种工作现场。数据研发人员被答疑、告警、紧急需求和复杂交付持续打断。团队当然知道，建设完整、标准的语义体系是一条正确方向，但在研发压力已经很高的情况下，重新人工梳理全部口径本身就是一项沉重工程。
与此同时，简单地让 AI 仿写历史代码也不可靠。一旦参照任务选错，后面的逻辑就可能沿着错误样本继续生成。
因此，这支团队没有直接从“对外业务赋能”起步，而是先服务具备专业判断力的数据研发；也没有在重语义层和历史代码仿写之间二选一，而是选择了一条中间路线：让 AI 阅读高质量的线上核心任务，从仍在生产运行的代码中提炼指标口径、依赖关系和避坑规则，再由人修订关键判断。
刘杰把这类与业务实现共同变化的知识称为“活元数据”。它的价值在于，知识不再完全依赖一次性的人工整理——表结构变化、指标逻辑调整、上下游依赖迁移后，团队可以自动校验元数据差异，把诊断结论反哺入库，并持续检查知识覆盖情况。
这并不意味着线上代码等于完整业务知识。代码能够反映当前如何实现，却未必解释为什么这样实现、当时基于什么经营目标，以及哪些隐性判断没有被写进代码。活元数据仍需要研发与业务共同修订，但它为知识持续保鲜提供了一个更贴近生产的入口。
在这之上，团队继续把能力做成可以复用的 Skill：找表、理解指标、拆解任务、生成代码、分析血缘、形成回刷方案，再把真实使用中的错误和经验沉淀回群体记忆。Skill 在这里不是一个“会写 SQL 的按钮”，而是一条进入真实交付链路的能力底座。
一项包含 200 多个指标的复杂需求，由一位同学借助 Skill，用约 1.5 天完成了 3 张线上表。另一个涉及九层血缘、30 余张下游表的回刷任务，人工梳理通常需要 1 至 2 天，Skill 在约半小时内给出了方案。
30 天内，这套能力获得 119 个 UV、863 个 PV。约 60% 的数据需求中，有六到七成环节已经可以由 AI 完成，团队成员体感提效在 30% 以上；7 月的需求交付效率较 6 月提升了 50%。
这些数字不能被改写成“六到七成需求已经完全自动化”。人在复杂需求里仍然保留口径、粒度、拆表、验数和上线判断。真正发生的变化，是人开始从重复执行转向关键决策。
刘杰将这种协作方式进一步归纳为 EDD + Harness：人在任务开始前定义什么叫达标，AI 在执行中按照标准自评和迭代，Review 的重点也从逐行检查，转向标准定义和关键结果确认。
现场，王天然顺着这一点追问：同一个业务需求可能有多种 SQL 写法，怎样判断 AI 的结果正确？刘杰的回答不是简单比对字符串，而是从真实需求建立 Golden Case，再拆分检查找表是否正确、指标是否正确、不同代码是否在业务语义上等价。
王天然继续把问题推向下一层：数据准确还可以量化，如果分析最终要产生业务价值，价值怎么评？刘杰没有把尚未完成的部分包装成闭环，他坦率地说明，这一步目前还没有解决——从研发提效走向业务策略，团队仍需与业务共同沉淀策略打法和判断知识。
这一问一答很重要。它说明“好用”与“可托付”之间仍有距离，也让两种看似不同的路线拥有了各自清晰的适用条件：李建杰服务缺少代码判断力的业务使用者，结果将直接进入业务自助，因此需要把正确性更早地压进语义层和证据链；刘杰先服务专业研发，允许人在关键环节继续判断，因此可以从生产代码和真实痛点轻量进入。
这不是先进与落后的区别，而是基于服务对象、生产风险和团队资源作出的不同选择——重治理，还是轻量落地。
两条路线也共享一个判断：生成越来越便宜以后，验证和知识维护会成为更大的成本。
当 AI 已经能够进入工作流，接下来需要回答的是：团队怎样知道系统正在变好，而不是只变得更快？郭人豪从一类常见的数据分析产品讲起。
为了保证稳定，取数、计算、渲染、结论常常被写成固定流程。它们可以可靠地重复一个已知任务，但留给 AI 的空间可能只剩下最后一句表达。系统守住了交付下限，也把探索新问题的上限一起焊死了。
如果接入大模型以后，答案不准就增加一条规则，流程出错就再叠一个补丁，系统可能越来越复杂，却没有形成更好的判断能力。旧流程只是被更快地复制了一遍。
郭人豪给出的架构观——流水的 Agent，铁打的底座。
模型会变化，Agent 会替换，交互和应用形态也会持续变化。组织真正需要长期留下来的，是知识、可信数据、真实问题集和评测能力。
在他的实践中，团队从线上真实问题中整理出 652 道业务题，覆盖不同类型的 Skill。系统出现错误以后，不急着针对单个问题加一条新规则，而是先将错误放进对应的根因桶，寻找能够被系统性修复的共同原因。
这些错误分类不是一张事后报表，而是下一轮架构修改的输入。四个月里，团队进行了三次知识架构重构。关注点逐步从“有没有整理知识”，走向“知识是否在正确的分析路径中被使用”。这意味着，评测不是上线前的一次考试，而是系统持续校准方向的反馈回路。
现场有人追问，开放式分析问题的标准答案从哪里来？郭人豪的回应把问题从技术推向组织：封闭任务可以比较明确地检查答案；但在探索分析中，大量问题没有唯一标准答案，团队还需要判断过程是否合理、证据是否充分、结论是否覆盖关键方面。更难的是，不同团队有时连指标和价值标准都没有形成共识。
于是，“什么叫对”不再只是模型问题。它会迫使组织重新回答：我们相信什么事实、用什么标准判断、哪些结果值得进入下一步。
AI 的价值由此不只是“同样的事做得更快”，也包括“过去因为成本和人力限制，根本没有机会做的事”。但能力越强，方向越重要——AI 会同时放大正确与错误。如果目标本身偏了、评测只覆盖了容易量化的部分，系统会用更高效率消耗资源。
第三道门——过程和结果是否可评。
前三场分享主要在解决“看得懂、做得对、能校准”。王天然把问题继续推向下一步：如果 Agent 不只生成答案，而是开始提出并执行经营动作，系统该怎样进入生产？
交易增长是一个适合观察这个问题的场景。同一套策略会随城市、行业、人群、时段、天气和供给持续变化。传统算法可以处理相对稳定的长期特征和基础预估，但短期变化仍需要不断观察、解释、形成动作并读取反馈。一次性的分析报告很难长期控盘。
王天然介绍的 AutoResearch，不是让模型一次性回答一个研究问题，而是让系统围绕真实经营目标持续研究：看见现象，解释变化，生成动作，通过安全检查，以小流量执行，再读取真实反馈，把有效经验与失败模式沉淀进下一轮。
这也不是一个 Agent 独自完成所有事情。不同 Agent 分别承担研究、执行、验收和沉淀，形成 Agent Team；Hermes 负责长期任务的编排和执行。为了让这套循环能够长期运行，团队还需要把目标、边界、动作和经验写进系统——
如果只看“系统能够自主规划”，很容易把 AutoResearch 理解成自动发现一个策略、然后直接上线。但现场讨论明确补上了中间的生产环节：策略结论需要经过人的审批和检测数据验证，再进入线上验证；真实动作先过安全门，并从小流量开始。
这不是对 Agent 能力的不信任，而是经营动作与普通内容生成承担的风险不同。只要系统会改变外部状态，权限、可逆性、影响范围和责任人就必须一起设计。
现场，郭人豪追问：既然已有传统算法，为什么还需要 Agent？王天然没有给出替代论——传统算法更擅长处理长期、稳定特征，Agent 则可以补充天气、热点等短期动态信息，以及最后一步更细粒度的规划。两者更像前后衔接的两段能力，而不是新技术把旧技术整体替换。
第四道门——动作、反馈和责任能否形成闭环。
所谓自主，并不只是少一个人工按钮。一个系统之所以能够动手，是因为目标、事实、过程、权限和责任都比过去更显式。
四场分享之后，现场的提问逐渐形成了一条清晰的递进线，可以拆成三层——
这三层评测并不能互相替代。代码测试无法证明经营建议有价值，A/B 实验也不能替代指标口径治理。越往业务动作走，评测越需要连接真实目标、反馈周期和责任链。
所以，评测不仅是在给模型打分。它还在迫使组织把原本模糊的判断说清楚：什么是正确，什么有价值，什么风险不可接受，出现什么情况必须停下来交还给人。
“AI 进入生产”，被拆成五个更加具体的问题
圆桌从一个直接的问题开始：什么时候可以把一项任务真正交给 AI？李建杰将它拆成三个阶段——第一阶段，人自己都没有说清判断标准，这时 AI 可以辅助，但判断权不能直接让出；第二阶段，人与 AI 在反复协作中形成判断机制，把达标标准、失败条件和关键节点逐渐写出来；第三阶段，当这些判断能够被系统稳定复用，AI 才可能接手更多执行。
即使进入第三阶段，最终生产责任也不会凭空消失。原禄城补充：AI 可以负责计划和实现的初稿，人需要把控最终目标、可维护性、可观测性和关键节点。
它们共同说明：人在 Loop 中，不应该永远等同于逐行检查。更成熟的人机协作，是把人的判断逐步转换成目标、事实、验收、升级和责任机制。
圆桌随后把“托付”落到一类数据团队熟悉的产物：日报、周报和月报能否完全由 AI 完成？李建杰区分了两种交付——如果任务是基于可信看板进行数据解读，边界相对清楚，自动化程度可以很高；但如果一份报告不仅要解释发生了什么，还要告诉业务怎么做，那它已经进入经营建议，则需要更深的行业知识和行动责任。
“报告自动化”和“经营决策托管”因此不能混为一谈。同一份内容是否可以交付，不只取决于模型能力，还取决于交付对象、使用方式和错误后果——内部参考、对外发布、策略建议和真实经营动作，需要不同的生产门槛。<