把自己当成第一次用这个产品的普通新用户：不懂技术，没看过源码，也不知道开发者的设计意图。
先真的去用，找出让新用户卡住、困惑、不放心的地方。然后切回开发者身份：逐条验证，替我判断值不值得改，给出能直接执行的修改方案。
我只会简单回复（比如「做」「做 1 3」「2 不要」），你根据回复实施修改并验证。所以判断和方案要你来做足，不要把问题抛回给我。
## 一、用 —— 真实用一遍，建议只能来自这里
- 先说清楚产品的入口、目标用户和 1–3 个核心任务。判断依据要来自产品本身（界面、文案、README、文档、默认数据），不要凭空猜。
- 能把产品启动起来，就必须实际打开、点击、输入，从零走完每个核心任务。
- 按真实使用的顺序走：第一次打开 → 完成核心任务 → 查看、修改、保存、导出结果 → 关掉再开 → 用了一段时间以后（数据变多、重复使用）。
- 一路上故意碰一碰这些状态：空状态、加载中、出错、没有结果、输入很长或不合法、中途退出再回来、窗口缩窄或手机屏幕。
- 一边走一边记下每个让你停顿的地方：在哪一步、想做什么、哪里不顺、最后是怎么凑合过去的。
## 二、尽力验证 —— 「未验证」是最后的选择
碰到驱动不了的环节（系统对话框、文件选择器、原生菜单、网络服务、大数据量），先想办法绕过去，再考虑标「未验证」：
- 在调用系统能力的那一层打桩或模拟（比如把目录选择器替换成固定返回某个测试目录），让界面流程照常走完。
- 直接调用同一个后端接口，然后检查实际产物：生成的文件、数据库记录、配置有没有变。
- 用脚本生成真实规模的测试数据（几百到几千条），体验浏览、筛选、扫描的速度和信息量。
- 关掉再开、删除缓存后重开，确认数据和状态有没有保留。
- 如果用了绕过手段，写明绕过了哪一段，以及剩下多少不确定性。
- 只有确实无法绕过的，才标「未验证」，并说明原因和你推荐的验证办法。
## 三、找 —— 让新用户停下来的地方（不限类型）
看不懂、找不到、用不顺、没反馈、不敢用（怕丢数据、怕误操作）、不符合预期、功能缺了、功能多余、细节不舒服。
以上不是检查清单，不要为了每类都凑一条去刻意找。
## 四、验 —— 每条都要先试着推翻
对每条建议，先站在反方，试着证明它不成立：
- 必须写清楚【在哪一步】+【用户期待什么】+【实际看到什么】+【用户因此卡住、绕路、出错或担心什么】。说不清楚的 → 丢掉。
- 必须来自正常、合理的使用流程。要篡改数据、破坏配置、用不支持的方式才会出现的 → 丢掉。
- 「别的产品都有」「以后可能用得上」「这样更好看」「我习惯这样」，一律丢掉。
- 这是普通用户的真实需求，还是少数高级用户、或者你自己的偏好？后者 → 丢掉。
- 现有行为是不是有意设计的？去看代码注释、README、文档、需求说明。有合理理由的，尊重原设计；确有冲突的，写明冲突在哪。
- 同一个原因导致的多条建议合并成一条，不重复计数。
- 只留下推翻不了的。宁可少，不要凑数。
## 五、判 —— 替我下结论
对每条留下来的建议，给出明确结论，不要写「可以考虑」：
- ✅ 建议做：影响真实、方案轻、风险可控。
- 🟡 可选：有价值，但有代价或取舍，写清楚取舍是什么，并说出你倾向哪边、为什么。
- ❌ 不建议：说明理由（收益太小、代价太大、和原设计冲突、只是偏好）。
判断原则：
- 始终提最轻的方案。能改文案就不改交互，能改交互就不加功能。
- 尽量不加弹窗、确认框、设置项、额外步骤。确实要加的，说明它减少了什么困惑或风险，以及为什么更轻的方案不行。
- 不为改善一个场景，去破坏老用户已经习惯的用法。
- 删除或隐藏功能、改变现有行为这类改动，最高只能判 🟡，除非证据非常充分。
- 优先级：高 = 完成不了核心任务、会丢数据、误操作后果严重；中 = 会让人困惑、反复尝试、走弯路；低 = 不耽误完成任务，但改进明确、能复现。
## 六、出方案 —— 写到我说「做」你就能直接动手
每条 ✅ 和 🟡 都要附上具体方案：
- 改哪里：页面或组件，以及对应文件（file:line）。
- 改成什么样：具体文案原文对照（旧 → 新）、交互怎么变、在什么条件下出现或消失、默认值改成什么。
- 不改什么：明确说出会保持不变的相关行为。
- 怎么验证：改完重新走哪条流程，看到什么结果才算成功，还要回归哪些正常流程。
- 规模：小（几行）/ 中（一个组件）/ 大（跨模块）。大改动拆成可以单独做的几步。
## 七、输出
1. 入口、目标用户、核心任务（几行就够）。
2. 走查记录：按使用顺序写，每步标【已验证 / 绕过验证 / 未验证】。
3. 建议清单，按「结论 → 优先级 → 收益 ÷ 代价」排序，编号 S1、S2……，每条格式为：
S编号 · 结论（✅/🟡/❌）· 优先级 · 类型 · 位置 · 期待 vs 实际 · 对用户的影响 · 方案（按第六节）· 置信度
❌ 的条目只写一行：问题 + 不做的理由。
4. 未验证事项：原因，以及推荐的验证办法。
5. 一句话结论：最先该做的是哪一条、为什么。
6. 回复菜单，放在最后，原样列出：
- 「做」= 实施全部 ✅
- 「做 S1 S3」= 只做这几条（也可以包含 🟡）
- 「全做」= ✅ 和 🟡 都做（🟡 按你推荐的那一边实施）
- 「S2 不要」/「S2 改成……」= 调整某一条
- 其他问题直接说。
## 八、收到我的回复以后
- 按回复实施修改，严格按方案的范围来，不顺手改别的。实施中发现方案行不通，先说明原因，换成最接近的方案，不要硬改。
- 每条改完，按方案里的验证步骤重新走一遍原流程，并回归相关的正常流程。项目里有测试就跑测试。
- 汇报：每条「已完成 / 部分完成 / 未完成」+ 实际改动（文件、文案原文对照）+ 验证结果。
- 然后以新用户身份重新走一遍核心任务，专门检查这次的改动有没有带来新的困惑、多余步骤或行为不一致。有新发现，就按第四到第六节出一份新清单，附上同样的回复菜单；没有，就明确写「本轮没有新的值得改的问题」。
- 连续 2 轮没有新的、经过验证且值得改的问题，就停下。不要为了凑数无限挑剔。
现在开始。
