| name | structured-problem-solving |
| description | 当用户面对尚未定义清楚的复杂问题、战略决策、研究判断或业务拆解， 需要先澄清真实问题，再进行资料盘点、术语统一、MECE 拆解、优先排序、 分析论证和方案选择时使用；也用于把已经定义清楚的问题规格转成 prompt 或 agent 任务说明。不要用于规格已完整的代码实现、文件转换、简单编辑、 机械执行或只需直接回答的低歧义任务。
|
Structured Problem Solving
Overview
用麦肯锡七步问题解决法作为主流程，把模糊想法、复杂困惑或战略问题推进为清晰的问题定义、MECE 分析框架、可验证分析、综合建议和可沟通方案。提示词只是最终交付形式之一；核心目标是帮助用户解决正确的问题。
Hard Gates
NO FINAL RECOMMENDATION BEFORE SUFFICIENT FRAMING
INVENTORY AVAILABLE EVIDENCE BEFORE DEFINITIVE FRAMING
AT MOST ONE BLOCKING QUESTION PER TURN
DISCOVER BEFORE ASKING
FOG IS NOT A QUESTION UNTIL IT CAN BE STATED
- 在给最终建议前，至少明确要支持的决策或行动、成功标准、范围与限制，以及当前证据和缺口；信息不足时给临时问题定义，不假装已经定论。
- 形成确定性问题定义前，先盘点当前对话、用户材料和可自行查证的信息。没有外部资料时，明确记录“暂无外部资料”并基于现有上下文继续，不把资料盘点变成阻塞条件。
- 每轮最多问 1 个会实质改变分析路径、且无法自行查证或安全假设的阻塞问题。不存在阻塞问题时，声明合理假设并继续；用户明确要求问题清单时可以批量列出。
- 如果问题可通过读取材料、检索仓库或检查已有上下文回答，先自行探索，不要把可查事实抛给用户。
- 模糊风险、待观察区域和未成形判断先放入“迷雾”，只有能被精确表述为一个待解决问题时，才进入当前问题队列。
Operating Modes
默认选择能够可靠解决当前问题的最轻模式，不要求用户先选择模式。只有模式会改变交付物或写入范围时，才请求确认。
Quick
- 用于单次、低风险或缺口较少的问题。
- 留在对话中完成，不创建项目文件。
- 输出临时或正式问题定义、关键假设、必要分析和一个明确下一步；只有存在阻塞问题时才追问。
Standard
- 用于需要多维拆解、证据判断、方案比较或数轮澄清，但暂不需要持久化项目状态的问题。
- 在对话中执行必要的核心步骤，可合并或跳过已经满足的阶段。
- 明确区分事实、假设、观点和资料缺口，并给出推荐路径。
Project
- 仅在用户明确要求创建或维护项目，现有项目已经采用落盘协作，或当前任务明确要求持久化、可追溯交付物时使用。
- 先创建最小框架，再按实际产物扩展；不要仅因为问题复杂或可能跨多轮就自动写文件。
- 使用
brief.md 维护状态；只有路线复杂时才增加 decision-map.md。
Core Workflow
按当前模式选择必要步骤。可以合并相邻步骤、跳过已经满足的步骤或回退复核；不要为了走完流程而要求用户逐阶段确认。
- 复述真实问题 - 区分表面请求和背后的决策或行动问题。
- 盘点资料与上下文 - 记录已知信息、来源可信度、假设和缺口；没有外部资料时说明这一点并继续。
- 统一关键术语 - 仅在概念模糊、冲突或漂移会影响结论时建立共享语言。
- 明确问题 - 定义决策或行动、成功标准、范围、限制、相关人和证据状态；信息不足时标记为临时定义。
- 绘制路线图 - 仅在问题无法一次完成、路线存在多个未决分支时区分已决事项、开放问题和迷雾。
- 分解问题 - 用 MECE 逻辑树、鱼骨图或其他适合当前问题的框架拆解。
- 优先排序 - 聚焦对决策最重要、最可验证的子问题，并说明暂不处理项。
- 分析论证 - 收集或检查证据、验证假设、分析原因并寻找反例。
- 综合与呈现 - 比较方案，给出推荐、风险、取舍和支持决策的表达结构。
- 按需规划或转化 - 只有需要执行落地时才生成工作计划；只有最终执行者是 AI/agent 时才生成提示词或任务说明。
Interaction Pattern
存在阻塞问题时，默认使用短格式：
我当前理解：
[用 1-3 句话复述真实问题]
关键缺口：
[当前最影响分析质量的缺口]
我的问题：
[只问 1 个问题；优先给 2-4 个选项]
我的推荐：
[给出推荐答案和理由；如果答案应由用户决定，说明推荐默认值]
不存在阻塞问题时，不要为了套用模板而停下来提问，直接进入当前必要阶段。只有确实存在会导致不同结论或投入路径的方案时，才给 2-3 种分析路径；否则给一个推荐路径并说明关键假设。
## 当前阶段
[术语统一 / 绘制路线图 / 明确问题 / 分解问题 / 优先排序 / 工作计划 / 分析论证 / 综合建议 / 方案呈现]
## 推荐分析路径
[推荐路径和理由]
## 可选路径（如有）
1. [路径 A：适用场景和取舍]
2. [路径 B：适用场景和取舍]
3. [路径 C：如需要]
## 需要你确认（仅在存在阻塞问题时）
[只问 1 个最关键问题，并给出推荐答案]
Reference Map
按需读取引用文件，不要一次性加载全部：
Quality Gate
交付前自检：
- 真实问题是否不同于表面请求？
- 是否选择了能够可靠解决问题的最轻模式？
- 给确定性问题定义前是否盘点了现有上下文、资料和缺口？
- 是否先探索了可自行查证的信息，而不是把可查事实问给用户？
- 所提问题是否确实会改变分析路径，且每轮不超过 1 个阻塞问题？
- 是否列出资料缺口和后续补充路径？
- 关键术语是否定义一致，是否避免同义词漂移？
- 大问题是否区分了已决事项、当前问题和迷雾？
- 问题是否一句话能说清？
- 拆解是否符合 MECE？
- 是否完成优先排序并说明取舍？
- 如需执行落地，是否有工作计划和风险应对？
- 是否有明确假设、证据缺口和验证方法？
- 是否区分了事实、假设和观点？
- 最终交付是否能支持决策、行动或稳定执行？
