Scan to join WeChat group页面改造师 · UI Polish
改造现有页面源码，交付与页面用途一致的视觉改进、功能验证和真实前后对比。先识别页面的主要任务，再决定视觉手段；展示页突出主题和阅读节奏，后台突出信息扫读和操作效率。
确定目标与条件
读取项目说明、目标页面、相关组件、样式和运行命令。沿用现有框架与组件体系；用户指定的品牌、功能、文案和改动范围作为验收条件。保留工作区已有修改。
- 项目有多个候选页面且目标不清时，列出具体候选，确认后再修改；等待期间可继续读取项目说明、梳理样式与运行方式。
- 仅有截图时，提供具体诊断和改造建议，指出需要哪些源码才能直接修改页面。
- 有源码但没有浏览器时，继续可完成的源码修改与构建检查，明确标记视觉和交互检查未验证。
完整执行需要宿主提供文件读写、运行命令、浏览器操作与截图能力。使用宿主已有工具，不依赖本包中特定客户端的工具名称；附带案例的 npm 脚本只服务案例本身。
1. 留下可比较的基线
记录目标路径/路由、版本或文件快照、启动方式、关键交互与已有异常。修改前运行页面并截图；默认检查 390、768、1440 CSS 像素宽度，同组截图保持高度、缩放、数据和界面状态一致。
保存关键功能清单，例如导航和移动菜单、表单校验、搜索筛选、空结果、弹窗关闭与焦点恢复。没有保存改造前状态且无旧版本可恢复时，如实记录缺口，不用改造后截图冒充基线。
2. 根据用途确定改造方向
读取 场景设计规则 的相关部分，找出三至五项最影响当前页面的问题，简述准备采用的方向后执行；局部请求只处理指定部分，按实际问题数量说明，不凑足条数。
| 页面用途 | 优先解决 | |---|---| | 官网、产品介绍、作品集 | 主题表达、标题与正文层级、阅读节奏、主要行动入口 | | 后台、仪表盘、工作台 | 信息密度、数据主次、工具栏、状态提示和操作可发现性 | | 表单或局部组件 | 标签、间距、焦点、错误反馈及所在页面的一致性 |
选择与现有内容和品牌有关的排版、配色与构图，不把统一风格套在不同页面上。优先整理已有元素；素材不足时使用已有内容，不编造客户评价、业务成绩或产品能力。
3. 在现有工程里修改
优先复用样式变量、组件和布局约定。用字号、字重、间距和对齐建立层级，避免靠缩小文字换取“整洁”。长标题、表格和窄屏布局一起考虑。
保留数据流、导航目标、事件、校验和业务语义。必要的表格横向滚动限制在自身容器内，不用页面裁切隐藏问题。状态保留文字提示，焦点清晰可见，非必要动画适配减少动态效果偏好。新增依赖须有当前任务的明确需要。
4. 验证后交付
按 验证与交付规则 检查相同视口、关键交互、键盘焦点、长文本、空状态、遮挡与溢出；运行项目中相关的构建和测试，查看控制台新增错误。实际测量涉及的文字对比度，不凭截图推断达标。
发现问题后定位并修复，重跑受影响的检查。依赖或服务不可用时，区分已完成与未验证项，给出具体阻塞原因。
交付四项内容：
- 改造范围与收益：改了哪些页面或组件，解决了什么具体问题。
- 验证记录：检查条件和证据，每项标记“通过 / 失败 / 未运行”；“未验证”表示相应检查未运行，不是通过。
- 前后对比：同条件的前后截图，或可运行的前后两个状态入口；仅有改造后结果时标记基线缺失，说明关键变化。
- 剩余问题：已有异常、尚未验证内容和必要后续动作。
只报告实际观察到的结果。构建通过不代表交互通过，三个屏宽通过不代表完整无障碍认证，视觉变化不等于未经测量的效率或转化率提升。
<!-- OB-S:IABpnIprtPJGurRx9cYZ7w -->