技能介绍

要解决什么问题

很多团队上线功能时，分析埋点是「补票」、实验设计事后才补，结果要么读不懂用户行为，要么 A/B 结论不可信。数据科学家、业务分析师和工程各跑各的，功能开关、事件 schema 和管道往往对不齐，上线后才发现样本量不够或护栏指标被拖垮。

技能如何组织工作流

本技能把数据驱动功能开发拆成六个阶段，并在每个步骤里指定可用的专业子代理（如 machine-learning-ops::data-scientist、business-analytics::business-analyst、data-engineering::data-engineer 等），用 Task 工具按上下文串联：

假设与实验设计：探索性数据分析、ICE/RICE 等业务假设、功效分析与随机化/多重检验规划（含贝叶斯 A/B 可选路径）。
架构与数据面：带 LaunchDarkly/Split.io 等思路的功能开关与渐进发布、Segment/Amplitude 类事件 schema、Kafka/Kinesis 与数仓的管道设计。
实现与验证：后端/前端/可选 ML 推理的一体化埋点与实验分流，预发环境的数据质量与漏斗校验。
发布与决策：渐进放量、实时仪表板与护栏监控，频率派/贝叶斯结果解读、ROI 与后续实验计划。

扩展说明里强调：分析在实现阶段应作为一等需求，功能开关支持不完全部署下的安全实验，监控支持快速回滚。

适用边界与注意点

适合：你要为具体功能 $ARGUMENTS 走完整「数据 → 假设 → 埋点 → 实验 → 决策」链路，或需要可执行的检查清单与最佳实践时。
不适合：任务与数据驱动功能开发无关，或你需要的是本范围外的单一领域深度（例如只做离线 ETL、不做产品实验）。
协调预期：数据科学家与业务分析师在假设阶段需对齐；成功标准包括事件覆盖、随机化有效性、统计严谨性、护栏指标与 p95/错误率等工程约束——文档中的具体阈值应结合你们环境再校准。更细的示例见技能内的 resources/implementation-playbook.md。