← 返回目录

第 56 卷

第 56 / 72 卷日期：2026-07-04

首页首屏能清楚表达产品用途
CTA 按钮更明显
移动端显示正常
不影响其他页面
项目可以正常运行和构建

需要哪些测试

改完之后不能只看 Codex 说“完成了”，还要提前说明需要怎么验证。

测试类型适用场景

页面预览UI 修改、页面布局调整

控制台检查前端页面、交互功能

构建测试	Next.js、React、Vue 项目
单元测试	有测试文件的项目
手动流程测试	登录、支付、表单、上传等流程
移动端测试	响应式页面、小红书首图、移动网页

有哪些风险

需求拆解时，还要提前让 Codex 判断风险。

这样它不会一边改一边乱试。

风险说明

影响范围过大小需求被改成大重构

样式污染	改了全局 CSS，影响其他页面
依赖风险	新增不必要依赖，项目变复杂
逻辑风险	为了修一个问题，改坏其他流程
数据风险	改接口、字段、数据库相关内容
兼容风险	桌面端正常，移动端出问题

需求拆解提示词模板

实际使用 Codex 时，可以直接复制这段：

需求：

【这里写你的需求】

请按下面结构分析：

背景是什么

当前项目大概是什么
为什么要做这个需求
这个需求属于新功能、Bug 修复、UI 优化，还是重构

要解决什么问题

当前具体问题是什么
本次要解决到什么程度
哪些内容不是本次范围

哪些文件可能相关

请根据项目结构判断可能涉及哪些文件
先列出来，不要直接修改

哪些功能不能动

不要改哪些逻辑
不要动哪些接口
不要影响哪些页面或组件

什么结果算完成

功能完成标准
页面完成标准
代码完成标准

需要哪些测试

需要运行什么命令
需要手动检查哪些页面
需要重点验证哪些流程

有哪些风险

可能影响哪些功能
是否有样式污染风险

建议先做哪一步
是否需要我确认后再修改

第二步：让 Codex 制定计划

需求拆解完成后，不要马上让 Codex 写代码。

这一步要让 Codex 先制定计划。

你可以把它理解成：

先让 AI 说清楚它准备怎么做，再决定要不要让它动手。

很多项目翻车，不是因为 Codex 不会改，而是因为它一上来就开始改。

等你发现方向不对时，它可能已经改了很多文件，回头检查和回滚都很麻烦。

所以第二步的核心是：

先计划，后执行。先确认，后修改。

先不要写代码

这一点要写在提示词最前面。

因为 Codex 的默认倾向是：看到需求后直接开始解决问题。

但在真实项目里，直接改代码风险很高。

直接写代码的问题	可能后果
没理解项目结构	改错文件
没确认需求边界	做了不该做的功能
没判断影响范围	误伤旧功能
没列测试方式	改完不知道怎么验收
一次改太多	出错后不好回滚

示例提示词：

先不要写代码，也不要修改任何文件。

请先根据当前需求和项目结构，制定一个修改计划。

等我确认后，再开始执行。

全站分卷索引 · 72 卷