slim-down

精简范围 — 缩小规模，保留扩展空间

将一个不断膨胀的计划或设计缩减为一个增量——能交付价值且不会阻碍未来扩展的最小步骤。

先让它可用，再让它出色——但绝不要把自己逼入死角。

适用场景

• 计划或设计显得过度设计时
• 用户说“这太多了”“我现在到底需要先做什么？”“MVP”时
• 范围膨胀到超出下一步实际可构建的程度时

核心原则

缩小范围，不降低标准。 删除功能，而不是质量。这个增量应该小而易于扩展——不走入死胡同，也不需要“以后推倒重来”。

工作流

第 1 步：了解现状

在删减任何内容之前，先了解现有情况：

• 阅读当前代码库——已经构建了什么，正在使用哪些模式
• 阅读需要精简的计划／梳理结果／规格说明
• 确认哪些是新增工作，哪些已经完成或部分完成

用简短的内容总结：

• 当前状态 — 目前已经有什么（2–3 行）
• 完整目标 — 计划要实现什么
• 差距 — 当前状态与完整目标之间还缺什么

第 2 步：找出核心

询问：“这个计划必须交付哪一件事，才能发挥作用？”

用一句话描述核心价值。展示给用户。这是判断其他所有内容的基准。

第 3 步：分类为保留／推迟／舍弃

将计划中的每一项分类：

	标准
保留	核心功能所必需。缺少它就无法交付。
推迟	有价值，但目前还不需要。设计时确保以后可以添加。
舍弃	可有可无、带有猜测性，或试图解决尚不存在的问题。

展示表格。让用户调整分类。

分类规则：

• 如果只有在规模扩大 10 倍时才需要 → 推迟
• 如果用于处理尚未发生的边缘情况 → 推迟
• 如果移除后不会破坏核心功能 → 推迟
• 如果只是“为了灵活性”而增加新的抽象层 → 舍弃，除非有证据表明确实需要
• 如果当前代码已经部分处理了它 → 保留（完成它，而不是重做）

第 4 步：检查可扩展性

对于每个推迟的项目，确认：

• 保留清单中的内容是否会阻碍以后添加它？
• 当前增量是否会造成死胡同，迫使之后重写？

如果是 → 将该项目移回保留，或调整设计。

如果用户问“这样能扩展吗？”——请根据代码如实回答，而不是根据假设作答。

第 5 步：写明增量

共同撰写一份简短的构建说明：

• 目标 — 一句话
• 交付内容 — 保留项目列表
• 推迟内容 — 推迟项目列表（避免遗漏）
• 范围之外 — 舍弃的内容及原因
• 完成标准 — 如何验证已完成

如果用户需要，就写入文件；否则只需确认双方已达成一致。

如何精简（而非掏空）

• 尊重现有代码。 不要建议替换可用的部分，要基于现有代码构建。
• 优先推迟，而非舍弃。 舍弃让人觉得是永久决定。推迟则能保留选择，也让用户更安心。
• 说明后续路径。 推迟某项内容时，简要说明当前设计如何为它留出空间。
• 具体明确。 “推迟身份验证”太含糊。“推迟 OAuth——暂时使用 API key，身份验证中间件接口保持不变”才具有可操作性。

不要做的事

• 精简时不要添加新功能
• 不要重新设计架构——基于现有设计开展工作
• 不要只说“做个 MVP”，却不具体定义它是什么
• 不要删掉用户已经构建的内容——那是浪费已有工作，不是缩小范围
• 不要假设用户想要最省钱的方案——他们想要的是最小的实用方案