# Question Details

> 当用户需求不清晰时，强制进入“需求澄清模式”，通过复述、反问、确认与证据化决策，把模糊请求收敛为可执行任务后再实施。

- Skill: `ly0o0o/question-details` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ly0o0o/question-details`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ly0o0o/question-details/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ly0o0o (https://skillmd.com/u/ly0o0o)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/ly0o0o/question-details

---


# question-details

## 这个 skill 做什么

这个 skill 用于处理“需求表达模糊、约束不完整、验收标准缺失”的场景。目标不是立即写代码，而是先把需求澄清到**可执行、可验证、可回滚**，再进入实现。

核心能力：

1. 先复述再执行：先准确复述理解，等待用户确认。
2. 不清晰就追问：任何关键点不明确，先提问，不盲猜。
3. 分步实现与分步校验：每一步落地后都检查是否引入问题。
4. 全面检索相关上下文：快速查找相关代码/配置/文档并做 review。
5. 证据化决策：遇到不清楚功能时，优先查官方文档（Context7/MCP/官方资料）再实现。

## 何时使用

当用户请求包含以下特征时触发：

- 目标不明确：如“优化一下”“改好看点”“这个不太对”。
- 范围不明确：不清楚改一个接口、一个模块还是全局。
- 成功标准不明确：没有明确“完成后应该是什么”。
- 约束缺失：未说明兼容性、性能、时限、风险边界。
- 外部依赖不清楚：涉及第三方 SDK/API 版本、参数语义或行为变更。

## 关键词（用于识别是否触发）

需求不清晰、需求模糊、先确认、先复述、反问、澄清、是否明确、MVP、边界、验收标准、范围、约束、兼容性、风险、回滚、官方文档、Context7、MCP、依据、不要猜

## 执行协议（必须按顺序）

### 第 1 步：复述理解（必须）

输出模板：

1. 你的目标是：`...`
2. 我理解的范围是：`...`
3. 我将交付：`...`
4. 验收标准将按：`...`

如果用户未确认，不进入开发。

### 第 2 步：澄清问题（有疑点就必须提问）

只问会影响结果的问题，优先级如下：

1. 业务目标（为什么改）
2. 改动范围（改哪里，不改哪里）
3. 成功标准（如何算完成）
4. 约束条件（性能/兼容/时间/安全）
5. 交付形式（只改代码、是否要测试/文档）

提问规则：

- 一次最多 1-3 个高价值问题，避免“问卷式轰炸”。
- 每个问题给默认选项，方便用户快速确认。
- 若用户未答全，继续追问到“可执行”为止。

### 第 3 步：相关内容全量定位与 review

在实现前，先定位并阅读：

1. 直接相关代码（接口、服务、调用链、类型定义）
2. 配置与环境（env、feature flag、路由注册、任务调度）
3. 测试与文档（单测、集成测试、README、设计文档）

review 要点：

- 是否存在与需求冲突的旧逻辑。
- 是否有边界条件/空值/权限/并发风险。
- 是否有明显 bug 或不一致行为。

发现问题：若与当前需求直接相关，直接修复；若无关，记录并告知。

### 第 4 步：证据化澄清（不确定就查官方）

当出现“API 行为不确定、参数语义不确定、版本差异不确定”时：

1. 使用 Context7/MCP 或官方文档查询。
2. 记录依据（版本、章节、关键结论）。
3. 基于依据实现，不凭记忆猜测。

### 第 5 步：分步实现 + 每步校验

实现规则：

1. 拆成可验证的小步骤。
2. 每步完成后执行对应检查（类型、lint、测试或最小回归）。
3. 若出现问题，先修复再进行下一步。

### 第 6 步：结果复盘（必须）

最终汇报必须包含：

1. 改了什么（文件 + 关键点）
2. 为什么这样改（简短依据）
3. 验证结果（执行命令、成功/失败、关键输出）
4. 风险与后续建议（如有）

## 需求是否明确：判定清单

满足以下条件才算“需求明确”：

- 有明确目标（要解决什么问题）
- 有明确范围（改哪些，不改哪些）
- 有验收标准（完成判据）
- 有约束条件（性能/兼容/安全/时间）
- 有交付预期（代码、测试、文档、上线要求）

任一缺失即判定为“不明确”，必须继续澄清。

## 示例

### 示例 1：模糊需求

用户：

“帮我优化一下这个接口，感觉慢。”

代理应答：

1. 复述：你希望提升接口响应速度，并且不改变现有业务语义。
2. 提问：
	- 目标接口路径是什么？
	- 当前可接受的耗时上限是多少？
	- 是否允许引入缓存（例如 30 秒）？
3. 确认后再实现，并在每一步后验证性能与正确性。

### 示例 2：功能边界不清

用户：

“把登录相关都修一下。”

代理应答：

1. 复述：你希望修复登录链路中的问题。
2. 提问：
	- 具体是密码登录、验证码登录，还是第三方 OAuth？
	- 是报错、性能问题还是权限问题？
	- 是否只修后端，前端暂不改？
3. 在范围明确前不直接改代码。

### 示例 3：外部能力不确定

用户：

“这个 SDK 应该支持批量删除吧？你直接接上。”

代理应答：

1. 先说明：该能力是否支持尚不明确。
2. 查询官方文档（Context7/MCP/官方文档）确认版本与方法签名。
3. 给出依据后再实现，避免错误接入。

## 反模式（禁止）

- 用户需求未确认就开始写代码。
- 关键约束不明时自行脑补。
- 不查依据直接使用不确定 API。
- 一次性大改，不做分步验证。
- 完成后不汇报验证结果与风险。

## 一句话原则

先澄清到“需求明确”，再执行到“可验证完成”。