Appearance
用 Codex 根据截图实现并迭代界面
嘿，我是小枫。今天聊一个我几乎每周都会干的活——把一张界面截图丢给 AI，让它帮我写出一个真实可跑的页面。
听起来挺简单的对吧？我也曾经这么想。直接把图拖进去，说一句"帮我实现这个页面"，然后等着收工。结果呢，出来的东西桌面看着还凑合，一切到手机尺寸就崩得稀里哗啦；或者页面长得挺像，但里面全是绝对定位和硬编码数值，后面想改一行间距都得动全身。吃了几次亏之后我才慢慢摸清门道：截图能告诉你的只有某一时刻的像素，组件结构、响应式规则、交互状态、数据边界这些关键信息，它统统不会主动告诉你。
所以这篇文章，我把自己踩过的坑和摸索出来的七步流程整理出来——从准备输入到最终验收，每一步都讲清楚怎么做、为什么做。
开始前：四样东西先备好
以前我经常随手丢张图就开始，后来发现这是给自己挖坑。现在我的习惯是，动手之前先确认四类输入：
- 参考图：尽量保持原始分辨率，明确告诉 AI 哪些区域必须贴近、哪些可以灵活发挥。
- 目标位置：告诉它现有路由结构、组件目录和入口文件在哪，不然它可能把新页面塞到奇怪的地方。
- 实现约束：框架是啥、样式方案是啥、有没有在用组件库、需要支持哪些浏览器。
- 截图看不到的行为：移动端怎么展示、hover 什么效果、loading 长什么样、空状态和错误状态怎么处理、键盘操作支不支持。
还有个小提醒：如果参考图来自第三方产品，把它当布局和交互的灵感来源就好，不要照搬人家的商标、素材和品牌元素，那是给自己埋雷。
第一步：让 Codex 先逛一圈你的项目
我最开始用 AI 写界面的时候，跳过这一步直接让它"照图实现"，结果它给我生成了另一套按钮、另一套卡片、另一套断点——跟项目现有的东西格格不入，后来删掉重写的比留下的还多。
现在我的做法是，先让 Codex 研究项目本身的风格：
text
先不要实现。阅读当前项目中最接近的页面、布局组件、颜色/间距 token、表单和响应式写法。
输出：
- 应复用的组件和样式变量；
- 新页面建议放置的路由与文件；
- 参考截图中可识别的布局区域；
- 截图没有表达、需要我确认的交互和移动端问题。这一步花几分钟，但能省掉后面几个小时的返工。你总不希望项目里出现第三套按钮系统。
第二步：把截图翻译成可执行规格
截图本身不是规格，它只是一张像素快照。你需要帮 AI 把视觉信息翻译成它能理解的结构化描述。
我常用的 prompt 模板大概是这样的：
text
根据附件实现 /analytics 页面。
视觉重点：
- 顶部标题与筛选区保持单行，宽屏时右对齐；
- 主指标区使用 4 列，不要把所有内容都做成独立浮层卡片；
- 图表区域比侧栏更突出；
- 使用项目现有字体、颜色和圆角，不复制截图品牌。
响应式：
- >= 1200px：4 列指标 + 主图表/侧栏；
- 768-1199px：2 列指标，侧栏移到图表下；
- < 768px：单列，筛选控件可换行，触控目标至少容易点击。
交互：
- 筛选时显示 loading；
- 无数据时显示解释和重置入口；
- 请求失败时保留筛选条件并允许重试；
- 键盘可以操作筛选和按钮。
先实现页面骨架和静态数据，不接真实 API。只修改该路由及必要共享组件。你注意到了没，我刻意把"先做骨架和静态数据"写进去了。这个习惯救过我很多次——后面会细说。
第三步：骨架先行，细节靠后
有一次我让 AI 同时搞定像素、接口、动画和所有状态，结果每一块都差一点，而且互相影响，根本看不出问题出在哪一层的。
后来我给自己定了一个固定顺序，每次只推进一步：
- 页面区域与信息层级——先把东西放在对的位置；
- 栅格和响应式——确保不同宽度下布局合理；
- 复用组件和真实数据形状——把占位换成真家伙；
- 字体、间距和颜色——这时候才追求视觉还原；
- 交互状态——loading、空数据、错误、hover 逐个来；
- 动画和装饰——锦上添花放最后。
按这个顺序来，每一步出问题都很好定位。你试试就知道。
第四步：开浏览器，真实验证
截图是死的，浏览器是活的。写完了一定要在真实页面上看一眼。
先启动开发服务器：
bash
npm run dev然后让 Codex 用浏览器工具打开实际路由：
text
打开本地页面并验证 /analytics。先检查控制台和网络错误，再按桌面、平板、手机三个尺寸检查布局。对照参考图列出最明显的五个差异，然后只修优先级最高的两项。如果当前环境没有浏览器工具，让 Codex 直接告诉你 URL 和检查步骤，你手动打开页面，截图反馈给它。效果一样的，就是多了一步手工操作。
我自己最常在这个阶段发现的问题：移动端某个按钮跑到屏幕外面去了、表格在窄屏下横向溢出、或者 hover 效果跟项目其他页面完全不一致。这些问题对着代码看很难察觉，浏览器里一眼就暴露。
第五步：小步迭代，别一口吃成胖子
这是一个我反复掉进去的坑：觉得某个区域"不够好"，然后发一句"再高级一点"。AI 可能把整个页面重新设计一遍，之前好不容易调好的布局全白费了。
现在我会这样写迭代指令：
text
保持现有布局，只调整顶部区域：
- 标题和筛选之间增加呼吸感；
- 筛选按钮高度与输入框一致；
- 手机宽度下按钮占满可用宽度；
- 不改图表和侧栏。每轮只动一个区域，改完看一眼效果再继续。这样做有个巨大的好处：万一哪里不对了，你立刻知道是刚才那一步改坏的，回退也简单。
第六步：状态和可访问性，别等到最后才补
页面看着好看只是第一步。用户真正用起来的时候，会触发各种你没想到的状态。我踩过的典型坑：某个列表在数据为空的时候直接白屏、loading 永远不消失、键盘完全无法操作下拉菜单。
我现在至少会检查这些：
- 初始、loading、空数据、部分数据、错误和成功——每种状态都触发一遍；
- 文本变长会怎样、数字变大溢出吗、窄屏下还正常吗；
- 键盘焦点是否看得见；
- 表单是否有标签，图标按钮是否有可读名称；
- 颜色是唯一的状态提示吗（色盲用户怎么办）；
- 图片有没有合适的替代文本；
- 动画是否尊重用户的减少动态效果偏好；
- 触控目标是否够大、间距是否够宽松。
让 AI 做一轮专项审查效率很高：
text
对这个页面做一次状态和可访问性审查。先报告会阻止使用的问题，再做最小修复。不要为了满足检查器大规模重写结构。注意后半句，"最小修复"是关键。我见过 AI 为了过无障碍检查把整个 DOM 结构重写了一遍，结果功能全坏了。
第七步：接上真实数据
静态数据确认没问题之后，才该接 API。这个顺序很重要——先确保结构和交互是对的，再接数据，不然你很难判断问题是出在 UI 层还是数据层。
接 API 时我要求 AI 至少考虑这些：
- 请求取消和重复请求处理——用户快速切换筛选时别炸；
- 服务端返回错误或字段缺失——给个可理解的提示；
- 权限拒绝——别让用户对着一个莫名其妙的报错发呆；
- 旧数据兼容——后端字段改了名，前端别直接崩；
- loading 不能闪一下就消失，也不能永久卡住；
- 数据格式化和时区规则要明确。
另外有一个容易被忽略的点：不要用假数据里那些"刚刚好"的字符串长度去判断真实布局。真实数据可能长得出乎意料。
验收矩阵
做完以上步骤，我一般对着这个表逐项过一遍：
| 项目 | 检查方式 |
|---|---|
| 视觉层级 | 首屏 5 秒内能识别标题、主要指标和主操作 |
| 桌面布局 | 常用宽屏无溢出、遮挡和异常空白 |
| 移动布局 | 单列顺序合理，控件可点击，文本不截断 |
| 状态 | loading、空、错、成功均可触发 |
| 控制台 | 没有新增错误和关键警告 |
| 网络 | 没有重复请求、失败死循环和错误接口 |
| 可访问性 | 键盘可完成主要流程，焦点清楚 |
| 工程验证 | 类型检查、测试和构建通过 |
那些年我踩过的经典坑
这几个失败模式我几乎全都亲身经历过，写出来帮你绕开：
页面长得像，但代码没法维护
典型症状：满屏绝对定位和硬编码像素值。看着挺还原，但改一行间距要调十几个地方。解法很简单：回到项目的布局系统和 token，让 AI 用项目已有的方式写。
桌面看着好，手机全崩了
截图只给了一个尺寸，AI 不知道其他尺寸下该怎么排列。响应式规则必须在文字规格里明确写出来，而且要在真实设备或浏览器里验证。
视觉优化把业务逻辑搞丢了
我有一次让 AI "优化一下表单样式"，它直接把一个必填字段给删了，因为"视觉上更简洁"。从那以后，我每次都明确要求保留现有表单字段、错误码和交互语义，视觉和数据分阶段做。
为了等素材把实现卡住了
别因为缺一张品牌图或人物照片就让整个页面搁置。先用明确的占位资源或项目现有资产顶上，功能跑通了再替换。品牌 Logo、人物和商品图要确保你有权使用。
下一步
界面搞定之后，下一步自然就是代码审查、Git 与 PR 闭环。如果是大型 UI 架构调整，建议先看看可回退的重构与迁移，别一上来就硬改。