埋点skill使用与自动化

做埋点测试这件事，很多团队都熟悉流程，但真正做起来通常还是一套偏手工的路径：产品给一份埋点表，测试自己翻需求、自己找账号、自己连手机、自己点页面、自己等上报、自己去日志平台查，再把结果一条条复制回表格，最后给研发提 Bug。

这套方式能完成任务，但问题也很明显：

重复动作太多，执行成本高
同样的需求换一个版本，还要重新组织一遍流程
证据分散，复测时经常要重新拼背景
"查到日志"不等于"埋点通过"，多报、错报、串报很容易漏掉
Bug 虽然提了，但从首测失败到修复复测，闭环仍然依赖人工记忆

所以我把这套流程进一步沉淀成了 3 个 Skill，让埋点测试从一次次重复劳动，逐步变成一条可以复用的工程链路：

tracking-workbook-prepare：把原始埋点 CSV 整理成可直接执行测试的 XLSX
tracking-android-verify：执行 Android 埋点真机验证、日志查询、表格回写和缺陷提单
tracking-ios-verify：执行 iOS 埋点真机验证、日志查询、表格回写和缺陷提单

一、为什么要把埋点测试做成 Skill

埋点测试看起来只是"点一下页面，然后查一下日志"，但真正影响效率和质量的，不是这一个点击动作，而是背后几件事能不能被稳定串起来：

需求表是否已经整理成可执行形式
操作路径是否足够明确
真机执行时是否记录了准确时间窗
日志查询时是否绑定了设备、版本、事件和时间
结果判定是否做到了字段级校验
未通过是否可以直接生成结构化 Bug
修复后能不能按原上下文自动复测

如果这些环节全靠人脑和临时经验，测试越做越累，复测越做越散。

而 Skill 的价值，就在于把"每次都要重新组织一次"的流程，沉淀成稳定可复用的执行能力。

二、这 3 个埋点 Skill 分别解决什么问题

1. `tracking-workbook-prepare`

这个 Skill 解决的是埋点测试最前置的问题：原始需求表并不适合直接测试。

原始 CSV 往往只有埋点基础字段，例如：

页面名称
区块名称
元素名称
事件名
重要描述
版本开发需求记录相关列

但真正执行测试时还缺很多关键信息，比如：

实际操作路径怎么走
测试数据要准备什么
曝光/点击/浏览的判定口径是什么
哪些地方存在不确定项，需要提前确认

所以这个 Skill 会把原始 CSV 整理成一份测试可直接使用的整理版 Excel，并自动补出几类结构化信息：

操作路径/操作数据
补充操作路径
补充操作数据
定位/验证说明
需求/APP依据
疑问点/待确认
待确认清单

对应本地脚本：

bash 复制代码

python3 /Users/leiyuxing/.codex/skills/tracking-workbook-prepare/scripts/csv_to_tracking_workbook.py \
  --input /绝对路径/埋点列表_xxx.csv

2. `tracking-android-verify`

这个 Skill 解决的是 Android 真机埋点验证的闭环问题。

它的职责不是只帮忙"查一条日志"，而是负责把下面这些动作串起来：

连接 Android 手机
按整理版埋点表执行目标场景
记录触发动作和时间窗
查询埋点日志
判定通过/未通过
回写 安卓测试结果
回写完整 JSON
未通过按埋点编号拆分提 Bug

3. `tracking-ios-verify`

这个 Skill 和 Android 版本的职责类似，只是落在 iOS 设备验证上。

它保留了同样的核心约束：

不是只看有无日志
必须校验事件数量
必须校验关键字段
必须回写完整 JSON
必须按埋点编号单独提 Bug

这样 Android 和 iOS 的测试链路虽然设备不同，但方法论和结果口径是一致的。

三、Skill 化之前，埋点测试最耗时间的地方在哪

真正做过版本埋点验收的人，通常都知道最耗时间的不只是点页面，而是中间的上下文搬运。

典型场景是这样的：

先从埋点需求表里找这一条是测什么
再判断它是 Android 还是 iOS，还是都要测
再找对应账号
再进 App 找入口
再确定这次操作具体发生在几点几分几秒
再去日志里拼查询条件
查到了还要继续判断是不是本次操作产生的
最后再把结果抄回 Excel，复制 JSON，提 Bug

这里面真正"有效验证"的时间其实不多，大量时间都花在：

理解需求
组织步骤
切换工具
复制证据
补全说明

Skill 的价值，不是神奇地替代测试判断，而是把这些高频、重复、容易出错的动作先收拢成稳定流程。

四、埋点 Skill 的整体工作流

下面这张图更适合用来理解这套 Skill 化方案的全貌。

从执行角度看，整体工作流可以概括成下面这条链：
#mermaid-svg-gV0vCIiyk0MAlb7K{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-gV0vCIiyk0MAlb7K .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-gV0vCIiyk0MAlb7K .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-gV0vCIiyk0MAlb7K .error-icon{fill:#552222;}#mermaid-svg-gV0vCIiyk0MAlb7K .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-gV0vCIiyk0MAlb7K .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-gV0vCIiyk0MAlb7K .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-gV0vCIiyk0MAlb7K .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-gV0vCIiyk0MAlb7K .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-gV0vCIiyk0MAlb7K .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-gV0vCIiyk0MAlb7K .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-gV0vCIiyk0MAlb7K .marker{fill:#333333;stroke:#333333;}#mermaid-svg-gV0vCIiyk0MAlb7K .marker.cross{stroke:#333333;}#mermaid-svg-gV0vCIiyk0MAlb7K svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-gV0vCIiyk0MAlb7K p{margin:0;}#mermaid-svg-gV0vCIiyk0MAlb7K .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-gV0vCIiyk0MAlb7K .cluster-label text{fill:#333;}#mermaid-svg-gV0vCIiyk0MAlb7K .cluster-label span{color:#333;}#mermaid-svg-gV0vCIiyk0MAlb7K .cluster-label span p{background-color:transparent;}#mermaid-svg-gV0vCIiyk0MAlb7K .label text,#mermaid-svg-gV0vCIiyk0MAlb7K span{fill:#333;color:#333;}#mermaid-svg-gV0vCIiyk0MAlb7K .node rect,#mermaid-svg-gV0vCIiyk0MAlb7K .node circle,#mermaid-svg-gV0vCIiyk0MAlb7K .node ellipse,#mermaid-svg-gV0vCIiyk0MAlb7K .node polygon,#mermaid-svg-gV0vCIiyk0MAlb7K .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-gV0vCIiyk0MAlb7K .rough-node .label text,#mermaid-svg-gV0vCIiyk0MAlb7K .node .label text,#mermaid-svg-gV0vCIiyk0MAlb7K .image-shape .label,#mermaid-svg-gV0vCIiyk0MAlb7K .icon-shape .label{text-anchor:middle;}#mermaid-svg-gV0vCIiyk0MAlb7K .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-gV0vCIiyk0MAlb7K .rough-node .label,#mermaid-svg-gV0vCIiyk0MAlb7K .node .label,#mermaid-svg-gV0vCIiyk0MAlb7K .image-shape .label,#mermaid-svg-gV0vCIiyk0MAlb7K .icon-shape .label{text-align:center;}#mermaid-svg-gV0vCIiyk0MAlb7K .node.clickable{cursor:pointer;}#mermaid-svg-gV0vCIiyk0MAlb7K .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-gV0vCIiyk0MAlb7K .arrowheadPath{fill:#333333;}#mermaid-svg-gV0vCIiyk0MAlb7K .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-gV0vCIiyk0MAlb7K .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-gV0vCIiyk0MAlb7K .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-gV0vCIiyk0MAlb7K .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-gV0vCIiyk0MAlb7K .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-gV0vCIiyk0MAlb7K .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-gV0vCIiyk0MAlb7K .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-gV0vCIiyk0MAlb7K .cluster text{fill:#333;}#mermaid-svg-gV0vCIiyk0MAlb7K .cluster span{color:#333;}#mermaid-svg-gV0vCIiyk0MAlb7K div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-gV0vCIiyk0MAlb7K .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-gV0vCIiyk0MAlb7K rect.text{fill:none;stroke-width:0;}#mermaid-svg-gV0vCIiyk0MAlb7K .icon-shape,#mermaid-svg-gV0vCIiyk0MAlb7K .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-gV0vCIiyk0MAlb7K .icon-shape p,#mermaid-svg-gV0vCIiyk0MAlb7K .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-gV0vCIiyk0MAlb7K .icon-shape .label rect,#mermaid-svg-gV0vCIiyk0MAlb7K .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-gV0vCIiyk0MAlb7K .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-gV0vCIiyk0MAlb7K .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-gV0vCIiyk0MAlb7K :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 原始埋点 CSV
tracking-workbook-prepare
整理版 XLSX
tracking-android-verify / tracking-ios-verify
真机执行
日志查询
字段判定
回写结果与完整 JSON
按埋点编号提 Bug
修复后自动复测

这条链路的关键不是某一环多复杂，而是每一环之间的输入输出被固定住了。

例如：

tracking-workbook-prepare 的输出不是一张"更好看"的表，而是一张后续 Skill 可以稳定消费的执行表
tracking-android-verify / tracking-ios-verify 的输出不是一句"通过"，而是结构化测试结果 + 完整 JSON + 缺陷材料
修复后的复测也不需要重新组织背景，而是可以回到原埋点编号、原页面路径、原查询规则继续验证

五、第一步：为什么要先整理 Workbook

很多埋点测试失败，并不是因为 App 上报错了，而是测试前置信息根本不够。

这张图可以直接说明整理版工作簿的作用：

Skill 化之后，整理版表不再只是"记录需求"，而是同时承担三件事：

执行入口
- 每一条埋点都能直接看到操作路径、操作数据和验证说明
结果载体
- Android / iOS 结果回写在固定列
- 完整 JSON 回写在固定列
问题上下文
- 哪些字段需要重点看
- 哪些地方还存在待确认项
- 哪些行需要补充业务样例

这一步做得越扎实，后面的真机验证越稳定。

因为测试不再是在"解释需求"，而是在"执行需求"。

六、第二步：Android / iOS 真机验证为什么适合做成 Skill

埋点测试和普通 UI 测试有一个很大的不同：

它不是只验证页面行为，而是同时验证"页面行为 + 日志上报 + 字段口径"。

所以一个合格的真机埋点 Skill，至少要同时处理 4 层问题：

设备层
- 手机是否在线
- 版本是否正确
- 登录态是否正确
场景层
- 入口路径是否准确
- 测试数据是否存在
- 按钮、卡片、筛选器是否可见
日志层
- 事件是否上报
- 是否命中本次时间窗
- 是否是本机、本版本产生的日志
判定层
- 是否多报
- 是否少报
- 是否错报
- 是否串报

对应的真机执行流可以理解成这样：

七、Skill 在自动化里的真正应用，不是"自动点击"，而是"自动组织闭环"

很多人一提自动化，第一反应是点击、输入、滑动。

但埋点场景里，自动化最有价值的地方往往不是这几个动作本身，而是把它们和日志证据、表格回写、缺陷流转连起来。

更准确地说，这套 Skill 化方案把自动化应用到了 5 个层面：

1. 需求整理自动化

原始埋点表转整理版，不再完全靠手工补充。

2. 真机执行标准化

不再每条埋点都从头想"这次怎么测"，而是优先按整理版给出的路径执行。

3. 日志查询自动化

用本地查询脚本把：

EID
设备
版本
时间窗

组合成稳定查询条件。

4. 字段级判定自动化

把"看起来像通过"升级成"字段、数量、时间窗都符合预期才算通过"。

5. 缺陷闭环自动化

未通过项不只是标红，而是继续进入：

结果回写
结构化描述
Yunxiao 提单
修复后复测

这个阶段最能体现 Skill 的工程价值。
#mermaid-svg-mddDyJijxgJ6GEl3{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-mddDyJijxgJ6GEl3 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-mddDyJijxgJ6GEl3 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-mddDyJijxgJ6GEl3 .error-icon{fill:#552222;}#mermaid-svg-mddDyJijxgJ6GEl3 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-mddDyJijxgJ6GEl3 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-mddDyJijxgJ6GEl3 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-mddDyJijxgJ6GEl3 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-mddDyJijxgJ6GEl3 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-mddDyJijxgJ6GEl3 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-mddDyJijxgJ6GEl3 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-mddDyJijxgJ6GEl3 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-mddDyJijxgJ6GEl3 .marker.cross{stroke:#333333;}#mermaid-svg-mddDyJijxgJ6GEl3 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-mddDyJijxgJ6GEl3 p{margin:0;}#mermaid-svg-mddDyJijxgJ6GEl3 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-mddDyJijxgJ6GEl3 .cluster-label text{fill:#333;}#mermaid-svg-mddDyJijxgJ6GEl3 .cluster-label span{color:#333;}#mermaid-svg-mddDyJijxgJ6GEl3 .cluster-label span p{background-color:transparent;}#mermaid-svg-mddDyJijxgJ6GEl3 .label text,#mermaid-svg-mddDyJijxgJ6GEl3 span{fill:#333;color:#333;}#mermaid-svg-mddDyJijxgJ6GEl3 .node rect,#mermaid-svg-mddDyJijxgJ6GEl3 .node circle,#mermaid-svg-mddDyJijxgJ6GEl3 .node ellipse,#mermaid-svg-mddDyJijxgJ6GEl3 .node polygon,#mermaid-svg-mddDyJijxgJ6GEl3 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-mddDyJijxgJ6GEl3 .rough-node .label text,#mermaid-svg-mddDyJijxgJ6GEl3 .node .label text,#mermaid-svg-mddDyJijxgJ6GEl3 .image-shape .label,#mermaid-svg-mddDyJijxgJ6GEl3 .icon-shape .label{text-anchor:middle;}#mermaid-svg-mddDyJijxgJ6GEl3 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-mddDyJijxgJ6GEl3 .rough-node .label,#mermaid-svg-mddDyJijxgJ6GEl3 .node .label,#mermaid-svg-mddDyJijxgJ6GEl3 .image-shape .label,#mermaid-svg-mddDyJijxgJ6GEl3 .icon-shape .label{text-align:center;}#mermaid-svg-mddDyJijxgJ6GEl3 .node.clickable{cursor:pointer;}#mermaid-svg-mddDyJijxgJ6GEl3 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-mddDyJijxgJ6GEl3 .arrowheadPath{fill:#333333;}#mermaid-svg-mddDyJijxgJ6GEl3 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-mddDyJijxgJ6GEl3 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-mddDyJijxgJ6GEl3 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-mddDyJijxgJ6GEl3 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-mddDyJijxgJ6GEl3 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-mddDyJijxgJ6GEl3 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-mddDyJijxgJ6GEl3 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-mddDyJijxgJ6GEl3 .cluster text{fill:#333;}#mermaid-svg-mddDyJijxgJ6GEl3 .cluster span{color:#333;}#mermaid-svg-mddDyJijxgJ6GEl3 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-mddDyJijxgJ6GEl3 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-mddDyJijxgJ6GEl3 rect.text{fill:none;stroke-width:0;}#mermaid-svg-mddDyJijxgJ6GEl3 .icon-shape,#mermaid-svg-mddDyJijxgJ6GEl3 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-mddDyJijxgJ6GEl3 .icon-shape p,#mermaid-svg-mddDyJijxgJ6GEl3 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-mddDyJijxgJ6GEl3 .icon-shape .label rect,#mermaid-svg-mddDyJijxgJ6GEl3 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-mddDyJijxgJ6GEl3 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-mddDyJijxgJ6GEl3 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-mddDyJijxgJ6GEl3 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 否
是
否
是
否
是
真机操作完成
查询到日志?
未上报
数量是否正确?
重复上报/少报
字段是否匹配?
字段错误/串报
判定通过
回写完整 JSON 与问题描述
按埋点编号提 Bug
回写通过结果与完整 JSON

八、为什么"完整 JSON 回写"必须是硬规则

这件事在埋点测试里特别重要。

如果表里只写一句"通过"或者"未通过"，后面会有几个问题：

研发看不到具体上报内容
产品没法复核字段是否和需求一致
复测时测试自己也要重新查一次日志
需求变更后无法回头核对历史口径

而把完整 JSON 固定回写到 版本开发需求记录.黏贴json 之后，价值会非常直接：

通过项也能复核
- 不是只有失败才留证据
失败项更容易归因
- 是没报、错报、多报，还是字段错，一眼能看出来
复测上下文可复用
- 下次不是重新查，而是拿历史 JSON 对照

这张图能更直观地说明日志查询和字段核对的关系：

九、为什么 Android / iOS 两个 Skill 要拆开

这不是为了"多建一个 Skill"，而是为了把平台差异隔离开。

虽然两边的业务需求和字段口径是一套，但实际执行时差异很明显：

设备连接方式不同
自动化工具链不同
页面元素定位策略不同
日志触发时机偶尔也会不同

如果把 Android 和 iOS 混成一个 Skill，最终往往会出现两种问题：

说明越来越长，真正执行时反而不清晰
平台差异和公共规则混在一起，不利于维护

拆成两个 Skill 后，公共规则保持一致：

完整 JSON 必须回写
点击一次上报两次算 bug
Bug 必须按埋点编号拆开
查询必须绑定时间窗和设备

而平台差异则留在各自 Skill 内部处理。这样更稳。

十、埋点 Skill 和 Appium / ADB / 查询脚本是什么关系

Skill 不是替代这些工具，而是把这些工具组织起来。

可以这么理解：

ADB / 真机操作工具
- 负责设备连接、基础操作、环境确认
Appium
- 负责复杂页面流程、元素定位、可见性确认
日志查询脚本
- 负责把埋点证据查出来
Skill
- 负责决定什么时候调用哪一个能力，以及最终如何落成闭环

下面这张图很适合理解 Appium 在这条链路里的位置：

所以从工程上看，Skill 更像一个"流程层"：

把自然语言需求转成执行路径
把执行路径转成日志查询条件
把日志结果转成表格结论和缺陷材料

十一、埋点 Skill 最适合解决哪些问题

这套 Skill 特别适合下面这些场景：

1. 版本新增埋点较多

每个版本都要从头整理和执行，重复度很高，Skill 化收益最大。

2. 多平台都要测

同一批埋点 Android / iOS 都要验证时，统一规则、拆分执行最合适。

3. 缺陷复测频繁

如果一个版本里埋点问题较多，后续反复复测时，Skill 能明显减少背景重建成本。

4. 字段归因容易争议

例如：

有日志但字段错
点击一次上报两次
页面名按 tab 动态拼接
from_nav / content_type 依赖页面上下文

这类问题只靠一句"未通过"很难推动修复，结构化 Skill 更适合。

十二、做成 Skill 之后，最大的变化是什么

最大的变化不是"测试更快了"这么简单，而是埋点测试终于有了稳定的工程结构。

以前更像这样：

需求在表里
操作在脑子里
证据在日志里
结论在聊天里
Bug 在 Yunxiao 里

现在更像这样：

需求先整理进可执行 Workbook
真机验证按 Skill 执行
日志证据回写回同一张表
未通过直接流向缺陷闭环
修复后继续按原上下文复测

对应闭环过程可以看这张图：

这意味着测试工作从"人肉搬运信息"逐渐转成"维护一条稳定流程"。

当流程一旦稳定下来，后续每个版本的边际成本都会继续下降。

十三、下一步还可以怎么继续演进

如果这套 Skill 继续往下做，我认为有几个方向很值得补：

1. 进一步补强待确认规则

让 tracking-workbook-prepare 不只是生成整理版，还能更聪明地区分：

可直接执行项
需要样例数据项
需要开发确认字段枚举项

2. 把复测触发再自动化

例如：

Yunxiao 状态变成"待复测"
自动回到原埋点编号
自动复用原时间窗策略和字段规则

3. 建立埋点结果看板

把：

通过率
未通过分布
多报/少报/错报类型
待复测积压量

做成版本级汇总视图，而不只是逐条表格记录。

4. 沉淀更多专项 Skill

比如再拆分成：

埋点复测 Skill
埋点 Bug 复核 Skill
埋点 JSON 差异对比 Skill
埋点需求口径校对 Skill

这样整条链会更细，也更稳定。

十四、结语

埋点测试本身并不新，但把埋点测试做成 Skill，会带来一个很实在的变化：

测试不再是"这次把任务做完"，而是"把这类任务沉淀成以后还能反复用的能力"。

这 3 个 Skill 的价值不在于名字，而在于它们把一条原本零散的链路固定了下来：

tracking-workbook-prepare 解决输入问题
tracking-android-verify 解决 Android 执行闭环
tracking-ios-verify 解决 iOS 执行闭环

真正有用的自动化，从来不是只会自动点页面，而是能把需求、执行、查询、判定、回写和缺陷流转真正串起来。

埋点 Skill 的意义，也正在这里。