第 58 卷

当前只执行第【1】步：

【这里写本次只做的一个功能点】

要求：

1. 一次只改这个功能点
2. 只修改和当前功能直接相关的文件
3. 不要顺手重构无关代码
4. 不要修改目录结构
5. 不要新增不必要依赖
6. 不要删除已有功能
7. 不要改计划外的文件

修改完成后请停止，并输出：

1. 本次修改了哪些文件
2. 每个文件改了什么
3. 为什么这些修改是必要的
4. 有没有改到计划外内容
5. 有没有潜在风险
6. 下一步建议做什么

注意：

如果遇到不确定的地方，请先停下来问我，不要自行决定。

第四步：测试

Codex 完成小步修改后，不能马上进入下一步，必须先测试。

很多人用 Codex 最大的问题是：

AI 说完成了，但项目其实没跑通。页面看起来正常，但某些功能已经坏了。当前功能修好了，旧功能却被影响了。

所以测试的核心是：不是相信 Codex 说「完成」，而是用结果证明它真的完成。

下面这张表覆盖了一次完整测试要做的事，按从快到慢的顺序执行即可：

测试类作用常见命令重点型

单元测检查函数、组件、模块是否正常npm test / pnpm test失败先说明原因，不要直接改

两个提醒：很多老项目本身就有 lint 或类型问题，不要让 Codex 把历史问题都顺手重构；回归测试是最容易被小白忽略的一步——改了首页按钮，也可能影响复用同一组件的其他页面。

手动测试时，可以让 Codex 把验证步骤列成「操作—预期结果」表格，例如：

测试阶段提示词模板

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

请按下面顺序执行或说明：

1. 单元测试

• 项目是否有单元测试
• 如果有，请运行测试命令
• 如果失败，请说明失败原因

1. 类型检查

• 项目是否有 typecheck 命令
• 如果有，请运行
• 如果没有，请说明

1. lint

• 运行 lint 检查
• 区分本次新增问题和项目原有问题

1. 构建

• 运行 build 命令
• 如果失败，请说明报错原因和影响范围

1. 手动测试

• 列出需要手动测试的页面
• 列出用户操作步骤
• 列出每一步预期结果

1. 浏览器测试

• 检查页面显示
• 检查控制台报错
• 检查移动端布局
• 检查关键按钮和交互

1. 回归测试

• 检查本次修改是否影响旧功能
• 列出可能受影响的页面、组件和流程

最后请输出测试总结：

• 哪些测试通过了