项目规划与需求分析

为什么先别急着写代码

新手最常见的做法：兴奋地把整个产品需求一股脑甩给 Claude——"帮我做一个完整的 XX 应用，需要登录、数据库、付费、推送、分享..."

Claude 确实会开始做，但最终产出往往是一团乱。信息太多太杂，它只能猜你最想要什么，猜错的概率非常高。

[!TIP] 核心原则 拆成最小可验证的步骤。先做登录，确认能跑。再做数据存储，确认能存能取。然后是核心业务逻辑，然后才是 UI。每一步验证通过，再进下一步。

推荐 vs 不推荐的需求描述

推荐——分步给需求：

先实现 GitHub OAuth 登录。登录成功后在页面上显示用户名和头像。

验证通过后再说：

现在添加获取 commit 的 API。获取登录用户最近 7 天在所有 repo 的 commit，返回 JSON。

不推荐——一股脑全甩：

做一个周报工具，需要 GitHub 登录、获取 commit、AI 总结、漂亮的 UI、分享功能、Slack 通知、部署到 Vercel。

规划流程

第一步：让 Claude 采访你

当你要做一个比较大的功能时，不要一上来就写需求文档。先对 Claude 说：

我想做一个支付功能，在动手之前，先采访我，
问清楚所有你需要知道的事情。

Claude 会问你一系列问题：支持哪些支付方式？需要处理退款吗？并发量预估多少？需要支持 webhook 回调吗？

这些问题中，至少有一半是你自己没考虑过的。

第二步：生成 SPEC.md

采访结束后，让 Claude 把答案整理成一份规格文档（Spec）。

第三步：开新会话执行

关键来了：开一个全新的会话，把 Spec 喂给新的 Claude，让它执行。

为什么要开新会话？因为采访过程中积累的对话历史已经很长了，占了大量上下文。新会话从一份干净的 Spec 开始，Claude 能更专注地执行。

先跑通最简版本

先做一个能跑的最简版本，自己用两天，发现真正需要什么再加。你脑子里想象的功能和实际用起来需要的功能，往往差异很大。

[!NOTE] 产品节奏 想法 → 1 天做出 MVP → 自己用 3 天 → 找 10 个人测试 → 根据反馈迭代 → 觉得还行就上线 → 数据说话。

常见陷阱

提前知道这些坑，能帮你省掉不少返工时间。