structured-problem-solving

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

按当前模式选择必要步骤。可以合并相邻步骤、跳过已经满足的步骤或回退复核；不要为了走完流程而要求用户逐阶段确认。

1. 复述真实问题 - 区分表面请求和背后的决策或行动问题。
2. 盘点资料与上下文 - 记录已知信息、来源可信度、假设和缺口；没有外部资料时说明这一点并继续。
3. 统一关键术语 - 仅在概念模糊、冲突或漂移会影响结论时建立共享语言。
4. 明确问题 - 定义决策或行动、成功标准、范围、限制、相关人和证据状态；信息不足时标记为临时定义。
5. 绘制路线图 - 仅在问题无法一次完成、路线存在多个未决分支时区分已决事项、开放问题和迷雾。
6. 分解问题 - 用 MECE 逻辑树、鱼骨图或其他适合当前问题的框架拆解。
7. 优先排序 - 聚焦对决策最重要、最可验证的子问题，并说明暂不处理项。
8. 分析论证 - 收集或检查证据、验证假设、分析原因并寻找反例。
9. 综合与呈现 - 比较方案，给出推荐、风险、取舍和支持决策的表达结构。
10. 按需规划或转化 - 只有需要执行落地时才生成工作计划；只有最终执行者是 AI/agent 时才生成提示词或任务说明。

Interaction Pattern

存在阻塞问题时，默认使用短格式：

我当前理解：
[用 1-3 句话复述真实问题]

关键缺口：
[当前最影响分析质量的缺口]

我的问题：
[只问 1 个问题；优先给 2-4 个选项]

我的推荐：
[给出推荐答案和理由；如果答案应由用户决定，说明推荐默认值]

不存在阻塞问题时，不要为了套用模板而停下来提问，直接进入当前必要阶段。只有确实存在会导致不同结论或投入路径的方案时，才给 2-3 种分析路径；否则给一个推荐路径并说明关键假设。

## 当前阶段
[术语统一 / 绘制路线图 / 明确问题 / 分解问题 / 优先排序 / 工作计划 / 分析论证 / 综合建议 / 方案呈现]

## 推荐分析路径
[推荐路径和理由]

## 可选路径（如有）
1. [路径 A：适用场景和取舍]
2. [路径 B：适用场景和取舍]
3. [路径 C：如需要]

## 需要你确认（仅在存在阻塞问题时）
[只问 1 个最关键问题，并给出推荐答案]

Reference Map

按需读取引用文件，不要一次性加载全部：

• 创建或维护分析项目目录时，读取 references/project-structure.md。
• 用户提供资料、需要转换/摘录/溯源，或资料缺口影响分析时，读取 references/material-handling.md。
• 出现术语混乱、概念边界不清、同义词漂移或需要形成共享语言时，读取 references/domain-language.md。
• 问题很大、路径不清、需要跨多轮推进或拆成研究/原型/追问/任务时，读取 references/decision-map.md。
• 进入麦肯锡七步问题解决流程任一阶段时，读取 references/mckinsey-seven-step.md。
• 最终需要生成 prompt、提示词或 agent 任务说明时，读取 references/prompt-handoff.md。

Quality Gate

交付前自检：

• 真实问题是否不同于表面请求？
• 是否选择了能够可靠解决问题的最轻模式？
• 给确定性问题定义前是否盘点了现有上下文、资料和缺口？
• 是否先探索了可自行查证的信息，而不是把可查事实问给用户？
• 所提问题是否确实会改变分析路径，且每轮不超过 1 个阻塞问题？
• 是否列出资料缺口和后续补充路径？
• 关键术语是否定义一致，是否避免同义词漂移？
• 大问题是否区分了已决事项、当前问题和迷雾？
• 问题是否一句话能说清？
• 拆解是否符合 MECE？
• 是否完成优先排序并说明取舍？
• 如需执行落地，是否有工作计划和风险应对？
• 是否有明确假设、证据缺口和验证方法？
• 是否区分了事实、假设和观点？
• 最终交付是否能支持决策、行动或稳定执行？