有 change_brief…

拿到 diff-intake 产出的 change_brief YAML 后，生成一份可供 PM 评审的完整候选分析事件清单。

适用场景

解决思路

1. 解析 change_brief：读取 classification.analytics_scope（若为 none 则停止并告知用户无可埋点内容）、summary、user_facing_changes（主要信号，每条代表用户新能做或看到不同的东西）、surfaces.components（被修改的 UI 组件，交互发生处）、file_summary_map（读取 surfaces 中或涉及用户可见逻辑的文件摘要，跳过测试/配置/工具文件）。
2. 生成事件前先扫描代码库并映射用户流程：完整阅读 surfaces.components 中列出的每个文件；阅读 file_summary_map 中涉及用户可见逻辑的文件（跳过测试、配置、工具）；沿 import 和引用向外追踪一层——若组件调用 hook、API 函数或跳转到其他路由，也读取目标文件，以发现 diff 未触及但属于同一流程的步骤。
3. 追踪用户从进入到结果的路径，重点查找：入口点（路由定义、导航调用、菜单项、链接、feature flag 开关）；交互序列（表单填写、选择、确认、上传，查看 onClick/onSubmit/onChange 等 handler 接线及其修改的状态）；异步边界（API 调用、mutation、server action，即“尝试”变为“成功”或“失败”之处）；终态（成功确认、错误处理、重定向、完成页）；分支路径（将用户导向不同结果的条件判断，如免费 vs 付费、首次 vs 回访）。
4. 产出漏斗假设：综合发现形成一条或多条漏斗——从入口到结果的用户步骤有序序列。每条漏斗需有描述性名称（如“Property extraction flow”“Onboarding wizard”）、有序步骤（每步标注所在文件与函数/handler）、明确的起点步骤与终点步骤。并非所有改动都有漏斗：单动作功能（开关、一键导出）无需漏斗，只需注明没有多步流程。假设必须基于实际读过的代码，不要臆造没有证据的步骤。
5. 调用 discover-analytics-patterns 并采用其输出的 event_naming_convention 和 property_naming_convention；命名解析流程与优先级由该技能负责，不要在此重新定义。
6. 拉取项目现有事件分类法以避免重复并匹配既有命名：若 change_brief 含 Amplitude projectId 则直接使用，否则调用 get_amplitude_context 解析项目名或询问用户目标项目；用解析出的 projectId 调用已连接目录的当前分类法事件读取器，仅遵循其声明的 schema；若支持调用方归属，用本技能 YAML frontmatter 中的 name 标识自己；无需 cursor，第一页足够做模式检测；若 schema 支持字段选择，请求事件名、分类、描述字段，并使用返回的字段名。
7. 构建命名参考与现有事件索引：将所有 eventType 值收集为一个集合，用于第 4 步去重。判断重复看语义是否匹配而非字符串完全一致——例如已存在 Subscription Upgraded，就不要再为同一动作提议 Plan Upgraded。
8. 从漏斗假设出发生成候选事件：若第 2 步识别出漏斗，先为漏斗起点和终点生成事件（作为锚点），再补充中间步骤和非漏斗界面的候选。对每个 user_facing_change 自问：“如果用户做了这件事，PM 会想了解哪些结果？”按四类优先级生成：business_outcome（收入、留存、增长动作，如购买、订阅变更、转化门槛——改动触及变现或留存界面时纳入）；user_journey（有意义的状态迁移，如工作流完成、功能激活、引导完成——改动引入或改变用户旅程步骤时纳入）；feature_success（“成功了”的时刻，是确认的结果而非按钮点击，如文档已创建、报告已生成——任何新增或实质变更的功能）；friction_failure（用户失败、卡住或放弃之处，如错误、空状态、流失——复杂多步交互或易错流程）。
9. 对现有事件去重：逐一检查候选与第 3 步构建的现有事件索引。完全匹配（eventType 已逐字存在）则丢弃；语义匹配（不同名称追踪同一用户动作或结果，如你提议 Plan Upgraded 但 Subscription Upgraded 已存在）则丢弃；部分重叠（现有事件覆盖更广、包含你的候选，如 Checkout Completed 已存在而你的候选 Payment Submitted 在同一时刻触发）则丢弃，除非候选承载明显不同的信息。因已存在而丢弃的候选，在输出的 already_tracked 列表中记录，让用户看到已覆盖内容。
10. 质量过滤：每个候选必须同时通过三项——决策有用（PM 仅凭此事件无需五个其他事件辅助即可做出产品决策）；结果导向（捕捉某事“发生了”而非用户“尝试了”，Property Extracted 优于 Extract Button Clicked，优先确认的结果，无服务端确认时表单提交可接受）；跨改版稳定（围绕业务/产品概念命名而非 UI 元素，若重命名一个弹窗就会让事件名过时，说明耦合过紧）。剔除：无结果的原始点击/悬停、内部技术动作（API 回调、状态更新）、带 UI 版本号的名称（modal_v2_submit）、子步骤级粒度。
11. 命名事件：使用 discover-analytics-patterns 返回的命名约定，新事件应与现有埋点风格一致——相同大小写、相同词序、相同分隔符、相同前缀模式、相同具体程度。若后续在 rationale 或 instrumentation 提示中需要建议属性名，使用 discover-analytics-patterns 返回的 property_naming_convention。始终使用产品领域主语（Property、User、Document），而非代码名（PropertyItem、ActionStore）。
12. 为每个候选确定文件与埋点位置：用 file_summary_map 和 surfaces.components 确定 file（埋点调用所属源文件，优先选最接近结果确认处而非用户发起动作处的文件，通常是 surfaces.components 中的组件文件或异步操作 resolve 的 hook）与 instrumentation（1-2 句说明何时触发——在什么条件/回调/状态迁移之后，以及如何接线——放在哪个函数/handler 中，引用文件摘要中的真实函数名以便工程师定位到具体行）。
13. 为每个候选先填写两个字段以具体思考事件价值：analysis_recipe（描述分析师会用此事件构建的具体图表、漏斗或查询，要具体到可视化类型、细分维度以及需结合的其他事件，如“每周漏斗：Panel Opened → Extract Type Selected → Property Extracted，按 extractType 细分，完成率低于 50% 时告警”）；stakeholder_narrative（写一句 PM 可直接放进季度评审或董事会材料的话，用该事件数据，想象指标已存在并写出它讲述的故事，如“尝试提取的用户中 68% 首次即完成，上季度为 45%”；若想不出有说服力的幻灯片句子，该事件可能不值得埋点）。
14. 在以上上下文新鲜时分配 priority：3（critical，缺失会阻塞发布，回答团队第一周必然会问的问题，仅用于直接衡量功能成败的事件，多数改动只产生 1-2 个 critical 事件）；2（useful，有真实分析价值但功能可无它上线，埋点成本低时值得加，如细分维度、次要工作流、配置选择）；1（optional，锦上添花，仅在团队有余力且有具体假设待验证时埋点，如边缘失败、探索性参与信号、可发现性指标）。
15. 漏斗事件需特别关注：当改动引入或修改多步流程（结账流、引导向导、数据导入管道）时，PM 的第一个问题会是“用户在哪里流失？”漏斗起点与终点之间没有可见性会形成盲区，可能掩盖严重产品问题——若 5 步中第 2 步参与度暴跌，团队需要知道而非猜测。
16. 漏斗起点和终点事件始终为 critical（priority 3）：没有这对书挡就无法衡量转化率——任何漏斗最重要的指标。无论漏斗长短或复杂程度，这两个事件不可省略。
17. 判断中间漏斗事件标为 critical 的数量需衡量漏斗长度与复杂度：短流程（2-3 步、单页）起点和终点事件足够，不要为简单流程埋点每个微步骤；中等流程（3-5 步、可能跨页）在最可能的流失点加一个中间事件——通常是用户投入精力处（填表、做关键选择、上传文件）；长流程（5+ 步、多页或向导式）在自然阶段边界加 2-3 个中间事件，思路是“started → configured → submitted → confirmed”而非追踪每个字段交互。
18. 对中间事件保持克制：每个标为 critical 的漏斗事件都意味着工程师要多实现一项、PM 要多监控一项。若不确定某个中间步骤是否值得追踪，它多半不值得——起点和终点事件会揭示是否存在问题，团队可在看到流失集中处后再补充粒度。少即是多：一组真正被做成仪表盘的聚焦 critical 事件胜过无人查看的庞杂清单。存疑时降级——事后加事件比移除已进入仪表盘的事件更容易。
19. 输出 YAML：只输出 YAML 块，不要周围文字。结构包含 event_candidates，其下 source_summary（取自 change_brief.summary）、analytics_scope（取自 change_brief.classification.analytics_scope）、event_naming_convention 与 property_naming_convention（优先 MCP，其次代码库埋点，最后 taxonomy 技能）；already_tracked（无重复时省略，含 existing_event、candidate_dropped、reason）；funnels（无多步流程时省略，含 name 与 steps，每步含 step、file、function、role 为 start|intermediate|end）；candidates 列表，每项含 name、category（business_outcome|user_journey|feature_success|friction_failure）、rationale、analysis_recipe、stakeholder_narrative、priority（3|2|1）、funnel（所属漏斗名，如有）、funnel_role（start|intermediate|end，非漏斗成员省略）、surface（取自 surfaces.components）、file、instrumentation。排序：更高类别在前，同类别内影响最大者在前。

适用边界 · 注意事项

• change_brief 的 classification.analytics_scope 为 none 时——没有可埋点内容，应停止并告知用户。
• 改动不涉及用户可见逻辑（纯测试、配置、工具类文件）时，不适合生成候选事件。
• 单动作功能（开关、一键导出）没有多步流程，不要强行编造漏斗或中间事件。