← 返回目录

第 57 卷

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

输入 /plan，先让 Codex 输出计划，再决定是否执行。

第三步：小步实现

计划确认后，才进入真正的代码修改阶段。

但这里有一个非常重要的原则：

不要让 Codex 一次性把所有东西都改完。

很多人用 Codex 翻车，就是因为一上来就让它“全部实现”。

结果它可能会同时改页面、改组件、改样式、改接口、改配置，最后项目虽然看起来变了，但你很难判断到底哪里出了问题。

所以更稳定的方式是：

一次只改一个功能点。改完一小步，就检查一小步。

一次只改一个功能点

小步实现的核心是控制修改范围。

比如你要优化首页，不要一次性说：

请帮我优化整个首页。

更推荐拆成这样：

步骤修改内容

第一步只优化首屏标题和副标题

第二步只调整 CTA 按钮

第三步只优化移动端布局

第四步只补充产品卖点卡片

第五步只处理最终样式细节

这样每一步都很清楚，出问题也容易定位。

不要让 Codex 顺手重构无关代码

Codex 有时候会觉得某些代码“不够优雅”，然后顺手帮你重构。

但真实项目里，顺手重构是很危险的。

重命名组件	导致引用路径出错
拆分文件	增加维护成本
改全局样式	影响其他页面
优化旧逻辑	破坏原本可用功能
升级依赖	引发兼容问题
删除它认为无用的代码	实际可能是业务逻辑

所以在小步实现时，要明确限制：

本次只实现当前功能点。

不要顺手重构无关代码。

不要修改命名、目录结构、依赖版本和全局配置。

如果你发现代码可以优化，请先记录为建议，不要直接修改。

这句话很重要。

Codex 可以提建议，但不能私自扩大改动范围。

不要接受大面积无解释修改

如果 Codex 一次性改了很多文件，而且没有解释清楚原因，就要暂停。

尤其是看到这些情况时，要提高警惕：

情况	处理方式
改动文件数量突然很多	要求解释每个文件为什么改
删除了大量代码	要求说明删除原因
新增了不认识的依赖	要求说明必要性
修改了配置文件	要求说明影响范围
改了和需求无关的页面	要求回退无关修改
代码风格大变	要求保持原项目风格

遇到不确定先停下来问

小步实现不是让 Codex 什么都问，而是遇到关键不确定时必须停下来。

比如：

不确定该改哪个文件	防止改错位置
不确定业务规则	防止逻辑做错
不确定是否能删旧代码	防止误删功能
不确定是否新增依赖	防止项目复杂化
不确定接口含义	防止影响数据
不确定测试失败原因	防止越修越乱

可以提前给 Codex 加这条规则：

如果你遇到以下情况，请先停下来问我，不要自行决定：

不确定该改哪个文件
不确定是否要删除旧代码
不确定是否要新增依赖
不确定业务逻辑应该怎么处理
不确定测试失败原因
发现需要超出原计划的修改

小步实现提示词模板

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

全站分卷索引 · 72 卷