why

关于 why skill 的概览

why skill 是一个聚焦的 Five Whys 分析工具，作用是把表面症状拆成根因链，再进一步转化为你可以实际执行的修复方案。如果你在做 why skill 的 UX Audit、产品问题排查、bug 分析或流程中断复盘，它能帮助你区分“发生了什么”和“为什么会发生”。

why 是用来做什么的

当第一层解释很可能过于浅显时，就该用 why：比如“用户流失了”“构建失败了”或“团队错过了截止时间”。这个 skill 的设计目标，是持续推进分析，直到找到系统性原因，而不只是停留在可见症状上。

适合哪些人读

这份 why 指南最适合运营、分析、工程和 UX 评审人员。它适合那些想要一条结构化的根因路径、但又不想从零搭建一套框架的人。前提是你已经有明确的问题陈述，并且需要一种有纪律的方法去追问它。

为什么它有用

它最大的价值在于节奏和聚焦：提供可复用的提问结构、默认分析深度，以及验证步骤，方便你测试某个原因是否真的能解释症状。当你发现通用头脑风暴总是在同一个显而易见的答案上打转时，安装 why 就很值得。

如何使用 why skill

安装并触发 why

先把 why skill 安装到你的 skills 工作流里，然后用一个具体症状来调用它，不要只给笼统主题。一个好的起点可以是：/why checkout conversion fell 18% after the redesign 或 /why CI failures spike on main branch。

提供问题陈述，不要先给理论

这个 skill 最好在你提供单一可观察问题、出现它的上下文，以及已知约束时使用。好的输入示例：Mobile users abandon the signup form on step 2 after the new validation rules shipped; analyze root causes in the current UX flow. 不好的输入示例：Why is UX bad?

先读最关键的源文件

先看 SKILL.md 了解分析流程，再根据你的环境检查 README.md、AGENTS.md、metadata.json，以及存在的话 rules/、resources/、references/ 或 scripts/ 目录。在这个仓库里，SKILL.md 是主要事实来源，所以最快的路径就是先读分析步骤和示例，再决定如何改写应用。

把分析当成一次工作会话来跑

把 why 当作一条引导式分析链来用：先陈述症状，再用证据回答每一个 “why”，直到原因已经足够根本、而且可验证时再停。如果出现不止一个原因，就分支展开，而不是硬拗成单一路径；最后提出能消除根因的改动，而不是去掩盖症状。

why skill 常见问题

why 只适合技术排障吗？

不是。只要你能描述真实症状，why skill 同样适用于 UX Audit、运营、产品、支持和团队流程问题。关键要求是：问题必须能沿着因果关系追踪下去。

每次都必须做五轮吗？

不一定。五层是默认深度，但更好的原则是“当解释已经具备可行动性且足够稳定时就停”。如果三步之内就已经到达真正的根因，再硬加两步通常只会增加噪音。

why 和普通提示词有什么不同？

普通提示词往往是在要点子；why 要的是有纪律的因果追问。当你需要根因分析、纠正措施，或者希望从原因倒推回症状做验证时，它会更好用。

什么时候不该用 why？

不要把它用于开放式头脑风暴、宏观战略，或根本没有可观察症状的问题。如果你连问题都没法清晰定义到足以测试因果链，why skill 只会给出浅层猜测。

如何改进 why skill

从更锋利的症状开始

why 输出质量取决于第一句话。要写清楚哪里坏了、谁受到了影响、什么时候开始变化、以及发生在哪个环境里：After the new onboarding copy, first-time activation dropped on iOS only. 这比单纯说 activation is down 好得多。

补充证据，不要先下结论

如果你有日志、用户原话、漏斗步骤、截图、时间戳或发布标记，就一起给出来。证据能帮助 why 区分相关性和因果关系，也能避免分析过早停在第一个看起来合理的解释上。

反向验证整个因果链

一个好的 why 结果，应该能从根因一路解释回症状。如果最后一个原因并不能清楚地产生前面的各个步骤，就该先修正链条，或者把它拆成多个分支，再去行动。

把发现落成一个可修复的动作

最好的 why 结果，最后都应该收束成一个你能发布、记录或衡量的改动。后续动作要聚焦在你真正能控制的原因上，然后在修复后重新运行这个 skill，确认症状是否按预期方向变化。