Codex 修改现有网页 UI 常见错误和修复顺序

Codex 改 UI 很快，但快不代表稳。新手常见情况是：客户只要修一个按钮间距，结果改了整个组件；桌面端看起来不错，手机端挤成一团；截图没留，客户说“之前不是这样”，你也没证据。

这篇是草稿，只做复盘参考，不替代具体项目人工审核。还没有固定流程的，可以先看 UI 修改安全流程 和 检查清单。

适合谁

适合已经让 Codex 参与前端 UI 修改的新手。你可能能快速调样式，但还不稳定：有时忘记响应式，有时让工具重构太多，有时交付时只说“已调整”。

也适合准备整理匿名作品集的人。UI 改动很适合展示前后对比，但前提是截图脱敏、范围清楚、客户允许公开。

不适合谁

不适合正在处理生产后台、支付页、账号权限页面或真实用户数据页面，但没有授权和测试环境的任务。UI 看起来只是视觉问题，实际可能影响关键业务流程。

也不适合把 Codex 输出当成设计方案的人。工具可以辅助修改，但品牌一致性、可用性、验收和业务风险需要人工判断。

风险提醒

发现 UI 改乱时，不要继续加更多样式去“压住问题”。先停下来，看 diff、截图和影响范围。越继续堆样式，后面越难恢复。

错误一：没有保存修改前截图

没有截图，就很难证明原状态和修改效果。客户反馈“改之前更好”时，你只能靠记忆沟通。

修复方式：每次 UI 修改前保存桌面和移动端截图。截图里有客户数据、订单、邮箱或后台信息时，先遮挡再保存。不要把未脱敏截图放进公开案例。

错误二：让 Codex 大范围重构

工具可能顺手改组件结构、抽函数、换样式系统。看起来更整洁，但验证成本变高，也容易影响无关页面。

修复方式：提示词里写明“只做最小修改，不重构无关模块”。提交前看 diff，任何不能直接解释和目标 UI 的关系的改动，都先移出。

错误三：只看一个屏幕宽度

UI 最常见的失败发生在你没看的地方：窄屏、宽屏、长文本、空状态、错误状态、按钮禁用状态、加载状态。只看一个桌面宽度不够。

修复方式：至少检查移动端和桌面端。遇到卡片、表格、导航、价格区块、表单按钮组，要额外看是否溢出、重叠、换行混乱。

错误四：破坏设计系统

客户项目可能有固定颜色、间距、圆角、字体和按钮规则。新手为了快速好看，可能直接写新颜色、新阴影、新字号，结果页面和整体风格不一致。

修复方式：先读现有组件和样式变量。优先使用项目已有 token、类名和组件模式。除非客户确认，不要引入新的视觉语言。

具体步骤：发现 UI 被改乱后怎么补救

1. 暂停继续修改，不要继续叠加样式。
2. 查看 git diff，列出所有 UI 相关改动。
3. 对照修改前截图，确认目标问题是否真的改善。
4. 删除无关重构和风格漂移的改动。
5. 保留最小修复，再跑页面和构建验证。
6. 在移动端和桌面端重新截图。
7. 写清未覆盖状态，例如没测暗色模式、没测平板、没测后台角色。
8. 如果需要更大重设计，重新和客户确认范围。

复盘模板

目标 UI 问题：
错误发生在哪里：
无关改动：
保留改动：
验证视口：
截图：
未覆盖状态：
下次新增检查项：

补救后怎么验收

补救不是把页面调回“看起来还行”就结束。你需要重新对照客户目标，看最初要修的问题是否解决；再检查无关页面是否被影响；最后把修改前后截图、验证视口和未覆盖状态写清楚。没有这个过程，补救只是另一次盲改。

如果补救后发现原需求其实是更大范围的重设计，要停止把它当作 bug 修复或小样式调整。你可以向客户说明：当前小修已经完成或无法满足整体目标，下一步需要重新确认设计范围、参考页面、验收标准和报价。

CTA：下一步

如果你想把这些错误变成固定流程，回到 UI 修改检查清单。需要向客户解释范围变化时，可以用 Proposal 生成器 起草，再手动加入截图和验证说明。

免责声明

本文只用于 AI 工具实践流程学习和草稿复核，不构成设计承诺、法律意见、职业建议或具体项目交付承诺。真实项目应以客户授权、平台规则、合同约定和人工复核为准；需要登录、授权或高权限操作的事项，应先记录并由客户确认。