Vibe Coding 架构选型与项目启动方法论

核心理念：Vibe Coding 的天花板，不是你的 Prompt 写得有多好，而是你架构想清楚没有。 AI 不怕代码多，怕的是"结构乱"。先选架构，再写代码。

强制工作流 — 必须按顺序执行

当此 Skill 被触发时，在写任何代码之前，必须按以下流程执行。

Phase 0: 判断是否需要完整流程

如果用户只是：

修一个 bug / 改一个 UI 样式 → 跳过此 Skill，直接干活
在已有项目上添加小功能 → 跳到 Phase 3（拆任务）
从零开始一个新项目 → 继续完整流程

Phase 1: 需求澄清（6个必答问题）

在选架构之前，必须先回答以下 6 个问题。如果用户没有提供，主动提问；如果信息足够，直接推断并确认。

#	必答问题	选项/示例
01	产品形态：Web / App / 桌面工具 / CLI 脚本 / Agent / 浏览器插件？	形态决定技术栈范围
02	运行环境：本地运行 / 云端部署 / 混合？	影响数据存储和网络架构
03	项目规模：原型 Demo / MVP / 完整产品？	决定架构复杂度
04	数据方案：数据库 / 云存储 / 本地文件 / 无持久化？	影响数据层设计
05	前后端分工：纯前端 / 纯后端 / 前后端分离 / 单体全栈？	影响模块划分
06	扩展预期：一步到位 / 未来可能扩展 / 必须可扩展？	影响架构弹性

输出格式：以表格形式展示 6 个问题的答案，让用户确认或修正。

Phase 2: 架构选型（提供 2-3 种方案对比）

基于 Phase 1 的答案，提供 2-3 种架构方案，用对比表呈现：

维度	方案 A	方案 B	方案 C
架构模式	单文件 / MVC / DDD / 微服务	...	...
技术栈	语言 + 框架 + 数据库	...	...
开发速度	⭐⭐⭐⭐⭐ / ⭐⭐⭐ / ⭐⭐	...	...
可维护性	⭐⭐⭐ / ⭐⭐⭐⭐ / ⭐⭐⭐⭐⭐	...	...
扩展性	⭐⭐ / ⭐⭐⭐⭐ / ⭐⭐⭐⭐⭐	...	...
适用场景	简述最适合什么情况	...	...

然后给出 推荐方案 + 理由，解释为什么不选其他方案。

架构模式速查表

架构模式	适用场景	复杂度	维护成本
单文件架构	原型、小工具、一次性脚本（< 300行）	极低	高（难维护）
MVC / 三层架构	通用 Web/App、CRUD 应用、中小型项目	中	中
DDD 轻量版	复杂业务逻辑、领域规则多、长期维护项目	高	低
微服务 / 模块化	大型团队协作、多独立功能、高可用要求	极高	中

Phase 3: 任务拆解

架构确定后，按功能模块拆分任务：

项目总目标
├── 模块 A（如：用户认证）
│   ├── A.1 子任务
│   └── A.2 子任务
├── 模块 B（如：核心业务逻辑）
│   ├── B.1 子任务
│   └── B.2 子任务
├── 模块 C（如：数据展示）
│   └── ...
└── 模块 D（如：部署上线）
    └── ...

规则：

每个模块独立可验证
标注模块间依赖关系
按优先级排序（核心功能优先）
每次只做一个模块，不要一次生成所有代码

Phase 4: 生成架构 Prompt

将前面所有决策收敛为一份 可直接用于编码的架构 Prompt，包含以下 10 个组成部分：

## 1. 项目背景
我要做什么，为什么做。（1-2 句话）

## 2. 目标用户
这个东西给谁用。（1 句话）

## 3. 核心需求
最重要的 3-5 个功能点。（列表）

## 4. 架构设定
产品形态 + 架构模式 + 运行环境。（基于 Phase 2 的决策）

## 5. 技术约束
语言 / 框架 / 数据库 / 部署方案。（明确版本号）

## 6. 非功能需求
性能 / 安全 / 可扩展性 / 兼容性要求。

## 7. 实施计划
分阶段实施路线图。（基于 Phase 3 的任务拆解）

## 8. 输出要求
每一步要求 AI 输出什么（代码 + 说明 + 测试）。

## 9. 验收标准
什么叫"完成"：功能正常 / 界面正常 / 数据持久化 / 可访问 / 代码清晰。

## 10. 限制条件（非常重要！）
不要做什么：不过度设计 / 不用不了解的技术栈 / 不引入不必要依赖 / 不大改功能。

Phase 5: 逐步实施

进入编码阶段后，严格执行：

小步快跑：每次只让 AI 做一个模块
及时验证：完成一个模块就运行、测试
发现问题：立即修复，不要积累技术债
保持架构：每次新增代码都必须符合已确定的架构
先完成再完美：MVP 能跑起来 > 功能完美但跑不起来

反模式（绝对要避免）

#	反模式	正确做法
1	打开工具就写 Prompt，直接让 AI 生成全部代码	先过 6 个必答问题，选架构
2	不告诉 AI 架构约束，让它自由发挥	用 10 部分架构 Prompt 明确约束
3	一次要求生成整个项目	按模块拆分，每次只做一个
4	只告诉 AI "要做什么"，不说"不要做什么"	第 10 项限制条件必须写
5	跳过测试直接推进	每个模块完成后立即运行验证
6	没验证就认为"应该没问题"	每次修改后必须独立运行确认
7	技术栈来回变，没有统一标准	Phase 2 锁定后不再改
8	文件夹乱、命名乱、越做越看不懂	架构里明确目录结构规范

快速启动模板

当用户说"帮我做个 XXX"时，直接使用以下对话模板：

你好，在开始写代码之前，我需要先帮你选架构。请回答几个问题：

1. 这个 [XXX] 是什么形态？（网页 / 桌面工具 / 手机App / 命令行脚本 / 其他）
2. 跑在哪里？（自己电脑 / 服务器 / 云平台）
3. 是先做个能用的原型，还是要做一个完整产品？
4. 需要存数据吗？（数据库 / 文件 / 不需要）
5. 你熟悉什么技术？（我根据你的技术背景推荐方案）
6. 未来会扩展吗？（比如加新功能、多人用、对外开放）

回答完这些，我会给你 2-3 个架构方案对比，你选一个，我们再开始写代码。

架构 Prompt 生成清单

完成 Phase 1-3 后，用此清单生成最终 Prompt：

项目背景（1-2句话，为什么要做）
目标用户（给谁用）
核心需求（3-5个功能点，按优先级排序）
架构设定（形态 + 模式 + 环境）
技术约束（语言 + 框架 + 数据库 + 部署，含版本号）
非功能需求（性能/安全/扩展/兼容）
实施计划（分阶段，每阶段目标明确）
输出要求（代码 + 说明 + 测试的标准）
验收标准（什么叫"完成"）
限制条件（不要做什么，至少4条）

来源与致谢

本方法论提炼自「子圭时安」的 21天 Vibe Coding Challenge Day 005 ——「不会选架构，你就还不会Vibe Coding」。

核心洞见：

写代码这件事，其实已经没那么重要了。更重要的是：你能不能先把事情想清楚，再把它讲清楚。 Vibe Coding 的第一步不是写代码，是先决定这个东西怎么存在。

vibe-coding-architect

SKILL.md.claude/skills/vibe-coding-architect/SKILL.md