AI时代，MVP（最小可行产品） 的“最小”可能正在失去意义
读完苏杰这篇文章，我最认同的判断是：MVP需要重新理解，因为支撑它的一些约束正在变化。开发能力不再像过去那样稀缺，软件开始服务智能体，功能也未必需要在发布前全部定义好。
这三件事放在一起，改变的是产品如何被设计、验证和使用。
构建变快，验证成为瓶颈
过去，“构建—测量—学习”这个闭环里，研发往往成本高、耗时长。少做功能，可以更快接触用户反馈，减少走错方向的代价。快速原型、设计冲刺，都有这层逻辑。
AI降低构建成本后，功能可以很快做出来，但功能是否有效，仍然需要验证。我认为，产品管理的约束应该随之调整：把“尽量少开发”转向“尽量少上线未经评估的功能”。
这也改变了需求文档的重点。除了描述要做什么，还要说明怎样判断它达成了目标。验收标准如果含糊，开发越快，越容易堆积无法证明价值的功能。
智能体成为用户，体验需要另一套尺度
面向人类时，功能堆砌会增加理解和操作负担。“少即是多”，有很现实的认知基础。
现在，软件开始增加另一类用户：AI Agent。智能体同样存在注意力限制，但它使用产品的方式，与人看界面、点按钮不同。产品需要同时考虑人的体验和智能体的体验。
原文提到的Agent Experience（AX），目前还没有公认标准，但已经提出一些值得关注的尺度：任务成功率、自主完成率、首次成功轮次、成功所需的Token成本，以及出错后的自恢复率。
我看这些指标，核心都指向一件事：智能体能否以可接受的成本，把任务完成。功能数量本身，解释不了这种体验。
功能可以按需生成，简单界面也能承载复杂任务
传统软件需要提前定义功能。为了服务更多人，产品经理把需求合并成“目标用户”的共同需求，再选择最常用的部分实现。功能一多，用户就会看到大量与自己无关的模块。
原文用“从固体变成液体”描述新的可能：软件具备智能后，一部分需求可以留到使用时，由用户和AI共同展开，界面也可以按任务生成，例如Generative UI。
我认为，这会让产品定义的重心从功能清单移向任务范围：系统能解决哪些问题，如何判断完成，哪些部分允许在使用中生成。
提前限制得太死，可能压缩智能发挥的空间。界面可以很小、很简单，背后却需要有足够高的任务完成能力。表面的简洁与能力的丰富，可以同时成立。
产品经理要把目标转化为可验证的结果
过去，产品经理的重要能力，是把用户需求翻译成软件功能。随着上述前提变化，更重要的工作可能变成：把人的目标转化为一个能够自主完成任务的智能系统。
苏杰把这进一步联系到垂直领域的harness设计。我理解，这意味着产品经理需要同时考虑任务、执行条件和评估方式，让智能能力能够稳定地交付结果。
因此，我仍然看重MVP中的“构建—测量—学习”闭环。每一轮应该做多大，取决于需要验证什么，以及怎样最快获得可信反馈。“最小”的尺度，也该随着真正的瓶颈一起变化。