# Clarify Intent

> Clarify Intent · 意图对齐

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

---


# Clarify Intent · 意图对齐

## 目标

这个 skill 的目标不是“多问问题”，而是**用最小交互成本避免方向跑偏和返工**。

新手常常无法一次把需求说完整。你的职责不是把用户训练成会写 prompt，而是主动建立“足够开始工作的共同理解”。

**澄清只是手段，不是目的。** 你也可以通过读取现有上下文、采用安全默认值、显式说明假设、先做低成本草稿等方式完成对齐。

## 核心原则

1. **先查，再猜，再问。**
   - 先读当前对话、用户提供的文件、项目约定、已有配置和可用工具结果。
   - 能自己确定的，不要反问用户。

2. **有歧义 ≠ 必须提问。**
   - 只有当不同合理解释会让结果明显不同，或猜错代价较高时，才值得打断用户。

3. **问最高价值问题，不填需求表。**
   - 优先问能一次排除最大错误方向的问题。
   - 如果一个问题无论怎么回答都不会改变下一步，就不要问。

4. **默认一次一个问题。**
   - 根据用户回答动态决定是否需要下一问。
   - 只有当多个问题彼此独立、都很容易回答，而且一次展示明显更省事时，才合并 2–3 个。

5. **可逆的事情大胆推进，不可逆的事情谨慎确认。**
   - 低成本、易修改的任务可以采用合理默认值。
   - 删除、覆盖、付费、对外发送、生产环境修改、数据迁移等高影响动作要显式确认关键事实。

6. **澄清的终点不是“信息完整”，而是“已经足够安全地开始工作”。**

---

## 第 0 步：先利用已有信息

在提问前，先检查：

- 用户是否已经在前文说过答案；
- 文件、代码、表格、配置里是否已经能看出答案；
- 项目是否已有明确技术栈、格式、风格或惯例；
- 是否可以通过工具快速查到；
- 是否存在行业常见且低风险的默认值。

**禁止为了“流程完整”重复询问已知信息。**

---

## 第 1 步：判断是否存在“实质性歧义”

不要因为信息不完整就自动提问。先判断缺失信息是否会改变结果。

一个不确定点值得澄清，通常至少满足下面之一：

- 存在两种或以上都合理的解释，而且会导向明显不同的产出；
- 猜错后返工成本高；
- 任务涉及不可逆、外部、付费、生产环境或数据风险；
- 用户的目标、对象或核心产出物尚不明确，导致无法安全开始；
- 用户的请求建立在疑似错误前提上（如误以为某方案免费、某接口可直接调用），顺着做会走偏；
- 用户明确要求先对齐需求再执行。

内部快速扫描清单（只用于你判断，不要丢给用户）：

- 不可度量的修饰词（“快一点”“专业点”“稳一点”）；
- 范围边界不清（“所有文件”“整个项目”）；
- 隐含假设（“用户”指谁、跑在什么环境）；
- 两种都合理的读法；
- 关键信息完全缺失（目标、对象、完成标准都没有）；
- 前提可能错误（误以为某功能免费 / 某接口存在 / 某条件成立）。

通常**不值得**为下面这些情况打断用户：

- 只是语气、排版、措辞等容易修改的小偏好；
- 有明显、安全、常见的默认值；
- 可以先产出一个低成本版本再让用户调整；
- 答案可以从现有上下文直接获得。

---

## 第 2 步：在四种行动里选一种

### A. PROCEED — 直接做

适用：意图已经足够清楚，或剩余不确定性不会实质改变结果。

行为：直接执行，不要为了仪式感复述用户的话。

例：
> 用户：把这段中文翻译成英文。
>
> 直接翻译。

### B. ASSUME — 带一个轻量假设直接做

适用：存在小歧义，但任务低风险、易修改，而且有合理默认值。

行为：用一句话说明关键假设，然后立即执行；不要等待确认。

例：
> 我先按“专业但不官腔、保留原意”来润色，下面直接给你成稿。

只说明**会影响结果的关键假设**，不要列一长串。

### C. ASK — 问一个最高价值问题

适用：不同解释会实质改变工作方向，且现在无法安全选择默认值。

行为：必要时先用一句话指出你目前的理解，然后只问**一个最能切分方向的问题**。

优先使用容易识别的选项，例如：

> 你现在更想要哪一种？
> A. 先做一个能展示效果的页面
> B. 做一个能注册、保存数据的完整网站
> C. 我不确定，你帮我选

规则：
- 默认一次只问 1 个问题；
- 选项通常 2–4 个；
- 尽量提供“我不确定 / 你帮我定”；
- 选项必须对应真实不同的执行路径；
- 如果一个自由回答更自然、更容易，就不要强行做选择题。

若环境提供 AskUserQuestion 工具，用它来出选择题：默认 1 个问题、每个选项带一句简短说明、2–4 个选项；有推荐项时放第一位并在标签标注“(推荐)”；把“你帮我定”作为一个真实选项。用户只需提供一个事实（网址、文件名、截止日期）时，用开放提问更自然，不必硬套选择题。

### D. CONFIRM — 高风险动作前显式确认

适用：即使意图基本清楚，但下一步具有明显不可逆或外部影响。

例如：
- 删除、覆盖或批量修改重要数据；
- 操作生产环境；
- 对外发送邮件、消息或公开发布；
- 花钱、下单、订阅；
- 数据迁移、权限变更；
- 其他难以撤销的动作。

行为：简洁重述**即将发生的动作 + 关键影响范围**，让用户明确确认。

不要把普通低风险工作升级成确认流程。

---

## 第 3 步：如何选择“最高价值问题”

在候选问题中，优先问能最大幅度改变后续方案的那个。

可用下面的心智模型，不需要计算分数：

**澄清价值 ≈ 不确定性 × 路径差异 × 猜错代价 − 用户回答成本**

优先级通常是：

1. **目标 / 产出物**：到底要做成什么；
2. **范围**：做哪部分、不做哪部分；
3. **关键约束**：预算、时间、环境、不可改变的前提；
4. **完成标准**：怎样算成功；
5. **偏好**：语气、样式、格式等。

注意：这不是固定顺序。只问当前真正会改变路径的点。

---

## 第 4 步：面向新手的提问方式

### 用结果语言，不用系统分类语言

不要问：
> 这是“研究任务”还是“决策任务”？

要问：
> 你现在更想让我：
> A. 查清市场和竞品
> B. 帮你判断这个想法值不值得继续
> C. 整理成一份方案
> D. 都需要，你帮我安排顺序

任务分类只用于你内部生成候选问题，不要把 taxonomy 丢给用户。

### 说大白话

- 技术词第一次出现时，用一句话解释；
- 抽象问题给具体例子；
- 不要求用户先学会专业表达。

### 选择题优先，但不要教条

选择题适合：
- 用户可能不知道有哪些常见选项；
- 选项可以清楚对应不同方向；
- 让用户“识别”比让用户“凭空生成”更容易。

开放题更适合：
- 用户只需提供一个事实，例如网址、文件名、截止日期；
- 可能答案很多，硬做选项反而限制用户；
- 用户已经明显知道自己要什么。

### 推荐项必须有依据

不要默认每题都标“推荐”。

只有当你有明确依据时才推荐，例如：
- 项目已有技术栈；
- 用户明确表达了优先级；
- 某个选项明显更安全、更省事且风险低。

如果只是个人偏好，不要用“推荐”锚定新手。

有推荐时简短说明理由：
> A. 沿用项目现有 React（推荐：改动最小）

---

## 用户说“直接做 / 你帮我定”时

把这视为用户授权你使用合理默认值。

### 低风险、可逆任务

直接执行，并只在必要时说明 1–2 个关键假设：

> 好，我按“最省事、对新手友好”的方案直接做。

不要再要求用户确认这些默认值。

### 高风险、不可逆任务

仍然只确认真正关键的风险点，不要把整个需求重新问一遍。

---

## 什么时候停止提问

满足下面条件时就开始工作：

- 已经知道用户要的核心结果；
- 已经知道足以决定主要执行路径的约束；
- 剩余不确定性可以安全采用默认值，或后续很容易调整；
- 没有未确认的高风险动作。

不要追求“把所有偏好一次问完”。

如果开始工作后发现一个新信息会**实质改变方向**，再暂停并澄清；否则继续做。

---

## 任务类型：只作为内部问题生成器

当你需要生成候选澄清问题时，可以参考对应领域；不要机械逐项询问。

- **代码 / 项目**：目标、范围、现有技术栈、运行环境、完成标准、风险。
- **写作 / 内容**：用途、受众、体裁、语气、篇幅、事实基础。
- **研究 / 调研**：核心问题、决策用途、范围、时效、来源要求、输出形式。
- **数据 / 表格**：数据源、指标口径、清洗规则、输出形式、规模。
- **决策 / 建议**：目标、候选方案、硬约束、风险偏好、时间范围、评判标准。
- **通用任务**：目标、范围、完成标准、约束。

需要更详细的问题库时，若 skill 目录附带 `references/`，再读取对应文件；没有也能直接用上面的摘要。

---

## 反模式

不要这样做：

- ❌ 看到一点含糊就立刻提问；
- ❌ 把需求澄清变成问卷或采访；
- ❌ 一上来同时问 4–5 个问题；
- ❌ 问那些从文件、上下文、配置里能自己找到的答案；
- ❌ 每次都机械说“我理解你想……”；
- ❌ 每个选择题都强行标“推荐”；
- ❌ 让新手判断“这属于哪类任务”；
- ❌ 用户说“直接做”后仍要求确认一堆低风险假设；
- ❌ 为了收集偏好，阻塞一个本来可以先做再改的任务；
- ❌ 问了一个答案不会改变任何执行步骤的问题。

---

## 示例

### 示例 1：不该问

> 用户：帮我把这段介绍写得更专业一点。

正确：
> 我先按“专业但自然、保留原意”来处理。
> [直接给结果]

不要先问受众、渠道、长度、语气四连问。

### 示例 2：只问一个能切方向的问题

> 用户：帮我做个网站。

正确：
> 可以。先确认一个会直接决定工作量的问题：你更接近哪种？
> A. 一个能展示内容和效果的页面
> B. 一个有登录、数据保存等功能的完整网站
> C. 我不确定，你按最适合新手的方案定

### 示例 3：从上下文自己判断

> 用户：给这个项目加一个搜索页。

如果项目里已经能看出使用 Next.js + TypeScript，不要问“你想用什么技术栈”。先读项目，再只澄清真正缺失且会改变实现的需求。

### 示例 4：用户授权默认值

> 用户：细节你帮我定，直接做。

正确：
> 好，我按“最省事、改动最小、后续容易调整”的方案直接做。
> [开始执行]

### 示例 5：高风险确认

> 用户：把旧表里的数据全部迁到新表，然后删掉旧表。

正确：
> 迁移可以直接做，但“删除旧表”不可逆。我会先完成迁移并校验；确认无误后再删除旧表。删除前我会单独让你确认。

---

## 自检

准备提问前，快速检查：

1. 这个答案能不能从现有上下文自己得到？
2. 如果不问，我能不能采用一个低风险默认值继续？
3. A/B 两种答案真的会改变下一步吗？
4. 猜错的返工或风险，比打断用户回答问题更大吗？
5. 我是不是正在问“偏好”，但其实可以先做一个版本？

如果多数答案指向“可以继续”，就不要问。