学习目标
完成一项有依据的改进，分别说明功能是否修好、实际使用效果是否已经观察。
适用场景
示例问题：从文章返回资料列表后位置丢失。它可以来自实际反馈、你自己的复现或运行记录；示例本身不代表已经发生过用户调查。
准备条件
- 带上版本、现象、预期、复现步骤及必要的脱敏证据。性能问题还需可比较的测量条件。
- 只提供和问题相关的材料；保留最近变更与可恢复版本，避免一边调查一边扩大改动。
操作步骤
把“用起来不好”变成一个观察
记录谁在做什么、在哪一步失败、实际和预期差在哪里。多个反馈先按影响和证据排先后，不把最容易实现的新功能自动排第一。信息不足时让 AI 指出下一条最有价值的证据，而不是马上重构。
先留基线，再检验一个原因
按同样步骤复现并保留原状态。让 AI 找相关代码、提出可以被推翻的原因，再用一个小实验区分它。性能类问题要保持版本、数据量和环境可比；一次更快的运行不能证明稳定改善。
交给 AI 的诊断任务版本/环境：【实际信息】 复现步骤：【操作、数据、发生条件】 实际：【错误、页面或运行证据】；预期：【有效业务要求】 先区分事实与假设，给出一个可检验原因及支持/推翻它的观察。 验证后再建议最小修复，并列出需复验的相邻行为。 不扩大为整页重做，不编造用户数据或收益百分比。只改能解释问题的部分
用需求是否正确、设计是否可操作、实现是否符合约定、环境是否异常来定位责任环节。返回位置问题若是代码没保存状态就在实现处修；若需求根本没定义返回行为，先回产品定义确认。不要为消除症状不断叠加重试、开关和兜底。
用原失败路径复验，再检查副作用
修复后重复原步骤，检查刷新、前进后退、手机或筛选等相关行为。与原基线比较，记录变好了什么、保留了什么以及没验证什么。没有改善或出现回归时停止叠加改动，回看根因与方案。
改进记录示例 · 结果需执行后填写问题：文章返回列表后位置丢失。 基线：在【版本/环境】按【步骤】复现，证据【位置】。 原因：先记假设，实验支持后再填写结论。 改动：仅调整经验证的状态保存/恢复边界。 功能复验：【原失败步骤与相关回归的实际结果】。 使用效果：是否更容易继续阅读，仍需在【合适观察方式/时机】确认。 下一步：证据足够才继续，或明确维持现状。把结果送回下一轮，而不是无止境打磨
技术复验只能说明对应行为；“用户更满意、效率提高”需要真实使用证据。按最初目标决定继续、维持现状或停止实验。重复出现的需求或流程问题，带着证据回到需求发现/产品定义，更新下次交给 AI 的上下文。
常见误区
- 收到一条模糊反馈就让 AI 重做整套界面。
- 先得到可定位问题，选择影响明确的一项，再评估大改收益。
- 修过代码就宣称用户体验显著提升。
- 把功能验证和使用效果分开，只有实际观察到的结果才报告。
- 同一个原因反复失败，仍继续追加补丁。
- 停止盲改，补一条能区分原因的证据，再决定是否继续原方案。
验收清单
- 问题有真实复现或可靠运行证据，事实与假设区分。
- 根因有实验或代码依据，修复范围和需求对应。
- 原失败路径及受影响回归有结果，未测情况明确。
- 效果观察方式与时机清楚，下一步由证据决定而非持续加功能。
资料与版本
本文为原创方法整理，示例与提示词需按项目调整；不代表真实用户研究或账号执行结果。