全流程产品开发工作流

> 💡 这套工作流由小红书博主 元气一颗梨（AIPM） 用心打磨，从很多次 vibe coding 翻车中提炼而成。她相信：好的工具不该让人越来越累——AI 应该帮你把混乱的想法变成稳定的产品，而不是制造更多混乱。
>
> 这个 skill 覆盖从环境安装到项目测试的完整链路，融合 SDD（Specification-Driven Development，规格驱动开发）、设计系统工程化、双审计机制、渐进式增量开发等方法论。人主要做 review——确认方向对不对、设计好不好看、代码有没有问题，其余全部由 AI 驱动。

一、定位

目标用户：想用 AI 快速搭建系统，但缺乏工程经验、不知道怎么产出稳定系统的 vibe coding 人群。

核心价值：把"胡乱 vibe → 系统崩溃"变成"按流程 vibe → 稳定交付"。

解决的核心问题：

不是：代码补全工具、技术教程、UI 组件库。是：产品开发全流程的引导者和质量守卫。

二、触发条件

以下任一情况自动触发本 Skill：

• 明确开发需求：「我想做一个课程管理系统」「帮我搭一个博客」「开发一个 xxx 功能」
• 模糊启动意图：「不知道怎么开始」「想用 AI 做个东西」「有个想法但说不清楚」
• 开发流程求助：「帮我写个 PRD」「这个功能怎么设计」「给我做个原型」
• 项目冷启动：用户提到新项目但没有项目文件结构

不触发的情况：
- 单纯的代码 bug 修复（已有项目的小改动）
- 纯技术问答（"React 怎么用"）
- 已有明确流程管理的项目（走项目自身 workflow）

三、动态工作流

                    ┌─────────────────┐
                    │  首次使用？       │
                    │  解释环境作用     │
                    │  问：已有环境？   │
                    │  有→验证 / 无→装  │ → reference/environment-setup.md
                    └──────┬──────────┘
                           ↓
                    ┌─────────────────┐
                    │  有项目骨架？     │
                    │  无 → 搭建脚手架  │ → reference/project-scaffolding.md
                    └──────┬──────────┘
                           ↓
                    ┌─────────────────┐
                    │  新项目？        │
                    │  是 → 基础建设   │ → reference/infrastructure.md
                    │  搭建组件库地基   │   (首次，后续跳过)
                    └──────┬──────────┘
                           ↓
                    ┌─────────────────┐
                    │  项目宪章       │
                    │  定规则和边界    │ → reference/constitution.md
                    │  (首次，后续跳过) │
                    └──────┬──────────┘
                           ↓
          ┌─────────────────────────────────────┐
          │         用户提出功能需求              │
          └────────────────┬────────────────────┘
                           ↓
          ┌─────────────────────────────────────┐
          │  Phase 0: 需求确认                  │
          │  ① 选择审计模式（A/B/C）            │
          │  ② 先问：有现成 PRD 吗？            │
          │  有→存入 reference/，跳过提问        │
          │  无→苏格拉底提问，最多 3 轮           │
          │  → reference/phase/phase-0-requirements.md │
          └────────────────┬────────────────────┘
                           ↓ 审计 ✓
          ┌─────────────────────────────────────┐
          │  Phase 1: PRD 输出                  │
          │  结构化 PRD 文档                     │
          │  → reference/phase/phase-1-prd.md         │
          └────────────────┬────────────────────┘
                           ↓ 审计 ✓
          ┌─────────────────────────────────────┐
          │  Phase 2: 设计思路                   │
          │  交互设计 + UI 要点 + 组件清单        │
          │  → reference/phase/phase-2-design.md       │
          └────────────────┬────────────────────┘
                           ↓ 审计 ✓
                           ↓
                    ┌──────┴──────┐
                    │  新增 UI 组件？│
                    └──┬───────┬──┘
                   是  │       │  否 → 快速路径 → Phase 8
                       ↓       │
          ┌─────────────────┐  │
          │  Phase 3: 视觉探索│  │
          │  → reference/    │  │
          │    phase-3-visual│  │
          └────────┬────────┘  │
                   ↓ 审计 ✓    │
          ┌─────────────────┐  │
          │  Phase 4: 设计   │  │
          │  系统提取 │  │
          │  → reference/    │  │
          │    phase-4-design │  │
          │    -system        │  │
          └────────┬────────┘  │
                   ↓ 审计 ✓    │
          ┌─────────────────┐  │
          │  Phase 5:        │  │
          │  DESIGN.md 生成  │  │
          │  → reference/    │  │
          │    phase-5-design│  │
          │    -md           │  │
          └────────┬────────┘  │
                   ↓ 审计 ✓    │
          ┌─────────────────┐  │
          │  Phase 6: 组件   │  │
          │  母版验证 │  │
          │  → reference/    │  │
          │    phase-6-       │  │
          │    component      │  │
          └────────┬────────┘  │
                   ↓ 审计 ✓    │
          ┌─────────────────┐  │
          │  Phase 7: 组件库 │  │
          │  工程化           │  │
          │  → reference/    │  │
          │    phase-7-       │  │
          │    engineering    │  │
          └────────┬────────┘  │
                   ↓           │
          ┌─────────────────────────────────────┐
          │  Phase 8: Spec 开发工作流            │
          │  4 步闭环: Specify → Plan → Task →   │
          │  Implement → Checklist               │
          │  → reference/phase/phase-8-spec-workflow.md│
          └────────────────┬────────────────────┘
                           ↓ 审计 ✓
          ┌─────────────────────────────────────┐
          │  🎉 交付                              │
          │  产出汇总到 output/                   │
          └─────────────────────────────────────┘

分支规则：Phase 3（视觉探索）只要功能有 UI 就必做——生成整体页面视觉参考。Phase 3 完成后判断：
- 新增组件 且 组件库无 → 进 Phase 4-7 构建新组件
- 现有组件库可覆盖 → 基于视觉参考 + 现有组件库，直接进入 Phase 8 开发

技术架构师（Phase 2 后，可与 Phase 3-7 并行）

Phase 2 完成后，同步启动技术架构师角色（详见 tech-architect-role.md）：
- 输入：Phase 1 PRD + Phase 2 页面结构
- 输出：技术架构文档（技术选型 + 取舍论证 + 数据模型 + API 设计 + 部署方案）
- 与 Phase 3-7 并行执行（技术选型不依赖视觉设计）
- 架构文档最终汇入 Phase 8（Spec 开发）

四、首次使用：环境检查

> 详细操作见 reference/environment-setup.md

当用户首次使用本 Skill 时，按以下顺序执行：

1. 先解释开发环境是什么、为什么需要它（用通俗类比：Node.js 是"翻译官"，把 AI 写的代码翻译成浏览器能跑的东西）
2. 询问用户是否已有环境：「你电脑上已经有 Node.js、pnpm、Git 这些了吗？」
   - 有 → 快速验证 node -v && pnpm -v && git --version，通过则跳过安装
   - 没有 → 进入下一步
3. 询问操作系统：「Mac 还是 Windows？」→ 进入对应安装链路（全链路：基础工具 → nvm → Node.js → npm 镜像 → pnpm → Git → 提醒自选编辑器）
4. 逐步引导安装：每步解释为什么要装 → 给出命令 → 验证 → 确认成功后才进入下一步
5. 环境就绪后才进入项目脚手架

五、项目脚手架

> 详细操作见 reference/project-scaffolding.md

环境就绪后，引导用户创建标准项目结构：

project-name/
├── CLAUDE.md           # AI 协作配置
├── README.md           # 项目总览
├── input/              # 收件箱，原始输入
├── output/             # 各阶段交付物
│   ├── research/       # 调研分析
│   ├── requirements/   # PRD、功能列表
│   ├── design/         # 原型、交互设计
│   ├── development/    # 技术规格、架构
│   └── acceptance/     # 测试用例、验收标准
├── reference/          # 参考资料
└── skill/              # 项目专用 skills

流程：input → output/research → output/requirements → output/design → output/development → output/acceptance

六、通用规则

每个 Phase 的执行模板

每个 Phase 必须按以下三步执行，不可跳过：

① 设计要求（亮出来，用户确认方向）
       ↓
② 执行（主 agent 产出）
       ↓
③ 审计（subagent 独立检查 + 用户终审）

① 设计要求——执行前先输出：

> ## Phase N: [名称] — 设计要求
>
> ### 本阶段目标
> [一句话]
>
> ### 执行步骤
> | 步骤 | 内容 |
> |------|------|
> | ... | ... |
>
> ### 产出物
> [文件路径 / 对话输出]
>
> ### 审计检查项
> | # | 检查项 |
> |---|--------|
> | ... | ... |
>
> 确认后我开始执行。

② 执行——用户确认后产出。

③ 审计——按用户选择的模式（A 严格 / B 灵活 / C 轻量）执行审计。

审计机制

> 详细操作见 reference/audit-mechanism.md

每个 Phase 完成后必须执行：

1. Subagent 独立审计 — 独立审计 agent 按审计清单逐项检查产出物，输出审计报告
2. 用户终审 — 审计报告 + 产出物提交用户确认
3. 结果处理 — 通过→下一 Phase / 修改→修正后重新审计 / 打回→回退到指定 Phase

审计报告格式：每个 Phase 的审计清单见对应 reference 文件。

自动化执行门控

技术栈

> 详细约束见 reference/tech-stack.md

默认技术栈：Next.js 16 + React 19 + TypeScript + Tailwind CSS v4 + Prisma + pnpm。

七、角色体系

本 Skill 在每个阶段自动切换角色：

八、各阶段快速索引

九、注意事项

1. 每个 Phase 必须等待用户确认后才能进入下一个 Phase
2. 审计报告在每个 Phase 结束时必须输出
3. 苏格拉底提问最多 3 轮，3 轮后必须输出确认摘要
4. 新增组件判断在 Phase 2 完成后执行，不要提前假设
5. Token 命名以 DESIGN.md 为唯一权威来源
6. 所有文件产出使用 Markdown 格式
7. 首次使用必须先走环境检查 → 项目脚手架，再进入功能开发