通用助手 编辑复核
模糊问题拆解树
把一句模糊诉求拆成问题定义、子问题、证据和下一步，帮助团队先解决正确的问题。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名问题定义顾问。请把模糊问题拆成互不重复、可验证的子问题，并指出哪些只是表面症状。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 原始诉求和真正需要决定的结果
2. 问题树：症状、可能原因和影响
3. 每个分支的证据与反证
4. 优先验证的最小问题
5. 必须向提问者追问的关键信息
输入变量：
- 原始问题（{{problem}}）：贴出原始描述，保留用户原话。
- 上下文（{{context}}）：提供时间、范围、已知变化和相关数据。
- 要支持的决定（{{decision}}）：说明分析结果要影响什么动作。
- 分析限制（{{constraints}}）：说明可用数据、时间和权限。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先验证定义和范围，再让模型扩展原因树。
- 不要把可能原因列表直接当成诊断结论。
WHEN IT FITS
适用判断
适合这些情况
- 问题笼统，不知道从哪下手。
- 需要判断哪些子问题是真正的瓶颈。
- 要把大问题拆到可以分工的粒度。
换个做法更好
- 你要的是发散想法：用《受约束的创意发散与筛选》。
- 问题已经很具体：直接解决。
- 问题的关键信息还缺失：先补信息再拆。
FAILURE MODES
常见翻车与修正
- 拆出的子问题互相重叠，或者加起来没覆盖原问题。
要求每层拆分说明为什么这几项是互斥且穷尽的，做不到的补上「其他」项并说明包含什么。
- 拆得太深，末端子问题细到没有意义。
要求拆到「可以指派给一个人在一周内推进」的粒度就停，并说明停在这一层的理由。
- 每个分支都平均展开，看不出哪里是关键。
要求标注每个分支的影响权重和不确定性，优先展开高影响高不确定的分支。
ACCEPTANCE
怎么判断输出合格
- 每层拆分互斥且穷尽，有兜底项。
- 拆分深度适中，末端可以直接指派。
- 标出了高影响高不确定的关键分支。
- 指明了哪些分支需要先补信息才能继续拆。
SAFETY BOUNDARY
使用边界
- 故障排查场景里的日志和配置贴入前要去掉密钥、内网地址和账号信息。
- 拆解树反映的是模型对问题的理解，可能整条分支都指错方向；先用低成本的方式验证再投入排查。