Codex CLI 第一次完整工作流：从读项目到提交前检查

很多人第一次用 Codex 时，会直接说“帮我改这个项目”。这通常不是最好的开始。更稳的方式是：先让 Codex 读项目，再让它说明计划，最后才允许它修改文件。

适合练习的第一个任务

建议选一个低风险任务，例如：

不要第一次就让 Codex 重构支付系统、迁移数据库或批量改权限代码。

进入项目目录后启动 Codex：

codex

第一句话建议这样写：

先不要修改文件。请阅读这个项目的目录结构，告诉我：
1. 主要模块分别是什么；
2. 本地开发和测试命令可能在哪里；
3. 如果我要改一个小功能，应该先看哪些文件。

这一步的目标不是马上产出代码，而是确认 Codex 对项目的理解是否靠谱。

确认它读对项目后，再给一个具体任务：

请帮我给 README 增加本地启动说明。
要求：
- 先说明你准备改哪里；
- 不要新增依赖；
- 保持现有文档风格；
- 修改后告诉我怎么检查。

如果 Codex 的计划里出现不相关文件，先让它收窄范围。

计划合理后再说：

按这个方案修改。完成后运行能证明文档没有破坏项目的最小检查命令。

文档任务可能没有自动化测试，但至少可以让 Codex 检查格式、链接或项目已有的 lint 命令。

Codex 完成后，不要只看总结。你应该运行：

git diff
git status

检查三件事：

如果不确定，可以继续问：

请逐个解释当前 git diff 中每一处修改的目的。只解释，不要继续改。

第一，不要把“解释项目”和“改项目”放在同一句里。先理解，再动手。

第二，不要跳过 diff。Codex 很适合帮你改代码，但最终责任仍然在你。

第三，不要让 Codex 在没有上下文的情况下猜测试命令。可以要求它先从 package.json、Makefile、README 或 CI 配置里找。