Codex 开发初体验
我对 Codex 开发流程的一点理解：重点不是“让 AI 写代码”，而是“让 AI 按文档执行”
这两天用 Codex 开发项目，我有一个比较明显的感受：所谓 vibe coding，并不是完全凭感觉让 AI 写代码，也不是一句“帮我做个系统”就等它自动完成。
真正重要的是：把需求、规则、边界和验收标准写清楚。
一开始我会担心，Codex 的对话变长了怎么办？过几天再继续开发会不会断？新开一个 Codex 对话会不会不知道之前做了什么？
后我逐渐明白，项目的连来续性不应该依赖某一个聊天窗口，而应该沉淀在项目文件里。
比如：
AGENTS.md是项目级规则docs/是项目开发文档schema.sql是数据库结构.env.example是环境配置模板- 测试清单是验收标准
- Git commit 是阶段记录
只要这些东西清晰，Codex 新开对话也能继续接上。
我现在对 Codex 的理解更像是：它不是一个“什么都知道的程序员”，而是一个依据文档执行任务的开发代理。文档越清楚，它越稳定；文档越模糊，它就越容易猜。
所以整个开发流程应该变成：
- 先写清楚模块目标
- 明确哪些功能要做，哪些功能不要做
- 给出接口、数据库、目录结构和验收标准
- 让 Codex 按文档开发
- 开发完让它自检
- 本地测试通过后提交 Git
- 阶段性再部署到服务器
这套流程跑下来，我感觉“文档”其实有点像项目级的 Skill。
Skill 是把一类任务的执行方法沉淀下来，项目文档则是把当前项目的上下文沉淀下来。它们的目标都一样：减少重复解释，让 AI 稳定执行。
这也是我现在对 AI 开发最大的变化：
以前我以为重点是“会不会写代码”，现在觉得重点是“会不会描述系统”。
因为 AI 能写代码，但它需要依据。
而文档，就是依据。
所以对我来说，Codex 真正提升效率的方式，不是替我省掉思考，而是把我的思考变成可执行的任务书。
以后做项目，我会更重视这几件事：
- 需求文档要清楚
- 项目边界要明确
- 数据库和接口要提前设计
- 每个模块都要有验收清单
- 每轮开发都要沉淀到文档和 Git 里
这样即使换对话、换模型、隔几天再继续，也不会乱。
最终我对 vibe coding 的理解是：
不是无文档开发，而是文档驱动、AI 执行、测试闭环。
AI 不是替代项目管理，反而会放大项目管理的重要性。
文档越清楚，AI 越像团队成员；文档越混乱，AI 就越像一个随机生成器。
内容通过 ChatGPT 整理