核心原则：把"做一顿饭"拆成"买菜→洗菜→炒菜"，而不是一口吃成胖子
一、按用户动线拆（最常用）
方法：跟着用户手指的点击顺序拆
示例：做一个"在线预约挂号"功能
- 第一步：选医院/科室（解决"去哪看"）
- 第二步：选医生/时间（解决"找谁看、何时看"）
- 第三步：填写就诊人信息（解决"谁看病"）
- 第四步：支付挂号费（解决"怎么付钱"）
- 第五步：生成电子凭证（解决"怎么取号"）
验收标准：每一步都能独立测试，第一步做完用户能看到医院列表就算成功。
二、按数据流转拆（技术友好型）
方法：看数据从哪进、经过哪、到哪出
示例：做一个"员工报销系统"
- 第一步：表单提交（只做前端页面+数据保存）
- 第二步：图片上传（对接OSS存储）
- 第三步：审批流（只做"通过/驳回"两个按钮）
- 第四步：财务打款（对接银企直联接口）
- 第五步：邮件通知（发成功/失败提醒）
好处：每做完一步，开发和测试都能拿到阶段性成果，避免全部堆在最后联调。
三、主流程与异常分离（风险控制）
黄金法则：先跑通" sunny day "（晴天场景），再处理" rainy day "（雨天场景）
示例：做"优惠券发放"
- 第一版：只处理"领取成功"（90%场景）
- 第二版：处理"已领完"、"网络超时"、"重复领取"（边界情况）
注意：第一版上线时，异常场景至少要有兜底提示（如"系统繁忙，请稍后再试"），不能让用户看到白屏。
四、按价值高低拆（MVP思维）
灵魂拷问：如果只做20%的功能就能解决80%的问题，先做哪20%？
实操技巧：
- 画四象限：横轴是用户价值，纵轴是开发成本
- 先砍右上角：价值高且成本低的先做
- 冷冻左下角：价值低且成本高的果断放到二期
真实案例：做"智能客服"
- 先做：关键词自动回复（开发3天，解决60%常见问题）
- 后做：AI语义理解（开发2个月，解决剩下40%）
五、拆分检查清单
拆完后的每个子需求必须满足：
- [ ] 可交付：做完能给用户看，不是半成品
- [ ] 可测试：QA能单独验证这个功能点
- [ ] 可回滚：如果上线出问题，能单独关闭这一个点不影响全局
- [ ] 有数据：能统计出这个功能的使用情况
避坑指南
- 别拆太碎：小于2人天的需求不要单独拆，管理成本太高
- 保留关联性：拆分时标注清楚"做这个之前必须先完成哪个"
- 预留缓冲：大功能拆分后总工时乘以1.2系数（联调、改bug总要时间）
一句话总结：拆分的本质不是把大石头砸成小石头，而是把"造汽车"改成"先造滑板，再升级成自行车，最后加装引擎"。