> 核心理念：Vibe Coding 的天花板，不是你的 Prompt 写得有多好，而是你架构想清楚没有。
> AI 不怕代码多，怕的是"结构乱"。先选架构，再写代码。
当此 Skill 被触发时，在写任何代码之前，必须按以下流程执行。
如果用户只是：
在选架构之前，必须先回答以下 6 个问题。如果用户没有提供，主动提问；如果信息足够，直接推断并确认。
| # | 必答问题 | 选项/示例 |
|:---|:---|:---|
| 01 | 产品形态：Web / App / 桌面工具 / CLI 脚本 / Agent / 浏览器插件？ | 形态决定技术栈范围 |
| 02 | 运行环境：本地运行 / 云端部署 / 混合？ | 影响数据存储和网络架构 |
| 03 | 项目规模：原型 Demo / MVP / 完整产品？ | 决定架构复杂度 |
| 04 | 数据方案：数据库 / 云存储 / 本地文件 / 无持久化？ | 影响数据层设计 |
| 05 | 前后端分工：纯前端 / 纯后端 / 前后端分离 / 单体全栈？ | 影响模块划分 |
| 06 | 扩展预期：一步到位 / 未来可能扩展 / 必须可扩展？ | 影响架构弹性 |
输出格式：以表格形式展示 6 个问题的答案，让用户确认或修正。
基于 Phase 1 的答案，提供 2-3 种架构方案，用对比表呈现：
| 维度 | 方案 A | 方案 B | 方案 C |
|:---|:---|:---|:---|
| 架构模式 | 单文件 / MVC / DDD / 微服务 | ... | ... |
| 技术栈 | 语言 + 框架 + 数据库 | ... | ... |
| 开发速度 | ⭐⭐⭐⭐⭐ / ⭐⭐⭐ / ⭐⭐ | ... | ... |
| 可维护性 | ⭐⭐⭐ / ⭐⭐⭐⭐ / ⭐⭐⭐⭐⭐ | ... | ... |
| 扩展性 | ⭐⭐ / ⭐⭐⭐⭐ / ⭐⭐⭐⭐⭐ | ... | ... |
| 适用场景 | 简述最适合什么情况 | ... | ... |
然后给出 推荐方案 + 理由，解释为什么不选其他方案。
| 架构模式 | 适用场景 | 复杂度 | 维护成本 |
|:---|:---|:---|:---|
| 单文件架构 | 原型、小工具、一次性脚本（< 300行） | 极低 | 高（难维护） |
| MVC / 三层架构 | 通用 Web/App、CRUD 应用、中小型项目 | 中 | 中 |
| DDD 轻量版 | 复杂业务逻辑、领域规则多、长期维护项目 | 高 | 低 |
| 微服务 / 模块化 | 大型团队协作、多独立功能、高可用要求 | 极高 | 中 |
架构确定后，按功能模块拆分任务：
项目总目标
├── 模块 A（如：用户认证）
│ ├── A.1 子任务
│ └── A.2 子任务
├── 模块 B（如：核心业务逻辑）
│ ├── B.1 子任务
│ └── B.2 子任务
├── 模块 C（如：数据展示）
│ └── ...
└── 模块 D（如：部署上线）
└── ...
规则：
将前面所有决策收敛为一份 可直接用于编码的架构 Prompt，包含以下 10 个组成部分：
## 1. 项目背景
我要做什么，为什么做。（1-2 句话）
## 2. 目标用户
这个东西给谁用。（1 句话）
## 3. 核心需求
最重要的 3-5 个功能点。（列表）
## 4. 架构设定
产品形态 + 架构模式 + 运行环境。（基于 Phase 2 的决策）
## 5. 技术约束
语言 / 框架 / 数据库 / 部署方案。（明确版本号）
## 6. 非功能需求
性能 / 安全 / 可扩展性 / 兼容性要求。
## 7. 实施计划
分阶段实施路线图。（基于 Phase 3 的任务拆解）
## 8. 输出要求
每一步要求 AI 输出什么（代码 + 说明 + 测试）。
## 9. 验收标准
什么叫"完成"：功能正常 / 界面正常 / 数据持久化 / 可访问 / 代码清晰。
## 10. 限制条件（非常重要！）
不要做什么：不过度设计 / 不用不了解的技术栈 / 不引入不必要依赖 / 不大改功能。
进入编码阶段后，严格执行：
| # | 反模式 | 正确做法 |
|:---|:---|:---|
| 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 个架构方案对比，你选一个，我们再开始写代码。
完成 Phase 1-3 后，用此清单生成最终 Prompt：
本方法论提炼自「子圭时安」的 21天 Vibe Coding Challenge Day 005 ——「不会选架构，你就还不会Vibe Coding」。
核心洞见：
> 写代码这件事，其实已经没那么重要了。更重要的是：你能不能先把事情想清楚，再把它讲清楚。
> Vibe Coding 的第一步不是写代码，是先决定这个东西怎么存在。
共 1 个版本