Creator Data Workbench · 真实业务案例
我把一下午重复几十次的达人提报工作，做成了可复用的数据自动化工作台。
Creator Data Pipeline & Talent Asset Management System（达人数据采集与资产管理系统）。它从实习期间真实的淘宝逛逛资料查找、Excel 回填和主页链接处理出发，逐步把一次性采集升级为可验证、可持续复用的达人数据资产管线。
我把亲自执行的达人提报拆成确定性自动化、人工确认和长期数据沉淀，并让名单输入、平台采集、字段标准化、质量检测、Supabase 入库与业务 Excel 输出形成一条可验证的数据管线。
- 约 30 人
- 使用或从流程中受益不代表每天都使用
- 约 10 分钟 → 约 2 分钟
- 单名达人的人工处理与介入时间基于实际流程估算
- 约 80%
- 单条任务人工处理时间下降不是严格对照实验
- 原约 3 小时 / 人 / 批次
- 得到显著释放的重复处理时间不外推年度节省工时
真实业务背景
产品机会来自我亲自做过的重复工作。
实习期间，我实际承担淘宝逛逛达人提报工作。一份业务名单通常包含几十名达人，需要在平台逐一查找资料，再按照 Excel 的当前表头复制和回填。约 30 名同事使用过该工具或从改造后的流程中受益。
参与这条流程的人
亲自执行达人提报的实习生与运营
需要批量整理候选名单的商务和内容团队
复用历史达人资料的约 30 名相关同事
原始人工工作流
一份达人名单，是如何占掉一下午的。
每名达人都要重复搜索、确认、复制字段和回填，人工处理约 10 分钟。其中只有“个人主页链接”字段需要二维码、手机到电脑、短链清理和公开链接转换；它不是获取其他字段的前置步骤。
- 01接收达人名单
打开业务 Excel，确认一份名单中的几十名达人，以及当前模板要求回填的表头。
- 02逐名搜索达人
在淘宝光合 / 逛逛后台按昵称查找目标达人，进入列表或详情页确认对象。
- 03按表头复制字段
根据 Excel 当前列名逐项复制粉丝、类型、商业指数、种草表现、报价等信息，再粘贴回对应单元格。
- 04单独处理个人主页链接
只有“个人主页链接”字段需要打开二维码，经过手机到电脑、二维码解析、短链清理和公开链接转换。
链接转换不是抓取其他达人字段的前置条件；该字段失败时，其他字段仍可继续处理。 - 05重复并检查
对名单里的每位达人重复搜索、复制、回填和核对，一次批量任务原本会占用每人约 3 小时。
问题发现
瓶颈不只是复制慢，而是每次都从零开始。
我先在亲自执行中发现了明显的复制劳动，但产品机会并不只在『更快填完一次表』。随着任务重复发生，更多问题逐渐出现：平台风控导致批次不稳定，不同 Excel 表头难兼容，重复抓取浪费时间，长任务缺少反馈，而每次结果都留在独立文件里，下一次仍要从头开始。
一份名单需要对几十名达人重复查找、复制和 Excel 回填；单名达人人工处理约 10 分钟，一次批量任务原本每人约需 3 小时。
“个人主页链接”字段额外涉及二维码、跨设备传输、短链清理和公开链接转换，但该字段不应阻塞其他达人数据。
结果停留在一次性 Excel，任务过程不可见、同一达人被重复访问，数据无法沉淀为下一次可以直接复用的资产。
Before / After
先释放重复劳动，再把结果变成可复用资产。
每名达人重复搜索、复制和回填，人工处理约 10 分钟。
固定字段由系统批量处理，平均人工介入约 2 分钟。
个人主页链接依赖二维码与跨设备手工转换。
该字段拥有独立二维码解析、短链清理和公开链接转换链路，不阻塞其他字段。
每次任务都重新访问平台，历史结果停留在一次性 Excel。
优先查询达人库，缺失或过期字段再访问平台补充。
任务运行时不知道进度、耗时和失败位置。
显示当前达人、完成进度、耗时、失败原因和可下载结果。
核心产品升级
从重复整理，到可持续复用的数据资产。
效率提升解决的是一次任务需要多少人工；Creator Repository 解决的是下一个项目是否还要从零开始。产品因此从一次性数据采集，逐步演进为自动化工作流、Creator Repository、数据资产管理系统，并成为 AI 辅助分析的基础设施。
- 一次性数据采集
- 自动化工作流
- Creator Repository
- 数据资产管理系统
- AI 辅助分析基础设施
每个项目重新处理达人数据
- 接收项目 Excel
- 人工查找达人信息
- 重新访问平台
- 复制字段并完成一次性提报
- 任务结束后，数据散落在 Excel、JSON 与临时结果中
- 重复访问平台
- 重复复制字段
- 数据无法持续积累
达人进入长期 Creator Repository
- 通过 Repository 统一读取
- Supabase 保存历史达人结构化数据
- 新项目优先查询已有达人
- 只补充缺失或需要更新的字段
- 持续沉淀为可搜索、可筛选、可导出的达人资产
- 历史数据复用
- 缺失字段补充
- 降低平台访问
- 支撑后续推荐
- 历史数据沉淀
- 把原本散落在 Excel、JSON 和临时采集结果中的达人信息，收拢为统一 Creator Repository；Supabase 承担长期结构化存储。
- 避免重复访问平台
- 对于已经沉淀的达人，系统优先从 Repository 查询已有信息，不再重复打开平台、登录、抓取和整理；仅对缺失或需要更新的字段进行补充。
- 支撑后续能力
- 结构化数据成为搜索、筛选、标签、导出、透明规则推荐，以及后续 AI 辅助分析的共同基础。
Data Pipeline Architecture
从数据采集，到达人资产管线。
Creator Repository 不是采集后的附加数据库，而是整条 Data Pipeline 的资产层：系统把达人名单、受控平台采集、字段标准化、质量检测、Supabase 入库、Cache First 查询和业务 Excel 输出连成可检查、可回填、可持续复用的管线。
- 达人名单 / Excel 输入
- Playwright 平台采集
- 业务 Excel 输出
- 项目结束
问题转变第一版解决了采集和回填，却没有形成数据资产闭环。每个新项目仍可能重新访问平台，问题由“如何抓取达人”转变为“如何让数据可信地进入长期资产，并在下一次任务中优先复用”。
从重新抓取，到优先复用已有资产。
输入名单后先查询 Creator Repository。系统不是只判断“数据库里有没有这个达人”，而是根据当前业务任务检查所需字段是否完整；满足 Cache Policy 时直接复用，关键字段不足时才回到平台补充并更新数据库。
- 输入达人名单
- 查询 Creator Repository
- 按任务检查字段完整度
- 完整数据直接复用
- 关键字段缺失时 fallback 平台采集
- 质量校验后更新数据库
Cache First 是优先复用策略，不代表 100% 不访问平台。未命中、关键字段不足或数据需要更新时，Playwright 仍承担受控补充入口。
从“记录存在”升级为“数据是否足够完成当前交付”。
数据库存在达人记录，不代表它能完成当前提报。早期过于笼统的完整度判断会让缓存策略失真：要么复用缺少交付字段的数据，要么因为非关键字段缺失而重复访问平台。
Cache Gate 按当前 Excel 任务需要的字段做分级判断。影响业务交付的字段进入 Hard Required；不会阻塞当前任务的增强字段进入 Soft Required，由此决定直接复用还是 fallback 平台补充。
- Hard Required · 影响匹配或当前交付
- userId · homepage · avatar · hotTags · commercialPowerIndex · 30 天核心指标
- Soft Required · 增强信息
- gender · talentType · tags
满足当前交付的历史达人可直接从 Repository 回填；Soft Required 缺失不会单独触发完整重抓，Hard Required 缺失才进入受控平台补充。
数据进入资产库之前，先保证可信。
Field Alignment：统一字段体系
真实问题历史文件和不同采集阶段出现 avatarImageUrl、avatarUrl、avatar、avatar_url 等不同命名，同一信息无法稳定读取和合并。
治理决策通过统一 Creator Repository Schema、字段别名和转换逻辑，将不同来源映射到同一标准字段，并保留兼容读取。
当前转换逻辑兼容头像、主页、userId、商业指数和 30 天指标的多种历史字段名。Excel Header Parsing：解析业务表头
真实问题业务 Excel 可能使用双层 Header，例如上层“30 天”、下层“发布作品数”。只读取单行会丢失字段语义，导致无法稳定识别写入位置。
治理决策自动识别表头行并合并双层语义，再通过别名映射到统一字段，不要求业务先重做已有模板。
当前模板识别兼容单行、双行表头以及达人昵称、商业指数、主页链接等历史列名。标签语义混乱
真实问题“新锐达人、优选达人、热门榜达人”属于业务身份，而“科技、数码、家居”属于内容分类；混在同一字段会让筛选和推荐失真。
治理决策hotTags 只保留新锐 / 优选 / 热门等业务标签，内容分类进入独立标签语义，不把内容类目误判为商业身份。
当前 hotTags 清洗规则只接受明确的业务身份词，并在写入前去重。Metric Validation：拦截异常指标
真实问题历史结果可能包含“—”、空值或字段串位，例如发布作品数错误读取为内容种草人数；直接迁移会把错误永久沉淀。
治理决策写入前增加空值、数值合法性、完整度与可疑指标关系校验；异常候选跳过并记录原因，不让单条污染扩散到 Repository。
安全回填会拦截无效指标，并对发布数与种草人数异常相等的可疑数据进行二次检查。Invalid Data Recovery：恢复已识别污染数据
真实问题历史解析错误可能已经进入本地缓存或数据库，仅在新任务中绕过这些记录不能修复已有资产。
治理决策先识别已确认的污染候选，再对候选执行受控重新采集；新指标完整并通过校验后，才修复 Repository 并同步更新 Cache。
当前提供独立的 invalid recovery 流程和 dry-run 检查；它只处理已识别候选，不宣称自动修复所有历史数据。从历史文件，到数据库资产。
历史 Excel 不需要为了入库再次访问平台，也不能未经检查直接灌入 Supabase。它先经过质量审计、污染过滤、字段标准化和身份匹配，再以补空值方式进入 Talent Database。
- 历史 Excel
- 质量审计
- 污染数据过滤
- 字段标准化与身份匹配
- 安全回填
- Supabase Talent Database
- 历史回填不重新访问平台
- 已确认污染数据不进入资产库
- 不使用历史值覆盖更优数据
- 只补充缺失信息并复用统一字段转换逻辑
- Supabase 不可用时保留 JSON fallback
- Excel / JSON / Temporary Result
- 项目结束
- 无法统一复用
- 达人名单 / Excel 输入
- Playwright 平台采集
- Schema Normalization
- Data Quality Validation
- Supabase Talent Database
- Cache First Query
- 业务 Excel 输出
产品演进
从一次性自动化，到达人数据基础设施。
每一次升级都不是为了增加功能数量，而是为了回应上一阶段暴露出的真实业务问题。
- Stage 1
人工 Excel 提报流程
- 问题
- 每份名单都要重复查找、复制和回填；项目结束后，达人数据仍停留在一次性文件里。
- 产品决策
- 先完整拆解真实提报链路，识别哪些动作是稳定规则，哪些判断必须继续由运营负责。
- 能力升级
- 把重复劳动和人工责任边界定义成一条可以逐步产品化的工作流。
- Stage 2
自动化采集与回填
- 问题
- 固定流程占用大量时间，但搜索、字段读取和 Excel 回填本身具有明确规则。
- 产品决策
- 先用确定性自动化处理重复步骤，对登录、异常和最终提报保留 human-in-the-loop。
- 能力升级
- 形成批量采集、模板识别、补空值、进度反馈和失败隔离能力。
- Stage 3
Creator Repository
- 问题
- 自动化提高了一次任务的效率，却没有解决历史结果无法持续复用的问题。
- 产品决策
- 建立统一 Creator Repository，让新项目优先读取已经沉淀的达人信息。
- 能力升级
- 系统从一次性采集流程升级为可以持续积累、查询和交付的达人数据资产。
- Stage 4
Cache First + Data Quality
- 问题
- 数据库有记录不等于数据可用；字段不一致、任务必需字段缺失和历史污染仍会造成重复采集或错误复用。
- 产品决策
- 引入按当前任务判断的 Cache Policy、Schema 标准化、写入前质量校验、安全历史回填和已识别污染数据恢复。
- 能力升级
- Creator Repository 开始具备可复用、可补充、可治理、可恢复和可追溯的数据基础设施能力。
- Stage 5
AI 辅助分析
- 问题
- 达人资产沉淀后，运营仍需要从大量候选中理解差异并缩小判断范围。
- 产品决策
- 先用透明规则实现标签、评分、排名和推荐；生成式 AI 语义分析继续保留人工确认边界。
- 能力升级
- 结构化数据成为辅助分析与后续 AI 能力的基础，但最终提报仍由运营判断。
核心产品决策
我没有追求完全无人化，而是先把责任边界做清楚。
我先用确定性自动化处理规则稳定的搜索、字段读取和 Excel 回填；对登录、风控、字段确认和最终提报保留 human-in-the-loop。随后增加补空值、模板兼容、任务可视化和达人库优先，让系统从一次性自动化回填逐步演进为长期数据资产。
固定流程用确定性自动化，判断节点保留 HITL
- 背景
- 搜索、复制和回填规则稳定，但登录、风控、对象确认和最终提报仍有业务风险。
- 决策
- 系统执行可重复步骤，运营负责登录、异常确认与最终名单判断，不做完全无人化 Agent。
- 取舍
- 仍需要少量人工介入，但责任边界更清楚。
- 结果
- 自动化后平均人工介入约 2 分钟，同时避免错误被整批放大。
默认补空值，不覆盖人工内容
- 背景
- 同一 Excel 可能已包含同事填写或人工确认的数据。
- 决策
- 增加 scan-missing 和 fill-empty，完整字段跳过，只补需要的空值。
- 取舍
- 系统不会每次强制刷新所有数据。
- 结果
- 减少重复访问，也保护人工判断和已有内容。
兼容现有模板，而不是要求业务迁移
- 背景
- 不同同事、客户和任务使用的表头名称、顺序和双行结构并不一致。
- 决策
- 建立模板识别、表头别名和字段映射，按原文件写回。
- 取舍
- 需要持续维护映射规则。
- 结果
- 工具可以进入原有工作流，不需要先重做所有 Excel。
达人库优先，平台抓取作为补充
- 背景
- 同一达人会在不同名单中重复出现，但数据库命中不代表字段足以完成当前交付。
- 决策
- 通过 Repository 先查 Supabase 或 JSON 缓存，再按当前模板的 Hard / Soft Required 字段决定直接复用或 fallback 平台采集。
- 取舍
- 需要持续维护字段策略、来源和双路径一致性。
- 结果
- 满足交付的历史数据直接复用，非关键字段缺失不会导致无意义的完整重抓。
数据进入资产库之前，先保证可信
- 背景
- 字段别名、双层 Excel 表头、空值、指标串位和历史污染会让“已存储”不等于“可使用”。
- 决策
- 在写入前执行 Schema 标准化、Header 解析和 Metric Validation；历史文件先审计再补空值，已识别污染数据通过独立恢复流程处理。
- 取舍
- 入库链路更严格，异常数据会被跳过并等待补处理。
- 结果
- Creator Repository 的价值从存储数量转向可复用数据的可信度。
面向真实生产环境的稳定性设计
- 背景
- 平台页面和网络环境并不稳定，搜索、详情打开、详情就绪和写入任何一段都可能短暂失败。
- 决策
- 分别设置 Search Retry、Detail Retry、Detail Ready Wait 和 Write Retry，并保留节流、诊断日志与单条失败隔离。
- 取舍
- 系统不会追求最快速度，重试次数也保持有限。
- 结果
- 单条失败不会导致整个批量任务失败，使用者可以根据失败阶段继续补处理。
先用透明规则辅助推荐，再谨慎引入 AI 标签
- 背景
- 数据沉淀后需要支持候选筛选，但当前没有训练数据证明机器学习排序有效。
- 决策
- 先用标签、指标权重和可读理由完成评分、排名与推荐；AI 语义标签作为后续建议并保留人工确认。
- 取舍
- 不把推荐包装成自动决策。
- 结果
- 运营能理解推荐依据，并继续保留最终提报判断。
问题驱动的迭代
每一项能力，都来自一次真实失败或新的业务要求。
- 阶段一
批量抓取与 Excel 回填
- 真实问题
- 一份名单要对几十名达人重复搜索、复制字段和粘贴。
- 产品决策
- 先自动化规则明确、重复频率最高的固定流程。
- 新能力
- 按名单批量搜索达人，并写回原 Excel 模板。
- 结果
- 把逐条手工操作变成可重复执行的批处理。
- 阶段二
个人主页链接转换
- 真实问题
- “个人主页链接”需要二维码、跨设备和短链清理，明显拖慢单条处理。
- 产品决策
- 把它作为独立字段管道，而不是其他字段的前置条件。
- 新能力
- 二维码解析、短链清理和公开主页链接转换。
- 结果
- 链接失败不再让整名达人的其他字段一起失败。
- 阶段三
登录态与生产稳定性
- 真实问题
- 搜索结果、详情页加载和网络写入都可能出现短暂波动，让长批次在不同阶段失败。
- 产品决策
- 保留人工登录与确认，并把重试拆到 Search、Detail、Detail Ready Wait 与 Write 四个明确阶段。
- 新能力
- 登录态复用、分阶段有限重试、诊断日志和单条失败隔离。
- 结果
- 单名达人失败不会中断整个批量任务，失败阶段也可以被定位和补处理。
- 阶段四
只补空值
- 真实问题
- 重复运行可能覆盖同事已填写或人工确认的数据。
- 产品决策
- 默认保护已有值，只处理缺失字段。
- 新能力
- 缺失扫描、fill-empty、全部字段完整时跳过。
- 结果
- 降低误覆盖和无意义平台访问。
- 阶段五
模板识别与字段兼容
- 真实问题
- 不同同事、客户和场景使用的表头名称与双行结构不一致。
- 产品决策
- 兼容原模板，不强迫业务先迁移到统一表格。
- 新能力
- 模板类型识别、表头别名、双行表头和字段映射。
- 结果
- 系统能写回现有业务文件，降低使用门槛。
- 阶段六
任务过程可见
- 真实问题
- 长任务开始后，使用者不知道处理到谁、还要多久、为什么失败。
- 产品决策
- 把运行状态作为产品功能，而不是终端日志。
- 新能力
- 进度、当前达人、成功失败、耗时统计和失败原因。
- 结果
- 使用者可以判断等待、补处理或重新登录。
- 阶段七
达人库与缓存优先
- 真实问题
- 同一达人被反复抓取，数据每次只留在结果 Excel，无法长期复用。
- 产品决策
- 先查长期达人资产，并按当前任务的 Hard / Soft Required 字段判断是否可直接复用。
- 新能力
- Repository Layer、Supabase-first、JSON fallback、Cache Policy 与采集后质量入库。
- 结果
- 产品从自动化回填升级为可持续维护的达人数据管线与资产管理系统。
- 阶段八
标签、评分、排名与推荐
- 真实问题
- 数据被沉淀后，运营仍需要从大量达人中判断谁更适合种草、成交或综合目标。
- 产品决策
- 先用透明规则形成标签、评分、排名和推荐理由，AI 语义标签只作为后续辅助建议。
- 新能力
- 规则标签、商业与表现指标排序、TOP10 推荐及可读理由。
- 结果
- 达人库开始支持候选判断，但不会把规则推荐包装成机器学习模型。
当前解决方案与架构
技术被放在业务故事之后，但每一层都有明确责任。
产品先解决几十名达人重复查找和按表头回填的问题，再把 Playwright 采集、字段标准化、质量检测、Supabase Talent Database、Cache First 查询与业务 Excel 输出连成完整数据管线。Creator Repository 不只是存储，而是长期复用、治理和辅助分析的资产层。
使用体验
让非开发使用者看见模板识别、进度、耗时、失败和数据健康，而不是面对一段不可解释的脚本。
Excel upload and template detection
Progress / elapsed time / failure reasons
Creator list / detail / data health
自动化执行
平台访问只补充当前任务缺失的关键字段，并把不稳定页面拆成可定位、可有限重试的执行阶段。
Playwright persistent login
Search / Detail / Ready / Write retry
Failure isolation
QR pipeline for profile link only
数据层
字段在进入长期资产前先完成标准化和质量检测，再由 Cache Policy 决定复用或平台补充。
Data Pipeline Architecture
Creator Repository
Supabase-first
JSON fallback
Cache-first Architecture
辅助判断与交付
数据交付、历史回填和辅助判断都使用可解释规则，保护原模板与已有优质数据。
ExcelJS header parsing / field aliases
Safe backfill / invalid recovery
Rule tags / score / ranking / recommendation
Excel / CSV export
当前自动化工作流
达人库优先，平台访问只补充缺失数据。
- 01解析名单与业务模板
读取达人名单、字段别名和双层 Header，确认当前任务真正需要的列。
- 02Cache First 查询
按 Hard / Soft Required 检查 Repository 是否满足当前交付。
- 03平台补充缺失数据
缓存不足时才复用登录态访问淘宝光合，并对关键阶段有限重试。
- 04标准化与质量检测
统一字段 Schema，拦截空值、串位和已识别污染指标。
- 05写入长期资产
通过 Repository 写入 Supabase Talent Database，并保留 JSON fallback。
- 06输出与任务反馈
按原业务模板回填，展示进度、耗时、成功、失败和原因。
- 07复用与辅助分析
历史资产继续支持搜索、筛选、标签、导出、推荐和 AI 分析基础。
产品证据
截图展示当前工作台，而不是用真实业务名单做证明。
当前公开证据包含 5 张使用完全虚构数据的 Workbench 截图。业务指标使用已确认近似值；截图不展示真实达人、客户名单、联系方式或平台登录态。
AI 与辅助决策
从数据沉淀继续走向辅助判断。
当前代码已经实现自动规则标签、指标评分、排名和推荐；生成式 AI 标签仍属于下一阶段，并且必须由运营确认。
自动标签
当前能力根据平台等级、商业指数、种草、成交、曝光和更新频率生成透明标签。
这是确定性规则，不是大模型生成。
评分与排名
当前能力围绕商业指数、种草人数和成交人数进行归一化比较，支持不同业务目标排序。
权重可解释，不宣称预测投放结果。
推荐
当前能力按种草、成交和综合目标输出 TOP10，并给出基于指标与标签的推荐理由。
推荐用于缩小候选范围，最终提报仍由运营判断。
AI 语义标签
下一阶段未来可根据简介、类目和内容信息辅助生成更丰富的人设与内容标签。
AI 结果必须经过人工确认，不能直接覆盖人工字段。
业务影响
指标说明真实变化，也保留估算边界。
约 30 人使用过工具或从流程中受益；单名达人从约 10 分钟人工处理降到平均约 2 分钟人工介入，人工处理时间下降约 80%，并显著释放了原本每人一次批量任务约 3 小时的重复劳动。更长期的价值是把一次性采集结果转成可持续复用的 Creator Repository，以 Cache First 减少重复平台访问。以上指标均为真实业务流程中的近似值，不作为严格实验结论。
单名达人约 10 分钟人工查找与回填
自动化后平均人工介入约 2 分钟
每人一次批量任务原约 3 小时重复处理
固定流程自动执行，人工主要处理登录、异常和结果确认
任务结果停留在单次 Excel
数据进入可搜索、可筛选、可打标签、可导出并支持推荐与 AI 分析的长期达人资产
每个新项目重新访问平台采集已有达人
先按当前任务查询 Repository，只对缺失的关键字段进行受控补充
约 30 名同事使用过该工具或从改造后的达人提报流程中受益。
单条任务人工处理时间约下降 80%，但仍保留登录、异常和最终判断的人工责任。
原本每人一次批量任务约 3 小时的重复劳动得到显著释放。
项目从自动化回填演进为由 Data Pipeline、Creator Repository、数据质量和辅助分析组成的达人数据采集与资产管理系统。
限制、反思与下一步
从真实流程继续，而不是把规划写成完成。
仍然存在的限制
约 30 人、10 分钟到 2 分钟、约 80% 和约 3 小时均来自真实流程中的近似记录，不是严格对照实验，也不外推年度节省。
当前标签、评分、排名与推荐主要基于透明规则，不是机器学习模型。
生成式 AI 人设 / 内容标签仍属于下一阶段，并且必须经过人工确认。
Cache First 不代表永不访问平台；未命中或当前任务的 Hard Required 字段不足时仍需受控补充。
历史污染恢复只处理已识别候选，不会自动修复所有历史数据。
淘宝光合采集依赖本地登录态，也会受到平台风控和页面结构变化影响。
公开截图使用完全虚构的演示达人，不包含真实业务名单和私人数据。