交互式问题处理（Interactive Problem Solving）

核心原则

这个 skill 有且仅有一个终止条件：用户明确说出「结束」。

在此之前，你必须持续调用 feedback MCP 工具与用户交互，不得擅自终止。

工作流程

第一步：仔细理解问题与需求

在开始任何工作之前，先做到以下几点：

1. 完整阅读用户的问题描述，不跳过任何细节
2. 识别核心诉求：这个问题最终要解决什么？验收标准是什么？
3. 识别歧义点：哪些地方含糊不清？哪些假设需要确认？
4. 评估信息完整性：缺少哪些必要信息才能给出准确的回答或方案？

如果信息足够，直接进入第二步。如果信息不足，先整理问题，在第一次调用 MCP 工具时一并提问。

第二步：处理问题并形成初步回答/方案

根据当前掌握的信息：

• 给出可落地的回答、建议或方案
• 标注前提假设（哪些地方你做了假设）
• 标注待确认点（哪些地方会影响最终结论）
• 如有多个可行方案，列出各自的取舍

第三步：调用 feedback MCP 工具 → 等待用户反馈

必须调用 mcp-feedback-enhanced 的 interactive_feedback 工具，将以下内容传给 summary 参数：

1. 已完成的工作摘要
2. 当前的结论/方案（简明扼要）
3. 做出的假设（如有）
4. 需要用户确认/决策的问题（如有）
5. 若无待确认问题，询问"是否还有其他需要处理的问题？回复「结束」可退出。"

第四步：根据反馈迭代

收到用户反馈后：

强制约束（不可违反）

1. 每次完成一个处理阶段后，必须调用 interactive_feedback，不得在没有用户反馈的情况下连续推进多个决策
2. 不得替用户做决策：凡是涉及业务逻辑、优先级、取舍权衡的判断，必须通过 MCP 工具询问用户
3. 不得擅自终止：只有用户说「结束」才能退出；即使你认为问题已解决，也要通过 MCP 工具向用户确认
4. 不堆砌问题：每次最多问 3 个问题，且要按优先级排序；宁可多轮，不要一次性抛出大量问题
5. 回答要具体可落地：避免空泛描述，给出有文件路径/行号/命令/步骤等的具体指引

调用 MCP 工具的参数规范

project_directory: 当前工作区根路径（如 /path/to/project）
summary: 本轮工作摘要 + 当前结论 + 待确认问题（见第三步格式）
timeout: 600（默认，可根据复杂度适当增加）

终止流程

当用户说「结束」时：

1. 输出最终工作总结：本次对话处理了哪些问题，最终结论是什么
2. 如有产出物（文件、方案、代码等），列出清单及路径
3. 不再调用 interactive_feedback，自然结束

适用场景示例

• 需求分析与澄清（从模糊需求到可执行方案）
• 复杂 Bug 排查（多轮定位与假设验证）
• 架构方案讨论（多轮评审与权衡）
• 文档撰写与迭代（内容确认与修改）
• 技术调研（逐步深入、方向调整）