Codex 修改现有网页 UI 的安全流程

用 Codex 修改现有网页 UI，看起来比写新功能简单：换颜色、调间距、改按钮、修移动端错位。但真实项目里，最容易出问题的也正是这些“小改动”。你可能把客户原有设计系统改乱，覆盖别人还没提交的代码，或者只在自己屏幕上看起来正常，到了手机和宽屏就变形。

这篇是草稿，只做流程学习和人工审核参考。你可以配合 报错解释器、Proposal 生成器 和 模板库 使用：先把 UI 目标和边界写清楚，再让 Codex 辅助小范围修改。

适合谁

适合准备接网页 UI 小单的新手，例如修改按钮样式、调整卡片间距、修复移动端换行、优化表单布局、统一标题层级、处理局部视觉错位。你不一定能独立设计完整系统，但需要能看 diff、留截图、跑本地页面，并愿意按多个视口检查。

也适合已经会用 Codex 改代码、但经常担心“它是不是改太多了”的人。UI 修改的核心不是让页面变得更花，而是在客户已有风格里做可验证的、范围清楚的改动。

不适合谁

不适合客户只说“让它更高级”“整体美化一下”，却不给参考、品牌色、验收标准或允许修改范围的任务。模糊审美需求很容易返工，新手不应该直接承诺完整重设计。

也不适合涉及支付页、登录页、后台权限、真实用户数据、生产环境配置或大规模前端架构改造的任务。遇到这些范围，先暂停并让客户确认授权、测试环境和回滚方式。

风险提醒

UI 修改的风险常常不是安全漏洞，而是“无关影响”。比如调了一个全局 CSS 类，结果十几个页面都变了；改了按钮组件，后台危险操作按钮也受影响；移动端修好了，桌面端布局被挤坏。每次改动都要确认影响范围。

如果客户要求你登录生产后台、导出真实数据、绕开正常审核、修改支付或权限页面，不要直接执行。需要登录、授权或高权限操作的事项，先记录为客户待确认。

具体步骤

1. 保存修改前截图，至少包含桌面和移动端。
2. 复述客户目标：改哪个页面、哪个组件、希望变成什么状态。
3. 确认不改范围：哪些页面、组件、文案、颜色、交互不能动。
4. 查看项目结构和样式来源，判断是 Tailwind、CSS module、全局 CSS、组件库还是设计系统。
5. 让 Codex 只处理目标文件，不做无关重构。
6. 修改后查看 git diff，确认没有改动无关组件和配置。
7. 在至少两个视口验证：移动端和桌面端；必要时加平板或宽屏。
8. 记录验证结果、截图路径、未覆盖范围和客户待确认事项。

给 Codex 的提示词模板

请只修改这个 UI 问题，不要重构无关组件。
目标：
当前问题：
允许修改文件：
不能改变：
需要验证的视口：

请输出：
1. 最小修改方案
2. 可能影响的组件
3. 修改后需要检查的页面
4. 回滚建议

这段提示词的重点是限制范围。Codex 很擅长给出“顺便优化”，但做项目时顺便优化很可能变成不可解释的风险。

交付记录怎么写

修改目标：
修改页面/组件：
修改文件：
验证视口：
验证结果：
修改前后截图：
未覆盖范围：
客户待确认：
回滚方式：

交付记录能帮助客户判断你不是凭感觉改了一下。它也能保护你：如果客户后续要求“再把整个页面风格换掉”，你可以把它识别为新增需求，而不是原 UI 修复的一部分。

为什么截图很重要

UI 问题很难只靠文字说清。截图能保存修改前状态，也能证明你验证过目标页面。对新手来说，截图还是作品集素材的基础，但必须注意脱敏：不要展示客户后台数据、真实用户信息、订单、邮箱、密钥或未公开业务信息。

如果截图里有敏感内容，先遮挡再记录。不要把客户私有页面直接发到公开案例、文章或社媒里。

CTA：下一步

想直接执行，可以看 Codex 修改现有网页 UI 检查清单。如果你经常改大范围，继续看 常见错误和修复顺序。项目前不确定能不能做，可以用 项目边界判断 和 报价计算器 拆范围。

免责声明

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