产品运营诊断

解决的具体问题

在产品运营诊断中，最容易出现的问题不是“没有数据”，而是信息来自多个断点：用户路径、埋点、版本记录、访谈、客服和流失证据各自独立。团队据此讨论时，结论常停留在“体验不好”“留存下降”“新用户没激活”这类描述，既难定位首要问题，也难形成可复测的实验。该技能面向的就是这种“证据很多、优先级不清、实验无法闭环”的状态。

核心能力与关键步骤

技能先把输入闸门固定下来，至少需要产品阶段、业务目标和核心用户、用户路径、行为数据、埋点与版本记录、用户反馈、访谈、客服和流失证据。信息不足时，会明确区分“已确认事实、保守假设、待验证项和补证日期”，而不是把猜测写成结论；无法路由请求时，也只会追问一个关键问题。

执行时按固定顺序推进：读取 references/methodology.md，只选择与当前请求直接相关的方法卡；读取 references/execution-rules.md，确认输入、事实、假设和前置闸门；读取 references/quality-boundaries.md，排除不适用、无授权和不可交付动作；读取 references/output-contract.json 与 assets/output-template.md 生成执行件；最后运行 scripts/validate_output.py --check-output。校验失败时，会修正业务内容，而不是删除测试或放宽规则。

适用边界与注意点

交付物至少包含事实、假设、缺口和指标字典；用户路径、价值节点和问题树；激活、使用、留存或流失的优先实验；以及复测指标、研究任务和停止条件。它不承诺固定结果，不伪造案例、指标或行业基准；也不会输出采集身份、原始链接、作者、账号、API Key 或素材出处。机器校验通过只代表结构、具体度和已知风险通过，业务负责人仍需确认是否适配真实运营场景。