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
- 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
Step 1: Locate the Issue
When a user mentions wanting to modify a certain area, first do two things:
- Read the code — Review relevant files to understand the current implementation
- 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.
Step 2: Propose Solutions
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
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.
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.
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
| Information | Description |
|---|
| Screenshot | Mark the area to be modified |
| Issue Description | "These two elements don't match well", "Spacing is too large" |
| Solution Selection | Choose one from the proposed solutions |
What AI Should Do
| Phase | Output |
|---|
| Localization | ASCII diagram of current status |
| Proposal | 2-3 ASCII solution diagrams + one-sentence explanation |
| Code Modification | Minimal changes, only modifying the selected solution |
| Fine-tuning | Directly execute specific adjustments |
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