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

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

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

例如：

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

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

用一条主流程定义 MVP#

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

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

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

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

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

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

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

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

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

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

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

只保留一条核心价值链#

功能可以分成三类：

例如一个内容整理产品：

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

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

AI 编程的正确分工#

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

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

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

三天 MVP 节奏#

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

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

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

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

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

建立验收清单#

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

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

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

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

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

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

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

发布后的观察指标#

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

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

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

什么时候停止增加功能#

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

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

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

第一版的边界#

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

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

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

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

先判断问题强不强#

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

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

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

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

再判断市场是否可触达#

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

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

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

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

先把竞品当成证据#

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

可以从四个角度看竞品：

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

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

判断是否适合独立开发#

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

需求评分表#

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

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

90 分钟筛选流程#

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

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

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

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

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

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

常见的错误判断#

最终输出：一张决策卡#

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

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

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

筛选后的决定#

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

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

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

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

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

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

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

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

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

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

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

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

第二步：先做人工服务#

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

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

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

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

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

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

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

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

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

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

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

可以准备三个价格假设：

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

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

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

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

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

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。

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

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

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

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

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

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

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

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

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

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

例如：

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

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

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

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

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

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

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

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

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

一个 48 小时验证流程#

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

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

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

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

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

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

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

如何保持客观#

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

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

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

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

什么时候停止一个方向#

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

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

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

从线索到决定#

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

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

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

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