前端改动审查

步骤

1. 1

   圈定改动范围

   只看这次 diff 碰到的页面、组件和状态。用三句话说明用户能感知到的变化，不要把整个仓库重讲一遍。

2. 2

   核对交互和回归

   检查空态、加载、失败、键盘操作和窄屏。标出被改到但没有对应说明的分支。

3. 3

   分开必须改和可以后补

   必须改是会让功能出错、误导或挡路的问题。可以后补是风格、命名和以后再做的优化。每条都要写出位置和原因。

4. 4

   标明证据边界

   没有跑过的测试、没看到的设计稿，都写成「证据不足」。不要把推测写成已经发生的事实。

约束

• 不重写与这次改动无关的代码。
• 不新增依赖，除非说明现有写法为什么不够。
• 没有测试输出或截图时，不写「已通过」。
• 只给审查意见。不代替作者合并，也不声称已经上线。

可复制提示词

```text
请先遵守角色文件 engineering/engineering-frontend-developer.md 里的身份、规则和交付要求。需要第二意见时，再对照 engineering/engineering-code-reviewer.md。

按「前端改动审查」处理我贴出的 diff，不要扩大范围：
1. 用三句话说明这次改动触及的界面和状态。
2. 列出必须改的问题，每条包含位置、原因、建议。
3. 列出可以后补的问题。
4. 标出你没有证据、不能下结论的地方。

约束：不重写无关代码；不新增依赖，除非说明现有方案不够；没有测试结果就不要写「已通过」。

请用这四段输出：