任务场景
你脑子里有一个产品想法 + 30 个 feature（一些在 Notion、一些在笔记本、两个是 co-founder 上周二在 Slack 提的）。你想 6 周 ship。你也知道——上个项目就是这么干的——没有书面 scope 你会”再加一件就好”三次、延期 4 周、最后做出一个 6 件事都做得差的 MVP。你要一份 1 页 scope：5-7 项 IN、带原因的长 OUT、前 50 用户手工替代方案、可测的 done 定义、以及延期时的砍序。
什么时候适合让 AI 来做
AI 擅长套 MVP 原则（一个核心 job、无设置、最小打磨）、给一份能站住脚的砍掉清单、为 OUT 写原因让未来的你不再回头讨论。它也擅长提 Wizard-of-Oz 替代方案——能等的功能的手工版。AI 做不到的：判断你这个受众真正先要哪个功能。把访谈里那条”被提及最多的用户痛点”原话喂它，不要喂你的解读。否则 AI 会回到通用 MVP 模板，可能造出真实用户不在意的东西。
经典失败模式：对称 IN/OUT——AI 给你 7 项 IN + 7 项 OUT。接下来 6 周你会把 OUT 项一个个谈回 IN。正确的形状是短 IN（3-5）+ 长 OUT（15-20），每条 OUT 都有”未来的你翻不动”的原因。Prompt 强制每项 OUT 给原因 + IN 清单给砍序。
需要先给 AI 的信息
- 产品想法一句话——讲价值，不讲技术
- 访谈里被提及最多的单一用户痛点（原话引用，不要 paraphrase）
- 诚实时间盒——多少周 ship + 真实工时（不是理想化）
- 前 50 用户——他们是谁、来自哪、你怎么触达？
- 你已经做完或能复用的（现有 API、设计系统、账号）
- 你 / co-founder / 顾问 / 直觉一直在推但不确定的 2-3 个 feature
- “第 6 周 ship + 之后 4 周”成功长什么样的指标（注册、周活、留存、转化）
- 你的诚实技能短板——做什么会最慢
可直接复制的 Prompt
帮我定 1 页 MVP scope。
产品想法（一句话，讲价值不讲技术）：{粘}
访谈中被提及最多的用户痛点原话：{粘原话}
诚实时间盒：{多少周 ship，真实工时}
前 50 用户——他们是谁、我怎么触达：{粘}
我能复用的（现有）：{API、设计系统、账号}
我想加但不确定的 feature：{2-3 个候选}
Ship + 4 周的成功指标：{一个可测信号}
我的技能短板：{什么会最慢}
返回：
1）MVP 定义——干的那一个用户 job。一句话。若两个 job 偷偷进来，挑杠杆更高的那一个。
2）IN 清单——为这个单一 job 必需的功能。最多 5-7 项。每项一行"为什么单一 job 必需"。
3）OUT 清单——人会要但你这版不做的。15-20 项。每项一行"为什么推迟"（不要"以后"——给真实原因："留存阶段才重要、激活阶段不重要"）。
4）Wizard-of-Oz 候选——前 50 用户可以手工"假装"的功能。每项配手工流程。
5）Done 定义——可测，不是"看起来 OK"。量化成功指标 + 证明它的用户行为。
6）砍序——若延期，IN 项按这个顺序砍。每项注明"砍掉的风险"。
规则：
- IN 短（最多 7 项）。OUT 长（15+）。
- 每项 OUT 必须有未来的我 relitigate 不掉的原因。
- 至少 3 个 Wizard-of-Oz 候选。
- 砍序必给——你一定会延期。短版本——单段 scope 压测
用一段话压测这个 MVP scope。
MVP 定义：{粘}
IN 清单：{粘}
对每项 IN，告诉我：是 MVP 定义必需，还是 scope creep？严格非必需就砍。输出：精简后的 IN 清单 + 每项一行 justification。输出示例
好的 MVP 定义：“帮单人创始人 60 秒内决定要不要从 Stripe + 现有 billing 切到我们这边，并在注册后 5 分钟内完成一次 webhook 测试。“打败”帮创始人管 billing”。前者是一个 job，可测；后者是一个产品。
好的 OUT 行：“用户 dashboard——OUT。原因：MVP 的 job 是’决定要不要切’，不是’长期管理订阅’。Dashboard 在留存阶段重要，不在激活阶段。Wizard-of-Oz 替代：前 50 用户每周邮件发一张手工截图。等到 200 付费用户再做真 dashboard。”
好的 IN 行：“Webhook 测试沙箱——IN。原因：用户没看到自己事件 payload 触发 webhook 成功，就没法决定切不切。没这个，MVP 就交付不了单一 job。”
好的砍序：“砍序：如果延期，（1）砍 Stripe 之外的 OAuth provider——前 50 用户手工粘 API key 够了；（2）砍 inline docs 面板——链到外部 docs 页；（3）砍 variant pricing 展示——只展示最低层，其他到 v2。每砍一项注明会失去什么。”
好的 Wizard-of-Oz：“客户 onboarding 邮件——假装。前 50 注册我亲自 2 小时内发欢迎邮件 + 约 15 分钟通话。比做自动化快，能暴露真正要回答的问题，制造的摩擦还能筛掉不认真的注册。“
怎么改输出
- 强制 IN ≤ 5 —— “砍 IN 到 5 项。点名延 1 周最可能被砍的 2 项。砍不到 5，就挑’最直接服务 MVP 定义’的 5 项，其余降到 OUT。”
- 加长 OUT、深化原因 —— “再加 5 项 OUT。每项必须有’未来的我翻不动’的原因。‘以后’不算原因；‘留存阶段才重要、激活阶段不重要’算。”
- 找 Wizard-of-Oz 候选 —— “IN 里最贵的 3 项是哪些？给每项一个’前 50 用户手工版本’方案。”
- 压测 done 定义 —— “把’看起来 OK”感觉对’换成可测的用户行为。‘X% 注册在 5 分钟内完成 webhook 测试’打败’onboarding 流畅’。”
- 压测砍序 —— “如果今天就要砍 2 项 IN 而不是第 5 周再砍，你会砍哪 2 个？砍完 MVP 还能证明什么？“
容易踩的坑
- “什么都做但都做得差”的 MVP——不如”一件事做得好”吸首批用户
- 没 done 定义——临近 ship 日 scope 创，因为没人能定义”做完”
- 没砍序——一定会延（你会），到时随机砍
- OUT 没原因——6 周里有人提出某项要做时，OUT 决策站不住
- 让 AI 自己挑用户痛点——喂它原话，不喂解读
- OUT 做出来安抚 stakeholder（“别担心、v2 会做”）——v2 就是换个标签的 OUT 清单
- 加团队”激动”但用户痛点不需要的功能——激动不是 signal
- 把”用户”定义成所有人——给所有人的 MVP 上线给没有人；scope 文档挑一个 persona
FAQ
- 如果我的受众是”所有人”？ —— 选一个。给所有人的 MVP 上线给没有人。scope 文档命名一个具体 persona（他的 job、他的 context、他今天的替代方案）。日后能扩——但只在第一个 persona 的 MVP 跑得通之后。
- MVP 要多打磨？ —— 用户 30 秒不用 tutorial 能看懂价值的程度。再多——直到有留存信号前是过度投入。单一 job MVP 可以丑，但不能让人困惑。
- 多个用户痛点并列怎么办？ —— 这版 MVP 挑一个。多痛点 MVP 会变多 job 产品，scope 会散。先 ship 单痛 MVP 拿信号，再挑第二痛做 v2。
- co-founder 一直推一个 feature，怎么用文档？ —— 把这个 feature 加进 OUT 并写原因。co-founder 不同意原因，那才是该谈的对话——在原因层不在 feature 层。文档把 feature 争论转成原因争论，更快。
- OUT 要公开吗？ —— 能建立 credibility 就公开（“我们暂不做 X——理由如下”）。竞争对手会拿来用就别公开。创始人经常过度保护；OUT 清单通常不是秘密。