第4章 把“大系统”拆成一张业务地图

真正让项目失控的，往往不是功能太多。
而是所有功能同时出现在你和 AI 面前，却没有人知道谁属于谁、谁依赖谁、谁必须先做。

4.1 一张需求卡解决不了一个系统

第3章结束时，林远已经学会了一件很重要的事：不要把一句模糊想法直接交给 AI。

“增加客户删除功能”被压成了一张可以开发、可以验收的需求卡。

这一步非常有效。

但当他准备继续整理 QuickCRM 时，一个新的问题出现了。

客户列表一张卡。客户详情一张卡。联系人一张卡。销售活动一张卡。CSV 导入 一张卡。权限一张卡。搜索一张卡。标签一张卡。报表以后也可能是一张卡。

如果继续这样写下去，他很快会得到几十张需求卡。

每一张都比以前清楚。

可把它们放在一起，系统仍然像一堆散落在桌面上的拼图。

哪几张属于同一块业务？哪些功能共同完成一个用户目标？哪些是第一版必须有的？哪些只是“有了更好”？哪些功能一旦失败会伤到核心业务？哪些功能可以让 AI 快速尝试，哪些绝不能凭感觉往前冲？

需求卡解