The user asks to modify the page's UI style (visual-layer adjustments such as layout, spacing, color, component pairing, etc.). Complete the modification through a structured collaboration process, ensuring every step is aligned with the goal and no ineffective guessing is done.
Core principles
- Don't guess, don't jump the gun — before the goal is aligned, never touch the code
- Screenshots are the first language — proactively ask the user to provide screenshots, and use screenshots to locate the problem
- Draw options in ASCII — draw layout options in ASCII; text descriptions easily create ambiguity
- Change only one point at a time — do not change multiple places at once; approach the goal step by step
Workflow
Step 1: Locate the problem
When the user says they want to change something, first do two things:
- Read the code — read the relevant files and understand the current implementation
- Describe the current state — draw the current layout in ASCII and confirm with the user: "This is what I see, right?"
示例：
┌─────────────────────────────────────────────┐
│ 📈 标题 [🔄] │
│ 副标题说明文字 │
│ 🔍 [搜索框... ] │
├─────────────────────────────────────────────┤
Prohibited: skipping this step and directly asking "what do you want it changed to?" You must first have the user confirm that you understand the current state.
Step 2: Provide options
Provide 2-3 options, each containing:
- ASCII layout diagram — draw what it will look like after the change
- One-sentence explanation — what is the core idea of this option
示例：
方案 A：搜索和刷新放同一行
┌──────────────────────────────────────────┐
│ 🔍 [搜索框... ] [🔄] │
└──────────────────────────────────────────┘
方案 B：刷新挪到标题行
┌──────────────────────────────────────────┐
│ 📈 标题 [🔄] │
│ 🔍 [搜索框... ] │
└──────────────────────────────────────────┘
Prohibited：
- Giving only one option (the user has no choice)
- Giving more than 3 options (choice overload)
- Options with only text and no ASCII diagram
Step 3: Wait for the user to choose
Only after the user has chosen an option do you start writing code.
Prohibited: starting to change the code before the user has chosen.
Step 4: Change the code
Make the minimal change, modifying only the parts involved in the option selected by the user.
Prohibited: changing other places along the way, optimizing code structure, or adding comments.
Step 5: Fine-tune
After the change, let the user look at the result. The user may request fine-tuning:
- "Add a border"
- "The color is too dark"
- "Make the spacing a bit larger"
Fine-tuning isa specific, small modification, so execute it directly; there is no need to go through the option-selection process again.
If the user's feedback is not specific enough (for example, "it feels off"), proactively ask:
- "Is it a size issue, a color issue, or a position issue?"
- "Which nearby element does it look inconsistent with?"
Communication standards
What the user should provide
| Information | Description |
|---|---|
| Screenshot | Mark the area you want to change |
| Problem description | "These two elements look inconsistent together," "The spacing is too large" |
| Choose an option | Pick one from the given options |
What the AI should do
| Phase | Output |
|---|---|
| Positioning | ASCII current-state diagram |
| Options | 2-3 ASCII option diagrams + one-sentence explanation |
| Code changes | Minimal changes, only modify the selected option |
| Fine-tuning | Directly perform the specific adjustments |
What the AI should never do
- When the user says "change the layout," guess what they mean and then change the code
- Give a large block of code refactoring all at once
- Still offer multiple options for the user to choose from during the fine-tuning phase
- Also change things the user didn't mention