用 Claude Code 做需求拆解：比你自己想得更细

那天我把需求描述给它，说：帮我做用户订阅功能，支持月付和年付，Stripe 接入。

它没有直接开始写代码。

它给我列了一张清单，十七条。涉及 Stripe Checkout Session 的创建、Webhook 的各种状态处理、订阅到期后的降级逻辑、用户取消订阅的 grace period、试用期结束的邮件通知……

我盯着那张清单，差点晕倒。

我以为这是一个功能。实际上是十七个。如果我直接让它写代码，那代码肯定只覆盖了最表层的三四个——剩下的会在上线后一个个炸给我看。

独立开发者最容易在哪里翻车

不是技术能力不够，是需求拆解不到位。

我见过太多情况：一个独立开发者花了两周写完一个功能，上线第三天用户反馈”我取消订阅了但还在扣款”，或者”我试用期过了但账号直接被封了没有任何提示”。

这不是 bug，是没想到的功能场景。

说人话就是：你以为做完了，其实你只做了 happy path。那些边界情况、异常场景、用户视角下的关键细节，没有人帮你想，你自己又在赶进度——就这样上线了。

我当时也是这种状态。一个人干，脑子里装着产品、营销、客服、代码，根本没有足够的带宽做完整的需求拆解。

直到我开始让 Claude Code 帮我拆需求，才意识到原来”想清楚”是一件需要刻意投入时间的事——而且它比我想得更细。

需求拆解的四步框架

我用了一年多，把这套流程固定下来。

第一步：用一句话描述需求，让它问你问题

不要一开始就让它帮你拆，先让它向你提问。

我要给我的 SaaS 工具加订阅功能，支持月付和年付，用 Stripe。在你开始帮我拆分任务之前，先问我你需要知道的问题，确保你完全理解这个需求。

它会问你大概七到十个问题，比如：

• 是否有试用期？试用期结束后未付款的账号如何处理？
• 用户能否在月付和年付之间切换？切换时的费用如何计算？
• 订阅到期后是否有 grace period？还是立刻锁定账号？
• 取消订阅后用户的数据保留多久？
• 是否需要支持退款？退款触发条件是什么？
• 订阅状态变更是否需要发邮件通知？哪些状态变更需要？

这些问题本身就是价值。

很多问题你可能之前没想到。看到问题的一瞬间，你才意识到”这个我还没决定”。这个阶段花半小时回答这些问题，比上线后修复那些”没想到的场景”要便宜得多。

第二步：让它基于你的回答生成完整任务清单

把第一步的所有问题回答完，然后：

好的，基于我的回答，帮我生成完整的任务清单。每个任务要具体到”实现 XX 功能/处理 XX 场景”这个粒度，不要笼统地说”处理支付逻辑”。按照功能模块分组，标注每个任务的依赖关系（哪个必须先做）。

它会给你一个分组清单，类似这样：

【模块一：Stripe 基础接入】（无依赖，优先实现）
1. 创建 Stripe Checkout Session（月付/年付两种 price_id）
2. 实现 success_url 和 cancel_url 的跳转逻辑
3. 初始化 Stripe Webhook 端点并验证 signature

【模块二：Webhook 事件处理】（依赖模块一）
4. 处理 checkout.session.completed → 更新数据库 subscription 状态为 active
5. 处理 customer.subscription.updated → 同步 plan 变更
6. 处理 customer.subscription.deleted → 触发降级逻辑
7. 处理 invoice.payment_failed → 标记 past_due，发邮件提醒
8. 处理 invoice.payment_succeeded → 更新 current_period_end

【模块三：用户操作】（依赖模块二）
9. 实现"升级到付费计划"入口和跳转 Checkout
10. 实现"取消订阅"功能（调用 Stripe cancel_at_period_end）
11. 实现"月付/年付切换"（调用 Stripe subscription update）
12. 展示当前订阅状态和下次扣费日期

【模块四：边界场景处理】
13. 试用期结束未付款 → 发邮件提醒，7天后锁定账号
14. 账号锁定后登录 → 展示"订阅已过期"页面，引导续费
15. Stripe customer 不存在时的容错处理
16. 重复 Webhook 事件的幂等性处理
17. 退款申请 → 手动处理流程（不自动退款）

大多数教程不告诉你的细节在这里： 模块四的”边界场景处理”，是大多数人第一次拆需求时完全忽略的部分。

幂等性处理尤其重要。Stripe 的 Webhook 在某些情况下会重试发送同一个事件——如果你的处理函数没有检查”这个事件我是否处理过”，同一笔订单可能在数据库里写入两次。这是生产环境里真实发生过的问题，不是理论上的。

第三步：让它评估每个任务的工作量和风险

清单有了，下一步不是直接开始写代码，是排优先级。

对这个任务清单里的每个任务，评估：1）实现难度（简单/中等/复杂）；2）出错代价（低/中/高，出错了对用户影响多大）；3）实现顺序建议。如果某些任务有”看起来简单但容易踩坑”的地方，单独提出来。

它给出的评估会让你意识到哪些任务表面简单实则危险。

比如”月付/年付切换”，看起来就是改一下 Stripe 的 subscription，但实际上涉及到按比例退款的计算、旧 subscription item 的删除和新 item 的添加，Stripe API 的调用顺序如果错了会产生双重收费。它会告诉你这个任务的风险级别是高，并建议你单独分配测试时间。

第四步：逐个任务实现——每次只做一件事

清单和优先级都有了，进入实现阶段。

原则只有一个：每次 Claude Code 会话只做清单里的一个任务。

不是两个，不是”把这几个相关的一起做”，是一个。

为什么？因为任务越多，它越容易在某个地方走捷径，或者做了你不想要的关联改动。每次一个任务，输出可控，也方便你逐个验证。

# 开始新任务前，用这个模板启动会话
claude

然后：

当前任务：实现 Webhook 处理函数中对 invoice.payment_failed 事件的处理。

处理逻辑：收到事件后，将 Prisma 数据库里对应用户的 subscription.status 更新为 past_due，同时触发发送邮件（用 Resend），邮件模板是”payment-failed”，发送到 user.email。

相关文件：app/api/webhooks/stripe/route.ts（已有 Webhook 框架，需要在这里添加新的事件处理）、lib/email.ts（已有 Resend 初始化，有 sendEmail 函数）

约束：不要修改 Webhook 函数的基础结构，只在 switch 语句里添加新的 case。幂等性检查：先查 subscriptionEvents 表里有没有这个 event.id，有的话直接返回。

这个 Prompt 精准到直接给出了实现目标、相关文件、约束条件和幂等性要求。它能做的就是按这个规格实现，不会越界。

踩坑环节

坑一：让它一次性实现整个订阅模块，代码有但没测试过边界

刚开始用这个方法时，我有一次没忍住，让它”把订阅功能全部实现”。

它给了我一大段代码，覆盖了 Checkout、Webhook、用户界面，看起来很完整。

上线两天后，有一个用户取消订阅后重新订阅，触发了一个之前没有覆盖的场景：他在取消订阅的 grace period 里重新订阅，Stripe 创建了新的 subscription，但我的代码没有处理”同一个用户存在两个 subscription 记录”的情况——数据库主键冲突，报 500 错误。

我花了三个小时修复，还要手动处理那个用户的数据。

解决方案： 任务必须一个一个做，做完一个、测一个、commit 一个。“全部一起实现”只是看起来快，实际上是把风险全部推后积累。

坑二：跳过了”让它问你问题”的步骤，拆出来的需求有遗漏

有一次我急着做，觉得让它问问题太耗时间，直接让它基于我的描述拆任务。

它拆出来的清单漏掉了”订阅状态变更的邮件通知”——因为我的需求描述里没有提到，它就没有包含进去。

我没发现。上线后有用户反馈说订阅续费了但没有收到任何确认邮件，觉得被扣款了但不知道是否成功，给我发了一封措辞强硬的投诉邮件。

那种感觉很糟糕，因为邮件逻辑其实很简单，加起来就两个小时的工作量。但就是因为没在拆需求阶段想到，导致了一次用户信任的损失。

解决方案： “让它问你问题”这一步不能跳过，那十个问题里藏着你的盲区。你急得省下的半小时，会在上线后以三倍时间的代价还回来。

总结

需求拆解的本质是：把所有”你以为知道但其实没想清楚”的地方，提前暴露出来。

做不到这一点，写出来的代码就是在赌运气。一个人开发，没有团队帮你兜底，你必须比任何人都想得更细。

Claude Code 做这件事的价值，不在于它帮你写了多少代码，在于它逼你想清楚了多少你本来会跳过的细节。

---

最后一个实际的问题： 你现在在做或者计划做的功能里，有没有某个”感觉很清楚但可能没想全”的需求？用今天这套流程的第一步试试——把需求描述给 Claude Code，让它向你提问——看看它问出来的问题里，有没有你之前没想到的。结果怎样，可以告诉我。

---

原文链接: https://mp.weixin.qq.com/s/E01lug5bpMP7XZxjnP10CA