Codex 修改现有网页 UI 检查清单

这份清单用于每次让 Codex 辅助修改现有网页 UI 前后。目标是把“看起来差不多”变成“范围清楚、截图可比、视口验证、可以回滚”的交付。

这篇仍是草稿，只做流程参考。建议先读 Codex 修改现有网页 UI 的安全流程，再把下面条目复制到项目记录里。涉及客户后台、真实数据、支付或权限页面时，要先人工确认。

适合谁

适合处理小范围 UI 修改的新手，例如按钮、卡片、表单、导航、移动端换行、间距、颜色、标题层级、局部布局错位。你需要能打开页面、保存截图、看 diff，并在不同视口检查效果。

也适合已经开始用 Codex 改前端文件的人。清单能帮你判断工具是否越界：是不是改了无关组件、是不是影响全局样式、是不是漏了移动端。

不适合谁

不适合没有设计目标、没有验收标准、没有页面访问方式、没有截图参考的“整体美化”任务。模糊审美需求需要先诊断和确认，不适合直接承诺完成。

也不适合高风险页面和高权限操作，例如支付流程、登录权限、后台用户数据、生产环境配置。遇到这些情况，先记录为客户待确认项。

风险提醒

UI 修改最怕全局影响。改一个基础组件、全局类名或主题 token，可能改变很多页面。每次修改都要问：影响范围是否可控？验证页面是否足够？客户是否知道未覆盖哪些状态？

具体步骤

一、修改前

• 是否保存当前页面截图？
• 是否确认目标页面、组件和视口？
• 是否有客户参考图、设计稿或文字验收标准？
• 是否知道哪些内容不能改？
• 是否确认这是测试环境还是生产环境？
• 是否运行 git status，确认工作区状态？
• 是否确认没有把客户敏感截图或后台数据交给工具？

二、分析代码时

• 样式来自哪里：Tailwind、CSS module、全局 CSS、组件库还是设计系统？
• 是否有复用组件？
• 是否有主题 token、颜色变量或 spacing 规则？
• 修改一个组件会影响哪些页面？
• 是否需要同时检查 hover、focus、disabled、loading、empty 状态？

三、让 Codex 修改时

• 是否限定了允许修改的文件？
• 是否要求最小修改？
• 是否禁止无关重构？
• 是否要求说明可能影响范围？
• 是否要求给出验证视口和回滚建议？

四、修改后

• git diff 是否只包含目标 UI 相关内容？
• 是否没有改动无关文案、路由、数据逻辑或配置？
• 是否检查了移动端和桌面端？
• 是否检查长文本、空状态、错误状态和按钮禁用状态？
• 是否截图保存修改后效果？
• 是否写清未覆盖范围？

交付模板

UI 目标：
修改页面：
修改文件：
验证视口：
验证结果：
截图说明：
未覆盖状态：
客户待确认：
回滚方式：

使用清单的小技巧

不要只检查你自己的屏幕。至少准备两个宽度：一个接近手机，一个接近桌面。页面里如果有表格、导航、按钮组、价格卡片或长中文标题，还要特别看是否换行、溢出、重叠。

如果客户只给了一句“更好看”，先让客户选择参考方向：更紧凑、更清晰、更接近某个页面、还是只修错位。没有方向时，Codex 可能会生成一套新风格，反而破坏客户原来的品牌一致性。

截图和隐私检查

UI 修改通常需要截图，但截图本身也可能泄露信息。保存或交付截图前，要检查页面里是否有客户姓名、邮箱、订单、后台菜单、余额、内部项目名、API key、测试 token 或未公开业务数据。如果有，先遮挡，再放进交付记录。

如果客户不允许公开展示，截图只能用于本次交付和内部记录，不能放进作品集、文章或社交媒体。对新手来说，保护客户材料比展示炫酷效果更重要。

CTA：下一步

如果检查中发现改动范围过大，先看 UI 修改常见错误。需要写客户说明时，可以用 Proposal 生成器 起草，再手动加入截图、验证视口和未覆盖范围。

免责声明

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