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