Codex 和 Cursor 网页修改选择清单

选工具前，先看任务。网页修改可能是文案、样式、移动端、组件、构建、部署或整站交付。不同任务需要不同的上下文、编辑方式和验证证据。下面这份清单帮助新手决定：用 Codex、用 Cursor，还是组合使用。

完整说明可读 Codex 和 Cursor 改网页怎么选。如果已经因为工具来回切换导致改动混乱，可以看 常见错误和修复顺序。

适合谁

适合正在做小网站、落地页、作品集页、Tailwind 页面和客户小修改的新手。你可能会用两个工具，但还不确定什么时候该让 AI 生成补丁，什么时候该自己在编辑器里调整。

也适合准备项目前做流程设计的人。工具选择清楚，报价和交付记录也会更清楚。

不适合谁

不适合只追求工具新功能、忽略验证的人。无论用哪个工具，都要看 diff、跑命令、截图和记录。

也不适合处理高风险生产系统的新手独立承接。工具选择不能降低支付、权限、数据库和用户数据风险。

风险提醒

切换工具本身会带来风险。一个工具改了文件，另一个工具继续基于旧理解生成建议，很容易出现重复修改、范围扩大和解释不清。

客户项目还要注意隐私和授权。不要把客户密钥、账号、私有截图和内部链接放进不该出现的地方。

具体步骤

1. 任务类型

• 文案替换。
• Tailwind 样式微调。
• 移动端检查。
• 组件重构。
• npm 或 build 报错。
• Vercel 部署排查。

文案和样式可以偏编辑器；报错和风险分析可以先用 Codex。

2. 上下文规模

• 只改一个文件。
• 涉及多个组件。
• 涉及配置。
• 涉及全站样式。
• 涉及部署和环境变量。

上下文越大，越需要先拆计划和风险。

3. 验证方式

• 是否需要截图。
• 是否需要 lint。
• 是否需要 build。
• 是否需要线上链接。
• 是否需要客户确认素材。

验证方式不明确时，先不要承诺交付。

4. 工具分工

• Codex：拆需求、解释日志、生成检查清单、写交付记录。
• Cursor：浏览项目、局部编辑、配合预览调整样式。
• 人工：review diff、跑命令、截图、确认边界。

把分工写下来，避免工具替你做最终判断。

5. 项目边界

• 是否需要客户账号。
• 是否涉及付费服务。
• 是否需要私有仓库。
• 是否需要生产数据。
• 是否需要长期维护。

有这些事项时，先写客户确认或待办。

选择结论怎么写

可以给任务写一句结论：“本任务适合 Cursor 局部编辑，Codex 负责检查清单，人工跑 build 和截图。”或者：“本任务风险不在样式，而在部署环境，先用 Codex 分析日志，再决定是否进入修复。”

这类结论能帮助你报价，也能让客户知道你不是随手试工具。

交付证据

• 修改前截图。
• 修改后截图。
• 已运行命令。
• 关键页面链接。
• diff 摘要。
• 未覆盖范围。
• 客户待确认事项。

工具选择只有配合证据才有意义。没有截图和命令结果，客户很难判断页面是否真的可交付。

报价前复核

报价前问自己三件事：任务是否能在本地复现，修改是否只影响指定页面，验证是否能在约定时间内完成。如果其中任何一项不清楚，就先问客户，而不是为了显得专业而直接报价。

需要估算时，可以用 报价计算器 把阅读、编辑、验证和沟通拆开。不要只按“改一行 class”估价，因为真正的成本常常在复查。

记录模板

任务名称：
客户原始需求：
适合 Codex 的部分：
适合 Cursor 的部分：
人工验证方式：
需要客户确认：
本轮不包含：
最终交付物：

这份模板能帮你把工具选择变成项目流程，而不是临场感觉。尤其在客户项目里，写清“本轮不包含”很重要，例如不包含部署、不包含设计重做、不包含表单后端配置。

客户确认项

网页修改常见客户确认项包括：最终文案、logo 和图片授权、目标链接、移动端设备范围、是否需要部署、是否有正式域名、是否允许访问私有仓库。缺少这些信息时，先问，不要让工具替你猜。

如果需要登录、授权或付费服务，把它列为客户待办。你可以协助整理步骤，但不要把自己的账号绑定到客户项目里。

CTA：下一步

拿一个网页修改任务，用这份清单写出工具分工。需要交付模板时，从 模板库 找记录表，再用 报价计算器估算时间。

免责声明

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