Back to Details

ui-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
用户要求修改页面的 UI 样式（布局、间距、颜色、组件搭配等视觉层面的调整）。通过结构化的协作流程完成修改，确保每一步都对齐目标，不做无效猜测。
When users request UI style modifications for pages (visual adjustments such as layout, spacing, color, component matching, etc.), complete the changes through a structured collaboration process to ensure each step aligns with the goal and avoid invalid guesses.

核心原则

Core Principles

  • 不猜，不抢跑 — 没有对齐目标之前，绝不动代码
  • 截图是第一语言 — 主动要求用户提供截图，用截图定位问题
  • ASCII 画方案 — 布局方案用 ASCII 画出来，文字描述容易产生歧义
  • 每次只改一个点 — 不要一次改多个地方，逐步逼近目标
  • No guessing, no premature action — Never modify code before aligning on the goal
  • Screenshots are the primary language — Proactively ask users for screenshots to locate issues
  • ASCII diagram for proposals — Use ASCII diagrams to illustrate layout proposals, as textual descriptions are prone to ambiguity
  • Modify only one point at a time — Don't change multiple areas at once; approach the goal step by step

工作流程

Workflow

第 1 步：定位问题

Step 1: Locate the Issue

用户说想改某个地方时，先做两件事：
  1. 读代码 — 读取相关文件，理解当前实现
  2. 描述现状 — 用 ASCII 画出当前布局，向用户确认："我看到的是这样，对吗？"
示例：
┌─────────────────────────────────────────────┐
│ 📈 标题                                [🔄] │
│ 副标题说明文字                               │
│ 🔍 [搜索框...                             ] │
├─────────────────────────────────────────────┤
禁止：跳过这一步直接问"你想改成什么样"。必须先让用户确认你理解了现状。
When a user mentions wanting to modify a certain area, first do two things:
  1. Read the code — Review relevant files to understand the current implementation
  2. Describe the current status — Draw the current layout using ASCII and confirm with the user: "This is what I see, is that correct?"
示例：
┌─────────────────────────────────────────────┐
│ 📈 标题                                [🔄] │
│ 副标题说明文字                               │
│ 🔍 [搜索框...                             ] │
├─────────────────────────────────────────────┤
Prohibited: Skip this step and directly ask "What do you want to change it to?" You must first have the user confirm your understanding of the current status.

第 2 步：给出方案

Step 2: Propose Solutions

提供 2-3 个方案，每个方案包含：
  • ASCII 布局图 — 画出改完的样子
  • 一句话说明 — 这个方案的核心思路是什么
示例：
方案 A：搜索和刷新放同一行
┌──────────────────────────────────────────┐
│ 🔍 [搜索框...                ]    [🔄]  │
└──────────────────────────────────────────┘

方案 B：刷新挪到标题行
┌──────────────────────────────────────────┐
│ 📈 标题                           [🔄]  │
│ 🔍 [搜索框...                         ] │
└──────────────────────────────────────────┘
禁止：
  • 只给一个方案（用户没有选择余地）
  • 给超过 3 个方案（选择困难）
  • 方案只有文字没有 ASCII 图
Provide 2-3 solutions, each including:
  • ASCII layout diagram — Illustrate the modified appearance
  • One-sentence explanation — What is the core idea of this solution
示例：
方案 A：搜索和刷新放同一行
┌──────────────────────────────────────────┐
│ 🔍 [搜索框...                ]    [🔄]  │
└──────────────────────────────────────────┘

方案 B：刷新挪到标题行
┌──────────────────────────────────────────┐
│ 📈 标题                           [🔄]  │
│ 🔍 [搜索框...                         ] │
└──────────────────────────────────────────┘
Prohibited:
  • Providing only one solution (users have no choice)
  • Providing more than 3 solutions (decision paralysis)
  • Solutions with only text and no ASCII diagrams

第 3 步：等用户选择

Step 3: Wait for User Selection

用户选完方案后，才开始写代码。
禁止：用户还没选就开始改代码。
Start writing code only after the user has selected a solution.
Prohibited: Modifying code before the user makes a selection.

第 4 步：改代码

Step 4: Modify Code

执行最小改动，只改用户选定方案涉及的部分。
禁止：顺手改其他地方、优化代码结构、加注释。
Implement minimal changes, modifying only the parts related to the user's selected solution.
Prohibited: Incidentally modifying unmentioned areas, optimizing code structure, or adding comments.

第 5 步：微调

Step 5: Fine-tuning

改完后让用户看效果。用户可能会提出微调：
  • "加个边框"
  • "颜色太深"
  • "间距再大一点"
微调是具体的、小的修改，直接执行，不需要再走方案选择流程。
如果用户的反馈不够具体（比如"感觉不对"），主动追问：
  • "是大小的问题、颜色的问题、还是位置的问题？"
  • "和旁边哪个元素搭配起来不协调？"
After modification, let the user review the result. The user may request fine-tuning such as:
  • "Add a border"
  • "Color is too dark"
  • "Increase the spacing a bit"
Fine-tuning refers to specific, minor changes; execute them directly without going through the option selection process again.
If the user's feedback is not specific (e.g., "It doesn't feel right"), proactively ask:
  • "Is it a size issue, color issue, or position issue?"
  • "Which adjacent element is it clashing with?"

沟通规范

Communication Guidelines

用户应该提供的

Information Users Should Provide

信息说明
截图标注出想改的区域
问题描述"这两个元素搭配不协调"、"间距太大"
选择方案从给出的方案中选一个
InformationDescription
ScreenshotMark the area to be modified
Issue Description"These two elements don't match well", "Spacing is too large"
Solution SelectionChoose one from the proposed solutions

AI 应该做的

What AI Should Do

阶段输出
定位ASCII 现状图
方案2-3 个 ASCII 方案图 + 一句话说明
改码最小改动，只改选定方案
微调直接执行具体调整
PhaseOutput
LocalizationASCII diagram of current status
Proposal2-3 ASCII solution diagrams + one-sentence explanation
Code ModificationMinimal changes, only modifying the selected solution
Fine-tuningDirectly execute specific adjustments

AI 绝不应该做的

What AI Should Never Do

  • 用户说"改布局"就直接猜想法然后改代码
  • 一次给出大段代码重构
  • 微调阶段还在给多个方案让用户选
  • 顺手改用户没提到的地方
  • Directly guessing and modifying code when a user says "adjust the layout"
  • Providing large-scale code refactoring at once
  • Providing multiple solutions for the user to choose during fine-tuning
  • Incidentally modifying areas the user didn't mention