“最小交付”常被误解为“功能最少”，结果是团队删减界面和模块，却没有减少用户完成任务的成本。真正的最小交付，指的是用受控范围兑现一个明确、可验收的结果。它可以由人工服务、模板、脚本和现成工具组成，也可以暂时没有完整的软件形态。判断标准不是功能数量，而是用户是否因此完成了原本困难、耗时或代价较高的任务。

最小交付的三个边界

第一，边界应围绕用户，而不是围绕产品架构。首个版本只服务一种主要用户，聚焦一个高频场景，交付一个主要结果。比如，不承诺“搭建完整内容系统”，而是交付一套未来两周可执行的选题与发布流程，并明确包含模板、示例和修改范围。

第二，边界必须能够验收。交付前应写清楚输入是什么、执行哪些步骤、输出是什么、多久完成、交付几次，以及哪些请求属于额外工作。没有验收标准的“灵活服务”，通常会演变成无限定制，最后验证的只是个人劳动能力，而不是可重复的产品。

第三，边界要服务于验证。早期交付的重点不是证明技术架构足够完善，而是观察用户是否真的使用、哪些环节最耗时、结果是否值得付费，以及交付能否在可接受的时间内重复完成。用户提出的新需求，也不应自动进入版本范围，只有直接影响核心结果的需求才值得优先处理。

因此，功能减少并不等于复杂度下降。一个只有少量按钮、却要求用户自行整理资料和理解流程的产品，可能比人工完成一次明确交付更难使用。相反，暂时增加人工环节，反而能更快验证价值。

用证据决定是否扩展

最小交付完成后，应分别记录结果证据、过程证据和价值证据：用户是否完成了目标任务，哪些步骤消耗了最多时间，用户是否愿意继续使用或支付。若每个用户都要求完全不同的结果，说明方向尚未收敛；若反馈集中在少数可执行改进上，才适合逐步标准化。

扩展功能之前，先确认三个问题：目标用户是否集中，核心问题是否稳定，当前交付是否已经产生真实投入。没有这些证据，增加功能只是把未经验证的假设包装得更复杂。最小交付追求的不是最少功能，而是用最少的不可逆投入，交付足够清晰的价值，并为下一步决策留下可靠证据。