用途：用 Shape Up 的 appetite-first（先定时间预算）思路来砍范围。核心是把问题从“这要做多久”翻转成“这个问题值多少时间”，先定胃口，再让方案去适配它，即固定时间、可变范围。
主要能力：设定 Appetite（小批量 1-2 周、1-2 人；大批量最多 6 周的小团队；若超过 6 周，或按 Linear 方法 1-3 人超过 3 周，就说明太大，需拆分或放弃）。胃口不是估算，估算说“这要花 X”，胃口说“这值 X”。若方案装不进胃口，就砍范围，或直接杀掉项目。
Scope Hammering（逐项锤范围）：对规格中每一项按顺序提问——是必须有还是锦上添花？没有它用户还能获得价值就砍；没有它能否发布可用版本？能就从 v1 砍掉；是边缘情况还是核心路径？少于 20% 用户会遇到就推迟；与基线比较，基线是“完全没有这个功能”，而不是理想版本，“比没有强”永远胜过“能不能做到最好”。
把方案做小：砍广度而非质量，例如只把 1 个认证提供商做好，而不是 3 个都做差；完整走通主路径，而不是覆盖所有错误状态。移除整个界面，如设置页、仪表盘，用合理默认值代替可配置性。给边缘情况设时间边界，例如“CSV 导入最多支持 1000 行，超过就发邮件给我们”，在规模需要自动化前先手动解决。问一句：“客户会感谢我们的最简单版本是什么？”那就是范围。
Circuit Breaker（熔断）：若一个周期内没发布，默认取消，不自动顺延，团队必须重新提案才能进入下一周期，避免僵尸项目无限拖延。
准则：绝不砍质量，只砍广度；一个打磨好、只做一件事的功能，胜过五个有 bug 的功能。绝不做估算，只定胃口。v1 的 must-have 绝不超过 5 个，否则说明范围砍得不够。始终与“完全没有该功能”的基线比较，而不是与理想实现比较。始终问“在[胃口]内我们能发布什么”，而不是“全部做完要多久”。绝不自动结转未完成工作，未完成必须重新提案。
适用场景：被要求缩减范围、寻找 MVP、裁剪功能、加快发布，或判断哪些内容不该进 v1。
限制：资料未提供具体工具形态、安装方式、平台支持、收费或价格信息，暂未提供。