Codex 使用笔记 01：先把它当成结对工程师

这是 Codex 使用笔记系列的第一篇。

我准备把它当成一个长期记录：不是单纯写“某个按钮怎么点”，而是记录在真实项目里，怎么把 Codex 用得更稳、更省心，也更符合工程习惯。

先说结论

我现在更愿意把 Codex 当成一个结对工程师，而不是一个代码生成器。

代码生成器的使用方式通常是：

我给一个需求
它吐一段代码
我复制、粘贴、再自己修

但 Codex 更适合另一种方式：

让它先读项目结构
让它理解已有约定
让它改代码、跑命令、看结果
最后由我确认方向和质量

这两种方式看起来差不多，实际体验差很多。前者像是在要答案，后者更像是在推动一个小任务闭环。

Codex 适合做什么

Codex 官方把它定义为面向软件开发的 coding agent。它能读代码、改代码、运行命令，也能帮助理解代码、修 bug、做代码审查。

我觉得最适合优先交给 Codex 的任务有几类：

已有项目里的小功能改造
UI 样式和交互细节调整
根据报错定位问题
写测试数据、补文档、整理脚手架
对陌生模块做解释和梳理

这类任务有一个共同点：它们不是完全凭空创作，而是依赖当前项目里的上下文。Codex 读完代码后，能沿着已有结构继续做，而不是每次重新发明一套写法。

第一步不是让它写代码

我现在给 Codex 任务时，通常不会一上来就说“帮我实现某某功能”。

更好的开头是：

先看一下当前项目结构，确认相关文件和已有实现方式，然后再改。

这句话很普通，但很关键。

因为工程项目不是孤立代码片段。目录结构、组件拆分、样式命名、数据来源、构建命令，这些都会影响最终实现。如果 Codex 没有先看项目，很容易写出“能运行但不像这个项目”的代码。

任务要说清楚边界

一个好用的 Codex 提示，不一定要很长，但边界要清楚。

比如这样：

首页文章列表每页展示 5 篇，剩下的做分页。
只改首页和文章列表页，不要动文章详情页。
完成后跑 npm run build。

这比只说“加个分页”要稳定得多。

我通常会给 Codex 四类信息：

要改哪里
不要改哪里
做完要怎么验证
暂时不要做什么额外动作

比如这个博客项目里，我会明确说“先本地预览，我确认后再推送 Git 和部署 Vercel”。这样它就不会在我还没看效果时直接上线。

Codex 不是免检工具

用 Codex 做开发，最重要的一点是：不要把它当成免检工具。

我会让 Codex 跑构建、跑测试、打开本地页面检查，但最终仍然要看三件事：

它改的文件是否在合理范围内
页面或功能是否真的符合预期
有没有顺手改了不该改的东西

尤其是 UI 调整，截图和实际页面非常重要。文字描述很容易有偏差，浏览器里的效果才是真正的结果。

什么时候需要给它项目规则

如果一个项目会长期用 Codex，我建议尽早沉淀项目规则。

比如：

用什么包管理器
构建命令是什么
提交前必须跑哪些检查
样式命名有什么约定
哪些目录不要动
什么时候可以部署，什么时候必须等人工确认

这些规则可以放在项目文档里，也可以用 AGENTS.md 这类方式告诉 Codex。这样每次打开项目，不需要重新解释所有约定。

我的当前用法

我现在比较常用的工作流是：

先让 Codex 读代码，不急着改。
让它给出影响范围。
小步修改。
每次重要改动后跑构建。
UI 改动用本地浏览器确认。
确认后再提交和推送。

这套流程听起来慢，但实际更快。因为少了很多“生成一堆代码再返工”的时间。

后面准备写什么

这个系列后面我准备继续写：

怎么给 Codex 写一个高质量任务描述
怎么让 Codex 更好地理解已有项目
怎么用 Codex 做前端 UI 调整
怎么让 Codex 辅助排查部署问题
怎么把 Codex 和 GitHub、Vercel 这类流程串起来
哪些任务不适合直接交给 Codex

第一篇先写到这里。

我的基本判断是：Codex 真正有价值的地方，不是“帮我少打几行代码”，而是让一个开发任务从理解、修改、验证到提交，尽量形成一个可控的闭环。