埋点验收Chrome插件在业务页面内回显埋点上报列表的界面示意。
设计自驱Vibe Coding端到端交付企业内部提效

埋点验收Chrome插件

即插即用的一站式H5埋点验收工具,让设计/产品在原页面快速、完整地验证埋点和参数上报,避免流程门槛导致的验收疏漏, 提升验收效率, 同时减少AB实验重跑

产品/设计参与内测

30+

次均埋点验收时长

-57.2%

时间
2026/02-2026/03
团队构成
设计&开发&测试(我)
我的角色
需求定义, 用户/技术调研, UX设计, AI协作开发测试
AI栈
Codex(GPT-5.2), Google AI Studio(Gemini 3 pro)

为谁, 解决什么问题?

为 做AB实验的产品/设计 降低埋点验证流程成本和犯错风险

埋点验证是AB实验上线的强制前置条件,但现有验证流程存在问题如下

三轮反复验证, 极其耗时

测试、预发、生产三套环境均需重复验证,时间成本高,实际执行中容易被压缩或跳过

现有工具的四重门槛

  • 查询特定账号, 尤其是QA专用构造数据的账号, 需申请权限
  • 需提前获取Page SN和UID才能查询
  • 验证页、查询列表、参数详情三级跳转割裂操作流
  • 数据经常存在延迟

为什么要现在解决?

团队对埋点验证效率和准确性要求剧增

团队AB实验量急剧增加,短期内已发生2次因埋点疏漏导致的实验重启,项目周期延长半个月~1个月,问题到了不可忽视的阈值

STEP 1在待验收页面打开DevTools获取Page SN和UID
DevTools 中获取 Page SN 和 UID 的截图。
STEP 2在YOLO(拼多多大数据平台)输入Page SN和UID
YOLO 平台输入 Page SN 和 UID 的截图。
STEP 3到待验收页面触发埋点 如: 点击/ 曝光目标埋点的热区
在待验收页面触发目标埋点的截图。
STEP 4回到YOLO上点击“查询”,确认列表是否有目标埋点, 触发时间/次数是否符合预期
在 YOLO 查询并检查目标埋点列表的截图。
STEP 5如埋点正确, 打开参数详情页看参数是否正确
打开参数详情页检查参数是否正确的截图。

效果

产品/设计参与内测

30+

覆盖商家端核心设计和产品团队

次均埋点验收时长

-57.2%

统计自用户调研问卷数据

因埋点验证出错而重跑实验

0

26年1季度团队内有2个需求因此问题重跑实验

项目过程

1

痛点定义和方案选型

  • 梳理现有工具痛点,定义核心用户和使用场景
  • 咨询开发、协同AI完成技术选型调研,确认Chrome插件方案可行
2

Vibe Coding跑通MVP

以“实时捕获页面埋点上报并页面内即时回显”为目标跑核心流程,输出可演示demo

3

UX设计和代码实现

输出设计方案并将其转化为代码实现,以对齐内部设计规范

4

验收、调试和持续迭代

  • 搭建QA Agent,完成端到端回归验证
  • 30+用户小范围内测,收集真实反馈持续迭代
AI 协作调试场景 PIC,展示业务页面、DevTools 网络请求、Codex 标识和 ping 请求放大提示。

人机协作挑战

使用chrome.debugger全量监听埋点上报, 导致Chrome顶部常驻一条“XX扩展正在调试你的浏览器”的提示, 常驻所有tab且无法关闭, 用户体验非常差

查看详情

开发和QA在同一线程,导致QA subagent继承开发逻辑写用例。 典型案例:真实用户连续点击同一个按钮两次,两次payload完全一样, Codex默认去重,QA subagent按此逻辑输出了用例

查看详情
两次关键迭代对比图:After 默认展示当前页埋点上报列表,Before 以元素 SN 查询为默认页。

基于用户反馈的2次关键迭代

用户主场景是“触发后看新增上报”而非“带目标SN查询”,改为默认展示全部埋点上报,查询降为辅助路径

查看详情

兼容查询跨页埋点, 解决用户需要在A页面验证注册在B页面的埋点的问题

查看详情
埋点验证插件在业务流中的位置图,展示产品设计、BI、数仓、前端之间的埋点注册、审核、接入、验收和使用链路。

从个人工具到可靠的企业产品

定义产品责任边界: 在产品内阐明本工具只验证前端上报,不覆盖埋点注册环节, 不代表BI/报表侧能查到目标埋点

查看详情

严格验收和控制发布节奏保证数据可信度: E2E自动化测试验证工具采集数据准确性; 小范围内测, 收集问题并快速迭代

查看详情