Codex + GORM 实战：自动生成模型、CRUD 和数据库迁移

大家好，我是 Codex 中文网的站长宇哥。

本文按 2026 年 8 月的 Codex 公开能力整理。Codex CLI、模型、Skill、Plugin 和第三方兼容接口更新较快，具体字段与可用能力请以你当前版本和官方文档为准。

用 Codex 做“Codex + GORM 实战”，最容易犯的错是让它在不了解仓库约束的情况下直接生成一大批代码。更稳的方式是先让它识别 GORM 项目的真实结构、依赖版本、已有模式和测试命令，再要求做最小实现。

推荐的四步工作流

1. 读项目：先找入口、模块边界、依赖文件和现有相似实现。

2. 定方案：列出要修改的文件、接口变化和数据流。

3. 小步实现：优先沿用现有风格，不顺手重构无关代码。

4. 验证：运行编译、单测、Lint、集成测试，并检查最终 Diff。

GORM 项目可以先让 Codex 运行这些检查

# 根据你的项目脚本调整
go test ./...
go test -race ./...
go test ./...

这些命令只是常见起点。真正应该执行什么，以仓库里的 README、CI、Makefile、package scripts 或 AGENTS.md 为准。不要为了“让命令成功”擅自删除测试或降低检查标准。

可直接复用的提示词

目标：Codex + GORM 实战
范围：先阅读相关代码和配置，再提出最小改动方案。
约束：遵循现有 GORM 项目结构；不要升级无关依赖；先找同类实现再写新代码。
验收：说明改了什么、为什么这样改，并运行能覆盖本次修改的测试或检查命令。
如果遇到不确定信息，先验证再修改，不要猜测项目结构。

怎么判断 Codex 真的完成了任务

不要以“它说完成了”为标准，而看这些证据：代码能编译、测试通过、接口行为符合需求、Diff 范围合理、没有新警告、关键失败路径被覆盖。涉及数据库或外部 API 时，还要验证迁移/回滚和错误处理。

常见问题

这篇文章适合新手照着做吗？

适合。建议先按文章里的顺序理解问题背景，再在自己的项目里做最小验证，不要一次修改太多配置。

文章里的命令和配置需要完全照抄吗？

不建议完全照抄。Codex、模型接口和第三方工具更新很快，执行前要结合当前系统、项目目录、账号权限和官方文档再确认一遍。

总结

在“Codex + GORM 实战”里，Codex 最适合承担的是高强度的代码阅读、候选实现、测试补齐和重复验证。把项目约束、验收标准和权限边界交代清楚，效果通常比单纯要求“帮我写代码”稳定得多。

参考资料

• OpenAI：Codex CLI
• OpenAI：AGENTS.md

如果你通过第三方 API、中转站或兼容层使用 Codex，协议行为可能与 OpenAI 官方链路不同，排查时要把“Codex 客户端”和“上游接口”分开验证。