1. 切片开发切的是什么先对齐定义1.1 垂直切片和水平切片别搞混一说“切片开发”很多人的第一反应是数据库分片、视频文件切片或者监控数据的采样切片。这些都对但我要讲的“切片开发”指的是软件交付过程中的需求切片更准确地说是敏捷迭代里的垂直切片Vertical Slice。这个词我在带迭代和做技术管理时反复提因为它几乎决定了一个团队能不能稳定交付、能不能快速响应变化。垂直切片的意思很简单每次交付一个从用户操作到系统反馈都完整可运行的小功能满足一个具体的业务场景而不是按“数据库层—接口层—界面层”这样水平地切。水平切片也有人说成“按技术层次切”比如第一周做建表第二周做接口第三周做界面最后三天联调。这种切法在PPT上很好讲实际开发中却是坑人的。为什么垂直切片是“最核心方法”因为它直接回答了软件项目中两个最致命的问题这个功能什么时候才能给人看和哪些需求可以先不做水平切片会把所有风险堆到最后那个“集成阶段”而垂直切片把风险分散到每一次交付里。说白了垂直切片追求的是“每一切完用户和产品都能看到点东西、能点一点、能验收”。1.2 为什么大家习惯按“层”切以及这个习惯从哪来按层切几乎是工程师的本能因为代码结构本来就是分层的。我见过很多团队需求下来第一反应是“先画表结构”“先把DTO定了”“先把接口定义出来”。这种习惯不能说错它是技术分解逻辑但它不是交付逻辑。用交付逻辑看研发唯一标准是这一个周期结束时有没有什么东西可以部署到线上让用户用按层切的问题在于前几周产出的表结构、接口都没有独立价值用户看不到、验证不了只有到联调阶段才第一次出现“可运行的整体”一旦有问题所有模块一起返工压力特别大。按层切的另一个诱因是团队协作模式。前端团队、后端团队、DBA各自有职责范围大家下意识就把工作按角色划分了。但垂直切片并不要求所有人同时围着一个切片转而是要求每一个切片都跨越这些角色一个需求切片可能涉及一张新表、两个接口、一个页面、一个状态流转。它是横着跨学科协作的不是纵着按专业分的。很多团队切换不过来是因为组织协作方式没跟着变不是方法论不行。1.3 一个合格的切片要长成什么样我自己判断切片合不合格用四个问题这个切片交付后用户能完成一个完整的动作吗比如“选一件商品加入购物车并看到合计金额”。这个切片能不能独立测试、独立部署、独立回滚哪怕其他切片还没做完。这个切片有没有明确的验收标准验收标准是不是可以被写成自动化测试或手动测试步骤这个切片切完之后是否让整个系统更接近最终目标而不是产生需要后续重构的临时逻辑如果四个问题里有任何一个答不上来切片就是不合格的。很多人把“一个功能的一个步骤”叫作切片比如“用户能点击登录按钮”——这是界面行为不是完整动作。一个最小切片至少要形成“输入—处理—输出”闭环中间可以有简化逻辑但不能是半成品。2. 切片的核心方法与完整策略2.1 切片的前置动作先把需求讲到“能演示”很多人问“怎么切片”其实第一步不是切是把需求整理成能讲清“谁、在什么场景下、要做什么、结果是什么”的一句话。这句话是切片的前提也是后续验收标准的地基。我常用的要求是每次开切片会前产品经理至少要把需求描述到“我能闭着眼描述这个功能给不相关的人听他能理解用户在干什么”的程度。如果需求本身是模糊的切出来的每个切片也会是模糊的。举个例子“做一个订单管理后台”这话没法切因为管理员、客服、财务看订单的角度完全不同涉及的操作也完全不同。先把它拆成“客服希望快速检索订单并修改地址”“财务希望导出特定时间段的结算单”切片才有抓手。这一步做扎实了后面所有切片都是在“用户故事/业务步骤”上做文章而不是在技术空想上做文章。我甚至建议产品经理把需求写成“用户故事补充条件”的格式作为某类角色我想要某项能力以便实现某个目的。这句话写完之后下一步才是切片。2.2 五种实战切片方法含具体案例第一种按用户完整旅程的关键节点切拿出一张纸把用户从进入功能到离开功能的每一步都写下来。比如“优惠券功能”完整旅程是查看领券入口—领取一张券—在订单结算页看到可用券—勾选抵扣—支付成功后核销—过期前收到提醒。这里每一步都可以形成一个独立切片越靠前入口的越优先做因为用户没入口的话后面的流程都无法验证。我做过一个案例团队原本的计划是把优惠券的创建、发放、核销、对账全做完再上线那是一个月的工作量。按旅程拆分后第一周只做了“后台创建一张固定优惠券 用户直接在个人中心看到并领取”第二周再做结算页的抵扣。第一周的东西虽然简陋但确实让用户在真实环境里跑通了“领券”动作产品验收和运营推广可以提前启动。第二种按数据字段的从简到繁切一个功能如果有很多字段先只做核心字段再做外围字段。“用户注册”是经典例子完整注册有手机号、验证码、密码、昵称、头像、兴趣标签、邀请码。第一刀只做手机号验证码和密码昵称不填默认为“用户随机数”头像不给上传入口。这样注册流程在上线当天就能用。下一个迭代再加昵称修改再下一个迭代加头像上传。这种切法特别适合表单类、配置类功能它能保证每次交付都具备可用性同时数据模型还能平滑演进。第三种按业务规则分支切业务规则多的时候按“主干流程 分支流程”来切。主干流程是用户成功率最高的路径分支是例外和异常情况。以“退款”为例主干是“发起申请—审核通过—原路退回—系统通知”分支包括“部分退款”“余额不足导致退款失败”“已发货状态下的退款申请”。第一刀只做全额退款不做部分退款因为全额退款的金额计算最简单第二刀才做“部分退款 按比例分摊优惠”第三刀再做“退款失败自动重试”。这里有个容易被忽略的点尽量把异常分支做成独立的“小切片”不要让它们在主干切片里以“逻辑分支”的形式混杂存在否则主干切片的验收会变得异常复杂。第四种按用户角色切同一个模块如果服务多个角色按角色拆是最稳的。“项目看板”这东西项目经理要的是进度统计执行人要的是自己的任务清单老板要的是跨项目汇总。这三个角色的使用场景、页面信息密度、操作权限都不一样。切片时不要让三个角色共用一个大而全的页面而是一个角色一个切片。第一个切片先做执行人视角的任务清单至少真实用户能用了再逐步给其他角色加视角。这类切片还有一个额外好处权限模型是随着角色切片渐次引入的而不是第一个版本就把完整的RBAC模型做完。第五种按外部系统依赖的强弱切很多需求离不开外部系统支付、短信、第三方登录、电子签章。按“可模拟—真对接—深度打通”三个阶段切是降低风险最有效的做法。第一刀用Mock数据或沙箱环境把完整流程先跑通第二刀接真实环境的只读/基础能力第三刀再做状态回调、失败对账等深度集成。我见过太多团队一开始就追求接真实支付结果参数对不上、回调不通整个版本卡了两个星期。如果第一刀先用沙箱把“下单—唤起收银台—支付成功回跳—订单状态变为已支付”整条链路跑通业务方和研发都能尽早看到真实交互真实对接的风险就被隔离了。2.3 切片颗粒度怎么定三个硬指标颗粒度没有标准公式但有三条硬指标可以检查。第一个指标切片时长不超过一个迭代周期的三分之一。如果团队迭代是两周一个切片最好控制在两到三天最长不超过一周。超过这个时长说明切片太大需要继续切。低于半天则可能切得太碎产生大量管理成本。第二个指标每个切片必须能回答“谁在用、用来干嘛”的问题。如果一个切片只能回答“这里加了三个表”那它就不是切片是技术任务。技术任务不是不能排而是不要假装它是用户可感知的需求切片。第三个指标切片之间可以并行但不强依赖。两个切片如果必须按顺序做那么它们其实属于同一个更大的切片。我通常用“如果B还没做A能不能独立上线”来判断这两个切片的耦合度。到这里就能回答颗粒度问题的核心了切片粒度是“价值”和“技术风险”博弈的结果不是按工作量平均分配的。价值密度高的部分切小点尽早验证技术风险高的部分也切小点尽早试错纯粹的后台数据迁移或重构可以单独列技术切片但一定要标注出它对用户价值的贡献在哪。3. 实操手记从需求到切片的完整流程3.1 实操示例购物车结算的一刀一刀我用一个几乎所有团队都做过的需求“购物车结算”来演示完整切法。原始需求是这样一句话“用户在购物车勾选商品点击结算完成支付后生成订单。”注意这就是典型的“能看懂但没法直接开发”的需求因为里面藏着运费计算、优惠、库存、支付回调、订单状态、超时取消一堆逻辑。拿到这个需求我做的第一步是列全量业务规则比如只有选中商品才能结算运费按地区模板计算部分商品不支持优惠券库存不足要在结算时提示支付成功后并发扣库存超时未支付自动取消。列完后我用主干优先法切出了下面这几刀第1切片勾选商品后显示合计金额纯前端计算这个切片只做金额展示不接支付不生成订单。它的价值是让用户看到购物车选品反馈让前端把选中态和金额联动调通。第2切片生成草稿订单后端点击“去结算”后后端根据勾选商品生成订单算出商品总额订单状态为“待支付”但不唤起任何支付。这个切片验证了订单表结构、金额计算逻辑、购物车到订单的数据转换。第3切片接入支付沙箱并回调接上支付平台的沙箱环境用户点击支付后跳转支付成功回调把订单状态改为“已支付”库存可以在这一步先不做扣减只记录支付时间。第4切片库存校验与扣减支付成功后扣库存并在结算前校验库存不足的提示。这一步开始涉及并发单独一个切片便于做压力测试。第5切片运费模板与优惠叠加这是规则最复杂的部分放到最后。因为前面四刀已经把主链路走通了运费和优惠属于“加条件”相对独立。这套切法最关键的点是每一刀都能独立验证每一刀上线之后用户在大部分情况下都能正常使用。第2切片做完后用户可以生成订单只是支付不了这个状态对后台演示、运营了解流程已经足够友好。第3切片做完后用户能完整走完一笔支付但对账报表和库存还不准团队知道这些是已知风险。3.2 切片之后的产出物与验收标准一个切片在进入开发前需要准备好四样东西需求描述、UI原型哪怕手绘、数据影响范围、验收标准。我在团队里最常强调的是验收标准而且要求写成“可执行的测试场景”不写“实现XX功能”这种话。切片验收标准可执行版本第1切片勾选两个商品后合计金额等于两个商品价格之和并展示取消勾选后合计变少不勾选时结算按钮置灰第2切片点击结算生成订单数据库中有记录且状态为待支付返回订单号订单金额与前端展示一致第3切片点击支付跳转沙箱支付成功回调后订单状态变为已支付重复回调不重复修改状态第4切片库存为1、用户买2时提示库存不足不可生成订单支付成功后库存扣减1超卖数量为0第5切片不同地区地址展示不同运费符合满减条件的订单自动减价与优惠券同时生效的顺序正确这些验收标准既是研发的自测清单也是测试人员的用例来源还是产品验收时的打勾清单。写验收标准有一个心法从用户能观察到的行为出发描述不要从代码实现出发描述。比如“状态变为待支付”比“插入订单表state字段置为0”更容易对齐各方认知技术细节留在研发自测里。3.3 在迭代计划里怎么排切片切片排进迭代还要注意顺序背后的逻辑。我用的原则是“先通后优、先验证后完善”第一个切片一定要是最能验证整体方案可行性的通常是主链路的打通哪怕界面丑、逻辑简陋第二个切片补上最常用的异常分支第三个才开始做锦上添花的部分。永远不要第一个迭代就去做报表导出、数据大屏这种边缘功能等核心链路跑通再上不迟。另外切片之间还有一个容易忽略的点——依赖顺序要与团队能力匹配。如果前端资源紧张第1切片这种纯前端任务可能要延后让后端先做第2切片如果后端资源紧张第1切片可以先上。不要为了保证“用户旅程的完整性”而强行保持切片顺序迭代节奏和资源约束同样重要。4. AI能帮你切片吗边界与配合方式4.1 现在的大模型能做到什么程度回到项目标题里那个问题“是人工切片还是AI切片”我直接用实测结论回答AI可以参与切片而且是个不错的助手但真正拍板的一定是人。我在实际项目里试过用大模型切需求。把一段产品需求丢给它问“请帮我拆成最小可交付的垂直切片并给出每个切片的验收标准”它在以下方面表现确实不错需求描述比较清晰时能快速列出功能点清单能基于常识识别出一些业务分支比如注册流程需要手机号校验、密码强度限制能生成看起来像模像样的验收标准能把模糊的大需求拆成更多小句子提供拆分的候选思路。对于从未接触过该业务的人来说AI的输出作为“初稿参考”完全合格。但AI的问题也很明显。它不知道你们系统的现状不知道哪些表已经存在、哪些接口已经能复用、哪些第三方的联调成本很高。它不清楚团队的技术能力边界一个切片在A团队可能两天做完在B团队可能两周做完。它对业务价值的判断是局部的它会关注功能完整性但不会主动思考“这个切片对业务策略、用户留存、后续运营意味着什么”。最关键的一点是它容易把“逻辑上的拆分”当成“交付上的切片”结果切出来的东西是一个个相互交织的模块而不是可以独立上线的闭环。4.2 我日常用的AI辅助切片提示词我不会直接让AI替我切而是用它做**“信息扩充 候选方案生成”**然后我再人工画边界。我常用的提示词是这样的你是一个资深敏捷教练。下面是我的一条产品需求。请完成三件事第一列出这个需求涉及到的全部用户操作步骤第二识别其中的主干流程、异常分支、复杂规则第三按“每个部分都让用户获得一个可感知结果”的原则给出3到5个候选切片方案。最后对每个候选切片说明它的独立价值、潜在风险和被拆分的理由。用这套提示词得到的结果通常比我直接问“怎么切”要靠谱得多。原因是它引导AI先做“场景拆解”再做“切片建议”而不是让它一上来就生成结构。得到AI的候选方案后我会把它当成一个“急于表现的初级产品经理”的输出逐条和团队过哪些切片在技术上没法独立部署哪些切片的验证成本太高哪些可以合并哪些因为依赖一个还没约定的接口而必须重排这个过程里人做的事情是对齐现实约束AI做的事情是提供结构化信息。4.3 为什么最终“拍板”还是要以人为主我把切片的决策权始终保留在人工一侧原因有三个。第一切片不仅是任务划分还是产品优先级判断。哪一部分先让用户看到这通常涉及业务策略和运营节奏AI理解不了。比如一个商城系统先做购物车还是先做收藏夹取决于当前业务重点是转化率还是用户留存这些背景只有懂业务的人知道。第二切片必须考虑现有系统的技术债。AI不知道你的订单表已经有三个状态字段不可更改不知道公司统一登录SDK二月份才升级过不知道某个老系统的接口调用成功率只有90%。一旦进入这些约束的讨论AI的结构化能力就不够用了需要靠人来协调。第三切片背后是团队的协作承诺。把一个切片分配下去意味着相关职能的人要在同一时间段投入这是组织和资源决策不是文本分析能替代的。AI可以输出完美的切片方案但如果团队现有的后端力量都在忙另一个项目方案就执行不了。所以我的最终答案很明确这个“切”的动作人来做主AI来查漏和提速。项目标题问“是人来切片还是用AI来切片”我给的答案是“人机协作人做最终决策”。成熟的团队可以把AI当“先遣侦察兵”用它先扫一遍需求产生候选人再基于现实情报划定最终边界效率比纯粹人工从零开会高不少。5. 常见问题与避坑指南5.1 问题一切太细交付碎片化切片切得越细每个切片的独立价值就越低这是很多团队从“切不细”掉进“切太碎”的典型轨迹。切太细的表现是每个切片只含有一两个前端控件或一两个接口研发半天完成但产品验收时要反复看“这个碎片和另一个碎片之间连不上”测试人员也难以下手。更麻烦的是切片之间往往存在隐式的数据依赖比如第3切片假设第2切片已经把某个状态字段写好了一旦第2切片延期第3切片连开发都无法开始。应对办法是回到我在2.3节提的硬指标切片必须能回答“用户能完成一个什么闭环动作”。如果只差一个“去重校验”就能让切片闭环那就把它并进来一起做不要为了追求体积小而强行切开。另外我建议每个切片排期不少于一天杜绝半天级切片累积大量管理开销。5.2 问题二切太粗集成地狱其实没躲掉有些团队名义上做垂直切片实际上还是把一个完整功能当成一个切片里面塞了三张表、五个接口、两个页面、一次第三方对接美其名曰“一个用户故事”。这种情况下切片时长往往会超过一周研发一半时间在写代码一半时间在等待其他模块的联调产品想提前验收也找不到入口其实又回到了水平切片的集成地狱。我的判断标准是如果切片过程中出现“这个接口要等XX完成后才能联调”“这个页面依赖XX团队的新接口”就说明需要继续下切。这时候不是把任务拆小而是把外部依赖隔离出来用Mock或者预定义契约先推进让主链路保持可运行。5.3 问题三验收标准写成“待办任务”而不是“可测试场景”这个问题常见得让人惊讶。很多团队写的验收标准是“完成订单列表功能”“实现优惠金额计算”这种描述既不可测试也无法约束开发边界验收时全靠双方自由裁量。我要求团队把验收标准全部改成“当……时系统应该……”的行为句式并明确列出可观察的输入和输出。比如“当未登录用户访问结算页时跳转登录页并在登录后返回原结算页”这句话任何人都能验收开发也知道写完是什么样。写验收标准还有一个技巧每个切片至少写一条异常场景。通常大家会先写正常路径异常路径容易被忽略这导致开发做完正常路径后测试才开始发现异常分支完全没实现。提前写出来等于提前把边界条件暴露给研发测试阶段少一轮来回。5.4 问题四把“切分”当“排序”以为只是在排优先级切片和优先级排序是两件事但很容易混在一起。切片解决的是“一个需求如何分解交付”排序解决的是“这些交付物哪个先做”。有些团队开会时只讨论“先做什么后做什么”根本不做结构拆解结果是优先做完的“优先级高的部分”本身还是一个无法独立交付的大模块。正确动作是先做切片再对切片排序排序依据是依赖关系、风险、业务紧急度三者的加权。6. 关于切片我最后想说的几句实在话做了这么多年交付我越来越觉得切片开发真正难的不是技术而是克制。克制住“一次性把所有逻辑做完”的冲动克制住“按自己专业领域舒服地切”的冲动克制住“把重构和技术优化都塞进同一个切片”的冲动。克制的回报就是每两周你都能拿得出一个看得见摸得着的东西每个迭代结束时团队都知道自己做了什么产品经理能向老板演示的不再是PPT而是真实功能。如果让我给团队定几条纪律第一条是“任何切片都必须打通主链路再做优化”第二条是“验收标准先写异常场景再写正常场景”第三条是“AI可以帮你做初稿但每个切片的边界人要有能力解释为什么这样切”。这三条拿着就能用至于切片切出来的东西到底好不好只有一个检验方式——把它上线然后看用户是否买账。