名称：问题框架化与模糊性解决 描述：专家级框架，用于检测模糊或不完整的需求，暂停执行以询问澄清问题，并在实施前确保相互理解，以减少幻觉和重做。它提供系统方法用于模糊性检测、问题制定和问题重述，以建立人类与AI代理之间的清晰理解。
问题框架化与模糊性解决
概述
问题框架化是任何实施前的关键第一步，教导代理检测模糊或不完整的需求，暂停执行并询问澄清问题。这项技能通过确保代理在尝试解决问题前理解问题，减少幻觉、防止浪费精力，并提高首次成功率。它提供模糊性检测、问题制定和问题重述的系统方法，以建立清晰理解。
为什么这很重要
- 提高首次成功率：通过预先澄清需求，防止在错误实施上浪费时间
- 减少重做：通过避免在误解的需求上工作，节省大量时间
- 提高用户满意度：交付符合实际需求而非假设的输出
- 增强沟通：通过早期建立清晰理解，减少来回沟通
- 支持AI-人类协作：使AI代理与人类用户之间的协作更有效
核心概念
1. 模糊性检测
使用清晰指标识别模糊或不完整的需求：
懒惰提示指标：
- 通用动词（“修复它”、“让它工作”、“更新这个”）
- 缺失上下文（“添加一个功能” - 什么功能？）
- 无约束（“优化这个代码” - 为了什么？速度？内存？）
- 模糊范围（“改进用户界面” - 哪部分？什么改进？）
- 缺失数据（“处理错误” - 什么错误？如何处理？）
- 未定义成功（“让它更好” - 比什么更好？用什么指标？）
检测清单：
- 到底需要做什么？
- 成功标准是什么？
- 约束是什么（时间、资源、范围）？
- 当前状态/上下文是什么？
- 期望的最终状态是什么？
- 利益相关者/用户是谁？
- 技术细节是什么？
- 缺失什么信息？
2. 停止并询问协议
处理模糊请求的决策流程：
接收任务 → 任务是否清晰？
├─ 是 → 进行实施
└─ 否 → 停止并识别差距
→ 制定澄清问题
→ 向用户呈现选项
→ 接收澄清
→ 仍然模糊？
├─ 是 → 制定更多问题
└─ 否 → 重述问题
→ 进行实施
何时始终停止：
- 提示少于20字且缺乏技术细节
- 存在多种解释
- 缺失关键约束（性能、安全性、兼容性）
- 范围未定义（包括什么 vs 排除什么）
- 成功标准缺失
- 上下文不足（无文件路径、无代码片段、无错误消息）
3. 问题制定原则
良好的澄清问题应：
- 具体：针对确切的缺失信息
- 可操作：用户可以用具体细节回答
- 非引导性：不假设答案
- 优先排序：先问关键问题
- 多选：适当时提供选项
问题模板：
- A/B测试意图：“哪个选项最符合您的需求？”
- 约束澄清：“性能/安全性/兼容性要求是什么？”
- 成功标准：“我们如何知道这已完成？”
- 上下文收集：“请分享相关代码、错误消息或文件路径”
4. 问题重述
接收澄清后，始终用自己的话重述问题：
## 问题重述
### 目标
[清晰、单句陈述需要完成的事项]
### 要求
- [ ] 要求1
- [ ] 要求2
### 约束
- [ ] 约束1
- [ ] 约束2
### 成功标准
- [ ] 成功标准1
- [ ] 成功标准2
**请确认此理解正确后再进行。**
快速开始
- 接收任务：从用户获取任务或请求
- 检测模糊性：检查懒惰提示指标 - 通用动词、缺失上下文、未定义范围、缺失成功标准、上下文不足
- 停止并识别差距：如果模糊，识别缺失内容 - 需要做什么、成功标准、约束
- 制定问题：创建具体、可操作的问题，按重要性排序 - 阻塞性问题优先，然后关键、重要
- 呈现给用户：展示问题，适当时提供多选选项
- 接收澄清：从用户获取额外细节
- 重述问题：用自己的话重写问题，并与用户确认理解
- 进行实施：确认后，根据澄清的要求执行解决方案
// 示例：问题重述
interface ProblemStatement {
objective: string;
requirements: string[];
constraints: string[];
successCriteria: string[];
}
function restateProblem(
task: string,
clarifications: Clarification[]
): ProblemStatement {
return {
objective: deriveObjective(task, clarifications),
requirements: extractRequirements(clarifications),
constraints: extractConstraints(clarifications),
successCriteria: extractSuccessCriteria(clarifications)
};
}
生产清单
- [ ] 任务接收并分析
- [ ] 模糊性检测执行
- [ ] 懒惰提示指标检查
- [ ] 缺失信息识别
- [ ] 澄清问题制定（具体、可操作、非引导性）
- [ ] 问题优先排序（阻塞 → 关键 → 重要 → 可有可无）
- [ ] 适当时提供多选选项
- [ ] 用户澄清接收
- [ ] 用自己的话重述问题
- [ ] 与用户确认理解
- [ ] 仅在确认后进行实施
反模式
- 过度澄清：询问不影响解决方案的细节浪费时间
- 引导性问题：建议答案限制用户提供所需信息的能力
- 跳过重述：始终确认理解以避免错位
- 假设意图：不要猜测用户想要什么 - 明确询问
- 在模糊性下进行：如果不确定，询问而非猜测并冒险浪费工作
- 忽略上下文：使用可用上下文，但不假设超出提供内容
- 询问太多问题：优先排序并分组相关问题，避免压倒用户
集成点
- AI模型集成：与GPT-4、Claude等LLM一起使用，用于系统问题理解
- 提示工程：模板与LangChain、PromptPerfect、PromptBase集成
- 文档平台：在Confluence、Notion、GitHub Wiki中存储问题重述
- 协作工具：使用Slack、Microsoft Teams、Discord进行澄清讨论
- 版本控制：在Git中跟踪问题陈述和澄清
- 测试工具：用Jest、PyTest、Playwright测试验证澄清的需求
进一步阅读
检测模糊性
懒惰提示指标
“懒惰提示”是缺乏足够上下文、约束或特异性的请求：
| 模式 | 示例 | 风险级别 |
|---|---|---|
| 通用动词 | “修复它”、“让它工作”、“更新这个” | 高 |
| 缺失上下文 | “添加一个功能”（什么功能？） | 高 |
| 无约束 | “优化这个代码”（为了什么？速度？内存？） | 中 |
| 模糊范围 | “改进用户界面”（哪部分？什么改进？） | 中 |
| 缺失数据 | “处理错误”（什么错误？如何处理？） | 高 |
| 未定义成功 | “让它更好”（比什么更好？用什么指标？） | 高 |
模糊性检测清单
在任何任务前，验证：
## 模糊性检测清单
### 输入清晰度
- [ ] 到底需要做什么？
- [ ] 成功标准是什么？
- [ ] 约束是什么（时间、资源、范围）？
### 上下文理解
- [ ] 当前状态/上下文是什么？
- [ ] 期望的最终状态是什么？
- [ ] 利益相关者/用户是谁？
### 技术特异性
- [ ] 涉及什么技术/框架？
- [ ] 性能要求是什么？
- [ ] 需要考虑的边缘情况？
### 缺失信息
- [ ] 我在做什么假设？
- [ ] 缺失什么信息？
- [ ] 存在什么依赖？
停止并询问协议
决策流程
graph TD
A[接收任务] --> B{任务是否清晰？}
B -->|是| C[进行实施]
B -->|否| D[停止并识别差距]
D --> E[制定澄清问题]
E --> F[向用户呈现选项]
F --> G[接收澄清]
G --> H{仍然模糊？}
H -->|是| E
H -->|否| I[重述问题]
I --> C
何时停止
始终停止并询问当：
- 提示少于20字且缺乏技术细节
- 存在多种解释对于同一请求
- 缺失关键约束（性能、安全性、兼容性）
- 范围未定义（包括什么 vs 排除什么）
- 成功标准缺失（我们如何知道完成？）
- 上下文不足（无文件路径、无代码片段、无错误消息）
何时进行
您可以进行当：
- 请求具体且有明确可交付成果
- 约束说明（明确或上下文暗示）
- 成功可衡量（测试、指标、可观察行为）
- 上下文足够（提供文件、代码、环境细节）
制定澄清问题
问题制定原则
良好的澄清问题应：
- 具体 - 针对确切的缺失信息
- 可操作 - 用户可以用具体细节回答
- 非引导性 - 不假设答案
- 优先排序 - 先问关键问题
- 多选 - 适当时提供选项
问题模板
模板1：A/B测试意图
我想澄清这个请求的范围。哪个最符合您的需求？
**选项A：**[具体解释A带细节]
**选项B：**[具体解释B带细节]
**选项C：**[具体解释C带细节]
请让我知道哪个选项正确，或如果都不匹配，请提供额外细节。
模板2：约束澄清
为了正确实施，我需要理解约束：
- **性能：** 是否有特定延迟/吞吐量要求？
- **兼容性：** 必须支持哪些浏览器/版本？
- **安全性：** 是否有特定安全要求或合规标准？
- **资源：** 是否有内存、存储或外部服务的限制？
请提供任何相关约束，或确认标准实践适用。
模板3：成功标准
为了确保我交付您需要的内容，帮助我定义成功：
1. **当这正确工作时应该发生什么？**
2. **不应该发生什么（要避免的边缘情况）？**
3. **这将如何测试或验证？**
4. **什么可观察行为确认完成？**
请提供具体示例或期望结果。
模板4：上下文收集
我需要更多上下文以提供最佳解决方案：
- **当前状态：** 现有实施看起来如何？
- **问题陈述：** 我们正在解决什么具体问题？
- **使用案例：** 这个功能/功能将如何使用？
- **相关代码：** 是否有其他文件或组件我应该考虑？
请分享相关代码片段、文件路径或错误消息。
问题优先排序
按此顺序询问问题：
- 阻塞性 - 绝对阻止进展的信息
- 关键 - 显著影响方法的信息
- 重要 - 精炼实施的信息
- 可有可无 - 提高质量但不必要的信息
问题重述
重述协议
接收澄清后，始终在进行前用自己的话重述问题。这确保相互理解并捕获任何剩余模糊性。
重述模板
## 问题重述
根据我们的讨论，我理解任务如下：
### 目标
[清晰、单句陈述需要完成的事项]
### 要求
- [ ] 要求1
- [ ] 要求2
- [ ] 要求3
### 约束
- [ ] 约束1
- [ ] 约束2
### 成功标准
- [ ] 成功标准1
- [ ] 成功标准2
### 方法
[我计划如何解决这个问题的高层次描述]
**请确认此理解正确后再进行。**
常见模糊性模式
模式1：“修复这个”
模糊性： 什么坏了？期望行为是什么？
澄清问题：
为了帮助您修复这个，我需要更多信息：
1. **当前行为是什么？**（现在发生什么？）
2. **期望行为是什么？**（应该发生什么？）
3. **这何时发生？**（具体步骤、条件或输入）
4. **有任何错误消息吗？**（请分享完整错误）
5. **您已经尝试了什么？**（以避免重复努力）
请提供尽可能多的细节。
模式2：“优化这个”
模糊性： 优化什么？速度？内存？代码大小？可读性？
澄清问题：
为了有效优化，我需要理解目标：
**哪方面需要优化？**
- [ ] 执行速度（减少运行时）
- [ ] 内存使用（减少RAM消耗）
- [ ] 代码大小（减少捆绑/字节码大小）
- [ ] 可维护性（提高代码清晰度）
- [ ] 可扩展性（处理更多负载）
**当前指标是什么？**
- 当前运行时：___
- 当前内存使用：___
- 当前捆绑大小：___
**目标指标是什么？**
- 目标运行时：___
- 目标内存使用：___
- 目标捆绑大小：___
模式3：“添加一个功能”
模糊性： 什么功能？哪里？应该如何行为？
澄清问题：
为了正确添加这个功能，我需要细节：
**功能描述**
- 这个功能应该做什么？
- 它应该在哪里可访问（UI、API等）？
- 谁可以使用它（认证/授权）？
**用户体验**
- 用户如何与之交互？
- 期望输入/输出是什么？
- 有任何边缘情况或错误条件吗？
**技术要求**
- 是否有现有组件要集成？
- 任何特定技术或库要使用？
- 是否有性能要求？
请提供详细描述或如果可用，提供模拟。
模式4：“让它更好”
模糊性： 更好在哪方面？用什么指标？
澄清问题：
为了改进这个，我需要理解“更好”意味着什么：
**哪方面应该改进？**
- [ ] 性能（速度、效率）
- [ ] 用户体验（可用性、可访问性）
- [ ] 代码质量（可维护性、可读性）
- [ ] 可靠性（错误处理、鲁棒性）
- [ ] 安全性（漏洞、合规性）
- [ ] 设计（美学、一致性）
**当前问题是什么？**
- 用户正在经历什么问题？
- 您收到了什么反馈？
- 什么指标表明问题？
**期望结果是什么？**
- 什么应该改进以及改进多少？
- 我们将如何衡量成功？
请提供具体示例或指标。
快速参考
决策树
请求是否清晰？
├─ 是 → 进行实施
└─ 否 → 停止并识别差距
├─ 是懒惰提示吗？
│ └─ 询问具体细节
├─ 约束缺失吗？
│ └─ 询问性能/安全性/兼容性要求
├─ 范围未定义吗？
│ └─ 询问包括什么/排除什么
└─ 成功标准缺失吗？
└─ 询问如何衡量完成
问题模板
| 情况 | 模板 |
|---|---|
| 多种解释 | “哪个选项最符合您的需求：A、B或C？” |
| 缺失约束 | “性能/安全性/兼容性要求是什么？” |
| 未定义范围 | “这个更改应该包括什么 vs 排除什么？” |
| 无成功标准 | “我们如何知道这已完成？” |
| 上下文不足 | “请分享相关代码、错误消息或文件路径” |
| 模糊“更好” | “更好在哪方面？速度、UX、代码质量等？” |
最佳实践
- 早期询问 - 在开始实施前检测模糊性
- 具体 - 用问题针对确切缺失信息
- 提供选项 - 适当时提供多选
- 优先排序 - 先问阻塞性问题，然后关键，然后可有可无
- 始终重述 - 在进行前确认理解
- 使用上下文 - 利用可用信息，但不假设超出
- 简洁 - 不要一次用太多问题压倒用户
- 保持专注 - 询问与解决问题相关的问题
- 文档 - 保持澄清和问题陈述的记录
- 迭代 - 继续澄清直到理解清晰
常见陷阱
- 假设意图 - 不要猜测用户想要什么；询问
- 过度澄清 - 不要询问不影响解决方案的细节
- 引导性问题 - 不要建议答案；让用户提供
- 跳过重述 - 始终在澄清后重述问题
- 在模糊性下进行 - 如果不确定，询问而非猜测
- 忽略上下文 - 使用可用上下文，但不假设
- 询问太多问题 - 优先排序并分组相关问题
- 不提供选项 - 适当时，提供多选选项