Claude Code 和 Codex 网页修改常见错误

新手用 Claude Code 或 Codex 做网页修改，最常见的问题不是工具不会写代码，而是人没有把任务边界守住。网页修改看似轻量，实际可能牵涉组件状态、响应式布局、SEO、构建流程、部署配置和客户验收。如果只看工具输出，很容易交付一个“看起来改了、实际没验证”的结果。

这篇草稿整理常见错误和处理步骤。建议配合网页修改新手检查清单、项目范围判断、/tools/proposal-generator 使用。

适合谁

适合已经尝试用 AI 工具改网页，但经常遇到构建失败、样式跑偏、客户说“不是这个意思”的新手。你不需要一次掌握所有框架，但需要建立固定的排查顺序。

也适合准备写交付说明的人。很多争议不是来自代码本身，而是你没有写清修改范围、验证方式和未覆盖内容。

不适合把客户生产站点当练习场的人。任何涉及真实用户、付款流程、后台配置、账号权限和隐私数据的修改，都不应该按普通小任务处理。

也不适合追求“工具一次生成完整结果”的人。网页修改需要观察、测试和复核，聊天输出只是中间材料。

错误一：直接让工具改“页面更好看”。这类需求太模糊，工具会凭默认审美改动，很容易偏离客户品牌。正确做法是先问颜色、字体、布局参考、目标用户和验收标准。

错误二：只改 CSS，不看组件逻辑。按钮禁用、加载态、表单错误、导航选中状态都可能由组件逻辑控制。只改样式可能解决不了真正问题。

错误三：没有跑构建。页面在开发环境看起来正常，不代表生产构建通过。至少要根据项目情况跑一次 npm run build 或等价命令。

错误四：忽略移动端。客户常说“网页坏了”，实际可能只在手机上重叠。交付前至少检查一个桌面尺寸和一个移动尺寸。

错误五：没有写未覆盖范围。你修了首页按钮，但客户以为全站按钮都改了；你改了视觉，但客户以为包含埋点和表单逻辑。未覆盖范围必须写出来。

遇到问题时，先回到事实：客户原话是什么，当前页面表现是什么，预期结果是什么，哪个文件变了，哪个命令失败。不要一开始就让工具继续扩散修改。

如果 Codex 已经改了多处文件，先看 diff，确认每处改动都能解释。如果解释不了，先不要提交。用 Claude Code 可以帮助整理风险和客户追问，但最终判断仍然要靠人工复核。

如果交付说明里写不出验证方式，就先不要发给客户。如果你不知道改动影响哪些页面，也先不要发。如果客户需求需要登录后台、接触真实数据或改生产配置，应先记录为高风险事项，等待人工确认。

停一下并不等于效率低。对新手来说，能识别不能做的范围，本身就是项目判断能力的一部分。

不要承诺工具可以替你完成所有网页修改。不同项目的框架、依赖、样式系统和部署方式差异很大。工具可能生成可运行代码，也可能引入隐藏问题。

不要把客户敏感信息、环境变量、私有链接或账号资料直接放入提示词。需要脱敏的先脱敏，需要授权的先记录，不要在未确认时操作。

本文仅供学习和项目排查参考，不构成安全、法律或平台合规建议。真实项目应根据客户授权、项目环境和验收标准处理。发布前请人工复核示例、工具功能和风险提示。

CTA：遇到网页修改需求时，先用 /templates 记录客户原话；需要写回复，用 /tools/proposal-generator 出初稿，再按本文清单删掉过度承诺。