Vibe Coding 架构师

核心问题：架构混乱的陷阱

在进行 Vibe Coding 时，开发者常犯的错误是直接向 AI 输入 “帮我做个 XXX”，期望 AI 能生成完整且结构良好的项目代码。这种“开放生成”模式极易导致代码结构混乱、模块耦合、命名随意和不可维护。当项目规模超过原型阶段时，这种缺乏前期设计的混乱会迅速成为技术债务，导致功能迭代困难、调试成本激增，最终让 AI 辅助编程的优势荡然无存。

该技能如何运作：强制性的结构化流程

这个技能并非一个代码生成器，而是一个强制执行的工程方法论。它通过一个清晰、有序的对话流程，确保你在让 AI 写下第一行代码前，先完成关键的设计决策。

• 触发与分流：首先判断任务类型。简单的 bug 修复或 UI 调整会直接跳过；在已有项目上添加功能则从任务拆解开始；只有从零开始的新项目才进入完整流程。
• 需求澄清（Phase 1）：强制回答 6 个核心问题，例如 产品形态（Web/CLI/Agent）、项目规模（Demo/MVP）和扩展预期。这如同一次快速的需求评审，输出一个确认表格，消除模糊性。
• 架构选型（Phase 2）：基于澄清后的需求，提供 2-3 种具体架构方案（如单文件、MVC、微服务）的对比表，从开发速度、可维护性、扩展性等维度进行评估，并给出明确的推荐及理由。这步将主观选择变为客观权衡。
• 任务拆解与约束（Phase 3及之后）：选定架构后，才进入任务拆分阶段，并使用 10 项架构 Prompt 生成清单来构建最终的 AI 指令。该清单强制包含限制条件（明确“不要做什么”）和非功能需求，从而将架构决策“锁”入 AI 的生成边界中。

适用边界与注意事项

这是一个为 “从零开始”和“大型功能新增” 设计的“重型”工作流。它的价值在于预防混乱，而非提升简单任务的编码速度。

• 适用场景：启动新项目、进行重大重构、或需要引入新架构模式时。
• 不适用场景：修复一个 bug、调整一个 CSS 样式、或在已有成熟架构下添加一个小功能（此时应遵循已有规范，直接拆分任务开发）。
• 关键原则：一旦通过此流程锁定了架构与技术栈，在整个开发周期内应避免轻易更改。其最终产出是一份详尽的、包含明确约束的架构 Prompt，而非即刻运行的代码。核心思想是“先想清楚，再讲清楚，最后写代码”。