把自己当成第一次用这个产品的普通新用户：不懂技术，没看过源码，也不知道开发者的设计意图。
这次不是审代码，而是真的去用，找出让人困惑、受阻、不踏实的地方，并修好值得修的。
## 用 —— 真实操作，不靠想象
先找出产品的主要入口和 1–3 个核心任务（普通用户最常用来完成的事），然后从零开始走完每个任务：
- 能把产品启动起来，就必须实际打开、点击、输入，不要只看代码或截图。
- 实在启动不了，就顺着代码和组件行为推导，每条结论都标【已验证】或【推测】。
- 按真实使用的顺序走：第一次打开 → 完成核心任务 → 查看、修改、保存、导出结果 → 第二次再用。
- 一路上故意碰一碰这些状态：空状态、加载中、出错、没有结果、断网或超时、输入很长或不合法、中途退出再回来、手机窄屏。
## 找 —— 只找会真实卡住用户的地方
- 看不懂：不知道这是干什么的，术语、文案或选项说不清楚。
- 找不到：不知道从哪里开始、下一步做什么，做完了也不知道结果在哪。
- 用不顺：步骤多、要重复操作、默认值不合理、操作顺序反直觉。
- 没反馈：点了不知道有没有生效，等待时不知道在干什么，失败了也不告诉人怎么办。
- 不敢用：不清楚操作后果，容易误删或覆盖，不知道有没有保存，担心数据丢失。
- 不符合预期：功能名字和实际行为对不上，同类操作在不同地方结果不一样。
## 验 —— 每个发现都要先试着推翻
对每个疑似问题，先站在反方，试着证明它不成立：
- 必须写清楚【具体操作步骤】+【用户原本期待什么】+【实际看到什么】+【用户因此卡住、绕路、出错或担心什么】。说不清楚的 → 丢掉。
- 必须能通过正常、合理的使用流程碰到。要篡改数据、破坏配置或用不支持的方式才会出现的 → 丢掉。
- 只是审美偏好、风格差异、理论上的不方便，或者用户已经有很顺手的办法 → 丢掉。
- 同一个原因导致的多处问题合并成一条，不重复计数。
- 只留下推翻不了的。宁可漏掉，也不要凑数。
优先级：
- 高：完成不了核心任务、会丢数据、误操作后果严重。
- 中：会让人困惑、反复尝试，或要别人帮忙才能完成。
- 低：不耽误完成任务，但改进效果明确、能复现。
## 改 —— 只修确认过的问题
- 修改要最小、对症。先改文案、反馈、默认值、入口位置，最后才考虑加东西。
- 不要擅自加功能、步骤、弹窗、确认框或设置。每多一个交互，都要能说清楚它减少了什么困惑或风险。
- 沿用现有的设计风格、交互方式和项目结构，多个页面之间行为保持一致。
- 改完把原来的复现步骤重新走一遍，再走一遍相关的正常流程，确认体验确实变好了，而且没有破坏别人已经习惯的用法。
## 迭代到收敛
一轮按「用 → 找 → 验 → 改 → 回归测试」做完，再开下一轮，去找已确认问题之外的新问题，尤其要回头检查这轮的改动有没有带来新的困惑、多余步骤、行为不一致或误操作风险。
连续 2 轮没有新的、经过验证且值得修的问题，就停下。不要追求「挑不出任何毛病」，一直挑剔下去永远收不了尾。
## 输出
每个确认问题一行：
位置（页面/步骤，必要时附 file:line）· 操作步骤 · 期待 vs 实际 · 用户受到的影响 · 优先级 · 证据【已验证/推测】 · 修复（实际改了什么，或标注「仅建议」）
每轮结尾：本轮新确认 N、推翻丢弃 M、实际修复 X、回归测试结果、累计确认 Y。
最后用几行总结：最影响新用户的 3 个问题、已经完成的修改、还没解决的问题，以及哪些地方没能实际验证。
现在开始：先说清楚产品的入口和核心任务，然后以新用户身份动手去用。能确认又适合直接修的问题，修完并验证，不要停在提建议的阶段。
