用途：在动手写代码前，把粗略想法收敛为可在一到两周内由一人构建并上线的 v1 规格，只覆盖 v1，不涉及远景与路线图。
使用方式：先只问一个问题“想法是什么？用一句话说”，得到回答后立即挑战范围，并必问“如果这周只能上线一个功能且要带来真实价值，会是哪一个？”答案即核心循环，规格围绕它展开；若用户列出三个功能作为“一个”，需追问哪个优先、若砍掉其余两个保留哪个。未确定这一个核心前不写规格。
主要能力：
- 捕获想法：功能、目标用户（如“用 Next.js 构建的独立 SaaS 创始人”，而非“开发者”）、变现方式（免费/免费增值/付费/积分，不明可跳过）、技术偏好。
- 单一构建规则：检查是否为一个产品而非三个缝合；v1 能否一人一两周构建上线；用户是否有一个明确动作获得价值；过宽则砍。
- 功能切分：LAUNCH（完成核心循环：注册、做那件事、获得价值、你能看到价值）与 LATER（设置、通知、团队协作、管理后台、分析看板、移动优化、集成/Webhook/API 等，默认归 LATER）。判断标准为“移除后用户仍能从 v1 获得价值吗”。
- 数据模型：仅针对 LAUNCH 功能设计，通常 users 与核心资源两张表，含 id(uuid)、email、plan/credits（若 v1 变现）、外键与时间戳；无协作则不加关联表。
- API 路由：仅列 LAUNCH 所需，如 POST /api/auth/signup、POST /api/auth/login、GET /api/auth/me，以及资源的 GET 列表、POST 创建、GET /:id、DELETE /:id；除非编辑是 v1 核心循环，否则不加 PUT/PATCH。
- 页面：/、/login、/signup、/dashboard、/[resource]/:id（如需）、/settings（仅上线所需）。
- 技术栈：按约束推荐并每项一句话解释原因，如最快单人上线用 Next.js + Supabase + Vercel；完全后端控制用 Next.js + Postgres + Prisma + Railway；AI 密集用 Next.js + Vercel AI SDK + Supabase；Python 后端用 FastAPI + Postgres + Supabase Auth。
- 范围削减清单：明确列出 v1 不构建的内容，防止构建期范围蔓延。
- 验证清单：问题陈述一句话、2-3 个有具体痛点的用户画像、核心循环唯一、功能已分 LAUNCH/LATER、数据模型只覆盖 LAUNCH、路由含 HTTP 方法、所有页面有路由、栈有理由、削减清单明确、整体一人一两周可构建。
适用场景：准备开始编码前，需要把已验证想法收敛成可执行 v1 规格的独立开发者或小团队。
限制：不覆盖 v1 之外的规划；除非用户提供，不编造需求；若无法确定唯一核心功能，则不适合进入规格阶段。