H2.09.4onboarding checklist length cap设计
清单项目过多时会被视为负担而非引导，需限制总量
别名: 清单过长 · 上手负担 · checklist overload · too many setup items
概念解释
清单把上手收成可见的债务。项一多，债务本身变成负担：人看到的不是「还差几步就能用」，而是又一张待办表。限制总量是在保护清单还像引导，而不是像项目管理。这条与「项要有价值」互补：有价值的项堆多了同样会压垮；也与进度显示无关——分母很大时，显示得再清楚也是一张大账单。
机制
工作记忆和动机都按可见项数估价。五项里完成两项像接近终点；十二项里完成两项像刚开工。目标梯度在大分母上变浅，甚至反转：人选择不打开清单，以免看见债务。每个产品团队往清单里塞自己的项，总量在组织层面膨胀，用户经历的却是一张表。负担还会改变策略：跳过整张清单、只做看起来最短的项、或勾形式项把百分比做上去。清单一旦被当成负担，后续真正必需的项也进不去注意。所以上限不是审美，是这张表面还能不能当引导用。把其余有价值的动作留到相关时刻或设置里，比全部陈列在上手表上更能被做完。分母越大，每一项分到的注意越薄，连真正值钱的那几步也会被扫成「以后再说」。
边界
受监管的入职（医疗、金融开户）法定步骤可能超过舒适上限，应拆成「准入门」和「上手清单」两张表，门不是引导。企业管理员为全组织做的一次性配置可以更长，那是管理员工具，不要拿同一张表给每个终端用户。用户主动打开的「还可以做这些」扩展区不计入上手上限，前提是默认清单已经短，扩展默认收起。
怎么落地
- 给默认上手清单设硬上限（通常三到五项），只保留不做就无法完成核心任务的动作。
- 新团队想加项时必须换下一项，禁止只追加。
- 其余动作放到相关时刻、设置、或收起的「可选」区，不要撑大默认分母。
- 验证：看清单的首次展开率和展开后的放弃。分母增大而展开率下降，或人只勾最短项，就把上限收回，并对比缩短后核心任务的到达时间。