最近在做一个 Flutter  xxx App，需要把已经完成的夜间模式逐步适配成白天模式。

一开始我以为这件事很简单：把页面截图和一句“改成白天模式”发给 Codex，让它修改颜色就行。

但真正执行后发现，UI 改造最容易出现的问题并不是颜色，而是：

• Codex 自己重新设计页面；

• 原有文字、图标和按钮位置被改变；

• 白天模式和夜间模式的组件大小不一致；

• 页面出现 RIGHT OVERFLOWED；

• 只改了空状态，没有改使用中状态；

• 白天模式改好了，却把夜间模式一起改坏；

• GPT 生成的效果图很好看，但 Flutter 落地后完全不是同一个效果。

经过多轮尝试，我逐渐整理出一套更稳定的流程：

先用旧截图固定页面结构，再用 GPT 生成白天模式样例图，之后由 GPT 根据旧图和新图生成 Codex 提示词，Codex 完成第一版代码修改，最后根据真机截图逐项小修。

---

一、为什么不能直接让 Codex 改 UI

Codex 更擅长根据代码和文字要求完成开发任务，但它并不知道我们脑子里的最终视觉效果。

例如，只发送一句：

把这个页面改成白天模式，使用浅蓝灰背景和白色卡片。

Codex 可能会理解成：

• 重新设计整个页面；

• 改变原有组件层级；

• 把横向语言选择改成纵向布局；

• 把按钮变大；

• 改变卡片顺序；

• 新增一些它认为合理的模块。

从代码角度看，它可能完成了“白天模式”。

但从产品和视觉角度看，结果已经不是原来的页面了。

因此，不能只告诉 Codex“要改成什么风格”，还必须告诉它：

• 哪些东西可以改；

• 哪些东西绝对不能改；

• 哪张图决定布局；

• 哪张图决定颜色；

• 哪些业务逻辑必须保留；

• 哪些状态都需要适配。

---

二、第一步：准备已经定好的旧版对照图

UI 改造前，先准备一张或多张当前已经定好的页面截图。

在我的项目中，旧版通常是已经确认的夜间模式截图。

旧版截图主要用来确定：

• 页面结构；

• 组件层级；

• 文字位置；

• 图标位置；

• 按钮大小；

• 卡片宽高；

• 卡片之间的间距；

• 页面上下留白；

• 空状态和使用中状态的区别。

例如，一个语音翻译笔记页面可能至少需要两张旧图：

1. 刚进入页面时的空状态；

2. 已经生成笔记后的使用中状态。

如果只给一张空状态截图，Codex 很可能只修改空状态，而遗漏有内容时的页面。

---

三、截图和代码冲突时，以哪个为准

这是这次修改过程中非常重要的一点。

项目中经常存在这种情况：

• 夜间模式是同事继续维护的；

• 自己本地分支中的夜间模式代码已经落后；

• 最新截图来自其他同事修改后的版本；

• 当前仓库里的旧代码和最新页面已经不一致。

这时候不能让 Codex 直接参考本地旧版夜间模式代码。

否则它会按照过时的组件尺寸、布局和间距去做白天模式。

提示词中必须明确写：

只参考我提供的夜间模式截图确定页面结构、组件大小和位置。

不要参考仓库中旧的 dark mode 代码布局，因为当前代码中的夜间模式已经落后。

这句话非常重要。

简单来说：

最新截图负责告诉 Codex“现在页面应该长什么样”，代码只负责告诉 Codex“功能逻辑在哪里”。

---

四、第二步：使用 GPT 生成白天模式样例图

准备好旧截图后，先不要直接让 Codex 修改代码。

应该先把旧截图交给 GPT，让 GPT 生成对应的白天模式效果图。

这个阶段的目的不是生成最终代码，而是先确认视觉方向。

我的白天模式风格最终确定为：

浅蓝灰智能硬件风、白色玻璃卡片、低饱和蓝色点缀、柔和阴影、深蓝黑主文字、灰蓝色辅助文字。

具体特点包括：

• 背景使用非常淡的浅蓝灰到白色渐变；

• 卡片使用白色或半透明白色；

• 大圆角；

• 极淡描边；

• 柔和阴影；

• 蓝色只用在按钮、图标和选中状态；

• 不使用大面积高饱和科技蓝；

• 不使用青绿色霓虹效果；

• 整体保持干净、轻盈、安静。

生成样例图时，需要强调：

夜间模式截图决定页面结构、组件大小和位置。

白天模式只改变背景、颜色、卡片质感、圆角、描边和阴影。

不要改变文字位置，不要放大按钮，不要重新排列页面。

否则 GPT 也会自由发挥，把白天模式生成成一套新的页面结构。

---

五、第三步：同时保留旧图和新图

样例图确认后，不是只把白天模式图发给 Codex。

正确方式是同时准备：

• 夜间模式旧图；

• 白天模式新图。

这两组图承担不同作用。

参考内容	使用的图片
页面结构	夜间模式截图
组件层级	夜间模式截图
文字位置	夜间模式截图
图标位置	夜间模式截图
按钮大小	夜间模式截图
卡片间距	夜间模式截图
背景颜色	白天模式样例图
卡片质感	白天模式样例图
阴影和描边	白天模式样例图
整体视觉氛围	白天模式样例图

可以概括成一句话：

夜间模式决定布局，白天模式样例图决定视觉。

这是整个流程中最核心的原则。

---

六、第四步：让 GPT 生成 Codex 提示词

准备好旧图和新图后，再让 GPT 根据两组图片生成 Codex 提示词。

一份完整的 Codex UI 提示词，至少要包含以下内容。

---

1. 明确参考优先级

夜间模式截图是页面结构、组件大小、文字位置和按钮位置的第一参考。

白天模式样例图只负责颜色、背景、卡片质感、圆角、阴影和视觉氛围。

不要照白天样例图自由重排页面。

---

2. 明确只改 Light Mode

本次只修改 light mode。

dark mode 已经定好，不能破坏，不能修改原有夜间模式效果。

最好要求 Codex 使用：

Theme.of(context).brightness

或者项目中已有的主题判断方式，分别处理 light 和 dark。

---

3. 明确哪些内容不允许修改

UI 改造提示词中，“不能改什么”往往比“要改成什么”更重要。

必须明确禁止：

• 不要重写整个页面；

• 不要改业务逻辑；

• 不要改路由；

• 不要改接口；

• 不要改状态管理；

• 不要改语言选择逻辑；

• 不要改录音逻辑；

• 不要改历史记录逻辑；

• 不要改固定文案；

• 不要移动固定图标；

• 不要改变按钮功能；

• 不要改变模块顺序；

• 不要删除原有 Widget；

• 不要破坏夜间模式。

---

4. 分别描述不同页面状态

有多个状态的页面，必须逐个描述。

例如翻译机模式：

状态 A：刚进入页面，没有翻译内容。

状态 B：已经完成翻译，页面中出现多条翻译卡片。

例如语音翻译笔记：

状态 A：空状态，显示介绍卡片。

状态 B：有内容状态，显示标题摘要、completed 状态、时间、原文、译文和展开按钮。

例如同声传译：

页面一：实时同声传译页面。

页面二：同声传译历史记录页面。

否则 Codex 可能只修改当前截图中显示的一个状态。

---

5. 写清楚动态组件不能被删除

有些页面中存在动态效果，例如：

• 声音波动条；

• 实时音量条；

• 波形动画；

• 录音状态动画；

• 动态发光边缘。

GPT 生成的静态样例图可能没有表现出这些动态效果。

这时需要在提示词中明确：

白天模式样例图中虽然没有显示动态声音波动条，但这个组件在现有代码中存在。

必须保留原有动画、数据来源和音频逻辑。

只允许修改 light mode 下的颜色，不能删除、隐藏或替换成静态 Divider。

否则 Codex 可能认为样例图里没有，就把动态组件一起删掉。

---

七、第五步：选择能力更强的 Codex 模型

UI 修改看起来只是颜色和布局，但实际涉及很多复杂内容：

• Flutter 页面结构；

• Row、Column、Stack；

• Expanded 和 Flexible；

• SafeArea；

• 多状态渲染；

• Light/Dark 主题分支；

• 响应式适配；

• 保留业务逻辑；

• 修复 overflow；

• 控制组件尺寸；

• 保持旧页面不被破坏。

因此，重要页面建议使用推理能力更强的 Codex 模型。

较弱模型容易出现：

• 只改颜色；

• 直接重写页面；

• 把夜间模式一起改掉；

• 漏掉使用中状态；

• 页面出现 overflow；

• 文字被截断；

• 按钮尺寸明显失控；

• 逻辑功能失效。

如果 Codex 支持先分析后执行，可以先让它输出：

• 页面主文件路径；

• 当前组件结构；

• Light/Dark 分支位置；

• 业务逻辑所在位置；

• 哪些 Widget 可以安全修改。

确认后再让它修改代码，会更加稳定。

---

八、第六步：必须用真机截图验收

Codex 输出“修改完成”，并不代表 UI 已经完成。

UI 必须以真机或模拟器运行截图为准。

检查内容包括：

• 白天模式是否生效；

• 夜间模式是否保持不变；

• 顶部按钮大小是否正确；

• 文字字号是否接近旧图；

• 卡片位置是否正确；

• 是否出现 RIGHT OVERFLOWED；

• 底部按钮是否遮挡内容；

• 列表是否能正常滚动；

• 空状态是否正确；

• 使用中状态是否正确；

• 动态组件是否仍然存在；

• 点击和路由是否正常。

不能只看代码。

也不能只看 Codex 的文字总结。

---

九、第七步：根据运行结果逐项小修

第一轮修改通常只能完成整体风格落地，很难一次达到完全一致。

接下来要根据真机截图进行第二轮小修。

小修时不要再发送一大段“重新改成白天模式”的提示词。

应该精确描述具体问题。

例如：

顶部语言切换条比夜间模式截图高，缩小高度和左右 padding。

只修改 light mode，不要改其他已经正确的部分。

或者：

底部两个语言录音按钮比夜间模式大。

请缩小按钮高度、麦克风图标圆底、主标题字号和副标题字号。

不要修改按钮点击逻辑。

或者：

当前出现 RIGHT OVERFLOWED BY 44 PIXELS。

请使用 Expanded / Flexible 调整顶部语言切换条，不要通过裁剪文字解决。

或者：

白天模式遗漏了原文和翻译卡片之间的动态声音波动条。

保留原动画和音频数据，只修改 light mode 颜色。

小修提示词最好加一句：

只修复我本次指出的问题，不要重新设计页面，不要修改已经正确的区域。

这样可以避免 Codex 在修一个问题时，又把其他区域改坏。

---

十、素材也必须先检查

UI 中如果使用图片素材，例如：

• 耳机图片；

• Logo；

• 背景波纹；

• 产品主视觉；

• 图标。

需要先检查素材是否合格。

尤其是所谓“透明 PNG”，必须确认：

• 文件存在 alpha 通道；

• 图片外部区域真的透明；

• 没有白底；

• 没有灰底；

• 没有矩形画布；

• 没有把卡片背景一起做进图片。

正确的做法是：

透明 PNG 只负责显示耳机本体。

外面的白色玻璃卡片、圆角、描边和阴影由 Flutter Container 或 DecoratedBox 绘制。

否则即使 Flutter 代码中没有设置背景，页面上仍然会出现明显的矩形底板。

---

十一、常见失败方式

1. 只给 Codex 一张白天模式图

后果：

• Codex 不知道哪些结构必须保留；

• 按钮大小和文字位置会跟着样例图改变；

• 页面容易被重新设计。

正确做法：

同时提供夜间模式旧图和白天模式新图。

---

2. 只说“改成白天模式”

后果：

• Codex 只修改颜色；

• 或者完全自由发挥；

• 无法准确控制结构和交互。

正确做法：

明确参考关系、修改范围和禁止事项。

---

3. 参考旧 Dark Mode 代码

后果：

• 白天模式结构跟着过时代码走；

• 和当前同事维护的夜间模式不一致。

正确做法：

当截图和代码不一致时，用截图确定布局，用代码保留业务逻辑。

---

4. 一次性让 Codex 完成全部页面

后果：

• 容易漏状态；

• 容易出现大量错位；

• 修改范围过大；

• 后续难以定位问题。

正确做法：

一个功能页一个功能页修改，每页先做第一版，再小修。

---

5. 为了消除 Overflow 直接裁剪文字

后果：

• 文字显示不完整；

• 页面看似没有报错，但视觉依然错误。

正确做法：

• 使用 Expanded；

• 使用 Flexible；

• 使用 LayoutBuilder；

• 调整 padding；

• 合理缩小字号；

• 让组件自适应，而不是直接裁剪。

---

十二、最终形成的标准流程

整套流程可以总结为：

准备当前最新的夜间模式截图
        ↓
分析页面结构、组件大小和交互状态
        ↓
让 GPT 按原结构生成白天模式样例图
        ↓
人工确认样例图视觉方向
        ↓
同时准备夜间模式旧图和白天模式新图
        ↓
让 GPT 生成带严格边界的 Codex 提示词
        ↓
选择能力较强的 Codex 模型执行
        ↓
真机或模拟器运行并截图
        ↓
对照夜间旧图检查结构和尺寸
        ↓
对照白天新图检查颜色和质感
        ↓
逐项修正字号、按钮、间距、遮挡和 Overflow
        ↓
确认 Light Mode 和 Dark Mode 均正常

---

十三、这套方法最重要的经验

1. 视觉目标必须先可视化

只用文字描述“浅蓝灰、高级、玻璃感”，每个人和每个模型理解都不一样。

先生成样例图，才能确定最终视觉目标。

---

2. 旧图和新图必须分工

旧图负责：

• 结构；

• 尺寸；

• 位置；

• 层级。

新图负责：

• 颜色；

• 材质；

• 阴影；

• 氛围。

不要让一张样例图同时承担所有参考作用。

---

3. 截图有时比旧代码更可信

多人协作时，本地代码很可能不是最新 UI。

最新截图反而更能代表当前已经确认的页面。

---

4. 给 Codex 的限制必须足够具体

“改成白天模式”不是一个合格的开发任务。

需要明确：

• 改什么；

• 不改什么；

• 参考什么；

• 哪些逻辑保留；

• 哪些状态要覆盖；

• 完成后如何验收。

---

5. UI 修改一定需要小修阶段

Codex 第一轮负责“把整体做出来”。

第二轮根据真机截图负责：

• 缩小按钮；

• 调整字号；

• 修正间距；

• 解决 Overflow；

• 修复遮挡；

• 补回动态组件；

• 统一页面节奏。

不要期待第一次执行就完全还原。

---

十四、总结

最终，我把这套 UI 修改流程总结为一句话：

先用最新旧截图锁定页面结构，再让 GPT 生成新的视觉样例，用旧图和新图共同约束 Codex，选择更强的模型完成第一版，最后根据真机截图逐项小修。

这套方法的重点，不是让 AI 直接替我们设计和修改全部页面。

而是把不同 AI 的能力拆开使用：

• GPT 负责理解视觉、生成样例图和整理提示词；

• Codex 负责阅读项目代码并落地 Flutter 页面；

• 人负责确认视觉标准、控制修改边界和验收最终效果。

这样做虽然比一句“帮我改成白天模式”多了几个步骤，但能够明显减少：

• Codex 自由发挥；

• 页面结构被改乱；

• 夜间模式被破坏；

• 多轮返工；

• Token 和时间浪费。

对于 Flutter、React、Vue 等前端项目，这套流程同样适用。