一、产品经理的数据分析工作流需要被重构

黄金流程（简称黄流）是用户进入商品详情页后的一系列触点。通过在核心购物节点进行精准的推荐，激发用户购物需求，提升连带率，最终满足用户需求和平台的经营目标。作为黄流推荐算法产品组的一员，我们的目标是通过推动前台形态、算法模型与策略、运营抓手的联动优化，实现用户价值和平台价值的提升。



在黄流推荐的业务里，数据分析不是一项边缘能力，它几乎渗透在每一类产品工作中：无论是前台形态优化、推荐机制设计、可运营能力建设，还是日常的业务需求承接、Badcase 排查、实验效果解读、策略机会判断，背后都离不开数据支持。在数据分析的工作流中，真正能体现产品经理价值的环节是：

1.定义清楚真正要解决的问题；

2.搭建合理的分析框架和验证路径；

3.理解数据背后的业务含义；

4.把分析结论转化为可落地的产品和策略动作。

但在实际工作中，我们花费了大量时间在寻找可用底表、核对字段口径、写 SQL、反复取数、整理表格等重复性执行工作上。与此同时，产品经理还要同时处理业务沟通、需求评审、PRD 撰写、项目推进、资源协调等大量事务。结果就是：很多本该做、也值得做的数据分析，要么没有被做，要么没有做深做透。



所以，我们团队虽然早已意识到数据分析在日常工作中的重要性，但由于缺少低成本、高可复用的自动化数据分析能力，导致即便是高业务价值的分析，最后也容易被时间、协作成本以及其他高优事项所淹没。



二、通用的AI能力远远不够

在真正开始重构数据分析工作流之前，我们尝试过很多“用 AI 提效”的方式。其中最典型的一种，就是让 AI 帮忙写 SQL。这种方式当然有一定帮助，但我们很快就发现，它只能让“写 SQL”这个动作本身变快一些，并没有提升整个数据分析工作流的效率。原因很简单：产品经理的数据分析问题，并不是一个孤立的 SQL 生成问题。在真实场景里，一次完整的数据分析任务通常还包括：

1.理解业务背景和分析目标；

2.判断该用哪类分析框架以及统计口径；

3.找到合适的底表、字段、埋点；

4.处理关联键、过滤条件等业务细节；

5.在结果出来后继续多维度下钻、补充验证；

6.最终把分析结论整理成对业务有指导意义的输出。

而通用 AI 在这些环节里存在明显短板。一方面，它缺乏业务知识，不理解黄流业务里的术语、指标口径、常见分析路径和历史踩坑经验，因此产出出错率高；另一方面，每次任务开始时，我们又必须重新补充业务背景、解释字段含义、说明历史规则，沟通成本很高。结果就是：看起来 AI 参与了分析，实际上只是把“写 SQL”这一小段动作提速了。它并没有真正改变原有的数据分析工作流，也没有真正减少产品经理在重复性执行工作上的消耗。整个数据分析工作流依然强依赖人的参与，AI 只是一个零散的辅助工具。

基于通用AI的使用经验和思考，我们逐渐意识到：要真正发挥 AI 的价值，关键不在于让它帮助我们更快地写SQL，而在于围绕 AI 重新设计工作流。让 AI 参与到分析任务识别、知识调用、执行协同和经验沉淀中，它才可能真正成为产品经理的数据分析伙伴。



三、解法：建设一个“懂黄流业务”的 “AI 分析知识仓库”

基于这个判断，我们开始重新思考：如何围绕 AI 重构整个数据分析工作流，让AI 成为产品经理的数据分析伙伴？

我们的想法是，AI 需要能够模拟一位真实的产品经理，在接受任务后，承担起原本依赖人来完成的工作：

1.通过调用业务背景和术语知识，理解分析目标；

2.基于分析目标，识别分析任务类型，并复用已有的分析 SOP，产出分析框架；

3.基于历史经验，明确可用的数据表、字段和口径；

4.复用已有的 SQL 模板，或基于分析目标，建设新的SQL；

5.根据历史踩坑经验主动避错；

6.完成自动提交取数任务、下载数据至本地并进行数据分析的闭环流程；

7.产出初步分析报告，并在与产品经理的交互中持续打磨；

8.在任务结束后，将经验和踩过的坑沉淀为AI永久能力的一部分。

在不断与AI交互打磨的过程中，我们逐步探索出了一种适合团队落地的模式：AI 分析知识仓库。

简单来说，它是一套基于团队共享知识构建的 AI 数据分析协作机制。我们把业务术语、数据表说明、SQL 模板、任务模板、踩坑经验等内容，沉淀进统一的知识仓库中，并通过 Git 和 AI Skill 的方式进行持续维护、调用和迭代。这套围绕AI建设的协作机制有两个明显的好处：

1.团队里的每一位成员再也不需要每次分析任务时，对一个通用 AI 重新解释业务背景，而是通过调用同一个“懂业务”的 AI 数据分析助手，自动加载所有业务背景知识。

2.更重要的是，这套能力是动态升级的。每一次项目中的新经验、新口径、新模板，都会更新至“AI 分析知识仓库”，成为团队共享的经验，也是下一次分析的起点。

“AI 分析知识仓库”不仅仅是一次效率的提升。更重要的是，它把原本分散在个人头脑中的经验、方法和判断路径，逐步沉淀成了团队可复用、可迭代、可验证的共同资产。这也是为什么我们把这件事定义为：从个人提效，到流程提效，再到团队复利。



四、细拆“AI 分析知识仓库”的结构和能力

“AI 分析知识仓库”由两部分组成：

1.数据分析skill (data analysis skill)

2.基于Git 版本控制系统的团队协作模式  

接下来，我们讲详细拆解和描述这两部分是如何建设和运作的。



4.1 数据分析skill (data analysis skill)

我们建设的“data analysis skill“，核心是由 6 份自然语言写的文档组成，存储在 “skill”文件夹中。里面的每份文件都是普通 markdown 文档，没有任何代码，没有技术背景的同学都能读懂。这就是AI 的"业务知识储备" 。看完这 6 份文档，AI 就从"通用工具"变成"懂黄流推荐的数据分析专家"。下图描述了“AI分析知识仓库” 的文件结构，以及每份文件功能和存在的价值

data-analysis skill 
  │
  ├── 顶层文档（入门必读）
  │   ├── README.md                    新手小白入门指引
  │   ├── SKILL.md                     AI 工作守则（角色、硬规则、协作模式）
  │   └── CLAUDE.md                    AI 工具的默认入口指针（指向 SKILL.md）
  │
  ├── 🧠 skill/   —— "AI 的大脑"：业务知识 + 方法论
  │   ├── glossary.md                  业务术语本（团队的"黑话词典"）
  │   ├── tables.md                    数据表说明书（已确认可用的表登记 + 字段口径）
  │   ├── sql_cookbook.md              SQL 模板库（高频查询，100%正确的SQL样例）
  │   ├── workflow.md                  标准工作流（从需求到报告的 9 步 SOP）
  │   ├── task_types.md                任务模板（常见分析的"诊疗方案"，如异动归因、A/B实验解读、专项数据洞察、业务指标异常定位、badcase 排查，等）
  │   └── lessons.md                   踩坑经验本（历史踩坑的"事故案例库"）
  │
  ├── 🦾 scripts/core/   —— "AI 的四肢"：把分析真做出来的工具
  │   ├── cdp_client.py                连接本地 Chrome 复用登录会话
  │   ├── jupyter_exec.py              在远端工作台直接执行命令
  │   ├── setup_runsql.py              在远端建任务工作目录
  │   ├── run_remote_sql.py            主控:推 SQL → 提交 → 监控 → 下载
  │   ├── run_remote_sql_batch.py      一次并发跑多个 SQL
  │   ├── wait_jobs.py                 轮询任务完成
  │   ├── download_large.py            大文件分块下载
  │   └── config_loader.py             读取统一配置
  │
  ├── 📂 工作目录（每个项目独立隔离）
  │   ├── workspace/<日期>-<任务>/sql/    项目专属 SQL
  │   ├── workspace/<日期>-<任务>/data/   项目专属数据文件
  │   └── reports/<日期>-<任务>.md       最终分析报告
  │
  └── 🔧 配套配置
      ├── config.yaml                  全局参数（连接配置、超时、目录）
      └── start-chrome-debug.sh        一键启动调试 Chrome 的脚本



4.2 基于Git 版本控制系统的团队协作模式

先理解：Git 到底是什么？Git 是一套多个开发者需要共同优化同一套代码时，常用的版本控制系统。由于它具备“支持多人协作” 和“知识沉淀”的能力，用它来管理“data analysis skill” 尤其合适。

团队成员的协作模式是：1 个云端主仓库（始终保持为“最权威的skill” 版本） + N 个本地副本。具体而言：

1.云端永远保留最新最全的版本，作为"最权威的skill "版本；

2.每个人电脑里都有一份完整副本，AI 直接读本地副本，不需要联网。每位员工只需要在云端的版本有更新时，拉取最新版本到本地，就可以继续使用"最权威的skill "；

3.每个人如果要优化skill, 都要先在本地改（如加新经验、改 SQL 模板、登记新表，等），再推到云端，由团队成员review 后，方可与原有版本merge，让skill 越来越聪明，越来越理解业务。









五、“AI 分析知识仓库” 的实践案例

下面我们将通过两个案例，来体现“AI 分析知识仓库”已经在工作中发挥的两个价值：

1.原本由于分析成本太高而做不深、做不完的分析，变得可以做下去；

2.原本依赖少数人经验的能力，逐步沉淀成团队可以复用的公共能力。



5.1 案例一：顺手买曝光机会点洞察 -- 降低复杂、高分析成本项目的实现成本

在黄流推荐业务里，结算页顺手买楼层一直是核心增长来源之一。但长期以来，我们始终没能精确回答几个非常关键的问题：

1.在结算页整体大盘里，到底有多少 PV 没曝光顺手买楼层？

2.这部分“不曝光”到底是因为前台被屏蔽，还是用户根本没有下滑到该位置？

3.不同人群、不同品类、不同结算页类型之间，差异究竟有多大？哪些组合的改造潜力最大？



这些问题听起来像是“一份简单的分析”，但真正拆开后，会发现它的复杂度远超一般专题分析：

•日均数据量级达到上亿 PV；

•需要同时处理浏览日志、曝光日志、活跃商品表、用户画像、顺手买生命周期等 5 张原始表；

•分析维度覆盖结算页类型、主品数量、用户画像、生命周期、类目、事业部等多个层次；

•需要搭建多张中间表反复校验结果。



这类项目很重要。但过去因为成本太高，团队通常没有时间接，或者做得不够深入和彻底。而本次项目，我们借助 AI把这样一个复杂的分析任务做完了。具体路径是：

1.项目一开始，AI 就先将任务识别为“综合归因分析”，并基于任务模板生成了初步分析框架；

2.产品经理与AI通过多轮沟通，补齐AI 的业务知识盲区和错误的核心假设，修正分析目标，合力完成了最终的分析框架。其内容包含核心假设拆解，分析维度设计，中间表搭建路径等；

3.由于当时的AI 缺少相关原始表的处理和关联知识，由产品经理进行调研，输入给AI，并且作为知识被永久地存储在AI的记忆中，供后续调用；

4.接下来，AI 持续承担了大量原本需要手工推进的执行工作：写完 4 张中间表的 SQL、自动调度 Spark 任务、监控执行状态、处理中断重跑、自动下载结果；

5.在完成核心中间表的搭建后，AI 继续写了14个分析SQL, 涉及 31 个独立维度(结算页样式、用户画像、商品画像), 实际跑出 300+ 个真实交叉组合

整个项目中， AI 实际接管了约 80% 的取数工作、60% 的分析工作和 20% 的报告撰写工作。最终，我们基于这次分析，对结算页顺手买的曝光有了深度和全面的了解，并产出了4个后续需要跨团队协作优化的方向。于此同时，基于这个项目里沉淀下来的新经验，包括底表关联键、结算页用户交互动线、常用分析维度等，都已经写回知识仓库，并在后续项目中开始自动发挥作用。



5.2 案例二：Badcase 排查SKILL -- 把“散落在个人头脑里的经验知识”变成团队公共能力

一个能体现“团队复利”的案例，是 Badcase 排查能力的沉淀。在推荐业务里，业务方经常会提出一个问题：某个 SKU 为什么突然效果下滑？



在之前，这个问题往往并没有现成答案，需要产品沿着曝光、过滤、定向、风控、算法分发等多个环节逐步排查。在缺少成熟方法论时，大多数情况下只能靠具体同学根据经验从头摸索：先想要查什么，再找表、写 SQL、判断口径、给结论。这种工作模式高度依赖个人经验。谁做得多，谁就更快；换一个人接手，效率和质量就会明显下降。 为了解决这个问题，我们做了以下动作：

1.首先，基于历史各种case 的排查经验，总结了一套联合运营、产品、算法的“Badcase 排查 SOP”。

2.下一步，团队同学在实际排查案例中使用这套SOP模版，不断优化SOP的同时，验证SOP的可行性和正确性

3.最后，我们将经过多轮实操验证的模版沉淀进 AI 分析知识仓库，具体沉淀的内容包括一类独立任务模板、7 步标准排查路径、9 段标准 SQL 模板，以及 8 张相关数据表的说明和常见使用规则。

这套 SOP 沉淀完成后，我们又专门做了一次“盲测”验证：使用一个全新的 AI 实例，不给它任何项目记忆，只让它读取仓库内容，然后独立处理一个真实历史 case。结果是，它在完整走完 7 步排查流程，并独立得出了与历史结论一致的主因判断。 这件事意味着：过去依赖少数人经验的分析能力，第一次被真正抽象成了可复用的方法论；而方法论一旦沉淀进知识仓库，就不再只属于原来的那个经验丰富的同学，而变成了团队每个人都能调用的公共能力。



六、AI 时代产品经理的新认知

在这轮实践之前，我们团队对 AI 的理解，更多还是“一个更聪明的辅助工具”：能写 SQL、能整理文档、能做一些重复性的执行工作。但真正把 AI 融入进团队工作流之后，我们越来越清楚地感受到：AI 带来的变化，不只是效率提升，而是在重新定义产品经理的能力结构、工作方式，甚至团队协作的底层模式。对我们来说，这里面最重要的有三点认知变化：

6.1 AI 会逼产品经理对问题有更清晰的定义

如果产品经理没有定义清楚问题，AI 会在更短时间里生成更多的分析路径、更多 SQL、更多草稿，从而高效地执行错误的方向。对于产品经理来说，AI最有价值的部分，是倒逼我们把问题想清楚，而这也是产品经理核心竞争力的来源

6.2 AI 时代，“工作流设计能力” 比“执行能力” 更重要

AI 让写 SQL、做基础分析、整理文档等过去需要花费大量时间的重复性执行工作自动化，这意味着，“设计让问题能够稳定被解决的SOP”成了产品经理更重要的能力。产品经理需要想清楚：

•一个复杂的分析项目要如何拆解？

•哪些节点适合交给AI？哪些需要保留人工判断？

•怎样把一次性的经验总结成可复用的模板和 SOP？

6.3 把个人经验转化成团队资产

AI 在改变每一个人的工作方式的同时，也改变着团队的协作模式。当AI不再是帮某一个人完成一次性的任务，而是把原本只存在于个人头脑中的经验、方法和判断路径，逐步转化为整个团队可复用、可迭代、可验证的共同资产，那么AI实际上是在提升团队长期能力的上限：每完成一个项目，AI 和团队就一起变得更强，下一次的起点也因此被抬高。