cause-and-effect

cause-and-effect 技能概览

cause-and-effect 技能是一款 Fishbone/Ishikawa 分析助手，用来把含糊的问题整理成结构化的根因图谱。它最适合那些需要先解释“为什么会这样”，再去修复问题的人：UX 审核人员、产品团队、运营负责人、支持分析师，以及任何需要在多个相互竞争的解释之间做判断、而不是靠猜的人。

用户真正关心的，不是它能不能输出一份泛泛的头脑风暴清单，而是能不能产出一个可用的因果树。这个 cause-and-effect 技能适合在你需要按 People、Process、Technology、Environment、Methods、Materials 六个维度做有纪律的拆解，并从症状一路推到可能的根因和后续动作时使用。如果你其实已经知道答案，只需要快速改写一下，它就没那么合适。

cause-and-effect 最适合的场景

在这些场景下使用 cause-and-effect：

• 需要给出站得住脚解释的 UX Audit 发现
• 已知现象、但原因不清楚的事故复盘
• 需要不止一句“沟通有问题”的团队复盘
• 存在多个因素可能相互作用的产品或服务问题

cause-and-effect 的区别在哪里

cause-and-effect 技能的核心价值在于结构。它不是简单让 agent “分析一下问题”，而是给你一个六分类框架，先逼出广度，再通过反复追问“为什么”往深处挖。这能减少漏掉关键原因的概率，也让结果更方便团队一起审阅。

什么时候不适合用

如果任务主要是下面这些，就跳过这个技能：

• 分类、总结或信息抽取
• 一个已经明确、修复方式也很明显的单点 bug
• 不需要根因纪律的创意发散

如何使用 cause-and-effect 技能

安装并触发技能

如果是 GitHub 托管的环境，添加技能时要把 repo 路径和技能名一起写上：
npx skills add NeoLabHQ/context-engineering-kit --skill cause-and-effect

然后直接用问题陈述来调用它，不要把一大段背景全倒进去。cause-and-effect usage 这种输入方式，在“一个清晰症状 + 足够上下文让分析成立”的情况下效果最好。

给技能正确的输入形状

高质量提示通常应包含：

• 可观察到的问题
• 问题发生的地点
• 受影响的人群
• “正常/理想”应该是什么样
• 任何限制条件或最近变化

例如：
“cause-and-effect: Mobile checkout conversion dropped 18% after the last release. Analyze likely causes across people, process, technology, environment, methods, and materials, then rank the top three root-cause hypotheses for a UX Audit.”

这比下面这种说法更好：
“为什么转化率下降了？”

先读这些文件

进行 cause-and-effect install 和首次运行设置时，先看 SKILL.md。然后检查任何会影响该技能在你环境里如何应用的相邻 repo 指引。这个仓库里路径比较简单，因为没有 rules/、resources/ 或 scripts/ 这类辅助目录，所以技能定义本身就是主要的事实来源。

能提升输出质量的工作流

按这个顺序来：

1. 写一句话的问题陈述。
2. 补充证据：指标、案例、截图、时间戳或用户反馈。
3. 要求技能区分“促成因素”和“根因”。
4. 按影响和可能性请求排序。
5. 把最重要的原因转成可验证的后续问题或修复动作。

这个工作流之所以重要，是因为这个技能在输入已经把症状和上下文区分清楚时最强。你的提示越具体，模型就越不会用泛泛的解释去补空。

cause-and-effect 技能常见问题

cause-and-effect 适合做 UX Audit 吗？

适合。cause-and-effect for UX Audit 非常适合用来解释可用性问题或流失模式，而且能给出可信的因果图谱，而不是只停留在一个人的主观看法上。它能帮助把观察结果转译成流程、界面、方法或环境中的潜在断点。

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

普通提示词可能只会给出一串猜测。cause-and-effect 技能会推动模型把这些猜测按类别组织起来，再进一步挖到更可能的驱动因素。这样结果更容易讨论、验证，也更容易转化成后续工作。

新手需要根因分析经验吗？

不需要。只要你能把问题描述清楚，这个技能就对新手很友好。真正的限制不是专业深度，而是输入质量：症状越模糊，因果图谱就越模糊。

什么时候不应该用 cause-and-effect？

当你需要的是直接答案、文案改写，或者简单分类体系时，不要用它。还有一种情况也不适合：如果你连问题都说不清楚，分析就会变得又宽又没把握。

如何提升 cause-and-effect 技能效果

给更好的证据，不要只加更多字

提升 cause-and-effect 最快的方法，是补充具体信号：错误率、漏斗步骤、客服案例、浏览器/设备拆分、发布时间，或者流程变更。这些细节能帮助技能区分相关性和更可信的因果关系。

要求输出排序后的假设

如果你想让结果更有决策价值，就要求把最可能的原因排序并说明理由。例如：“按影响和可能性给前三个原因排序，并注明每个原因需要什么证据才能确认或排除。” 这样比单纯输出一张很长的鱼骨图更可执行。

运行前先收窄范围

像“分析一下我们产品的问题”这种大而空的提示，只会得到浅层覆盖。把 cause-and-effect 指南收窄到一个结果、一个人群，或一个旅程阶段。聚焦后的提示会给你更干净的分类和更少的噪音。

先测试最强分支，再继续迭代

第一次分析后，不要马上要求整篇重写。更好的做法是继续深挖优先级最高的分支：“只展开 Technology 相关原因”或者“把 Process 分支整理成调查清单”。这就是从解释走向诊断、同时减少猜测的方式。