从反馈进入下一轮迭代
迭代从真实使用证据开始。先观察用户在哪一步停下，再判断是体验、可靠性还是需求问题，最后只改一个主要假设。
- 完成一次用户任务观察，整理证据并选择一个有明确验收标准的下一版改动。
- 行为数据、访谈和错误日志
- 实现从反馈进入下一轮迭代后，应当完成一次用户任务观察，整理证据并选择一个有明确验收标准的下一版改动，并保留用户任务观察、改动差异、冒烟测试和版本复盘作为可重复检查的依据。
- 完成 8.3「发布第一个可用版本」
FOUNDATION
必须理解
产品上线后得到的是证据，不是终点。反馈需要区分事实、解释和解决方案，再按频率、影响、信心与成本排序，避免被声音最大的一条意见带走。
本课依次讲清行为数据、访谈和错误日志、问题频率、影响与成本排序和假设、实验和版本复盘，最后通过“选择最高价值问题，定义一个最小改动与成功信号”检查学习结果。
顾客说“把门换大”是解决方案，真实问题可能是推婴儿车进门困难。先理解阻碍，再决定换门、加坡道还是调整入口。
用户说“希望自动规划”，观察却发现很多人根本找不到新增按钮。首轮应先修核心流程可发现性，再验证是否真的需要复杂 AI 功能。
行为数据、访谈和错误日志
行为数据告诉你用户实际做了什么，访谈帮助你理解为什么，错误日志则能揭示技术失败。只看其中一种，很容易得到片面的结论。
基础概念
行为数据记录用户实际做了什么，访谈解释动机与感受，错误日志揭示技术失败。三类证据互相补充，单独使用都可能误导。
进一步理解
行为显示在哪一步退出，却不直接说明原因；访谈能提供原因但会受记忆与礼貌影响；日志能证明请求失败，却不知道用户是否理解界面。
收集前先定义问题与隐私范围，只记录决策需要的数据。把时间、用户类型和场景一起保存，避免脱离上下文统计。
数据显示多人停在创建页，日志无错误，访谈发现按钮文案像“保存草稿”而非“创建任务”，于是问题更可能在理解而非技术。
点击量高不自动代表价值高，访谈中的称赞也不代表用户会持续使用；最终要看核心任务是否更成功。
这一小节记住：用行为看发生什么，用访谈理解为什么，用日志确认系统是否失败。
问题频率、影响与成本排序
用户原话最好保留下来，同时记住是谁、在什么场景、出现了几次、影响多大。用户提出的功能可以参考，但它只是一个候选办法。
基础概念
反馈排序要综合问题频率、用户影响、战略价值、解决成本与证据可信度。用户描述的困难是证据，提出的功能只是候选方案。
进一步理解
先把相同问题聚类，保留原话和场景，再判断影响的是核心流程还是边缘偏好。高频小摩擦与低频灾难性问题都可能优先。
成本不仅是开发时间，还包括迁移、支持、长期维护与新增风险。排序公式提供讨论框架，不能替代产品判断。
多位用户找不到今日任务属于高频核心阻碍；一位用户要求十种主题属于低影响偏好，先验证导航问题。
“声音最大”不等于“影响最大”，频率也不能单独排序；严重数据丢失即使只发生一次也应优先。
这一小节记住：先确认问题与影响，再比较成本；不要直接照做用户给出的解决方案。
假设、实验和版本复盘
迭代就是先提出一个假设，做尽量小的变化，再看结果有没有改善。复盘时把原本预期、真实结果和下一步写下来，避免下个版本又从猜开始。
基础概念
迭代假设说明某个变化为什么会改善某项结果，实验用最小改动验证，版本复盘比较原预期、真实结果与下一步。
进一步理解
假设应具体到目标用户、改变、指标和时间范围。一次实验尽量只验证一个核心变量，并提前定义成功、失败和无结论。
上线后收集足够样本与定性反馈，避免看到第一条好评就宣布成功。复盘保留未预期影响，决定扩大、调整或撤销。
假设“把今日任务放到首页可提升新用户首日完成率”，先对一部分用户调整入口，两周后比较并访谈。
发布新版本不是实验完成；没有对照、目标指标或决策规则时，只能知道做了改动，不知道为何有效。
这一小节记住：每轮只用足够小的变化回答一个重要问题，并让结果决定下一步。
AI COLLABORATION
AI 如何参与
在从反馈进入下一轮迭代这一课，AI 负责根据真实材料解释行为数据、访谈和错误日志并指出遗漏，学习者负责控制范围、执行修改和核对用户任务观察、改动差异、冒烟测试和版本复盘。
推荐协作顺序
- 1
把原始访谈、行为数据和日志分开交给 AI。
- 2
让它为每条归纳标注证据来源和不确定性。
- 3
只选一个最高价值问题设计小实验，观察结果后再决定是否扩大。
以下是脱敏的观察记录、支持问题和使用数据。请区分事实、解释与建议，按影响人数、任务阻塞程度和修复成本整理。不要虚构用户动机或样本结论。最后给一个最小实验及成功和停止条件。
反馈与证据可追溯，事实和推测分开；实验小而可测，并说明放弃了哪些低优先级问题；从反馈进入下一轮迭代的人工验收必须回到真实页面、请求、终端、测试或数据结果，不能用 AI 的文字说明代替。
人工检查清单
- 确认 AI 没把缺失数据补成数字，也没有把称赞、单个意见或异常用户代表所有人。
- 要求 AI 区分用户原话、观察事实、推断和建议方案，禁止补造人数或结论。
- 上线实验前写明指标与决策规则，结束后用真实数据和访谈核对，而不是让 AI 概括出想听的答案。
COMMON TRAPS
常见误区
下面三类问题会让任务看似完成，却经不起刷新、错误输入或真实环境检查。先看现象，再找原因和修正方法。
把所有反馈都做掉
- 你会看到
- 产品范围失去方向
- 为什么发生
- 反馈服务于不同用户和场景，未经筛选地合并会冲淡产品主任务。
- 怎样纠正
- 用核心场景和证据筛选
替用户解释动机
- 你会看到
- 观察记录混入开发者猜测
- 为什么发生
- 观察只能证明发生了什么，动机若未追问就仍是开发者的猜测。
- 怎样纠正
- 分开记录事实与推断
一次改很多变量
- 你会看到
- 结果变化后无法判断原因
- 为什么发生
- 多个因素同时变化后，结果无法归因，下一轮也就没有可靠结论。
- 怎样纠正
- 每轮只验证一个主要假设
HANDS-ON
动手任务
完成一次用户任务观察，整理证据并选择一个有明确验收标准的下一版改动。
- 完成 8.3「发布第一个可用版本」
跟着做
- 01
整理三位用户的观察记录和原话。
- 02
加入主流程成功率、错误日志等行为证据。
- 03
把问题按发现、理解、操作、技术失败分类。
- 04
用频率、影响、信心、成本进行排序。
- 05
选择最高价值问题，定义一个最小改动与成功信号。
完成一次用户任务观察，整理证据并选择一个有明确验收标准的下一版改动。
写一份版本复盘：原假设、做了什么、证据说什么、保留或放弃什么、下一轮只验证什么。
离开本课前，自问四件事
- 行为数据、访谈和错误日志分别能证明什么、不能证明什么？
- 排序反馈时为什么要同时考虑频率、影响、成本和证据？
- 用户遇到的问题与用户建议的方案有什么区别？
- 一个可验证迭代假设应包含哪些对象、变化、指标和决策规则？
确认完成后，会同步更新学习中心的课程学习进度。