用户访谈：怎么问出真实需求

这节教程只讲 用户访谈。 用户访谈 的重点是判断“这个问题值不值得做”，而不是提前讨论框架、数据库或支付。 读这篇的人通常是愿意和你聊天的真实潜在用户，所以先不要急着打开代码编辑器，也不要让 AI 直接替你“做完整方案”。第一步是把问题、约束、材料和完成标准写清楚。

为什么要先做这一步？因为独立开发最稀缺的不是工具， 而是判断力。你一个人做产品时，需求、设计、开发、运营和客服都会压到同一个人身上。如果 用户是谁 没有写清楚，后面每一步都会变成返工。

本节采用“从行为里找需求”作为执行原则。 它的意思是：先做能留下证据的小动作，再决定是否扩大投入。证据可以是用户原话、搜索结果、替代方案截图、公开评论、试用记录、付款记录或你亲手整理的表。

先建立边界。 今天你只需要围绕 用户是谁、问题是否高频、现在如何解决、是否有明确成本、下一步验证动作 做判断，不需要把所有周边问题一起解决。比如还没有真实用户证据，就不要急着设计复杂后台；还没有明确行动成本，就不要先做完整会员系统；还没有上线，就不要先纠结高级监控。

实际执行时， 按这个顺序走：先写一句话问题假设；列出可联系用户和证据来源；准备问题脚本或打分表；记录原话和行为证据；根据证据决定继续、缩小或暂停。每一步都要留下材料。如果你只是“想了一下”“看了一眼”“问了 AI”，这不算完成。完成的标志是别人能打开你的文档，看到你为什么这么判断。

建议你从 问题假设表 开始。 先建一个文件，标题就写「用户访谈 - 问题假设表」。文件里放四块内容：当前判断、证据来源、暂不处理的部分、下一步触发条件。这四块比漂亮排版更重要。

如果你是小白， 最容易卡在 问题是否高频。处理方法是把它写成一句普通话：我现在要确认什么？我手上有什么证据？我缺什么材料？我今天能完成的最小动作是什么？只要这四个问题能回答，就可以继续推进。

一个可操作的例子是： 写出 3 个候选 Idea 的目标用户和场景。 这一步不要追求完整，先让它可见。你可以用 Notion、飞书表格、Excel、纸笔或仓库里的 Markdown 文件记录，工具不重要，关键是能被复用。

第二个动作是： 为每个 Idea 找到 5 条真实抱怨、搜索结果或竞品评论。 这里要特别注意，不要只写结论。比如“用户有需求”不是证据，“3 个目标用户最近一周都手动做过这件事，其中 1 个人愿意试用”才是证据。

第三个动作是： 用统一维度打分：频率、预算、可触达性、交付成本。 这一步通常会暴露取舍：哪些应该手动，哪些需要产品化，哪些暂时不值得做。把“不做什么”写下来，能帮你避免后面被新想法拖走。

第四个动作是： 选出一个方向做 7 天最小验证，而不是同时推进多个方向。 做完后不要马上开新任务，先复盘一次。复盘只问三件事：这一步证明了什么？还有什么没有证明？下一步如果失败，应该缩小范围还是换方向？

本节建议产出的材料包括： 问题假设表、用户访谈记录、竞品和替代方案表、优先级打分表。这些材料不只是给自己看，也可以作为后续让 AI 继续工作的上下文。你把材料写得越具体，AI 越容易帮你生成页面、代码、检查清单或下一步任务。

这件事最需要警惕的是： 最容易犯的错是把自己的兴趣当成市场需求，或者只听朋友夸奖，不看用户是否真的投入时间、数据、预算或迁移成本。 所以不要把“我看懂了”当成完成标准。真正的完成标准应该是能拿出文件，能解释取舍，能根据结果决定下一步。

AI 可以参与这件事， 但不能替你做判断。更合适的用法是：让 AI 帮你把草稿整理成表格，把步骤改成 checklist，把风险转成测试项，把输出改成可以直接执行的任务。关键决策仍然要由你根据产品目标和真实约束来定。

最后要形成一个可交付结果： 一份包含原话和结论的访谈记录。这个结果不一定漂亮，但必须能被复用，能指导下一步行动，也能让别人快速理解你现在做到了哪里、还差什么。