产品理念与 Idea 的产生

这节教程只讲 需求验证。 需求验证 的重点是判断“这个问题值不值得做”，而不是提前讨论框架、数据库或支付。 读这篇的人通常是你能直接联系到的细分用户，所以我们不从抽象概念开始，而是直接把它拆成可以执行、可以检查、可以复盘的工作流。

先确认边界。 这里的“先验证问题再验证功能”不是一句口号，而是你做决策时的约束条件：哪些事现在必须做，哪些事可以手动处理，哪些事应该明确暂缓。边界越清楚，后面让 AI 或工具协助时越不容易跑偏。

第一组重点是： 用户是谁、问题是否高频、现在如何解决、是否有明确成本、下一步验证动作。你可以把它们写在一张表里，每个重点下面只保留最关键的判断问题。不要急着追求完整，先保证自己能用普通话向另一个人解释清楚。

实际执行时， 按这个顺序走：先写一句话问题假设；列出可联系用户和证据来源；准备问题脚本或打分表；记录原话和行为证据；根据证据决定继续、缩小或暂停。每一步都应该留下可检查的材料，例如文档、表格、截图、链接、命令输出或配置记录。没有留下材料，就很难判断自己到底有没有完成。

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

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

如果你今天只能做 30 分钟， 就先做一个最小动作：从本节产出里挑一个最小文件，把标题、字段、状态和验收标准写出来。独立开发最怕把任务写成“优化产品”“研究一下”这种大词，大词没有边界，也没有完成标准。

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

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