之前我专门讲过立项篇，但发出去之后我发现，还是有很多人卡在立项这一步。
有的人压根不知道立项该从哪开始。
有的人倒是写了一堆文档，可写得乱七八糟，东一块西一块，到最后连自己都理不清。
所以这一篇，专门来补立项篇没讲透的地方。
立项最基础的部分：为什么不能一句话就让 AI 做项目、怎么和它讨论需求、立项文档该包含什么，这些在之前的立项篇里已经讲得很细了，没看过的建议去合集视频里找一下。
这一篇接着往下讲：立项之后，怎么把项目一步步拆清楚，又怎么把这些文档组织得不乱。
而这，恰恰是最多人做成一团糟的地方。
先补一个小习惯。
立项篇讲过，要给项目建一个文件夹。
在这里我建议你，再在项目里单独开一个放开发资料的子文件夹，名字随意，比如叫 dev-docs。
立项文档、待会儿要讲的功能清单、阶段计划，全都集中放进去。
这个文件夹，就是你和 AI 之间的“规则仓库”，以后每一步开发，都让 AI 回来这里对规则。
这里再多提一句。
dev-docs 里放的，你可以理解成内部资料，只给你自己、或者团队内部的人看，不用对外公开。
所以等以后做 git 版本管理、往远程仓库推代码的时候，建议把这个目录排除掉，不要一起推上去。
但如果你又想给这些文档留个修改记录，可以单独针对这个目录，建一个独立的本地仓库，只在你自己电脑上管它的版本。
这样既不会把内部资料泄露出去，自己又能随时看到文档改了什么。
一、把项目拆成一份对得清清楚楚的功能清单
立项文档解决的是“这个项目大概要做什么”。
但它还比较粗，不能直接拿去写代码。
下一步，是把它拆细，变成一份详细的功能清单。
先说怎么拆。
一个项目，通常有三种拆法，你可以混着用。
第一种，按角色拆：先列清楚有哪些角色，比如普通用户、商家、管理员，再看每个角色各自能做什么。
第二种，按业务流程拆：顺着一件事的流程走，比如下单、支付、发货、确认收货。
第三种，按模块拆：把相关功能归到一起，比如账号模块、商品模块、订单模块。
拆出功能之后，关键是每一个都要“对清楚”。
什么叫对清楚？不是写一句“做一个下单功能”就完了。
一个功能，至少要说明白这几样：谁来用，需要填什么、传什么，最后得到什么结果，涉及哪些角色和权限，正常流程怎么走，遇到异常和边界情况又该怎么办。
这些只要有含糊的地方，AI 写代码时就会自己脑补，补出来的往往不是你要的。
所以所有功能务必全部对清楚，不清楚的，千万别急着写代码。
你可以一边和 AI 过功能，一边让它把功能清单写成文档，哪个功能有问题，就直接在文档上改。
不过有一类功能要特别处理一下，就是复杂功能。
先说什么样的功能算复杂。
举几个最常见的：电商里的角色权限系统、订单的状态流转、支付和退款、优惠券的叠加规则。
它们有个共同点——这个功能自己内部，就藏着一整套规则。
拿订单状态举例：一个订单，要从待支付，到已支付、已发货、已完成，中间还可能拐到退款中、已退款。
每一步能跳到哪一步、由谁触发、跳完之后又影响库存和钱，这是一长串规则。
再拿权限举例：电商里有买家、商家、运营、管理员，每个角色能看什么、能改什么、数据怎么互相隔离，规则也是一大堆。
这种功能，你要是硬塞进功能清单，一两行根本写不下，硬写就会漏；全写又会把清单撑得又臭又长。
所以判断标准很简单：一个功能，如果它自己内部就有一套规则、状态或者分支，或者很多别的功能都要依赖它、引用它，就把它单独拎出来，写成一份专门的文档，再在功能清单里留一个索引指过去。
甚至，如果上面这些标准你也拿不准，那就用最省事的一招：
你自己觉得哪个功能最难、最没把握，就直接把它单独拆出来，写一份。
宁可多拆一份，也别让一个你自己都没想明白的功能，混在清单里被 AI 一笔带过。
这样清单保持清爽，复杂的部分也有地方讲透。
把这些都讲清楚之后，你可以这样要求：
“请根据立项文档，输出一份详细的功能清单。请逐个功能说明：这个功能给谁用、需要哪些输入、产生什么结果、涉及哪些角色和权限、正常流程是什么、有哪些异常和边界情况。如果某个功能特别复杂，比如角色权限系统，请把它单独写成一份文档，并在功能清单里留一个索引指过去。先不要写代码。”
二、功能清单之后，先定大的阶段，别急着定太细
功能都拆清楚了，再往下，是把它们排进几个大的开发阶段。
做项目不要想着一口气全做完，要分阶段来。
但很多人就卡在这一步：到底多大，才算一个“大阶段”？
给你一个最简单的判断标准：一个大阶段做完，得能让某一类用户，完整地跑通一条核心流程，真的能用起来。
我拿电商平台举个例子。
阶段一，也就是最小可用版本 MVP：买家能浏览商品、下单、付款，完成一次完整的购买。这一版先不做商家入驻，商品就由你平台自己上。
阶段二：引入商家端，让商家能入驻、上架商品、管理自己的订单。
阶段三：再做营销，比如优惠券、活动、推荐。
你看，每个阶段做完，都能让某一类人真正用起来——阶段一买家能买，阶段二商家能卖。这就叫大阶段。
那什么不算大阶段？
比如你说“第一阶段就先把登录做完”。
登录只是个零件，光做完它，用户什么也干不了。
它只是某个阶段里的一步，不是一个能独立交付的大阶段。
所以记住：大阶段看的是，能不能交付一个能用起来的东西，而不是做完了多少个功能点。
想清楚怎么分阶段，你可以这样要求：
“请根据功能清单，把开发拆成几个大的阶段。第一个阶段必须是一个能跑通核心流程的最小可用版本（MVP）。请说明每个阶段包含哪些功能、为什么这么排。先只给大的阶段划分，不要现在就细化到具体技术实现和详细开发计划。”
为什么这里特意强调，不要定得太细？
因为这个时候，你的技术栈、底层架构都还没确定。
地基还没打，你就让 AI 去落实一份非常详细的开发计划，那份计划大概率是空中楼阁。
等后面技术路线、后端骨架定下来了，再去细化每个阶段的具体开发计划，才靠谱。
所以这一步记住一句话：阶段先定大方向，细节往后放。
三、文档之间，要连成一条清晰的线
到这里，你的开发资料文件夹里，已经攒了好几份文档：立项文档、功能清单、复杂功能的单独文档、阶段计划。
这里有个很重要的原则：文档组织一定要清晰。
第一，一份文档只干一件事，有它自己明确的职责。
立项文档讲项目是什么，功能清单讲具体有哪些功能，复杂功能文档讲透某一块，阶段计划讲先做什么、后做什么。
第二，文档之间的引用关系，要像一条线一样清楚。
功能清单根据立项文档来，复杂功能从功能清单索引出去，阶段计划又是基于功能清单来排的。
一条线下来，谁依据谁、谁引用谁，都清清楚楚。
千万不要什么都往一个文档里胡乱塞。
一份文档塞太多东西，到最后你自己都找不着，AI 读起来也容易抓错重点。
也不要到处乱引用，这份指那份，那份又绕回来，最后乱成一团。
记住一句话：一份文档一个职责，引用关系是一条清楚的线。
这样以后不管是你自己回看，还是让 AI 回来对规则，都能顺着这条线一路找下去。
四、最后
这一篇补的是立项篇没讲透的地方，重点是立项之后的“拆分”。
总结起来就几句话：
先单独开一个开发资料文件夹，把立项文档、功能清单、阶段计划都集中放好。
把项目拆成一份对得清清楚楚的功能清单——可以按角色、按流程、按模块来拆，每个功能都讲明白谁用、输入输出、权限、正常流程和异常情况，复杂功能单独成篇。
只定大的阶段方向，先 MVP 再细化，别在技术栈还没定时就硬抠详细计划。
而所有这些文档，要组织清晰：一份文档一个职责，引用关系连成一条线，不要什么都胡乱塞。
说到底，立项和拆分这一步，不是在拖时间，而是在给 AI 立规矩。
你前面把规则拆得越清楚，后面 AI 写起来才越不容易跑偏。
还有一点想提醒你：和 AI 讨论立项、拆分，不只是为了给它派活。
AI 的知识面和调研能力其实很强，你认真跟它聊，它还能帮你补全盲区、完善想法。
很多时候一轮聊下来你会发现，项目比你最开始想的更完整，甚至比你预期的还要大。
立项和拆分讲完，后面我会继续按这套流程，一个阶段一个阶段地往下总结。
如果你还没做立项，可以先去翻我之前的立项篇。
