# Understand First

> 当用户刚描述完一套流程、规则、约束、判定标准、数据结构或工作方式，而 agent 即将据此实现、改造或批量执行时触发。触发词包括「我的思路是、流程是、规则如下、要求是、本质是、你理解一下、重新理解、证明你理解了、给几个例子看看、产出案例」。强制先证明理解：压缩复述规则 → 给出至少 3 个与用户举例不同领域的具体样例（含正例与反例）→ 指出规则内部的张力与边界疑点 → 给出实施骨架，等用户确认后才动手。禁止用用户自己举过的例子来证明理解。不接管需求澄清（归 initer）、方案设计（归 real-solution-plan）、只读分析（归 analyze-only）。

- Skill: `ruosong320/understand-first` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ruosong320/understand-first`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ruosong320/understand-first/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Ruosong320 (https://skillmd.com/u/ruosong320)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/ruosong320/understand-first

---


# Understand First

用户描述完规则后，agent 的第一反应不是动手，是**证明自己没理解错**。

理由很实在：规则复述可以靠复读蒙混过关，**换个领域造例子不行**。造得出跨领域的正例反例，说明抽到了规则本身；造不出，说明只记住了用户的措辞。这个 skill 存在的唯一目的，就是把"是否真懂"这件事提前到动手之前暴露出来，而不是实现完 300 行之后才发现方向就错了。

## 何时用

用：用户刚讲完一套**可复用的判定规则或流程**，接下来要按它产出/改造/批量执行。
典型信号——「我的思路是…」「本质是…」「限定输出必须满足①②③」「你理解一下再做」「重新理解一下并产出案例」。

不用：
- 单步明确指令（「把这个变量改名」）——直接做。
- 需求还没成形，边界不清 → `initer`。
- 要的是技术方案不是理解确认 → `real-solution-plan`。
- 要的是只读分析 → `analyze-only`。
- 同一套规则本轮已经确认过 → 不要重复表演，直接执行。

## 硬流程

### 1. 压缩复述

把规则压成**编号条目**，不要整段复述用户原话——原话复述是零信息量的。

复述时必须做一次**信息增益动作**，至少一项：
- 补出用户没明说但逻辑上必然蕴含的条件；
- 指出两条规则之间的张力（例："②要求组合后能完成上级任务，③要求不偏离原目标；但拆得越独立越容易偏离，这对约束是有张力的"）；
- 指出规则未覆盖的情形。

只会原样复述 = 没理解，重来。两条规则直接互斥、压不成一组自洽条目时，取「理解卡壳时的兜底」表中以 *两条规则直接互斥* 开头的那一行处理，不得替用户裁决。

### 2. 跨领域造例（核心）

给 **≥3 个样例**，硬性约束：

1. **领域必须与用户举的例子不同。** 用户举女鞋，就不许用女鞋、女鞋销量、女鞋市场——那是同一题换皮。跨到出海、RAG 上线、办发布会这种真正不同的语义空间去。
2. **每个样例给正例 + 反例。** 只给正例无法证明理解了边界；反例要标出**违反了哪一条**。
3. **样例要具体到可以直接被判对错。** 「一个好的拆分」不算样例，「合规准入 / 本地化运营 / 渠道建设」才算。
4. **至少一个样例踩在边界上**，即那种「看起来合规但其实违反某条」的情形——这是最容易暴露误解的地方。

格式：

```
样例 N｜<领域>
  输入：<具体输入>
  ✓ <具体产出>
  ✗ <具体产出> —— 违反第 X 条：<原因>
```

**🔴 CHECKPOINT — 样例交出去之前逐条过。任一条 ✗，先按该条箭头的动作处理再交，不得用「差不多」的样例换用户的确认。**
- **领域真的与用户举过的例子不同吗？** 同题换皮（女鞋 → 女鞋销量）不算。✗ → 取兜底表中以 *用户举的例子覆盖了整个目标域* 开头的那一行处理。
- **每个样例都配了反例，且反例标了违反第几条吗？** ✗ → 补齐后重过。
- **至少一个样例踩在边界上吗？** ✗ → 补齐后重过。
- **样例具体到能直接判对错吗？** 「一个好的拆分」这种不算。✗ → 补齐后重过。

造不出真正跨领域的样例时，取「理解卡壳时的兜底」表中以 *用户举的例子覆盖了整个目标域* 开头的那一行处理；用户举的例子本身就违反规则时，取以 *用户举例里本身就含有违反规则的情形* 开头的那一行处理。不要自行降级。

### 3. 标出疑点

列出 1-3 条**答案会改变实现**的边界疑点，每条写清"若 A 则我会…，若 B 则我会…"。让用户看到分歧的后果，而不是问一句空泛的「这样理解对吗」。

没有真疑点就写「无阻塞疑点」，不要为凑格式硬编。

### 4. 实施骨架

3-6 行说明确认后要做什么、改哪里、怎么验。不展开细节——细节是 `real-solution-plan` 的活。

### 5. 等确认

🛑 STOP — 用户没回复就是没确认。把「等确认」当作默许动手，是本 skill 最常见的失败方式。

明确停下。用户纠正后，**回到第 2 步重造样例**（不是打补丁式地改一个例子），因为规则一变，之前所有样例的有效性都要重判——重造前先取「理解卡壳时的兜底」表中以 *用户纠正的是规则本身* 开头的那一行处理。用户沉默不回应，取同表中以 *用户对复述与样例不回应* 开头的那一行处理。

## 理解卡壳时的兜底

以上流程每一步都可能卡住。下列情况按表处理，不得静默降级成「差不多懂了」；下表不限于某几步。

| 触发条件 | 一线修复 | 仍失败兜底 |
|---|---|---|
| 用户举的例子覆盖了整个目标域，找不到真正跨领域的样例 | 别在同题换皮里打转：把行业抽象成机制再换场景（女鞋 → 选品与库存周转 → 冷链生鲜的选品与周转），证明的是同一个机制 | 换了机制仍无处可去 → 明说「此规则的跨领域样例造不出」，退为同域不同子场景，并声明证明力下降，不得假装仍是跨领域证明 |
| 用户纠正的是规则本身，不是某个例子 | 不要打补丁式改那一个例子：回到第 2 步整批重造，因为一条规则变了，其余样例的判定可能全变 | 重造一轮后用户仍全否 → 停止造第三个版本，改为逐条请用户指出「第几条你读成了什么」，把分歧收敛到具体条上 |
| 两条规则直接互斥，压不成一组自洽条目 | 不替用户裁决：把矛盾作为疑点提出，并给出「若 A 则我会…，若 B 则我会…」两条实现路径 | 用户仍不裁决 → 停在阶段一，明说这是进入实现的硬前置，不得自行选一条动手 |
| 用户举例里本身就含有违反规则的情形 | 当场指出该例是反例、违反第几条，并要求确认这是举例失误还是规则本身要改 | 用户坚持该例为正例 → 以用户认可的这条为准，同时在疑点里记下它与原规则的冲突，不静默改规则 |
| 用户对复述与样例不回应（沉默） | 用具体选项把球踢回去：「是第①条、第②条，还是都不对？」 | 仍无回应 → 停在等确认，在动任何手之前明说在等确认，不得把沉默当作默许 |

## 反模式

**用用户的例子证明理解**
```
✗ 用户举例「女鞋 → 品类/价格带/渠道」，agent 回「明白，比如女鞋可以拆成品类、价格带、渠道」
   —— 这是复读，零证明力
✓ 换到「企业出海 → 合规准入/本地化运营/渠道建设」
```

**只给正例**
```
✗ 三个都是对的例子 —— 证明不了知道边界在哪
✓ 每个配一个具体的反例并指出违反哪条
```

**样例全部安全**
```
✗ 三个都是显然成立的简单情形
✓ 至少一个卡在边界上：「东南亚合规准入」看着像独立目标，
   实则是「合规准入」的地域限定交织，违反独立性
```

**假确认**
```
✗ 「以上理解正确吗？正确的话我就开始了」然后不等回复直接动手
✓ 真停下
```

**规则被推翻后打补丁**
```
✗ 用户说「第②条你理解反了」→ 只改那一个例子
✓ 重造全部样例 —— 一条规则变了，其余样例的判定可能全变
```

## 与其他 skill 的关系

- `initer` 之后、`real-solution-plan` 之前。initer 问的是"你要什么"，本 skill 证的是"我懂了你说的规则"。
- 被 `prompt-forge` 复用：改写 skill/prompt 前，先用本 skill 证明理解了用户的验收口径。
- 确认通过后，实质工作按 CLAUDE.md 门禁继续走 `mission-spliter` / `scoped-code-change`。