Codex CLI 第一个项目

背景与动机#

Codex CLI 的第一课不是学会所有命令，而是在一个真实项目里完成最小闭环：

这个闭环跑通后，再处理复杂任务会稳很多。

进入项目前先看状态#

建议先执行：

1
git status --short

如果有未提交改动，要区分：

• 哪些是用户已有改动。
• 哪些是本轮任务新增改动。
• 哪些文件不能回滚或覆盖。

Codex 处理本地文件时，最怕把已有改动当成可随意整理的垃圾状态。开始前明确工作区状态，是保护用户工作的第一步。

让 Codex 先读项目规则#

第一条任务可以是：

1
请先读取项目规则文件、README 和依赖配置。
2
只总结项目结构、常用命令和验证方式，不要修改文件。

如果项目有 AGENTS.md，它通常应作为 Codex 的首要规则入口。里面可以写编码、测试、搜索、权限和输出要求。

第一个任务要小#

适合作为第一个 Codex CLI 任务：

• 修正文档里的一个命令。
• 给已有笔记补一小节。
• 修复一个明确 lint 问题。
• 添加一个缺失但简单的测试。

不适合：

• 一次性重构目录。
• 迁移框架版本。
• 接入新外部服务。
• 生产部署操作。

推荐提示词#

1
请完成一个最小闭环任务：
2
1. 先读项目规则和相邻实现。
3
2. 只修改当前问题需要的文件。
4
3. 不改 UI、不改路由、不做额外重构。
5
4. 完成后运行项目已有校验命令。
6
5. 汇报修改内容、验证结果和未完成项。

这类提示词的重点是把 Codex 的行为限制在项目已有模式里。

验收结果怎么看#

完成后至少看三类信息：

• 改了哪些文件。
• 运行了哪些命令。
• 是否存在未解决问题。

如果 Codex 只说“已完成”，但没有验证命令和结果，就不能算闭环。

第一次项目验收清单#

1
是否读取了 AGENTS.md 或项目规则？
2
是否说明了项目技术栈和常用命令？
3
是否只改了任务要求的文件？
4
是否运行了验证命令？
5
是否说明未运行验证的原因？
6
是否避免覆盖已有工作区改动？

一句话总结#

Codex CLI 入门的关键是先建立本地工程闭环，而不是把它当成只会回答问题的聊天工具。