本节要解决的事：子任务越多，不代表理解越清楚。拆分应该产生可以独立交付和验证的结果，而不是只把鼠标动作编号。
十个点击与三个子目标
要比较三家供应商。方案甲按十个细碎动作拆分：打开网页、点搜索框、输入词、提交、点结果、展开规格、找价格、找运费、找库存、抄记录。方案乙按三家供应商拆，每个子任务交付同样的结构：规格、数量、含运总价、库存、证据位置。两种拆法都能完成任务，但交接的信息不同。
假设连续执行相同的实际工作都需 30 秒，每次交接另需 1 秒。十段之间有九次交接，总时长 39 秒；三段之间有两次，总时长 32 秒。这里故意不算首段启动与最终汇总，且假设各段没有并行，是为了单独观察切分开销。真实系统可能有其他成本，不能从这组数字推断三段永远最好。
为什么点击级拆分容易丢失含义
执行者收到“点击第三个结果”时，可能不知道搜索目标是蓝笔、数量是十盒、预算包含运费。如果页面排序变化，它甚至不知道第三项已经换成红笔。把每个动作交给独立子任务，却不给目标与状态，会把局部执行变成脱离语义的指令。
按供应商拆分时，每个执行者掌握一个完整局部目标：确认这家能不能满足条件，并返回证据。这减少交接，也让结果可验证。但子任务若过大，例如“独立完成整个采购”，又可能跨越太长执行跨度，积累错误。合理粒度通常在“有完整含义”和“能明确验证”之间。
工作量相同，改变交接数量
先做预测，再逐步展开。这里是固定规则的教学回放，不是真实模型测评。
教学构造场景 · 按下方规则逐步回放；不调用真实模型，不代表实际成功率。
实际工作 30 秒；十段串行；每相邻两段交接 1 秒。
- 1. 数边界
十段共有九个段间边界。
- 2. 算开销
9×1＝9 秒。
- 3. 算总时长
30＋9＝39 秒。
十段共有九个段间边界。
先预测，再核对结果与原因
39 秒细切分增加接口数量，还必须传递页面状态与目标。
最容易被切丢的是总预算
把旅行分成机票、酒店、餐饮看起来很自然。但若三组各自认为“只要不超过 1,000 就行”，可能分别花 600、500、200，总额 1,300，超出总预算 300。每个子任务局部合格，整体却失败。共享约束不能因为任务拆开就自动复制成三份独立额度。
可以由协调者维护统一预算账本，或先为子任务分配明确上限并在汇总时重新检查。但分配也有取舍：一开始把酒店额度锁死太小，可能错过机票便宜、酒店稍贵却总价更低的组合。全局汇总不仅加数字，还要检查跨子任务兼容性，例如到达时间是否赶得上入住、颜色和型号是否一致。
什么时候该拆细，什么时候该合并
如果某一步有独立风险和明确验证，例如提交订单前的授权检查，拆成显式节点有价值。若两步高度依赖同一个临时页面状态，且都只是一个小操作的一部分，频繁交接可能只增加状态丢失。应按依赖、错误恢复边界与能力需要切分，而不是按固定字数或动作数。
也不能用“每步成功率 99%”轻率推导真实任务成功率。只有在成功事件独立、条件概率固定等假设下，连续十步都成功才是 0.99 的十次方，约 90.4%；真实后续错误常受前面状态影响。这个玩具计算提醒我们长链有风险，但不能取代实测。
理解检查
问题一：十段为什么是九次交接，不是十次？ 因为本例只数相邻段之间的边界，第一段启动和最后汇总被排除。改变统计口径时应重新计算，不能混用数字。
问题二：三家子任务都说报价符合预算，是否可以直接汇总成功？ 不可以。需要确认它们用的是完整采购预算还是分配额度，最终购买组合的总额与其他全局约束仍须统一检查。
问题三：只要减少交接，就应该把全部工作交给一个超大子任务吗？ 也不对。过长执行跨度可能增加错误积累和恢复困难。需要可验证中间产物，在交接开销与局部任务难度之间选择粒度。
下一问
即使粒度合理，步骤仍可能缺少实际前提。下一节把“下单”写成明确的状态转移：哪几个条件不成立，就不能执行这一步？