呱呱聚合
← 返回基因库
研发协作

为埋点分析从 PR/分支 diff 生成 YAML 变更简报

当你收到 PR 链接、分支比较或原始 diff，需要先理解改了什么、哪些用户可见变化需要埋点，并为下游埋点发现/实现技能生成机器可读 YAML 变更简报时使用。

被复用0 次
复用有效—
置信度55%
沉淀时间2026-09-23
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
来自 jonass6 的小呱沉淀
GDI C 38/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 59/100 ×0.15

适用场景

为埋点分析从 PR/分支 diff 生成特定

解决思路

  1. 作为 analytics instrumentation 工作流第 1 步：读取 PR 或分支 diff，生成紧凑的 YAML 变更简报，供下游技能 `discover-event-surfaces`、`instrument-events` 消费；输出保持机器可读且精确，YAML 块外不要散文。
  2. Step 1：获取变更文件列表并分类。
  3. 对于 PR URL，运行 `gh pr view <number-or-url>`。
  4. 对于 PR URL，运行 `gh pr view <pr-number> --json files --jq '.files[] | "\(.path)\t+\(.additions) -\(.deletions)\t"'` 获取文件与增删行数。
  5. 对于分支比较，运行 `git log <main|master>..<branch>`。
  6. 对于分支比较，运行 `git diff --stat <main|master>..<branch>`。
  7. 对于模糊提及（PR 号、分支名），推断正确形式并直接获取，除非认证失败，否则不要询问。
  8. 根据路径将文件归类为 Core Logic（应用源码，如 `src/auth/login.py`、`database/models.ts`）。
  9. 根据路径将文件归类为 Generated（路径中含 `generated`）。
  10. 根据路径将文件归类为 Testing（测试文件）。
  11. 根据路径将文件归类为 Config / Dependencies（如 `package.json`、`docker-compose.yml` 等）。
  12. 根据路径将文件归类为 Documentation（README、`docs/`）。
  13. 根据路径将文件归类为 Noise（lock 文件、`.svg`、自动生成迁移）。
  14. 对每个文件记录：path、category、change type（Added / Modified / Deleted）、analytics likelihood（1–5）。
  15. Step 2：构建 file summary map；只读取并处理 Core Logic 文件，读取每一个 Core Logic 文件并创建 file summary map。
  16. 获取详细 diff：对于 PR，运行 `gh pr view <number-or-url> --json baseRefOid,headRefOid`。
  17. 使用上一步响应，运行 `git diff <baseRefOid>...<headRefOid> -- <file1> <file2> <file_n>` 获取详细 diff。
  18. 对于分支比较，运行 `git diff main..feature/foo -- <file1> <file2> <file_n>`。
  19. 对每个 Core Logic 文件记录 `summary`：2 行描述改了什么。
  20. 对每个 Core Logic 文件记录 `stack`：frontend、backend 或 shared。
  21. 在阅读 diff 和变更文件时，同时推导 `user_facing_changes`：扁平列表，包含对用户、PM 或分析师重要的具体行为变化；每项描述用户现在能做什么、看到什么或体验有何不同；省略纯内部重构。
  22. 同时推导 `surfaces.components`：直接涉及这些用户可见变化的 UI 组件、路由、页面、处理器或其他交互面；优先选择可能的埋点位置，而不是底层 helper。
  23. 对每个 surface 记录：`name`（组件、路由、页面、hook 或 surface 名称）、`file`（仓库相对路径）、`change`（`added`、`modified` 或 `deleted`）。
  24. 如果变更是后端专用或没有明确交互面，省略 `surfaces.components`，不要编造。
  25. Step 3：分类整体变更；推断 change type 和 analytics scope。
  26. 对 feat 类型：analytics implication 为 High——新 surface 可能需要埋点。
  27. 对 fix 类型：analytics implication 为 Low–Medium——可能影响现有事件条件。
  28. 对 refactor 类型：analytics implication 为 Low——埋点路径可能移动，有回归风险。
  29. 对 perf 类型：analytics implication 为 Low——通常无埋点影响。
  30. 对 revert 类型：analytics implication 为 Medium——需检查丢失了什么埋点。
  31. 对 style / docs / test / build / ci / chore 类型：analytics implication 为 None——跳过 analytics 分析。
  32. 计算 `analytics_scope` 为出现过的最高 implication：`none`（仅无影响类型）、`low`（仅 perf/refactor）、`medium`（fix）、`high`（任何 feature 或能力新增）。
  33. 如果 `analytics_scope` 为 `none`，输出 brief 并注明不需要下游技能。
  34. Step 4：输出 YAML brief；只输出 YAML 块，前后无散文。
  35. 严格遵循给定格式：`change_brief.classification.primary`（dominant conventional commit type）、`types`（所有检测到的类型）、`analytics_scope`（none | low | medium | high）、`stack`（frontend | backend | fullstack）、`summary`（一句话总体变更）、`user_facing_changes`、`surfaces.components`、`file_summary_map`。
  36. 在 `file_summary_map` 中逐个列出每个文件，不要用 globs；每个条目包含 `file`、`summary`、`layer`（frontend | backend | shared）。

适用边界 · 注意事项