Files

闫旭隆 c484cafb45 Initial commit: VibeEngineering V2

- 两阶段分离：设计阶段人工确认，执行阶段全自动化
- 子代理驱动：Implementer → Spec Reviewer → Quality Reviewer
- 原生 Task 系统：使用 Claude Code Task 替代自定义状态管理
- 跨 Compact 恢复：PreCompact + SessionStart Hook（内联命令实现）

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

2026-02-04 18:00:55 +08:00

3.5 KiB

Raw Blame History

name, description

name	description
brainstorming	在任何创造性工作之前必须使用 - 创建功能、构建组件、添加功能或修改行为时。探索用户意图、需求和设计，然后再实现。

头脑风暴：将想法转化为设计

概述

通过自然的协作对话，帮助将想法转化为完整的设计和规格。

首先了解当前项目上下文，然后每次只问一个问题来细化想法。一旦你理解了要构建什么，以小节（200-300 字）呈现设计，每节之后确认是否正确。

流程

理解想法

首先查看当前项目状态（文件、文档、最近的提交）
每次只问一个问题来细化想法
尽可能使用多选题，但开放式问题也可以
每条消息只问一个问题 - 如果一个主题需要更多探索，拆分成多个问题
关注理解：目的、约束、成功标准

探索方案

提出 2-3 种不同的方案及其权衡
以对话方式呈现选项，并给出你的推荐和理由
先说推荐的选项并解释原因

呈现设计

一旦你认为理解了要构建什么，呈现设计
将设计分成 200-300 字的小节
每节之后询问是否正确
涵盖：架构、组件、数据流、错误处理、测试
如果有不清楚的地方，准备返回澄清

设计完成后

文档

将验证过的设计写入 docs/plans/YYYY-MM-DD-<topic>-design.md
提交设计文档到 git

输出

完成后输出：

设计文档已完成并保存到 docs/plans/YYYY-MM-DD-<topic>-design.md

下一步：执行 /vibe-plan 创建实现计划。

核心原则

每次只问一个问题 - 不要用多个问题淹没用户
多选题优先 - 在可能时比开放式问题更容易回答
严格遵循 YAGNI - 从所有设计中移除不必要的功能
探索替代方案 - 在确定之前总是提出 2-3 种方案
增量验证 - 分节呈现设计，验证每一节
保持灵活 - 当某些内容不清楚时返回澄清

常见错误

错误	正确做法
一次问多个问题	每条消息只问一个问题
假设用户意图	询问澄清
跳过方案探索	总是提出 2-3 种方案
设计完直接开始编码	等待用户确认设计
添加"可能有用"的功能	严格遵循 YAGNI

危险信号 - 停下来

如果你发现自己想：

"用户可能想要这个功能"
"我先开始编码，边做边设计"
"这个设计很明显，不需要确认"
"我可以跳过方案探索"

所有这些都意味着：停下来。遵循流程。

示例工作流

用户: 我想添加一个用户认证功能

你: 让我先了解一下项目情况...
[查看项目文件和结构]

你: 关于认证方式，你倾向于哪种？
1. 用户名/密码（传统方式）
2. OAuth（第三方登录，如 Google、GitHub）
3. 两者都支持

用户: 先支持用户名/密码

你: 关于密码存储，你有特定的安全要求吗？
1. 使用 bcrypt 哈希（推荐，安全性高）
2. 使用 SHA-256（较快，安全性中等）
3. 有其他要求请说明

用户: 用 bcrypt

你: 好的，让我呈现设计的第一部分...

## 1. 用户模型设计

用户表结构：
- id: UUID
- username: 唯一字符串
- password_hash: bcrypt 哈希
- created_at: 时间戳
- updated_at: 时间戳

这部分设计是否正确？

用户: 是的

你: [继续下一部分...]

[设计完成后]

你: 设计文档已保存到 docs/plans/2026-01-19-user-auth-design.md

请审查设计，确认后我将创建实现计划。

3.5 KiB Raw Blame History Unescape Escape