从好奇到产品：AI 作为共建者的故事

认识那位好奇的构建者（和他们的 AI 助手）

Maya 并不是想“创办一家初创公司”。她只是想阻止一件小而恼人的事再发生。

每个星期一，她团队的状态更新以五种不同的格式到来——要点、段落、截图、半成品想法——她要花一小时把这些整理成领导层能读懂的内容。这不是辛苦的活，只是……不必要。

几个月后，问题终于卡住了：

为什么这事总是发生？

好奇心变成产品想法的那一刻

起初，Maya 做了大多数人会做的事：抱怨、耸肩、再做一个表格。

但这一次她停下来，把自己的烦恼当作线索。如果每周都有这个问题——影响到多个人——也许它就不是“只有 Maya 的团队”的问题。也许这是值得理解的模式。

这是转变：从“这很烦人”到“这可能是别人愿意付钱解决的问题”。不是因为方案多么光鲜，而是因为痛点普遍。

AI 助手登场（但它会问更好的问题）

Maya 打开她的 AI 助手，写了一个凌乱而诚实的提示：

“我厌倦了重写状态更新。这里能有一个简单的产品想法吗？”

AI 没有直接给出一个光鲜的应用概念，而是开始问澄清性问题：

• 谁在写这些更新（角色、资历、团队规模）？
• 对你的受众来说，什么样的更新被视为“好”的更新？
• 现在的更新放在哪里（Slack、电子邮件、Notion）？
• 哪个环节最费时间：追人、重写、格式化还是摘要？

Maya 回答后意识到她一直在试图同时解决三个问题。其中一个最突出：把零散的更新变成一致、可读的周报。

明确期望（这样你不会把方向盘交出去）

AI 帮助 Maya 结构化思路——组织问题、列出假设、建议测试方法。但 Maya 仍然决定什么重要：要聚焦哪个痛点、哪些权衡可以接受、以及对真实用户来说“更好”是什么样子。

AI 可以起草选项，构建者做决定。

把一个问题变成值得解决的问题

好奇心常以模糊的一句话开始：“为什么这么难？”或“有没有更好的办法？”在 Maya 的记事本里，这听起来很有意思——但并不可操作。

于是她让 AI 助手像一位耐心的编辑，而不是炒作机器。目标不是更多的点子，而是更清晰的问题。

1）从好奇到问题陈述

她把凌乱的想法贴上去，然后要求：

“把这段话改写成一句话的问题陈述。然后给我三个版本：面向初学者、面向商业人士、以及情感上诚实的版本。”

几秒钟内，她得到了足够具体可以评估的选项。她选了那个指向真实摩擦点的，而不是功能性的描述。

问题陈述示例： “试图做 X 的人在 Y 时常常卡住，导致 Z 后果。”

2）谁有这个问题——什么时候发生？

接着，AI 让场景具体化：

• 人物： 谁在感受痛点？
• 时刻： 出问题前他们在做什么？
• 情境： 在手机上、工作中、时间紧迫、单独、与客户在一起？

这会把“任何人”这种泛泛的受众，变成真实的人群（例如：“新的团队负责人，在周报前 30 分钟”）。

3）在构建前要测试的假设

AI 给出一个快速的假设清单，用可测试的断言来表述：

• 人们经常遇到这个问题，足以在意。
• 现有的变通办法感觉慢、冒险或令人厌烦。
• 更简单的方法会被信任。
• 构建者能接触到这些人以便进一步了解。

4）简单的成功指标

最后，她定义了“更好”而不需要复杂表格：

成功指标： “首次用户在不到 10 分钟内能从卡住到完成，无需寻求帮助。”

现在问题不再只是有趣——而是值得去测试。

快速研究且不迷失方向

Maya 的好奇心有个问题：信息噪声太多。随便搜“帮我规划 MVP”会打开几十个标签页——模板、课程、无代码工具、互相矛盾的观点。

于是她让 AI 助手简化请求：“绘制已有市场图谱，告诉我人们在不买产品时通常怎么做。”

从市场地图开始（别掉进兔子洞）

几分钟内，AI 把空间分组为：

• 类别（工具、服务、模板、社区）
• 替代方案（人们会买什么以外的东西）
• 自助解决办法（电子表格、Notion 文档、短期雇佣自由职业者）

这不是裁决——只是地图。它能帮 Maya 看清点子可能落在哪儿，而不是在读完三篇博文后就自以为“做了研究”。

做一个你能实际用的比较表

接着，她要求一张表格：“主要选项、典型定价、缺点与常见抱怨。”

它是不同的，还是熟悉的换汤不换药？

AI 会抛出更难的问题：“什么能真正让它与众不同，而不是另一个同类包装？”这会把 Maya 推向一个清晰的切入角度——更快的清晰度、更少决策，而不是“全能一体的平台”。

标记以后要验证的断言

最后，AI 会把一些在客户发现中要验证的陈述标注出来：“人们讨厌课程”“模板不管用”“教练太贵”。这些是假设，直到真实用户来确认。

选择产品的目标人群

好奇心会在你脑中召集一群人：学生、经理、自由职业者、父母、创始人。你的 AI 助手会乐于为所有人头脑风暴功能——但这恰恰是项目悄然膨胀的方式。

解决办法很简单：为一个真实的人在真实场景下构建首个版本。

草拟 2–3 个快速人物画像（有具体场景，不要泛泛而谈）

别用“忙碌的专业人士”这种刻板标签，让 AI 帮你用具体情境描绘人物：

• 他们在问题发生时在哪里？（在办公桌上、在工地、在会议间隙的手机上）
• 他们已经用哪些工具？（电子表格、WhatsApp、Notion、电子邮件）
• 他们害怕什么？（看起来没准备、浪费时间、错过截止）

示例人物：

• Maya，一位自由职业市场人员，在客户请求和不断切换上下文之间奔波。
• Jordan，一位团队负责人，需要在周会前快速理清状况。
• Sam，一位学生型构建者，喜欢快试错但在选择下一步时常卡住。

把人物画像变成用户故事

让 AI 把每个画像转换为 2–3 个用户故事，格式为：

“当 X 时，我需要 Y，以便 Z。”

例如对 Maya： “当客户发送零散笔记时，我需要一份清晰的简报，这样我就能在不重读所有消息的情况下自信回复。”

选一个主要用户——和一个主要工作要完成

现在做一个艰难的选择：把一个主要用户定为版本一的目标。

一个好的规则是选那个痛点最明确且到达小胜利路径最短的画像。然后定义一个主要的待办工作（job-to-be-done）——你第一版必须实现的单一结果。其它都写到“以后再说”。

客户发现：更好的问题，更快的进展

我们的好奇构建者脑里有个原型、一些强烈的观点，以及一个大风险：用只会证实自己偏见的方式访谈别人。

AI 让客户发现更快——但真正的价值在于让过程更干净：减少诱导性问题、更清晰的笔记、更简单的方法来判断反馈是否重要。

1）生成不“引导证人”的问题

好的发现性问题应能引出故事。坏的问题在于询问许可。

让 AI 把你的问题改写成无假设的开放式问题。例如：

• 不要问： “你会使用一个自动记录膳食的应用吗？”
• 改问： “讲讲你上次尝试记录膳食的经历——发生了什么？”

你可以用的提示：

Rewrite these interview questions to avoid leading language or assumptions. 
Make them open-ended, focused on past behavior, and easy to answer.
Questions: ...

（注：上面代码块保持原样以便直接复用。）

2）构建一个紧凑的 30 分钟访谈脚本（和笔记模板）

速度来自结构。让 AI 起草一个你可以重复十次的简单流程：

• 0–5 分钟： “你的一天/职责是什么？”
• 5–20 分钟： 两到三个近期故事（“带我回到上次……”）
• 20–25 分钟： 优先级与权衡（“如果只能修复一处，你会选哪一部分？”）
• 25–30 分钟： 收尾与推荐（“我还该找谁聊？”）

然后生成一个笔记模板，避免你被逐字稿淹没：

• 情境： 他们是谁，今天用的工具
• 触发器： 问题何时开始
• 当前变通办法： 他们现在做什么（以及为什么）
• 痛点程度： 代价（时间、金钱、压力）
• 引用： 直接粘贴他们的原话

3）规划外联：找到 10 个类似目标用户

让 AI 头脑风暴你的精确受众聚在哪里，然后当周选两个渠道执行：小众 Slack/Discord 群组、LinkedIn 搜索、Reddit 社区、聚会名单或熟人推荐。

目标不是“很多访谈”，而是10 次相关对话，每次用一致的问题。

4）决定什么算“信号”（而不是好评）

好听的反馈说：“挺酷的想法！” 真正的信号表现为：

• 他们能无提示地描述最近的一次具体情境
• 他们已为此花时间或金钱
• 如果问题变糟他们会感到失望
• 他们会问“什么时候能试？”或愿意引荐他人

让 AI 给你的笔记标注 Signal / Maybe / Noise，但最终判断权仍在你手里。

把人们说的话整理成可操作的东西

经过几次用户对话后，好奇的构建者会遇到熟悉的问题：笔记成堆、许多“也许”，以及害怕自己只听到了想听到的东西。

这时 AI 助手能真正派上用场——不是靠发明洞见，而是把凌乱对话变成可操作的输出。

把笔记变成主题（但不要抹平矛盾）

先把原始笔记放到一个文档里（每次访谈一个段落）。然后让 AI 把每条陈述归到简单的类别：

• 痛点（令人恼火或成本高的事）
• 触发器（促使他们寻找解决方案的时刻）
• 现有工具/变通办法（他们现在用什么，即便是“电子表格和希望”）

目标不是完美的分类法，而是一个共同的地图，便于回顾。

用 AI 总结模式——并指出矛盾点

接着，提示 AI 总结重复出现的模式并高亮矛盾。矛盾是金矿：它们往往代表不同的用户类型、不同情境，或问题并不一致。

例如：

“我没有时间去设置任何新东西。”

……可以与：

“如果它能每周节省我 2 小时，我愿意学它。”

并存。AI 可以把这些并列呈现，避免你把它们平均成无意义的糊状物。

写出带证据的“前三大问题”

把主题变成一个简单的 前三大问题 列表，每项包含：

1. 问题的通俗陈述
2. 谁会遇到（角色/情境）
3. 1–2 条证据引用

示例格式：

• 问题 #1： 当 Y 发生时，人们会失去对 X 的跟踪。
  • 证据： “……”

这能帮你保持诚实。如果找不到引用，也许那只是你的假设，而非他们的现实。

决定：继续、转向，还是暂停

最后，让 AI 帮你基于所学做出决定：

• 继续：如果相同的痛点反复出现并且人们已经为应对而花费时间/金钱。
• 转向：如果痛点存在但“谁”或“何时”与预期不同。
• 暂停：如果兴趣只是礼貌性的、证据薄弱，或问题在深入调查后消失。

你不需要确定性——只需要一个扎实的下一步。

设计最小可用版本（MVP）

此时，好奇的构建者有一本笔记和一堆“顺便再做这个…”的想法。AI 在这阶段最有用的，不是加更多功能，而是帮助你删去到能真正交付的核心。

草拟几条路径，然后选一个

别把精力都放在一个想法上，让 AI 列出 5–7 个解决方案草图：不同方式让产品传递价值。让它按工作量 vs. 影响给每个方案打估分。

一个简单的提示：

“列出 7 种解决这个问题的方法。对每个估计工作量（S/M/L）和影响（S/M/L），并说明原因。”

你不是要完美，只要清晰的优先选手。

选一个能交付单一核心结果的 MVP

MVP 不是“完整产品的最小版本”，而是能为特定的人交付一个有意义结果的最小版本。

让 AI 把这个结果表述为可测试的承诺：

• “在 10 分钟内，你会得到 __。”
• “到结束时，你会有 __。”

如果结果不清晰，说明 MVP 还太模糊。

把要排除的写出来才是真正的计划

为了避免功能蔓延，和 AI 一起列出明确的“v1 不包含”清单：

• 仪表盘和分析
• 多种用户类型
• 集成
• 自定义和主题

这张清单会在新点子出现时成为你的盾牌。

用一句话说明它

最后，让 AI 帮你起草一句可复述的文案：

• 一句话价值主张： “一个 [简单工具]，为 [特定人群] 提供 [核心结果]，并避免 [常见痛点]。”
• 电梯陈述（2–3 行）： 它做什么、为谁服务、以及比现有变通更好的地方。

现在 MVP 是小而有目的、易于解释——正是原型之前你需要的状态。

原型制作：把点子变成可触碰的东西

原型是产品不再只是描述而开始表现得像真实东西的阶段。不是“完全构建”，也不“完美”，只是足够具体，让人可以点击、阅读并给出反馈。

把 MVP 翻译成简单流程

让 AI 把你的 MVP 转成逐屏大纲。目标是短路径，能证明核心价值。

例如，可以用这样的提示：

You are a product designer. Create a simple user flow for a first-time user.
Context: [what the product helps with]
MVP scope: [3–5 key actions]
Output:
1) Flow diagram in text (Screen A -> Screen B -> ...)
2) For each screen: title, primary CTA, and 2–4 lines of copy
Keep it friendly and clear for non-technical users.

（注：上面代码块保持原样以便直接复用。）

从这些说明你可以做出快速线框（甚至纸面），或在任一工具里做一个可点击的模型。目标是让人 10 秒内“懂它”。

先写好文案再画像素

多数原型失败的原因是文案含糊。用 AI 起草：

• 引导流程（先做什么、再做什么）
• 帮助文本（在用户犹豫处的简短说明）
• 错误信息（发生了什么，下一步该做啥）
• 关键邮件（欢迎信、“你快设置完成了”的提醒、以及简单的后续邮件）

如果你能把原型读出来并且仍然通顺，那就很稳了。

做一个“假门”测试验证兴趣

在完全构建前，先做好一个着陆页，描述承诺、展示 2–3 张原型屏幕，并放一个明确的 CTA（如“申请试用”或“加入候补名单”）。如果有人点击未构建的功能，显示友好的信息并收集邮箱。

AI 可以帮你写着陆页、FAQ 和简单的定价提示（即便只是占位符如 /pricing）。

你要看的不是称赞，而是承诺：点击、注册、回复和揭示真实意图的具体问题。

验证：在扩大投入前证明价值

验证是好奇的构建者从“这可能行吗？”转为“有人会采取行动吗？”的时刻。目标不是完美产品，而是在最小投入下证明价值。

选一个轻量测试（并让它真实）

别去构建功能，而是选一个会逼人做决定的测试：

• 一页式着陆页，明确承诺并放候补名单
• 用人工代劳的“礼宾式”版本来提供服务（但要一致）
• 与 3–5 位目标用户做小范围试点

AI 在这里能把凌乱想法变成清晰要约：标题、短描述、几个好处和一个不那么像营销的行动号召。

定义可量化的结果

发送任何东西前，写下“成功”的数字标准。不要看表面指标——看意图信号。

示例：

• 注册： 30% 的访客加入候补名单
• 回复： 50 封外联邮件产生 10 条有价值回复
• 节省时间： 用户完成任务提前 20 分钟
• 重复使用： 5 名试点用户中有 3 人下一周回归

无法衡量就无法学习。

让 AI 生成 A/B 变量（快而不是随意）

让 AI 为一个具体的人生成 10 组标题 + CTA，然后选择两组做测试。一个版本可能侧重“节省时间”，另一个侧重“避免错误”。同一要约，不同角度。

捕捉学到的并决定下一步

测试后，让 AI 总结发生了什么：人们点了什么、问了什么、困惑在哪、忽略了什么。最后用一句话决定：继续、调整或停止——并写一句关于下一步的建议。

在不懂技术的情况下规划构建

你不需要会“开发语言”来规划构建。你需要的是清晰：第一天产品必须做什么、什么可以等待、以及如何判定它是否有效。

在这里，AI 助手从“头脑风暴”转为“谨慎的项目伙伴”。

从三类清单开始

让 AI 把你的想法转成简单的构建计划：必须有（Must-haves）、可有可无（Nice-to-haves）、和以后再说（Later）。把 must-haves 压到极小——那些直接兑现你对用户的承诺的功能。

然后让它为每个 must-have 写一页“完成定义”。示例提示：

• “给出用户保存草稿的通俗规范，包括边界情况。”
• “列出‘导出为 PDF’的验收标准，非技术人员也能测试。”

用通俗语言的规范和检查表

让 AI 草拟：

• 分步构建清单（按顺序需要做什么）
• 简单的用户故事（“作为… 我想… 以便…”）及验收准则
• 你自己在分享前可以运行的测试清单

这能减少开发者或外包者的猜测空间。

明确谁做什么

如果你和别人协作，让 AI 列出角色分工：谁做界面、谁做后端、谁写文案、谁搭分析、谁负责 QA。即便一人戴多顶帽子，明确职责也能防止工作遗漏。

基本的隐私与数据处理问题

在构建前，用 AI 生成一份实用问题清单：我们收集哪些数据？存在哪里？谁能访问？用户如何删除？这不是法律条款，而是避免未来意外的准备工作。

准备构建时，选一个配合你速度的工作流

如果你非技术出身（或只是想快速推进），有些“vibe-coding”平台能帮忙。例如 Koder.ai 可以把你用通俗话写的规范通过聊天界面变成 Web、后端或移动应用——然后在测试时用快照和回滚来迭代。

实际好处不是魔法式的代码生成，而是缩短“从发现学到”到“有可试用版本”的闭环。如果以后想迁移到传统流程，也可以导出源代码。

上线：清晰的文案与冷静的检查清单

上线日不应该像上台时忘词。如果你做了调研并构建了一个小而有用的 MVP，下一步就是清楚地说明它——并让首批用户易于尝试。

一个让人安心的上线检查清单（真正重要的事情）

把 AI 当作务实的项目经理：让它把凌乱笔记变成一张整洁的列表，然后你决定哪个是真正需要的。

“够用”的清单可以是：

• 文案： 一句话说明为谁、一句话说明能做什么、一句话说明为什么与众不同。
• 演示： 60–90 秒演示（录屏或直播）。不做功能全览，只演示主要任务的完成过程。
• 引导： 首次运行的 3 步检查表（最多 3 步），再提供一个示例，避免用户面对空白页面。
• 支持： 一个联系渠道和诸如“我们 24 小时内回复”的承诺。

让 AI 根据异议草拟 FAQ

把客户发现中的主要疑虑——“这适合我的工作流吗？”，“设置要多久？”，“我的数据安全吗？”——交给 AI 起草 FAQ 回答，保留你的语气。

然后把答案修订得诚实。如果还有不确定的地方，就说明并写出计划。

一个基于故事的产品页 + 首次公告

让 AI 给出简单大纲：

1. 那一刻的挫败感（以客户为主角，而不是你的）
2. 你的小胜利（产品带来的微小改善）
3. 三步使用流程
4. 凭证（引用、截图或具体结果）
5. 明确 CTA（开始、加入候补名单、申请访问）

首次公告要真实：‘这是我们做的事、为谁做、下一步我们要测试什么。’

时间表与第一个“胜利”

设一个现实的上线窗口并定义第一个胜利，例如：10 名活跃用户、5 次完成引导流程或3 个付费试用。AI 可以帮你跟踪进度，但你要选择能证明价值的目标，而不是浮夸指标。

保持动力：把 AI 当作长期共建者

上线后，好奇的构建者并不会“从 AI 毕业”。只是他们使用 AI 的方式会改变。

早期，AI 提高速度——起草、结构化、做原型。晚些时候，它帮你保持节奏：注意模式、保持一致、让小决策更省心。

把迭代做成每周循环（而不是一次性冲刺）

设定简单节奏：与用户对话、发布一个小改进、记录结果。AI 成为默默的助手，保持循环运转。

一些能坚持下去的习惯：

• 每周用户通话（即便很短）。 AI 根据上周笔记生成通话议程和 5 个定制的跟进问题。
• 实验日志。 每次改动后记录：假设、发布内容、预期、实际结果。AI 总结结果并建议下一步测试。
• 提示库。 保存那些持续有用的提示（研究摘要、访谈问题、发布说明）。随着时间推移，它会变成你的“操作手册”。

AI 不该做的事

划清界限，让助手保持有益而非鲁莽：

• 不是最终裁判。 AI 可以建议，但由构建者决定要发布什么。
• 不是伦理部门。 AI 能提醒风险，但构建者必须设定政策与价值观。
• 不是绕过用户同意的捷径。 不要抓取私人数据、偷偷录音或说“我们让 AI 知道你想要什么”。直接问用户并保持透明。

一个可复制的框架

当动力下滑，回到这份简单脚本：

1. 倾听： 3–5 次短用户对话。
2. 综合： 请 AI 提炼主题、矛盾与未决问题。
3. 选择： 选一个问题和一个关键指标。
4. 发布： 做出能测试该想法的最小改动。
5. 学习： 记录结果，更新你的提示库，重复。

这就是好奇如何变成产品——而产品如何变成一种实践。