---
description: 记录新想法 — 理解并记录灵感，为后续展开做准备
---

# 记录新想法

记录并理解新想法。不是详细设计——那是 `/dev-new` 的职责；也不是架构讨论——那是 `/epic-new` 的职责。核心是**把握想法的本质**：解决什么问题、大致方向、关键边界。

## 定位

| 命令 | 侧重 | 深度 |
|------|------|------|
| `/idea-new` | 理解想法 | 轻——把握 what & why，不细化方案 |
| `/epic-new` | 架构设计 | 重——多轮讨论确立技术方向 |
| `/dev-new` | 需求分析 | 中——细化到可执行的方案 |

聊天记录已经捕捉了想法的字面内容，本命令的价值在于**让 AI 理解它**——必要时分析代码库、调研外部技术、向用户澄清，确保后续展开时有可靠的认知基础。

## 执行流程

**第一步：理解想法**

1. 仔细阅读用户描述，把握核心诉求
2. 用一句话复述核心，确认理解无偏差

**第二步：适度分析**

根据想法的性质决定分析深度：

- 想法清晰简单 → 直接进入保存
- 想法涉及现有代码/功能/模块 → 主动探索代码库相关部分，理解上下文、可行性和影响范围
- 想法涉及外部技术或未知领域 → 用 web 搜索了解现状和主流方案

**提问原则**：该问就问。为理解想法本质而必须澄清的问题，不要为了"快"而省略。区别于 `/epic-new` 的多轮架构讨论——这里问的是"这个想法到底是什么"，不是"怎么做"。有多个问题时用 `question` 工具一次性提出。

> 用户如果需要紧急离开，可以直接 `/idea-save` 跳过后续分析，将当前已理解的内容保存下来——不必强求走完所有步骤。

**第三步：引导保存（必须主动向用户输出以下内容）**

```
想法已理解，可以保存：
  /idea-save    ← 保存到 ideas/<名称>.md
```

## 约束

- ⛔ 不做多轮架构讨论——这是 `/epic-new` 的职责
- ⛔ 不生成详细技术方案——这是 `/dev-new` 的职责
- ✅ 可以探索代码库（当想法与现有系统相关时）
- ✅ 可以 web 搜索（当涉及外部技术时）
- ✅ 该问的问题就问——不为了"快"而牺牲理解
- 不评判想法好坏，只确保理解到位