design-first

Category: Tools & Productivity | Uploader: Sleepwal | Downloads: 0 | Version: v1.0（Latest）
强制执行'先想清楚、再动手'工作流程。当任务涉及设计/架构决策、新功能实现、重构或任何需要规划的代码变更时调用此技能。
Changelog: Source: GitHub https://github.com/Sleepwal/Skills
Directory Structure

Current level: tree/main/Skills/design-first/
📁 references/
- 📄 决策框架.md 18.3 KB
- 📄 敏捷开发实践.md 23.1 KB
- 📄 软件工程方法论.md 15.7 KB
📄 SKILL.md 12.0 KB
SKILL.md

---
name: "design-first"
description: "强制执行'先想清楚、再动手'工作流程。当任务涉及设计/架构决策、新功能实现、重构或任何需要规划的代码变更时调用此技能。"
---

# 设计先行 (Design First)

## 核心原则

**暂停。思考。批准。编码。**

本技能强制执行结构化的决策流程，确保 AI 在设计方向获得用户明确批准之前，不会编写任何代码。该技能以聚焦、高效的方式取代零散的澄清、繁琐的文档要求和无限的反馈循环。

> **理论基础**：本技能的设计理念源于软件工程方法论、决策科学和敏捷开发实践的融合。详见 [参考资料目录](./references/)。

---

## 技能激活条件

本技能**必须**在以下场景激活：

- 用户请求实现新功能
- 用户提出架构变更或重构需求
- 用户提及系统设计或技术决策
- 任何需要设计判断或权衡分析的任务
- 用户希望添加/修改组件、API 或数据结构

---

## 强制边界规则

```
┌─────────────────────────────────────────────────────────────┐
│  ⛔ 方向批准前禁止执行：                                      │
│  - 编写任何代码                                             │
│  - 创建项目脚手架                                           │
│  - 生成文件                                                 │
│  - 重构现有代码                                             │
│  - 进行结构性变更                                           │
│                                                             │
│  ✅ 批准前允许执行：                                         │
│  - 提出澄清性问题                                           │
│  - 提出设计方案                                             │
│  - 分析权衡利弊                                             │
│  - 阅读现有代码以获取上下文                                  │
└─────────────────────────────────────────────────────────────┘
```

> **参考**：边界规则的设计基于认知负荷理论，避免在信息不充分时做出不可逆决策。详见 [决策框架 - 决策类型分类](./references/决策框架.md#12-决策类型分类)。

---

## 四阶段工作流程

### 第一阶段：发现/澄清 (Discovery)

**目标**：在单次交互中收集关键信息。

**规则**：
- 在**单条消息**中提出 2-3 个最关键的问题
- 优先采用**选择题**格式，而非开放式问题
- 聚焦于：项目上下文、既有模式、约束条件、成功标准、优先级
- 在收到回答前，**绝不**追加提问

**问题模板**：
```
在提出方案之前，我需要了解以下信息：

1. [上下文问题]
   a) 选项 A
   b) 选项 B
   c) 选项 C

2. [约束条件问题]
   a) 选项 A
   b) 选项 B

3. [优先级问题]
   a) 选项 A
   b) 选项 B
```

**深度动态调整**：
- 小型修改（1-2 个文件，简单逻辑）：跳过发现阶段，直接进入提案阶段
- 中型功能：提出 2-3 个问题
- 大型架构：可能需要更深入的探索，但仍需批量提问

> **参考**：批量提问的设计基于认知负荷理论，减少上下文切换带来的认知负担。详见 [软件工程方法论 - 认知负荷理论](./references/软件工程方法论.md#6-认知负荷理论)。

---

### 第二阶段：提案 (Proposal)

**目标**：呈现恰好 2 个方案，并附带清晰的权衡分析。

**规则**：
- 呈现**恰好 2 个**可行方案（不多不少）
- 每个方案**必须**包含：
  - 清晰的描述
  - 优势（Pros）
  - 劣势（Cons）
  - 风险及缓解措施
  - 未来扩展性考量
- 明确给出 AI 的**推荐意见**及理由
- 最终决定权在用户

**提案模板**：
```
## 方案 A：[名称]

**描述**：[该方案的具体内容]

**优势**：
- [优势 1]
- [优势 2]

**劣势**：
- [劣势 1]
- [劣势 2]

**风险**：[潜在问题及缓解方式]

**扩展性**：[如何应对未来需求]

---

## 方案 B：[名称]

[与方案 A 相同的结构]

---

## 我的推荐：方案 [A/B]

**理由**：[为什么偏好此方案]

**所做的权衡**：[我们获得什么 vs 放弃什么]
```

> **参考**：方案数量限制基于决策科学中的对比效应和认知负荷限制。权衡分析方法详见 [决策框架 - 权衡分析技术](./references/决策框架.md#2-权衡分析技术)。

---

### 第三阶段：收敛 (Convergence)

**目标**：在继续执行前获取用户的明确批准。

**规则**：
- 等待用户回应：批准、拒绝并说明理由、或要求修改
- 如果被拒绝：最多允许 **2 轮迭代**，以避免无限循环
- 2 轮被拒后：升级至用户，请求直接指导

**用户回应处理**：

| 回应 | 行动 |
|------|------|
| "批准" / "继续" / "执行" | 进入第四阶段，然后开始编码 |
| "拒绝，因为 X" | 针对性修改提案 |
| "修改 Y" | 按 Y 的要求更新提案 |
| "方案 C：..." | 如果可行，接受用户的替代方案 |

**迭代限制机制**：
```
第 1 轮：初始提案 → 被拒绝
第 2 轮：修改提案 → 被拒绝
→ 停止并询问用户："我们已探索 2 轮方案，建议：
   a) 您提供具体方向
   b) 安排会议讨论
   c) 由我基于最佳判断执行"
```

> **参考**：迭代限制机制避免决策瘫痪，符合敏捷开发中的"速度优于完美"原则。详见 [敏捷开发实践 - 反馈时效性原则](./references/敏捷开发实践.md#32-反馈时效性原则)。

---

### 第四阶段：记录 (Capture)

**目标**：以最小开销记录决策。

**规则**：
- 以行内注释或聊天消息形式记录（用户偏好为准）
- **不强制要求**独立文档，除非用户明确要求
- 聚焦于"为什么"，而非"是什么"

**记录格式**（行内注释）：
```
// 设计决策：[日期]
// 选择：方案 [A/B] - [简要理由]
// 权衡：[我们接受的条件]
// 背景：[驱动此决策的关键约束]
```

**记录格式**（聊天消息）：
```
📝 **决策已记录**
- **选择**：方案 A
- **理由**：[为什么选择此方案]
- **接受的权衡**：[我们放弃了什么]
- **下一步**：[即将实施的内容]
```

> **参考**：轻量级记录方式符合敏捷宣言中"工作的软件高于详尽的文档"原则。详见 [敏捷开发实践 - 敏捷宣言与设计先行](./references/敏捷开发实践.md#11-敏捷宣言核心价值映射)。

---

## 指导原则

### 1. 速度优于形式 (Speed Over Ceremony)
- 除非必要，不创建正式文档
- 优先快速决策，而非完美文档
- 为发现阶段设定时间上限

### 2. 只做当前需要的 (YAGNI)
- 只设计**当前**需要的功能
- 避免为"未来可能需要"过度工程化
- 延迟可以稍后做出的决策

### 3. 偏向行动 (Bias Toward Action)
- 不过度分析简单变更
- 当上下文清晰时，做出合理假设
- 优先"现在足够好"，而非"以后完美"

### 4. 思考过程比文档更重要 (思考 > 文件)
- 思考过程比文档本身更重要
- 在最便捷的地方记录决策
- 不让文档成为障碍

> **参考**：这些原则源自极限编程(XP)、精益创业等方法论。详见 [软件工程方法论 - YAGNI 原则](./references/软件工程方法论.md#1-yagni-原则-you-aint-gonna-need-it) 和 [软件工程方法论 - MVP](./references/软件工程方法论.md#2-最小可行产品-mvp)。

---

## 快速参考卡

```
┌────────────────────────────────────────────────┐
│           设计先行工作流程                      │
├────────────────────────────────────────────────┤
│  1. 发现：提出 2-3 个问题（单次批量）          │
│  2. 提案：2 个方案 + 推荐意见                  │
│  3. 收敛：获取明确批准                         │
│  4. 记录：行内记录决策                         │
├────────────────────────────────────────────────┤
│  然后且仅然后：编写代码                        │
└────────────────────────────────────────────────┘
```

---

## 实际案例

### 案例 1：小型修改（跳过发现阶段）

**用户**："为提交按钮添加加载动画"

**AI 回应**：
```
这是一个简单的 UI 添加。让我提出 2 种方案：

## 方案 A：纯 CSS 动画
- 优势：无依赖、轻量、快速
- 劣势：定制性有限
- 适合简单场景

## 方案 B：组件库动画
- 优势：与设计系统一致、动画丰富
- 劣势：增加依赖

**推荐**：方案 A - 遵循 YAGNI 原则，如有需要后续可升级。

是否批准执行？
```

---

### 案例 2：中型功能（完整流程）

**用户**："为应用添加用户认证功能"

**AI 回应**：
```
在提出方案之前，我需要了解以下信息：

1. 主要的认证方式是什么？
   a) 邮箱/密码
   b) 社交登录（Google、GitHub 等）
   c) 两者都要

2. 后端架构是什么？
   a) 自有后端 API
   b) Firebase/Supabase
   c) 尚未决定

3. 优先级是什么？
   a) 快速实现（MVP）
   b) 企业级安全
   c) 两者平衡
```

[用户回答后，进入提案阶段...]

---

### 案例 3：大型架构（扩展发现阶段）

**用户**："重新设计我们的微服务架构"

**AI 回应**：
```
这是一个重大的架构变更。让我先了解背景：

1. 这次重新设计的驱动力是什么？
   a) 扩展性问题
   b) 团队结构调整
   c) 技术迁移
   d) 其他：___

2. 当前的痛点是什么？
   a) 部署复杂
   b) 服务通信
   c) 数据一致性
   d) 以上多项

3. 有哪些约束条件？
   a) 必须保持零停机
   b) 预算有限
   c) 时间线：[具体日期]
   d) 团队专长：[具体技术]

注：鉴于范围较大，在您初次回答后我可能需要进一步澄清，但会批量高效地进行。
```

> **参考**：大型架构设计需要考虑渐进式架构原则。详见 [软件工程方法论 - 渐进式架构](./references/软件工程方法论.md#3-渐进式架构-evolutionary-architecture)。

---

## 应避免的反模式

| ❌ 错误模式 | ✅ 正确做法 |
|------------|------------|
| 一次只问一个问题 | 批量提出 2-3 个问题 |
| 呈现 5+ 个方案 | 呈现恰好 2 个方案 |
| "让我先开始编码看看" | 先获取批准 |
| 为每个变更创建 design.md | 除非被要求，否则行内记录 |
| 无限修改循环 | 最多 2 轮迭代，然后升级 |
| 为"某天可能需要"过度设计 | 只设计当前需要的 |

---

## 技能激活检查清单

当本技能激活时，在任何代码变更前验证：

- [ ] 是否已提出澄清性问题？（如需要）
- [ ] 是否已提出恰好 2 个方案？
- [ ] 是否已给出推荐意见？
- [ ] 用户是否已明确批准？
- [ ] 是否已记录决策？

如果**任何**复选框未勾选：**暂停。不要编写代码。**

---

## 参考资料

本技能的设计基于以下理论框架和实践方法：

| 文档 | 内容概述 |
|------|----------|
| [软件工程方法论](./references/软件工程方法论.md) | YAGNI、MVP、渐进式架构、技术债务、设计思维、认知负荷理论 |
| [决策框架](./references/决策框架.md) | 结构化决策流程、权衡分析技术、方案生成与收敛、决策质量评估 |
| [敏捷开发实践](./references/敏捷开发实践.md) | 敏捷宣言映射、迭代开发、持续交付、用户故事、看板方法、DevOps 集成 |

---

## 版本信息

- **版本**：1.0.0
- **创建日期**：2026-03-20
- **适用场景**：所有涉及设计或架构决策的软件开发任务
Comments 0
Latest | Hot
Please login before commenting.
No comments yet. Be the first one!
design-first

Directory Structure

SKILL.md

Report

Notice
