我如何在扩展 AI 产品前先验证需求

在扩展 AI 产品前，我会先确认现有工作流能否在清晰边界内被使用、检查和验证。

实际可行的循环应该刻意保持小而清晰：先构建能够回答一个真实问题的最小版本，再交给真实用户，观察实际使用方式和付费意愿，最后只在证据支持下一步时扩展。这是一套决策纪律，不代表每次实验都一定会变成产品。

先明确一个有用问题

当 MVP 的任务足够明确，验证会更容易。第一个版本应该只负责一个工作流，同时列出边界：输入是什么、输出是什么、哪些决定仍由人来做，以及什么结果会支持下一轮修改。

边界不是掩盖未完成工作的借口，而是让一次有用测试可以被复核。具备清晰失败状态的小型工作流，比无法分辨价值来源的大型界面，更容易为下一步决策提供信息。

验证循环

1. 构建最小可用版本。 把工作流收窄到可以从输入一路检查到输出。
2. 交给真实用户。 观察用户在哪里理解流程、在哪里犹豫，以及实际使用了什么。
3. 记录证据。 把实际使用、付费意愿和实施假设分开，不要把假设写成结果。
4. 作出下一步决策。 根据现有证据选择扩展、修改、暂停或移除。

MVP 纪律不等于低质量

两者必须区分。验证不是要求用户接受粗糙工作，而是让最小版本足够诚实，使下一步建立在真实观察之上。

限制 — 这套原则本身不会产生转化数据，只会界定在扩大范围前如何收集和理解证据。

一份实用的决策记录

question: 这个有边界的工作流能否被使用和复核？
observed_use: 记录用户实际做了什么。
missing_evidence: 记录仍然未知的部分。
next_decision: 扩展、修改、暂停或移除。

可以立即采取的做法很简单：在增加功能前先写下要回答的问题。如果当前版本无法产生可复核的答案，增加范围通常只会让决策更难，而不是更清楚。