YuBai

从需求到 MVP：独立开发如何控制第一版范围

Mon, 28 Sep 2026 00:00:00 GMT

需求有了一些证据后，先决定第一版要完成什么，不急着列完整功能清单。

MVP 是验证工具：让目标用户完成一次核心任务，并留下真实使用结果。第一版只做这件事，其他“以后可能需要”的功能先放着。

先写用户任务，不写功能#

“需要登录、搜索、收藏、导出和团队协作”是一组功能，不是用户目标。第一步是写出用户想完成的任务：

用户在某个场景下，提供某种输入，经过一个关键处理，得到可以继续使用的结果。

例如：

用户上传一篇长文，得到一份可以直接发布的标题、摘要和标签。

这句话已经包含了第一版所需的边界：输入是一篇长文，核心处理是结构化整理，输出是四个内容字段。登录、历史记录、多人协作和模板市场都暂时不属于核心任务。

用一条主流程定义 MVP#

可以把 MVP 写成一条最短主流程：

1
进入页面
2
  ↓
3
提交输入
4
  ↓
5
系统完成核心处理
6
  ↓
7
展示结果
8
  ↓
9
用户复制、下载或继续使用

如果主流程中有五个以上必须配置的步骤，应重新检查范围。第一版应该尽量让用户在一次会话里完成任务，而不是先搭建一个复杂的管理系统。

明确输入、输出和失败情况#

AI 编程时最容易卡在目标没写清楚。为了减少返工，可以先写一份很小的功能规格：

1
目标用户：
2
用户任务：
3
输入格式：
4
最小有效输入：
5
核心处理：
6
输出字段：
7
成功标准：
8
输入无效时怎么提示：
9
暂不处理的情况：

“暂不处理的情况”要写清楚，让开发者和 AI 都知道这一版不解决什么。例如第一版只处理中文纯文本，不处理扫描 PDF、复杂表格和超长文件。边界越清楚，第一版越容易完成。

用结果定义完成，而不是用页面数量定义完成#

MVP 的完成标准不看首页、后台和设置页做了多少，而看用户能不能得到这些结果：

用户可以提交一份符合要求的输入
系统可以在可接受时间内返回结果
结果包含用户承诺的核心字段
用户可以复制、下载或继续完成原任务
错误输入会得到清晰提示

这几条比“页面看起来完整”更接近产品价值。只要用户能完成任务，界面可以先简单，数据结构也可以先小。

只保留一条核心价值链#

功能可以分成三类：

类型	判断方式	MVP 处理
核心功能	没有它，用户无法完成任务	必须做
辅助功能	能减少理解或操作成本	只做最简单版本
扩展功能	让未来体验更完整	暂时不做

例如一个内容整理产品：

核心：输入文章，输出结构化内容
辅助：复制按钮、示例输入、错误提示
扩展：账号体系、历史记录、团队空间、模板市场

先完成核心功能，再选择一两个真正减少操作成本的辅助功能。扩展功能要等真实用户反复提出，并且影响使用或付费时再加入。

AI 编程的正确分工#

AI 可以快速生成代码，但不能替开发者决定产品范围。分工通常是：

先写清楚用户、任务、输入、输出和限制。
AI 帮助拆分实现步骤，指出遗漏的边界情况。
AI 一次只实现一个小步骤。
运行并检查每一步的结果。
出现问题时，先描述实际现象，再让 AI 修改。

不要把“做一个完整产品”作为一次指令交给 AI。更可靠的方式是先让它完成输入页面，再完成核心处理，再完成结果展示，最后补充错误状态。每一步都能运行和检查，返工成本会低很多。

三天 MVP 节奏#

对于一个边界清晰的核心任务，可以用三天作为第一轮开发上限：

第 1 天：跑通主流程。 完成输入、核心处理和结果展示，先使用最简单的数据存储或临时方案。

第 2 天：处理真实输入。 用真实用户数据测试，补上格式校验、错误提示和最明显的阻塞问题。

第 3 天：交给用户使用。 不再继续增加功能，邀请目标用户完成任务，记录完成率、耗时、失败点和是否愿意再次使用。

三天还交不出去，就先删减范围，别继续堆代码。MVP 延期通常说明核心任务没有被拆小，或者实现方案依赖了不必要的基础设施。

建立验收清单#

每个 MVP 都应该有一份短验收清单：

1
[ ] 目标用户知道自己该输入什么
2
[ ] 正常输入可以得到核心结果
3
[ ] 无效输入不会让页面卡死
4
[ ] 结果可以被复制、下载或继续使用
5
[ ] 用户不需要口头解释才能完成任务
6
[ ] 可以记录一次使用是否成功
7
[ ] 明确下一轮要观察什么

清单没有全部完成时，可以作为内部测试版；完成后才适合交给第一批陌生用户。这里的“完成”指核心任务可用，不代表产品已经打磨成熟。

什么时候加入第二个功能#

等到有真实使用记录后，再判断是否加入新功能。通常满足下面至少一个条件，才值得考虑：

多个用户在完成同一任务时遇到同一个阻塞
用户愿意继续使用，但核心流程中的某一步明显浪费时间
用户已经完成核心任务，并主动提出与当前任务紧密相关的需求
新功能可以明显改善留存、交付成本或付费转化

单个用户的一次性建议，不足以直接改变产品范围。它可以进入需求池，等更多证据出现后再处理。

发布后的观察指标#

第一版不需要复杂数据平台，但至少要记录：

有多少目标用户开始任务
有多少人完成核心任务
完成一次需要多长时间
用户在哪一步退出或失败
有多少人第二次回来
有多少人愿意提交反馈、推荐或付费

更应关注“完成任务的人做了什么”，而不是只看访问量。访问量可以来自好奇，完成任务和再次使用才更接近产品价值。

什么时候停止增加功能#

出现下面情况时，可以暂停功能开发，回到需求验证：

用户无法说清楚产品解决了什么问题
核心流程完成率很低
用户使用一次后没有理由回来
每个用户都要求完全不同的功能
增加功能没有改善完成率或付费行为

核心任务还没验证时，登录、主题、动画和管理后台都先放下，否则只会让问题更难看清楚。

第一版的边界#

定义 MVP 时只保留这几件事：

一个明确用户、一个具体场景、一个核心任务、一条最短流程、一个可以观察的结果。

第一版只要证明一小类用户愿意用它完成一次真实任务。完成这一步，后续反馈和功能才有依据。

明确第一版范围后，就可以进入实现阶段；真实用户能否顺利完成任务，还需要通过后续测试和反馈来验证。

独立开发者如何筛选需求：市场、竞争与可行性

Mon, 28 Sep 2026 00:00:00 GMT

找到问题之后，不应马上决定开发。需求线索只是候选项，还需要回答一个更现实的问题：这个问题是否值得投入接下来的时间？

问题可能真实，但用户太少；也可能用户很多，却已经被成熟产品覆盖；还有些问题看起来有价值，却找不到第一批用户。早期不必追求最大的市场，而是先找一个能触达、能验证、也能交付的切口。

先判断问题强不强#

应先把注意力放在问题，而不是市场规模。对每个候选需求，可以记录四件事：

问题多久出现一次？
不解决会造成什么具体损失？
用户现在用什么替代方案？
用户已经为替代方案付出了什么？

“希望效率更高”太宽泛，因为没说清楚到底哪里慢。“每周把同一批数据复制到三个系统，出错后还要人工核对”就具体得多，也更值得继续验证。

应优先选择已经存在替代方案的问题。用户正在用表格、脚本、人工服务、多个工具拼接，说明他们已经在为这个问题付出代价。需要判断的是，项目能不能提供更好的解决方式。

再判断市场是否可触达#

市场规模很大，不代表一定能触达用户。早期先找到一小群明确的人，再考虑更大的市场，不必急着估算一个漂亮的总数字。

可以用下面的问题检查触达难度：

能说出这类用户在哪里交流吗？
能用一句话描述他们的工作或身份吗？
能找到十个真实用户，而不是只找到行业报告吗？
他们是否已经在公开讨论这个问题？
是否有机会在一周内让其中几个人试用？

如果这些问题都答不上来，不应因为“市场很大”就继续投入。早期项目需要的是可触达的窄市场，之后才有机会扩展到更大的市场。

先把竞品当成证据#

看到竞品时，可以先把它当成一条线索：已经有人尝试解决这个问题，可以继续观察用户怎么使用、哪里不满意。

可以从四个角度看竞品：

观察项	需要确认什么
用户	它服务的是谁，是否和目标用户相同
核心任务	它真正帮用户完成了哪一个动作
价格	用户为哪一部分价值付费
差评和流失	用户为什么不满意，为什么离开

尤其要关注低分评价和“替代品”讨论。用户抱怨不是自动出现的机会，但它能帮助发现现有产品的边界：太贵、太复杂、缺少某个平台、学习成本高、结果不稳定，或者根本不适合某类小用户。

不应把“竞品功能列表”当成产品计划。复制十个功能，只会让项目进入一个更大的竞争范围。更有价值的问题是：能不能只解决竞品没有照顾好的一个场景？

判断是否适合独立开发#

可以把开发可行性拆成三个层次：

核心动作能否独立交付#

第一版必须完成一个完整动作，不能只完成流程的一半。例如，用户上传资料后，是否能得到可使用的结果；用户输入需求后，是否能得到可以执行的输出。

是否依赖复杂基础设施#

需要大量实时数据、复杂合规、重运营、线下履约或高额算力的项目，不一定不能做，但不适合拿来做第一次验证。独立开发应该先选择可控的核心环节。

是否能在短周期内得到反馈#

如果做完第一版要几个月，才知道用户是否需要，风险就太高。更适合选择可以在几天内做出手工版本或可点击原型的需求。

需求评分表#

可以给每个候选需求从 1 到 5 分，分数只用于比较，不代表精确预测：

维度	1 分	3 分	5 分
问题频率	偶发	每月	每周或每天
问题损失	几乎没有	有时间损失	有明确金钱或机会损失
付费迹象	没有	有替代性支出	已有稳定付费
用户触达	找不到人	有零散渠道	有清晰社区或名单
竞争空隙	没有空隙	有小缺口	有明确未满足场景
MVP 难度	数月以上	数周	数天可完成
后续使用	一次性	偶尔使用	高频重复使用

不必把所有分数简单相加。付费迹象和用户触达是两道门槛；这两项都低时，技术再可行也不该马上开发。

90 分钟筛选流程#

当存在多个候选需求时，可以用 90 分钟做一次快速筛选：

前 20 分钟：写清问题。 每个候选项只用一句话描述用户、场景、任务和当前替代方案。

接着 25 分钟：找现有方案。 记录三个竞品或替代方案，重点看定价、差评和用户抱怨。

再用 20 分钟：确认触达方式。 写出可能的社区、搜索词、平台或第一批用户名单。

最后 25 分钟：评估 MVP。 写出一个用户动作和一个可交付结果，估计能否在几天内完成手工版或原型。

可以把剩下的时间用来写下一步验证动作，而不是继续搜集更多资料。筛选的结果应该是一个可验证假设，而不是一份几十页的市场报告。

常见的错误判断#

只看市场规模#

市场报告可以说明行业存在，但不能说明一定能找到用户。早期应优先判断触达和交付。

只看竞品数量#

没有竞品可能是机会，也可能是没人需要。竞品很多可能竞争激烈，也可能说明付费需求稳定。数量本身不能替代用户证据。

把技术难度当成护城河#

难做不等于有价值。用户不愿意使用的复杂技术，不能形成产品优势。

一开始就追求完整市场#

不必一开始服务所有人。一个足够窄、足够明确的用户场景，反而更容易验证和传播。

最终输出：一张决策卡#

筛选结束后，可以把候选需求整理成一张决策卡：

1
目标用户：
2
具体场景：
3
核心问题：
4
当前替代方案：
5
已有证据：
6
竞品空隙：
7
第一批用户在哪里：
8
MVP 的一个核心动作：
9
48 小时内要验证的假设：
10
继续的条件：
11
停止的条件：

如果最后三项写不出来，说明问题还没有想清楚。下一步应回到用户和场景，重新收集证据。

筛选后的决定#

筛选需求时可以按这个顺序检查：

问题强度 → 用户触达 → 现有替代方案 → 竞争空隙 → MVP 可行性 → 后续使用。

独立开发不必一开始就选出“绝对正确”的方向。先用低成本排除明显不值得做的选项，把时间留给最容易拿到真实反馈的候选项。

下一篇会讨论如何验证用户是否愿意付费，而不是只得到一句“这个想法不错”。

如何验证用户愿意付费：独立开发者的低成本测试方法

Mon, 28 Sep 2026 00:00:00 GMT

“有人说需要”不等于“有人愿意付费”。

需求验证可以拆成两步：先确认用户确实遇到问题，再确认他愿意为解决方案付出代价。前一步靠访谈和观察，后一步要尽量接近真实交易。

目标是在投入大量开发时间前，找到继续投入的信号，也尽早确认哪些方向不值得做。

不要先问“你会不会买”#

用户回答未来问题时，往往会出于礼貌、想象或对新鲜事物的兴趣给出积极答案。下面这些表达都不能直接当作付费证据：

“这个想法挺好的。”
“做出来我应该会用。”
“如果便宜一点，我可能会买。”
“你上线了告诉我。”

更应重视已经发生的行为：用户最近一次怎么解决、花了多少钱、投入了多少时间、是否愿意提供样例、是否愿意试用、是否愿意留下联系方式或预订。

第一步：访谈最近一次经历#

访谈不应用来让用户设计产品，而应确认问题发生的过程。一次访谈只需要围绕最近的一次经历展开：

你上一次遇到这个问题是什么时候？
当时想完成什么任务？
你实际采用了什么办法？
哪一步最耗时、最容易出错或最让你不满意？
这个问题多久出现一次？
你为现在的解决办法付出了什么？
如果暂时没有更好的方案，你会继续怎么做？

应尽量让对方描述事实，不急着介绍产品。如果对方没有具体经历，只有抽象看法，这条线索的优先级就应该降低。

第二步：先做人工服务#

很多产品想法一开始都可以人工完成。比如：

自动整理资料，先人工整理一份结果
自动生成报告，先人工交付一份报告
自动匹配资源，先手动为用户筛选
自动处理图片或文本，先用现有工具完成一次

人工服务能先确认用户要的结果，以及是否愿意为结果付费，也会暴露输入格式、异常情况和交付边界。这些信息比凭空写 PRD 更有用。

可以把人工服务的范围限制在三到五个用户，记录每次交付花了多少时间，以及用户是否愿意再次使用。若人工交付已经让用户觉得不值得，自动化通常也不能自动创造价值。

第三步：做一个清晰的落地页#

落地页不需要介绍所有功能，只回答四个问题：

这是为谁做的？
它解决哪个具体问题？
用户最终能得到什么结果？
用户现在可以做什么？

行动入口可以是预约、申请试用、提交样例、加入候补名单或预订。不同入口代表不同强度的信号：

行为	能说明什么	不能说明什么
浏览页面	价值主张有人看到了	用户一定需要
点击按钮	对表达有兴趣	愿意持续使用
留下邮箱	愿意接受后续联系	愿意付费
提交真实样例	有具体任务	价格可以接受
预约演示	愿意投入时间	一定会购买
支付订金	有明确购买意愿	产品已经有长期留存

应提前写好每个行为对应的判断，避免测试结束后只挑对项目有利的数据解释。

第四步：测试价格，而不是只测试兴趣#

如果不谈价格，很多验证只能说明用户喜欢这个想法。价格不必一开始就精确，但必须进入对话。

可以准备三个价格假设：

一个容易被接受的价格
一个能够覆盖交付成本的价格
一个如果用户真的很需要也能接受的价格

然后观察用户的反应：他是否继续了解、是否询问交付方式、是否提出替代预算、是否愿意先付一小笔订金。拒绝本身也有信息：要分清是太贵、价值不够、现在不需要，还是不信任交付结果。

不要用“免费用户很多”推导“付费用户会很多”。免费试用应该有明确的完成任务和转付费条件，否则只能得到大量低意愿用户。

第五步：做一次真实任务测试#

当问题和付费意愿都有初步信号后，才进入最小版本。第一版只需要让用户完成一个核心任务：

1
输入：用户必须提供什么？
2
处理：产品真正完成哪一步？
3
输出：用户拿到什么可以继续使用的结果？
4
成功：用户如何判断任务完成？

可以邀请用户使用真实数据，而不是演示数据。记录他们是否能独立完成任务、在哪里卡住、是否需要额外解释，以及完成之后有没有继续使用。

真正有价值的反馈通常来自行为：用户主动回来、把产品推荐给同事、要求增加相关能力，或者愿意继续付费。单次使用结束后的“挺不错”，只能作为弱信号。

一个 7 天验证安排#

如果需要给验证设一个边界，可以采用 7 天：

第 1 天：整理假设。 写清目标用户、场景、问题、现有解决方式和价格假设。

第 2 天：联系用户。 找到至少五个符合条件的人，优先联系有最近一次真实经历的人。

第 3 天：完成访谈。 只讨论过去的行为，不急着展示完整产品。

第 4 天：人工交付。 选择两到三个用户完成一次结果交付，记录耗时和修改次数。

第 5 天：测试页面和价格。 让用户看到明确的结果和行动入口，观察是否愿意留下更强承诺。

第 6 天：做核心流程。 只实现人工交付中最重复、最值得自动化的一步。

第 7 天：复盘行为。 根据实际使用、再次访问、提交样例和付费动作决定继续、调整或停止。

如何解释结果#

验证结果通常不是简单的成功或失败。可以用下面的方式判断：

没人回应： 可能是渠道不对，也可能是问题不够强，先检查目标用户定义。
有人回应但不提供样例： 可能只是感兴趣，没有真实任务。
愿意试用但不愿付费： 价值、信任或价格至少有一项没有成立。
愿意付费但交付成本太高： 需求可能成立，但方案还不适合自动化。
持续使用并主动反馈： 可以进入下一轮产品迭代。

可以把“没有付费”拆开分析，不要直接把它归因于产品不行。不同原因对应不同动作：换渠道、缩小用户、改交付结果、调整价格，或者停止方向。

设定继续和停止标准#

测试开始前，应写下继续条件和停止条件。例如：

1
继续条件：
2
- 至少 3 个目标用户完成真实任务
3
- 至少 1 个用户愿意支付或预订
4
- 核心结果可以在可接受时间内交付
5

6
停止条件：
7
- 连续接触 10 个合适用户仍没有真实任务
8
- 用户承认问题存在，但不愿投入任何代价
9
- 每次交付都需要完全不同的定制
10
- 核心结果无法在小范围内稳定交付

这些数字不是通用标准，可以按产品价格、用户类型和触达成本调整。先写下来，测试结束后才不容易被情绪带着走。

用行为决定是否继续#

验证付费意愿时可以按这个顺序走：

真实经历 → 人工结果 → 明确价格 → 真实任务 → 付费或预订。

在开发前确认“不值得做”，同样是有效结果。它省下的可能不是几小时，而是后面几周的开发时间。

下一篇会讨论：当需求已经值得继续时，如何把它收缩成一个真的能完成的 MVP。

独立开发者如何找需求：从线索收集到付费验证

Sun, 27 Sep 2026 00:00:00 GMT

独立开发最容易走错的一步，是把“能做什么”误当成“用户需要什么”。

现在用 AI 编程做出一个能运行的产品，可能只需要几小时。但代码写得越快，越应该把时间花在开发之前：确认问题是否真实、用户是否反复遇到、现有方案为什么不够用，以及有没有人愿意为更好的解决方案付出代价。

先不要急着给项目贴上“做中文工具”或“做全球产品”的标签。最后做成 AI 工具、网站、App 还是服务，都要看问题本身。更重要的是先把遇到的问题记下来，弄清楚它多久出现一次、大家为什么还在用笨办法，以及有没有人愿意为解决它付费。

先分清：想法、问题和需求#

这三个词常被混用，实际对应三个阶段：

名称	例子	还缺什么
想法	做一个帮人提高效率的 AI 工具	用户、场景和问题都不清楚
问题	独立设计师交付网页时，要反复把设计稿内容整理成前端结构	需要确认频率、影响和现有替代方案
需求	一类独立设计师每周都要处理这项工作，现有方法耗时且愿意付费减少手工操作	可以进入验证阶段

需求至少要满足下面这句话：

某类用户在具体场景中反复遇到一个问题，并且愿意付出时间、金钱或迁移成本来解决它。

这里至少要同时看到三个要素：用户、场景和代价。缺一个，就还只是线索，不能直接当成产品方向。

第一步：建立需求线索池#

先别打开编辑器，建立一个可以持续收集的线索池。每条线索先记录问题，功能放到后面再想。

1. 从日常生活和工作里收集抱怨#

最容易开始的地方是日常遇到的麻烦：重复复制、反复对照、频繁切换工具、手工整理、等待别人回复，或者每次都要搜索同一个问题。

可以把这一步叫作“收集抱怨”。用户未必能设计解决方案，但通常说得清哪里不舒服。记录时先保留原话和事实，不急着改成产品语言：

谁在什么情况下遇到了什么问题？
他现在用什么办法解决？
这个办法浪费了什么？
这个问题多久出现一次？

2. 去真实用户表达不满的地方#

比起直接问“你想要什么功能”，下面这些地方更容易看到真实问题：

App Store、Google Play、Chrome Web Store 的低分评价
G2、Capterra、Trustpilot 等软件评价平台
Reddit、Discord、论坛和垂直社区的讨论
YouTube、TikTok、X、LinkedIn 帖子下的评论
小红书、知乎、微博、微信群等中文社区
客服工单、售后聊天、产品社区的反馈
搜索结果中的“替代品”“太贵”“不好用”“怎么解决”等表达

更应该关注重复出现的抱怨。一次性的情绪不一定能形成产品，跨用户、跨时间、跨平台反复出现的问题才值得继续研究。

3. 从已有交易中寻找需求#

已有付费行为是很强的信号，但它不意味着可以直接复制产品。可以观察：

App Store 或 Google Play 中已经有收入的产品
Product Hunt、Indie Hackers 等产品社区里的付费产品
Gumroad、Lemon Squeezy、AppSumo 等数字产品交易
Amazon、Etsy、淘宝、闲鱼等商品和服务交易
自由职业平台上的重复需求和报价

需要注意的是，榜单和交易平台只能用来确认“市场上是否已经出现付费”，不能直接证明某个产品适合独立开发。看到付费之后，还要继续确认用户为什么购买、现有方案哪里不够，以及项目能否从一个更小的切口进入。

第二步：把线索写成可验证的问题#

“做一个 AI 工具”“做一个效率产品”无法验证。把线索改写成下面这个句式：

某类用户在某个场景下，因为某个具体限制，无法顺利完成某项任务，目前只能用某种低效替代方案。

例如：

独立设计师在交付网页项目时，需要反复把设计稿中的文字和结构整理成前端代码，目前主要靠手工复制，容易遗漏且每个页面都要重复处理。

这还不是产品需求，但已经能拿来验证。它没有提前假设一定要做 AI，也没有提前决定使用什么技术。

每条线索建议记录成一张卡片：

1
问题原话：用户实际怎么描述？
2
目标用户：谁遇到这个问题？
3
发生场景：什么时候、在哪里发生？
4
当前做法：用户现在如何解决？
5
问题代价：时间、金钱、错误、风险或机会损失是什么？
6
出现频率：每天、每周、每月，还是偶发？
7
已有证据：链接、评价、交易、访谈或实际使用记录
8
待验证假设：下一步最需要确认什么？

第三步：用证据筛选，而不是凭兴奋感选题#

收集十到二十条线索后，再做初筛。可以使用 1 到 5 分的简单评分：

维度	1 分	5 分
出现频率	偶尔发生	每天或每周发生
问题代价	不解决也没影响	造成明显损失或风险
用户范围	只有一个人	有清晰且可触达的一类人
付费证据	没有任何交易	已有稳定付费或明确预算
现有方案	用户很满意	用户持续抱怨或被迫绕行
触达难度	找不到用户	有明确社区、渠道或名单
MVP 可行性	需要复杂基础设施	可在几天内完成核心动作

这张表不是用来算出“正确答案”的，而是把判断依据留下来。分数最高的题目也不一定要做，分数最低的题目也不一定完全没有机会；它只是帮助判断是否因为喜欢某个技术，就忽略了需求证据。

三个快速排除问题#

遇到下面三种情况，可以先停下来：

不解决也没什么损失。 用户觉得麻烦，但不会因此花钱、换工具或改变流程。
问题出现得太少。 一年遇到一次的问题，通常很难支撑持续使用的产品。
现有方案已经足够好。 用户没有理由承担迁移成本，除非你能提供明确的价格、体验或渠道优势。

判断标准可以压缩成一句话：需求就是有人愿意付出代价。这里的代价不只指现金，也包括留下联系方式、提供数据、切换工具、投入时间试用或委托他人处理。

第四步：从低成本验证付费意愿#

验证不是为了证明所有人都会买，而是尽快知道这个问题值不值得继续投入。可以按成本从低到高推进：

1. 验证问题是否重复出现#

在三个以上独立来源中寻找相似表达，记录原文、时间、用户类型和上下文。不要只统计点赞数，因为高赞代表内容受欢迎，不一定代表用户愿意购买解决方案。

2. 访谈最近一次真实经历#

不要问“你会不会使用这个产品”，而要问：

你上一次遇到这个问题是什么时候？
当时具体怎么处理？
花了多少时间或钱？
现在为什么还没有换一种方式？
如果必须解决，你会先尝试什么？

用户描述过去的行为，比预测未来的态度更可靠。

3. 先人工交付，再考虑自动化#

如果产品想法是“自动生成”“自动整理”或“自动分析”，先手工为三到五个用户完成一次结果。这个过程能验证用户真正需要的输出是什么，也能发现原本没有想到的输入、边界和例外。

4. 发布一个明确的页面#

用 Landing Page 说明四件事：为谁解决什么问题、现在的解决方式有什么不足、你的方案交付什么结果、用户下一步要做什么。可以用预约、试用申请或预订作为行动入口。

页面访问量、点赞和收藏只能说明有人看到了它。更强的信号是用户留下可联系的信息、提交真实样例、愿意试用，或者愿意支付订金。

5. 做一个只包含核心动作的 MVP#

MVP 的任务不是展示完整产品，而是让用户完成一次真实任务。比如：

输入一份资料，得到可直接使用的结构化结果
上传一张图片，完成一次转换
填写一个表单，得到一个可以执行的报告
连接一个数据源，解决一个重复操作

如果 MVP 需要登录、复杂后台、多人协作和十几个设置项才能验证核心假设，范围通常已经太大。

一个 48 小时验证流程#

调研不能无限拖下去，所以可以把第一轮验证限制在 48 小时：

第 1 至 4 小时：收集线索。 从日常经历、差评区、社区和交易平台记录十条问题，保留原始链接和原话。

第 5 至 8 小时：合并重复问题。 把相似抱怨归类，筛出出现频率最高的三类问题。

第 9 至 16 小时：补充证据。 找竞品、价格、用户评价、替代方案和可以触达的用户群体。

第 17 至 24 小时：写出验证假设。 明确用户、场景、核心动作和成功指标，不写完整功能清单。

第 25 至 40 小时：进行低成本测试。 做一个页面、原型或手工服务，邀请真实用户完成一次任务。

第 41 至 48 小时：做去留判断。 记录用户实际做了什么、是否愿意继续使用、是否出现付费或预订行为，再决定继续、修改还是放弃。

如何保持客观#

成功案例很容易把需求调研带偏。可以给每条结论标上来源：

事实： 有原始链接、交易记录、用户行为或访谈记录支持。
经验： 某个开发者在特定项目中的做法和结果。
推断： 根据现有证据提出的假设，还没有被验证。

例如，“某 App 在付费榜上排名靠前”是事实；“这个品类适合独立开发”是推断；“两天就能做出替代品”则需要通过 MVP 验证。

全球市场也不意味着只研究英文内容。不同地区的用户可能有不同的支付方式、法规、分发渠道和使用习惯。正确做法是先用同一套问题框架收集证据，再单独验证目标市场的用户、渠道和商业条件。

什么时候停止一个方向#

以下情况出现时，可以暂停投入，而不是继续增加功能：

连续接触的用户都没有最近一次真实经历
用户承认问题存在，但不愿意投入任何代价解决
现有产品已经足够好，你只能复制功能而没有明显差异
找不到稳定触达目标用户的渠道
核心价值无法在一个小版本中交付
多轮测试都没有出现实际使用或付费行为

遇到这些情况就先停止投入，把时间留给证据更充分的线索。独立开发的优势在于能用较低成本排除错误方向。

从线索到决定#

找需求时可以按这条顺序走：

收集原话 → 找重复问题 → 记录现有替代方案 → 判断问题代价 → 验证真实行为 → 决定是否开发。

AI 编程让“做出来”越来越容易，“决定做什么”就更要靠前。先找到具体的人和场景，再确认他是否反复为同一个问题付出代价。

下一篇会继续讨论：当你收集到多个需求线索后，如何比较它们的市场空间、竞争和独立开发可行性。