用户要求修改页面的 UI 样式（布局、间距、颜色、组件搭配等视觉层面的调整）。通过结构化的协作流程完成修改，确保每一步都对齐目标，不做无效猜测。

核心原则

• 不猜，不抢跑 — 没有对齐目标之前，绝不动代码
• 截图是第一语言 — 主动要求用户提供截图，用截图定位问题
• ASCII 画方案 — 布局方案用 ASCII 画出来，文字描述容易产生歧义
• 每次只改一个点 — 不要一次改多个地方，逐步逼近目标

工作流程

第 1 步：定位问题

用户说想改某个地方时，先做两件事：

1. 读代码 — 读取相关文件，理解当前实现
2. 描述现状 — 用 ASCII 画出当前布局，向用户确认："我看到的是这样，对吗？"

示例：
┌─────────────────────────────────────────────┐
│ 📈 标题                                [🔄] │
│ 副标题说明文字                               │
│ 🔍 [搜索框...                             ] │
├─────────────────────────────────────────────┤

禁止：跳过这一步直接问"你想改成什么样"。必须先让用户确认你理解了现状。

第 2 步：给出方案

提供 2-3 个方案，每个方案包含：

• ASCII 布局图 — 画出改完的样子
• 一句话说明 — 这个方案的核心思路是什么

示例：
方案 A：搜索和刷新放同一行
┌──────────────────────────────────────────┐
│ 🔍 [搜索框...                ]    [🔄]  │
└──────────────────────────────────────────┘

方案 B：刷新挪到标题行
┌──────────────────────────────────────────┐
│ 📈 标题                           [🔄]  │
│ 🔍 [搜索框...                         ] │
└──────────────────────────────────────────┘

禁止：

• 只给一个方案（用户没有选择余地）
• 给超过 3 个方案（选择困难）
• 方案只有文字没有 ASCII 图

第 3 步：等用户选择

用户选完方案后，才开始写代码。

禁止：用户还没选就开始改代码。

第 4 步：改代码

执行最小改动，只改用户选定方案涉及的部分。

禁止：顺手改其他地方、优化代码结构、加注释。

第 5 步：微调

改完后让用户看效果。用户可能会提出微调：

• "加个边框"
• "颜色太深"
• "间距再大一点"

微调是具体的、小的修改，直接执行，不需要再走方案选择流程。

如果用户的反馈不够具体（比如"感觉不对"），主动追问：

• "是大小的问题、颜色的问题、还是位置的问题？"
• "和旁边哪个元素搭配起来不协调？"

沟通规范

用户应该提供的

AI 应该做的

AI 绝不应该做的

• 用户说"改布局"就直接猜想法然后改代码
• 一次给出大段代码重构
• 微调阶段还在给多个方案让用户选
• 顺手改用户没提到的地方