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