analyse-problem

analyse-problem 技能概览

analyse-problem 是做什么的

analyse-problem 技能会把一团乱麻式的问题整理成结构化的 A3 问题简报：背景、现状、目标状态、根因分析、对策、实施计划和后续跟踪。它特别适合 Strategic Planning、运营、产品和工程场景——当你需要的是能直接支持决策的问题陈述，而不是头脑风暴时，这个技能最有用。

适合安装 analyse-problem 的人

如果你经常需要把问题讲清楚、对齐相关方，或者把症状推进到原因层面，就很适合安装 analyse-problem。它适合想要一个可复用格式来做事故复盘、流程改进、项目阻塞分析或规划会议的人。

它的不同之处

它的价值不在于“让 AI 写得更多”，而在于约束。analyse-problem 会推动模型把问题压缩到一页纸内，把事实和假设分开，并以行动和验证收尾。正因为如此，它比一个面向 Strategic Planning 的通用 prompt for analyse-problem 更有用，因为它会强制形成更紧的决策框架。

如何使用 analyse-problem 技能

安装并触发 analyse-problem

先通过你的 skills manager 完成安装，然后用一段简短的问题描述来调用 analyse-problem skill。这个仓库的使用方式是 /analyse-problem [problem_description]，并且默认支持可选的问题描述以及 markdown 输出。如果你的环境里 skills 的映射方式不同，也可以传入同样的意图：一个简洁、具体的问题陈述。

给 analyse-problem 正确的输入

高质量输入会明确问题、范围和证据。比如：“本月企业账户的客户 onboarding 完成率下降了 18%；请分析原因并提出对策。”像“改进 onboarding”这样的弱输入，只会让模型猜目标、负责人和成功指标。使用 analyse-problem 时，最好包含：

• 现象
• 受影响的流程或团队
• 相关数据点、案例或时间线
• 期望结果或约束条件

先看这些仓库部分

先从 SKILL.md 开始，然后查看 README.md、AGENTS.md、metadata.json 里有没有关联说明，以及 rules/、resources/、references/ 或 scripts/ 这类目录（如果存在的话）。对于这个仓库来说，主要内容集中在 plugins/kaizen/skills/analyse-problem，所以不需要到处追着找额外脚手架。

怎样组织 prompt 才能得到更好的输出

一个好的 analyse-problem guide prompt 应该足够具体，能填满 A3 的每个部分。比如：
“Use analyse-problem to document why release delays increased in Q2. Include baseline metrics, likely root causes, 3 countermeasures ranked by impact and effort, and a 30-day follow-up plan.”
这样的结果会比泛泛要求“做分析”更可用，因为它同时给了模型可组织的事实和要支持的决策。

analyse-problem 技能常见问题

analyse-problem 只适合 Strategic Planning 吗？

不是。凡是需要把问题框定、调查并分派行动的场景都很适用：产品问题、运营瓶颈、团队流程失效，或者 Strategic Planning 评审。A3 格式的适用面很广，但当输出需要和其他人共享时，这个技能的价值最大。

它和普通 prompt 有什么区别？

普通 prompt 也可以要求分析，但 analyse-problem 技能提供了可复用的结构和输出纪律。尤其当你需要稳定覆盖根因、对策和后续跟踪，而不是一段自由发挥的解释时，这一点就很重要。

新手能用好吗？

可以，只要输入足够具体。新手最常见的问题是把问题说得太模糊，所以要把你已知的信息给出来：观察到的现象、范围、时间点和大致目标。这个技能可以帮助整理不完整的思路，但不能安全地凭空补齐缺失事实。

什么时候不该用它？

如果你只需要快速摘要、状态更新，或者创意发散，就不要用 analyse-problem。若问题的范围还没有稳定下来，也不适合直接上这个技能；这种情况下，应先把问题定义清楚，再去做结构化分析。

如何改进 analyse-problem 技能

给它证据，不要只给结论

质量提升最大的来源，是提供具体输入：指标、案例、事故时间戳、用户原话，或者流程记录。如果你已经怀疑某个根因，也要把它标成假设而不是事实，这样分析才能去验证它，而不是顺着它重复一遍。

要求输出能直接用于决策

对于 analyse-problem，最好明确要求团队能直接行动的内容：按优先级排序的原因、与原因对应的对策、负责人、依赖项，以及验证计划。如果你看重 Strategic Planning 价值，就要要求影响与投入的权衡，而不是一篇很长的叙述。

注意常见失败模式

最常见的失败是把症状写得很长，却没有把目标状态说清楚。另一个问题是把多个问题塞进一页里。应把彼此无关的问题拆开，让一份分析只聚焦一个决策、一个负责人和一个可衡量结果。

在第一版之后继续迭代

先用第一版输出检查缺口：是否缺数据、因果链是否薄弱、行动是否和根因不匹配。然后结合新的事实和约束继续细化 prompt，比如预算、截止时间、团队产能，或者领导层评审需要的固定格式。