从真实问题定义产品
在写代码前明确用户、场景、问题和成功标准，让所有技术决定服务同一个结果。
- 团队和 AI 都能判断一个需求是否属于当前版本。
- 用户问题、价值主张和主流程
- 为一个两周内能完成的产品写 Brief，并明确至少五项本期不做。
- 完成 7.5「日志、监控、备份与恢复」
FOUNDATION
必须理解
在写代码前明确用户、场景、问题和成功标准，让所有技术决定服务同一个结果。
真实产品从具体人群、具体情境和具体阻碍开始。需求说明把模糊想法变成可验证范围，让设计、代码和 AI 都围绕同一个问题工作。
“做一辆好车”无法开工，“让每天通勤 5 公里的人在雨天安全到达，首版只载一人”才包含用户、场景、目标和边界。
任务应用首版服务于需要安排自学任务的大学生，核心流程只有登录、创建、查看、完成任务；社交、AI 自动规划和复杂统计暂不进入 MVP。
用户问题、价值主张和主流程
问题陈述要说清谁在什么情况下遇到了什么麻烦，以及他现在怎么凑合解决。先把问题弄明白，别因为自己想用某项技术，就反过来编一个需求。
基础概念
用户问题描述特定人群在特定场景中的阻碍，价值主张说明产品带来的改善，主流程是用户从进入到获得核心结果的最短行为链。
进一步理解
问题陈述要包含谁、何时、想完成什么、现有办法为何不够。先观察问题，再讨论功能，避免因为想用某项技术而编造需求。
价值要能被用户感知，例如节省整理时间或减少遗漏；“使用 AI”只是实现方式，不天然构成价值。
学生在课程多且分散时无法知道下一步，任务应用让他从一个入口看到今日唯一任务并记录完成。
用户提出的功能不是问题本身。“需要日历”可能来自害怕忘记截止时间，也可能来自安排冲突，解决方案会不同。
这一小节记住：先定义谁在什么场景遇到什么阻碍，再选择最短主流程。
MVP、非目标和范围控制
MVP 是能验证最关键假设的最小产品，不是把十个功能都做成半成品。任务应用只要让核心用户顺利完成一条主流程，就已经能开始验证。
基础概念
MVP（Minimum Viable Product，最小可行产品）是能够验证关键价值假设的最小完整版本；非目标明确本期不会解决什么，范围控制保护核心流程按时完成。
进一步理解
最小不等于粗糙或只有半条流程。用户必须能够完成核心任务，只是次要角色、自动化和高级设置可以暂缓。
每增加功能都要问：没有它能否验证关键假设？若能，进入后续清单。非目标写出来能减少开发中“顺便加一下”。
第一版只支持登录、查看今日任务、标记完成；团队协作、积分、日历同步和 AI 自动规划明确不做。
原型可以是假数据和演示，MVP 通常需要让真实用户完成真实任务并产生可观察反馈，两者目的不同。
这一小节记住：用最小但完整的体验验证一个最重要假设。
可观察的验收标准与风险假设
验收标准告诉大家怎样算完成，非目标则提前写清这版不做什么。两张清单一起用，能挡住开发过程中不断冒出来的“顺便加一下”。
基础概念
验收标准是能够被观察和明确判定的完成条件；风险假设是尚未被证明、但失败后会显著影响方案的重要判断。
进一步理解
标准应描述输入、行为与结果，例如“未登录访问任务页会进入登录，登录后返回原位置”，而不是“登录体验良好”。
风险假设包括用户是否需要、技术是否可行、数据是否可得和运营是否可承受。优先验证影响大且不确定性高的假设。
验收规定三位目标用户无需口头指导即可在两分钟内找到并完成今日任务；风险是他们是否愿意每天打开。
任务清单描述要做什么，验收标准描述怎样算成功；测试用例可由标准进一步展开，但三者并非同义词。
这一小节记住：把模糊愿望改写成可观察结果，并提前暴露最危险假设。
AI COLLABORATION
AI 如何参与
让 AI 先提出影响方案的问题，再输出多种范围选择和取舍，而不是立即生成完整应用。
推荐协作顺序
- 1
先让 AI 提问，不允许它直接替用户写需求。
- 2
把回答交给它整理成问题、假设、MVP 和非目标。
- 3
逐条标记哪些有证据、哪些只是猜测，再删掉首版不需要的功能。
请作为产品经理帮助我澄清“个人学习任务应用”。先连续提出不超过 8 个问题，覆盖目标用户、使用时刻、现有替代、最痛阻碍、核心动作、成功信号和不做什么。收到回答后输出一页产品简报，不要自行虚构用户研究。
简报包含问题、用户、核心流程、MVP、非目标、风险和可测验收；未知信息明确标注为假设。
人工检查清单
- 确认 AI 没把自己的猜测写成“用户需要”，也没有把技术栈当作用户价值。
- 让 AI 先提出影响用户、场景和成功标准的问题，再生成不同范围及明确取舍。
- 拿 Brief 交给一位目标用户复述，确认他理解的问题与主流程和你一致。
COMMON TRAPS
常见误区
错误不是需要隐藏的失败，而是帮助你看清系统边界的证据。下面三类问题在 AI 辅助学习中最常出现。
先选技术，再找问题
- 你会看到
- 因为想学 AI 或 Redis，硬给产品加入用不到的功能。
- 为什么发生
- 功能数量容易被当作进度代理，却不能证明用户问题被解决，反而稀释主流程。
- 怎样纠正
- 先确认用户在什么时刻被什么阻碍，再决定技术是否有帮助。
MVP 变成所有功能的简陋版
- 你会看到
- 社交、统计、AI 规划都做一点，但核心任务仍走不通。
- 为什么发生
- 技术偏好会诱导团队寻找使用场景，最后产品只证明某项技术能被接入。
- 怎样纠正
- 只保留验证关键假设所需的完整主流程。
把 AI 猜测当成用户研究
- 你会看到
- 简报里写满“用户通常会”，却没有访谈或行为证据。
- 为什么发生
- 没有非目标时，每个合理建议都会进入当前版本，发布日期和验收边界不断移动。
- 怎样纠正
- 未知内容明确标为假设，去找真实用户验证。
HANDS-ON
动手任务
为一个两周内能完成的产品写 Brief，并明确至少五项本期不做。
- 完成 7.5「日志、监控、备份与恢复」
跟着做
- 01
访谈或观察至少一位目标用户的真实学习安排。
- 02
写出问题陈述与现有替代方式。
- 03
画出从进入产品到完成任务的最短流程。
- 04
定义首版功能、非目标和三条验收标准。
- 05
请 AI 找出模糊词，再由你根据证据修订。
团队和 AI 都能判断一个需求是否属于当前版本。
删掉首版中价值最低的一项功能，并说明它将在什么证据出现后重新考虑。
离开本课前，自问四件事
- 问题陈述、价值主张和主流程分别回答什么？
- 为什么 MVP 不是许多功能各做一半？
- 非目标如何帮助保护当前版本？
- 我能否把一个模糊需求改成可观察验收标准和风险假设？
确认完成后，会同步更新学习中心的课程学习进度。