---
name: ask-first
description: Use when user input lacks a concrete object, action, or constraint and the agent should clarify tacit intent before implementation, refactoring, or verification.
---

# 先问后做（Ask First）

用户说出来的往往少于他想要的。在 AI 动手之前，把缄默意图拉到显式。

---

## 定位

- **不是**「AI 自检理解是否到位」——那是 `confidence-check` 的活。
- **是**在 AI 行动之前，把用户模糊的意图从缄默区（tacit）拽到显式区（explicit）。
- 两者是上下游：`ask-first` 管**用户侧输入完整性**，`confidence-check` 管**AI 侧理解完整性**。

### 优先级规则（非常重要）

当一次用户输入**同时匹配**本 Skill 与 `confidence-check`（或 `code-refactor` 等其他实施型 Skill）的触发条件时，**本 Skill 绝对优先**。

判定依据：如果输入中任何一项是「形容词级模糊」而非「具体可度量」，本 Skill 吃下。
- ❌ "优化 UserService.ts 的**性能**" ← "性能"是形容词级 → **本 Skill 先跑**
- ❌ "重构 auth 模块" ← "重构"未定形态 → **本 Skill 先跑**
- ✅ "把 getUserList 改成**分页，每页 20 条**" ← 参数具体 → 让给 confidence-check

只有当输入三要素齐全（**具体对象 + 具体动作 + 具体约束/目标值**）时，本 Skill 才沉默让位。

---

## 触发规则

### 自动触发（检测到以下任一信号）

| 信号 | 示例 |
|------|------|
| 形容词密度高、具体对象少 | "让它更优雅"、"做得更专业"、"体验要好" |
| 动作对象缺失 | "优化一下"、"改改"、"你看着办" |
| 多义动词无边界 | "整合"、"重构"、"升级"（不说改什么、到什么程度） |
| **有对象但动作形容词化**（易漏档位，必须命中） | "优化 UserService 的**性能**"、"重构 auth **模块**"、"让首页**更现代**" |
| 类比参照缺失 | "像某某那样" 但没提供链接/截图/样例 |
| 大任务无边界 | "做个后台系统"、"写个爬虫"、"给我来个 AI 助手" |
| 价值观形容词 | "高端"、"现代"、"有设计感"、"自然"（未锚定具体参考） |

> 关键原则：**只要动作或目标里出现形容词级词汇（优化/提升/现代/专业/优雅/自然/简洁/高级…），不管有没有具体对象，都立即触发本 Skill**。对象明确 ≠ 意图明确。

### 显式触发

- `@ask-first`、"先问后做"
- "帮我想清楚"、"我想法很模糊"、"不知道怎么描述"
- "我有个模糊的想法"

### 跳过触发的场景

以下情况**不**触发，直接执行：

- 请求已具备「**具体对象 + 具体动作 + 具体约束**」三要素
  - ✅ 跳过：「把 `UserService.ts` 的 `getUserList` 改成分页，每页 20 条」
  - ❌ 触发：「优化一下 UserService 的性能」（缺动作和约束）
- 单纯的知识问答、代码解释、阅读请求
- 用户明确声明"直接干"、"不用问"、"我想清楚了"（需先提醒风险，见文末）

---

## 核心流程

### 第 1 步：锚定参考（Reference Anchoring，成本最低的一步）

任何对话前，先问**一个**问题：

```
在开始前，有没有一个你觉得接近你想要的样例可以给我？
   - 参考可以是：截图 / 链接 / 代码片段 / 具体产品的具体功能 / 类似文档 / 样例数据
   - 🚀 强参考 → 快车道：1-2 轮对齐后即可开干
   - 🐌 无参考 / 弱参考 → 慢车道：我通过 3-5 轮对话帮你挖出来
你选哪种？
```

#### 强参考 vs 弱参考（必须严格区分）

不是所有"类比"都算参考。**弱参考与无参考等价，都走慢车道，第 2b 的三方向发散不可跳过。**

| 类型 | 判定标准 | 例子 | 走哪条车道 |
|------|---------|------|-----------|
| **强参考** | 具体到可成像的产物：截图 / URL / 代码片段 / 具体产品的具体功能 | "像 Notion 的表格视图"、"这张设计稿"、"这段 GitHub 代码"、"Stripe Checkout 那个付款页" | 🚀 快车道 |
| **弱参考** | 宽泛类比，覆盖范围过大，Agent 无法具象出单一形态 | "类似 GPT"、"像 AI 助手那样"、"像苹果那种感觉"、"做一个后台系统的东西" | 🐌 慢车道，**视同无参考** |

**Agent 自检规则**：拿到参考后，在心里反问一次——

> "如果让 5 个不同的工程师按这个参考去实现，他们做出来的东西会不会是**几乎一样**的？"
>
> - 会 → 强参考 → 快车道
> - 不会（会做出 3 种以上完全不同的东西） → 弱参考 → 慢车道，仍需三方向发散

> **为什么这一步最重要**：强参考 = RAG。用户"挂载"一个具体参考，等于把 AI 从"靠预训练权重猜"切换到"读用户提供的 RAM"。一张截图 ≈ 500 轮文字描述。但**弱参考是幻觉放大器**——用户以为给了锚点，AI 以为有了依据，双方都高估了共识，最后做出四不像。

---

### 第 2 步：三方向发散（3-Way Divergence，核心机制）

#### 2a. 先判断对象是否明确

在发散前做一次**30 秒自检**——输入是否已经有"要改/要做的对象"？

- **对象明确**（如"UserService.ts 的性能"、"博客首页"、"AI 助手"）→ **直接跳到 2b 做三方向发散**。
- **对象缺失**（如"优化一下"、"改改"、"帮我做个东西"）→ 三方向发散无从下手，**必须先锚定对象**。用一个最小问题问清楚：

  > 你想[优化/改/做]的是什么？
  > - (a) **某段代码 / 某个文件 / 某个函数**（给我路径或名字）
  > - (b) **某个 UI / 页面 / 产品**（截图或链接最好）
  > - (c) **某个文档 / Prompt / Skill**（给我文件路径）
  > - (d) **某个流程 / 配置 / 工作方式**（简单描述现状）

  等用户给出对象后，**立刻进入 2b**，不要再拆成更多轮。

#### 2b. 三方向发散（核心）

**只要对象明确，无论快慢车道都必须做这一步。** 基于用户输入（或 2a 锚定后的输入），生成 **3 个互斥的方向**，不是三个"更好的同一件事"，而是代表**不同的价值取舍**。

每个方向必须包含：

| 字段 | 内容 |
|------|------|
| **方向名** | 一句话标签（如 "方向 A：极简主义"） |
| **核心假设** | 这个方向假设你最在乎的是什么 |
| **具体产出示例** | 3-5 行描述产出**具体长什么样**——用数据、结构、元素、文案，**不用形容词** |
| **适合场景** | 什么情况下这个方向最合适 |
| **⚠️ 放弃了什么（必填，不可省略）** | 选这个方向就牺牲掉的东西。**如果三个方向的"放弃"栏写不出真正的损失，说明这三个方向不互斥，必须重新生成。** |

然后问：

> **"哪个方向最接近你要的？或者都不对，我再生成 3 个不同的？"**

#### 三方向发散的反模式

- ❌ 三个方向都是"更好版本"（"简洁"、"极简"、"清爽" 是同一个东西的三种说法）
- ❌ 方向 A = 低配、方向 B = 中配、方向 C = 高配（这不是发散，是配置表）
- ❌ 用形容词堆砌代替具体产出示例

#### 三方向发散的正模式

例：用户说"帮我优化博客首页"

- **方向 A：信息流派**（像 Twitter/Medium）
  - 核心假设：你最在乎**被更多人读到**
  - 具体产出：首屏列 10 条最新文章，每条带 2 行摘要+阅读量+时间；无顶部大图
  - 适合：内容高频更新、想提升点击率
  - 放弃：品牌感、深度阅读氛围
- **方向 B：杂志派**（像 The Verge）
  - 核心假设：你最在乎**品牌调性**
  - 具体产出：首屏一张大图 + 一篇头条，下方 3×3 网格精选
  - 适合：深度长文、追求视觉冲击
  - 放弃：首屏信息密度、SEO 文章曝光
- **方向 C：极客派**（像 HN/Substack）
  - 核心假设：你最在乎**阅读效率**
  - 具体产出：纯文字列表，标题+日期+分类标签；无图、无摘要、字号 16px
  - 适合：订阅读者为主、追求加载速度
  - 放弃：新访客的第一印象

---

### 第 3 步：自适应追问（Adaptive Questioning）

用户选定方向后，进入深度对话。每轮问题数量根据**剩余模糊度**自适应：

| 剩余模糊度 | 每轮问题数 | 风格 |
|------------|------------|------|
| 大方向还不清 | **1 个** | 苏格拉底式，挑最核心的那一刀 |
| 方向清楚、关键细节模糊 | **2-3 个** | 打包问，效率高 |
| 只差具体参数 | **清单一次问完** | 填空式 |

#### 提问五条铁律

1. **用数据锚定，不用形容词**
   - ✅ "列表每页显示多少条？10 / 20 / 50？"
   - ❌ "列表要简洁" ← 什么叫简洁？

2. **给候选项，不给开放题**
   - ✅ "报错时你希望：(a) 静默重试 (b) 弹窗提示 (c) 仅记日志？"
   - ❌ "报错了怎么办？"

3. **一次一变量**
   - ✅ "界面优先简洁还是信息密度？"
   - ❌ "界面要简洁且高效还是美观？" ← 同时问了 3 个维度

4. **"不知道" 是有效答案**
   - 用户说不知道时，**替他默认一个合理选项并明说**："那我默认用 20 条/页，你不反对就继续。"
   - 不要逼用户在他还没概念的维度上做决定。

5. **宁可多问 1 个选项，也不要拆成两轮**
   - 同一档次的参数必须**一次打包问完**，不要问完 3 个又突然补问第 4 个。
   - 打包前先在心里过一遍："如果用户这 N 个问题都答了，我是否还需要再问？" 答案是"需要"就继续往清单里加；答案是"不需要"才发出。
   - 拆成两轮 = 浪费用户一个回合的注意力，是本 Skill 最常见的设计缺陷。

---

### 第 4 步：意图回放（Intent Playback）

对齐完成、开干之前，**必须完整复述一次理解**：

```
📋 我理解你要做的是：

目标：     [一句话总结]
核心方向： [第 2 步选定的方向]
关键参数：
   - [参数 1]：[值]
   - [参数 2]：[值]
   - [参数 3]：[值]
输入：     [数据/文件/上下文]
产出：     [具体格式，有样例最好]
边界：     [不做什么 / 不优化什么]
成功标准： [怎么算做完了]
参考：     [用户提供的参考链接/截图/样例]

这样对吗？不对的地方直接改对应行，其他保持不变。
```

- 用户 ✅ 确认 → **强制进入第 5 步（移交给下游 Skill）**，不得直接开干。
- 用户 🔧 修改 → 只针对改动项再对齐一轮（不要整个流程重来）。
- 用户 ❌ 全部推翻 → 回到第 2 步重新发散 3 个方向。

---

### 第 5 步：强制移交下游（Mandatory Handoff）

用户确认意图回放后，**本 Skill 的工作结束**，但不得跳过技术层面的自检。必须**显式声明交接**：

```
✅ 意图对齐完成。现在切换到 [confidence-check] 做 AI 侧自检（重复实现 / 架构合规 / 官方文档），再开始实施。
```

根据任务类型选择下游 Skill：

| 原始任务 | 下游 Skill |
|---------|------------|
| 代码开发/修改/重构 | `confidence-check` |
| Go 代码审查 | `go-code-review` |
| UI/UX 改造 | `ui-ux-auditor` |
| 创建新 Skill | `skill-creator` |
| 产品战略决策 | `strategic-product-advisor` |
| 其他 | 默认 `confidence-check` |

**下游 Skill 不必重新询问意图**——已在第 4 步意图回放中锁定。下游只做各自职责内的检查。

> 为什么必须有这一步：本 Skill 的职责是**让模糊输入变清晰**，不包含技术可行性检查。如果直接跳过 confidence-check 开干，可能会重复实现已有代码、违反项目架构、或误用 API。本步骤是把对齐后的意图"扔回 Skill 生态"的明确信号。

---

## 完整调用示例

> **用户输入**：「帮我做个工具监控我的健身情况。」

**Agent（第 1 步）**：
> 在开始前，有没有一个你觉得接近你想要的工具可以参考？比如 Apple Health、Keep、Strava、或者一个你朋友用的 Excel 表？
> - 🚀 有参考 → 我 1-2 轮就能对齐
> - 🐌 没有参考 → 我会用 3-5 轮帮你挖出来

**用户**：「没啥参考，我就是想知道我练得怎么样。」

**Agent（第 2 步，三方向发散）**：
> 根据你的描述，我想到 3 个差异很大的方向：
>
> - **方向 A：成绩追踪型**（像 Strava）
>   - 核心假设：你最在乎**突破个人纪录**
>   - 产出：每次训练记录「动作+重量+次数+组数」，图表显示 PR（个人最佳）走势
>   - 适合：力量训练为主、想看数据进步
>   - 放弃：心率/卡路里/睡眠这些健康维度
>
> - **方向 B：健康监测型**（像 Apple Health）
>   - 核心假设：你最在乎**整体身体状态**
>   - 产出：心率、睡眠、步数、体重、体脂的时间序列图
>   - 适合：关注长期健康、有可穿戴设备
>   - 放弃：训练动作的细粒度记录
>
> - **方向 C：习惯打卡型**（像 Keep 的打卡功能）
>   - 核心假设：你最在乎**有没有坚持**
>   - 产出：日历视图显示每天练/没练，连续天数、本月训练次数
>   - 适合：刚开始健身、克服拖延
>   - 放弃：训练质量的评估
>
> 你选 A / B / C？或者都不对，我再造 3 个？

**用户**：「A 最接近，但我也想看大概的身体变化。」

**Agent（第 3 步，自适应追问，1 个核心问题）**：
> 好，以 A 为主 + 轻量 B。最关键的一个问题：你希望**多频繁**记录身体变化？
> - (a) 每天称重记体重（高频）
> - (b) 每周一次拍照+量腰围（中频）
> - (c) 每月一次体测（低频，但数据最稳）

**用户**：「b」

**Agent（继续第 3 步，细节清单）**：
> 最后几个参数一次性问完：
> 1. 训练动作种类：预设（深蹲/卧推/硬拉 ×N）还是你自己增减？
> 2. 数据输入方式：手动输入 / 语音 / 导入 Apple Health？
> 3. 展示端：网页 / 手机 App / CLI？

**用户**：「1 预设 + 自己增减；2 手动；3 网页就行」

**Agent（第 4 步，意图回放）**：
> ```
> 📋 我理解你要做的是：
>
> 目标：    做一个个人健身记录+进步追踪的工具
> 核心方向：以成绩追踪为主（方向 A），辅以周度身体变化记录（轻量 B）
> 关键参数：
>    - 训练记录粒度：动作 + 重量 + 次数 + 组数
>    - 动作库：预设 + 用户可增删
>    - 身体数据：每周一次（腰围 + 照片）
>    - 输入方式：手动
>    - 展示端：网页
> 输入：    用户每次训练结束后手动录入
> 产出：    
>    - 训练页：每个动作的 PR 走势图
>    - 身体页：腰围折线图 + 照片对比
> 边界：    不接入可穿戴设备；不做饮食记录；不做社交
> 成功标准： 用 2 周后能看到至少 3 个动作的进步曲线
>
> 这样对吗？
> ```

**用户**：「对，开干」→ 进入实施。

---

## 反模式：不要做

- ❌ **把问题扔回用户**："能说详细点吗？" "你需要什么？" —— 这些是废话。
- ❌ **用形容词描述方向**："我们可以做得更优雅一些" ← 什么叫优雅？用具体元素代替。
- ❌ **一次抛 10 个问题**造成压迫感——分轮次，自适应。
- ❌ **用户第一次回答后就开干**——必须至少做一次意图回放。
- ❌ **生成完整代码/完整界面作为"原型"**——三方向发散用**文字描述**就够，生成完整产物浪费 token 且易幻觉。
- ❌ **重复问用户已经回答过的事**——每轮追问前先回顾已确认项。

---

## 用户声明"跳过"的处理

如果用户说"不用问了，直接干"、"跳过澄清"等：

> ⚠️ **跳过意图对齐的风险**：
> - 60% 的"返工"由意图错位导致（不是代码 bug）
> - 3 分钟对齐 = 节省 3 小时重做
> - 模糊输入 → 模糊输出 → 用户失望 → 回炉重造
>
> 你确认已经想清楚这三件事了吗？
>   1. 我要的**具体产出形态**（不是形容词）
>   2. 我最在乎的**一个核心价值**（不是"都很重要"）
>   3. 我**不需要**什么（边界）
>
> 如果三件都清楚，告诉我你的答案，我直接干。如果有任何一件不清楚，我强烈建议至少走三方向发散这一步（只需 1 分钟）。

---

## 与其他 Skill 的关系

本 Skill 在生态中是**前置中间件**。具体交接协议已写入**第 5 步**（强制移交），这里只做定性说明：

```
用户模糊输入
   │
   ▼
┌─────────────────┐
│   ask-first     │  用户侧：挤出显式意图（本 Skill）
└────────┬────────┘
         │ 意图回放 + 用户确认 + 第 5 步显式交接
         ▼
     下游 Skill
  （confidence-check / code-refactor / ui-ux-auditor /
    skill-creator / strategic-product-advisor …）
```

### 不耦合的设计

本 Skill **不要求**下游 Skill 修改自己的代码。下游的 `confidence-check` 等保持原样，只靠以下机制达成双层护栏：

1. **优先级规则**（见"定位"章节）：模糊输入永远本 Skill 先吃。
2. **第 5 步显式交接**：Agent 结束本 Skill 后主动调用下游。
3. **意图回放作为契约**：下游 Skill 直接读第 4 步的回放块，不重复询问。

### 相关 Skill 分工

| Skill | 关系 |
|------|---------|
| `confidence-check` | 默认下游。做 AI 侧自检（重复实现 / 架构 / 文档） |
| `strategic-product-advisor` | **垂直专化版**。做产品战略时它优先（有自己的 5 维度提问） |
| `skill-creator` | "写一个 skill" 场景下游 |

---

## 原则

- 用户不是在**隐藏**意图，是**无法表达**意图（缄默知识）。
- AI 的任务不是"听懂"，而是"**帮用户把意图挤出来**"。
- 最贵的不是 token，是**走错方向的 token**。

---

## 约束

### 必须做

- 三方向发散**必须互斥**，不能是"同一件事的三种形容词"
- 三方向的「放弃了什么」**必填**，写不出真正的损失就重新生成
- 提问**必须用具体候选项或数据**，不用形容词
- 同一档次的参数**一次打包问完**，不拆轮次
- 意图回放**必须在动手前做一次**，不能省略
- 尊重用户的"不知道"——替他默认并明说
- 优先鼓励用户提供参考（截图/链接/样例 = 最便宜的对齐方式）

### 不要做

- 不问空泛开放题（"你有什么要求吗"）
- 不在一个问题里塞多个维度
- 不假装理解了就开干
- 不生成完整原型作为发散的替代——文字描述足够
- 不重复已经对齐过的问题
- 不把这个 Skill 当成万能前置——具体的 `confidence-check` 场景（有明确对象的任务）应让位给 `confidence-check`