Codex 和 Cursor 改网页常见错误和修复顺序

同时使用 Codex 和 Cursor 改网页，效率可能很高，也可能很快变乱。新手常见情况是：Codex 给了一套方案，Cursor 又重写了组件，最后 diff 很大、验证很少、客户要求的原始问题反而说不清。工具越强，越需要流程。

这篇文章整理常见错误和修复顺序。完整选择流程见 Codex 和 Cursor 改网页怎么选，短表版见 工具选择清单。

适合谁

适合已经用两个工具改过页面，但发现改动范围扩大、代码难 review、客户反馈难解释的新手。

也适合准备做网页修改项目的人。你需要证明的不只是会用工具，而是能控制范围、验证结果和交付证据。

不适合谁

不适合在客户项目里反复试工具、不保存记录的人。客户项目需要可解释、可回退、可验收。

也不适合大型高风险系统的新手独立承接。工具不能替代安全审查和经验。

风险提醒

最常见风险是工具之间上下文不同步。一个工具不知道另一个工具刚改了什么，建议可能过时。第二个风险是过度重写：为修一个按钮，重写整个组件和样式体系。第三个风险是没有验证：页面看起来好，但 build、移动端、链接和表单没检查。

做项目时还要注意客户材料和授权。截图、品牌素材、私有代码和账号权限都需要确认。

具体步骤

第一步：回到原始需求

先写清客户到底要什么。是改文案、修移动端、改 hero、修 build，还是做完整页面？不要让工具把任务带偏。

第二步：冻结当前状态

看 git status 和 diff。知道当前改了哪些文件，再决定是否继续。若 diff 已经很大，先不要让另一个工具继续重写。

第三步：分配工具角色

Codex 负责分析和审查，Cursor 负责局部编辑，人工负责验证。角色越清楚，越少互相覆盖。

第四步：小步修复

每次只修一个问题。移动端横向滚动、按钮样式、文案替换、构建错误不要混在同一轮里。

第五步：跑验证

根据任务跑对应验证：样式看截图，构建跑 build，部署看线上链接，小网站跑交付检查。可以参考 Tailwind 移动端检查 和 Vercel 部署检查。

常见错误清单

第一类是没看 diff。第二类是没跑 build。第三类是没有保存客户原始需求。第四类是让 AI 过度重写组件。第五类是工具切换后没有同步上下文。第六类是没有交付记录。

第七类是把工具输出当成事实。AI 说“已修复”，不等于你已经验证。第八类是把工具选择当作卖点，而不是把结果和证据当作卖点。

修复顺序示例

假设客户只要求移动端按钮不要遮挡，但你已经重写了整个 hero。先回到 diff，看是否有无关修改。保留必要变更，撤掉不相关的重写，再按移动端截图验证。

假设 build 失败，Cursor 提示改依赖，Codex 提示改配置。先保存日志，判断错误类型，再只选一个低风险验证动作。不要同时升级依赖和改配置。

交付记录怎么写

交付记录应包含：使用工具分工、修改文件、验证命令、截图、未覆盖范围和客户待确认事项。需要模板时，从 模板库 开始；报价时用 报价计算器估算阅读、修改和复核时间。

如何把流程拉回来

如果你已经让两个工具都改过代码，先暂停生成新内容。第一步看 git diff，按文件分组：文案、样式、组件、配置、依赖。第二步标出哪些改动和客户原始需求直接相关。第三步把无关改动放到下一轮，或者先不提交。

然后重新跑最小验证。样式任务先看截图，构建任务先跑 build，部署任务先看 Vercel 日志。不要在验证失败时继续加功能。

客户沟通示例

可以这样写：“我已经把改动范围收敛到移动端导航和按钮布局，本轮不包含文案重写和部署配置。接下来会提供修改摘要、桌面和移动端截图，以及未覆盖范围。”这比“我用 AI 修好了”更有交付感。

如果客户继续追加需求，把新增项写成下一阶段。项目早期，阶段边界能救你很多次。

CTA：下一步

打开最近一次网页修改 diff，标出哪些改动来自原始需求，哪些是工具顺手生成。删除或拆出无关改动，再进入下一轮验证。

免责声明

本文是学习和排查流程，不构成法律、财务、安全或职业承诺。工具能力、价格和平台规则会变化，具体项目需要结合客户授权、代码环境、任务风险和人工复核判断。