网页修改 AI 工具检查清单：Claude Code 和 Codex 怎么选

网页修改项目前，先不要急着问工具“帮我改”。更稳的做法是先确认需求、文件范围、验证方式和风险边界。Claude Code 和 Codex 都能帮忙，但如果输入不清楚，输出就会把不确定性包装得像确定答案。

这份清单是草稿，用来帮助新手在接小型网页修改前做人工判断。它适合配合 Claude Code 和 Codex 哪个适合网页修改、常见错误 和 /templates 使用。

适合谁

适合准备处理按钮样式、页面文案、响应式布局、组件状态、静态页面和轻量构建问题的新手。你需要愿意看代码、跑命令、截图验证，而不是只复制工具输出。

也适合已经收到客户需求但还没报价的人。清单可以帮你判断任务是否清楚、是否需要追问、是否超出新手能力。

不适合谁

不适合处理支付页、登录系统、客户数据库、生产后台、敏感账号和复杂安全问题的新手。看到这些关键词时，应先暂停并找人工复核。

也不适合没有本地运行环境、没有仓库权限、无法验证结果的任务。不能验证的网页修改，很容易变成口头承诺。

具体步骤

1. 保存客户原始需求、截图、链接和期望效果。
2. 标注页面类型：静态页、React 组件、Next.js 路由、CMS 页面、表单还是第三方嵌入。
3. 看 git status，确认是否有未理解的改动。
4. 找到相关文件，不要全仓库盲改。
5. 决定工具用途：Codex 负责仓库内修改；Claude Code 辅助解释、审阅或生成提问清单。
6. 修改后跑本地检查，并保存命令结果。
7. 截图对比修改前后，确认桌面和移动端都能看。
8. 写交付说明，列出已做、未做、验证方式和客户待确认项。

项目前清单

• 客户是否提供了截图或明确页面链接？
• 是否知道要改的是文案、样式、布局还是功能？
• 是否能在本地或测试环境验证？
• 是否有设计稿、品牌色、字体或组件规范？
• 是否会影响导航、表单、登录、付款或数据提交？
• 是否需要客户账号、环境变量或后台权限？
• 是否有明确验收标准？
• 是否准备了回退方式？

工具选择清单

用 Codex 的情况：需要读多个文件、改代码、跑 lint、跑 build、看 git diff、保持工作区干净。用 Claude Code 的情况：需要解释某段代码、比较方案、生成客户追问、审阅 proposal 或整理风险清单。

如果任务同时需要两者，可以先用 Claude Code 拆需求，再让 Codex 在仓库里执行。不要让任何工具替你决定报价、承诺交付时间或跳过验收。

验收记录模板

任务名称：
客户原始需求：
修改文件：
验证命令：
桌面截图：
移动端截图：
未覆盖范围：
客户待确认：
是否需要人工复核：

这个模板可以放在每个小项目的交付记录里。新手早期最值钱的不是“改得快”，而是能证明自己改了什么、怎么验证。

客户追问模板

我可以先帮你判断这个网页修改是否适合处理。为了避免范围不清，需要确认：
1. 需要修改的页面链接或截图是什么？
2. 期望效果是否有参考图或文字说明？
3. 是否能提供代码仓库或测试环境？
4. 修改是否会影响表单、登录、付款或后台？
5. 验收时以哪个页面、哪个设备或哪个命令为准？

这段追问适合在报价前发送。客户如果只能给一句模糊描述，先不要进入完整报价；可以把第一步定义为需求诊断，等材料齐了再判断是否能做。

完成后的复核

复核时不要只看目标页面。还要看导航是否仍可点击、按钮文字是否溢出、移动端是否换行异常、控制台是否有明显错误、构建命令是否通过。对新手来说，复核范围可以小，但不能完全没有。

如果改动涉及公共组件，还要检查至少两个使用该组件的页面。比如你改了一个 Button 组件，首页没问题，不代表表单页也没问题。交付说明里要写清你检查了哪些页面，没有检查哪些页面。

风险提醒

不要在没有备份、没有测试、没有截图的情况下交付网页修改。小改动也可能破坏布局、表单提交、SEO 元信息或移动端体验。

不要处理你无法解释的权限请求。客户如果要求你登录后台、接触真实用户数据或修改生产配置，先把它从“网页修改小单”里拿出来，作为高风险事项单独复核。

免责声明

本文仅供学习和项目检查参考，不构成安全、法律或平台合规建议。不同项目、框架和客户环境差异很大，发布前请人工复核工具功能和示例命令。

CTA：开始前先下载 /templates 里的需求记录表；需要写客户回复时，用 /tools/proposal-generator 生成初稿后再人工复核。