Codex 教程
Codex 教程
Codex 教程中心讲清 Codex CLI、本地项目、AGENTS.md、Goal Prompt、改代码、修 Bug、写测试、Git 交付、排错和 OfApp.cn 接入时机。
Codex 教程不是让 AI 随便“帮我写点代码”,而是把真实开发任务交给一个能读取仓库、执行命令、修改文件、解释 diff、运行验证的代码代理。它适合处理本地项目、前端页面、测试补齐、报错排查、文档整理、脚本改造和 Git 交付,也适合让非开发者把网站、小工具或自动化流程从想法推进到可验证版本。
| 项目 | 说明 |
|---|---|
| 阅读时间 | 约 6 分钟 |
| 更新时间 | 2026-07-03 |
| 适合人群 | 开发者、产品经理、运营、设计师、学生、老师、创作者和需要维护网站的人 |
| 适合任务 | 改代码、修 Bug、写测试、生成 README、搭建网站、整理脚本、配置 Docker、处理 Git 流程 |
Codex 适合做什么
Section titled “Codex 适合做什么”| 任务 | Codex 能做的部分 | 人应该复核什么 |
|---|---|---|
| 读懂项目 | 扫描目录、识别框架、阅读关键文件、梳理脚本 | 业务背景、隐含规则、历史包袱 |
| 写新功能 | 根据目标改文件、补状态、补样式、接路由 | 交互细节、权限边界、真实数据 |
| 修 Bug | 复现报错、定位根因、做小范围修复、跑回归 | 线上影响、临时方案是否可接受 |
| 生成测试 | 找风险点、补单元测试或集成测试、运行测试命令 | 断言是否覆盖真实业务分支 |
| 改网站 | 调整页面结构、内容、内链、移动端体验和构建问题 | 品牌语气、SEO 关键词、转化入口 |
| Git 交付 | 总结 diff、准备 commit、推送分支、整理 PR 描述 | 提交范围、敏感信息、发布窗口 |
Codex 工作流图
Section titled “Codex 工作流图”开始前准备什么
Section titled “开始前准备什么”| 准备项 | 建议写给 Codex 的信息 |
|---|---|
| 仓库目录 | 当前项目在哪,是否有多个包、多个应用或多个语言栈 |
| 任务目标 | 用户能看到什么变化,或者哪个报错应该消失 |
| 关键文件 | 入口文件、路由、组件、测试、配置、接口说明 |
| 边界 | 哪些文件不能碰,哪些行为不能做,哪些内容不能编造 |
| 验证命令 | npm run build、npm test、pytest、go test ./... 等 |
| 密钥规则 | 只使用环境变量名和示例值,不把真实 Key 写入代码或日志 |
任务怎么写更稳
Section titled “任务怎么写更稳”把需求写成“目标、上下文、约束、验证、交付证据”会明显降低返工。一个可复用模板如下:
Goal:把 /pricing 页面里的套餐说明改成更清晰的对比表,并保持现有视觉风格。
Context:项目是 Astro 站点。相关文件可能在 src/content/docs、src/components 和 src/styles。
Constraints:不要改动真实价格、模型名和支付逻辑。不要提交密钥。中文文案要像人工编辑写的说明。
Verification:运行 npm run build,并检查移动端页面没有横向溢出。
Done when:说明改完,构建通过,给出修改文件、验证结果和还需要人工复核的点。模板里的 Verification 不只是形式。对网站任务,它可以是构建通过、浏览器截图、移动端无横向滚动、关键链接可点击;对后端任务,它可以是单元测试、接口最小请求、日志脱敏和失败分支覆盖。验证写得越具体,Codex 越容易把“看起来完成”推进到“可以交付”。如果验证命令耗时很长,可以要求它先跑局部测试,再说明完整测试由谁在什么环境执行,哪些风险保留给人工复核,并记录原因。
| 任务 | 教程 | 验收方式 |
|---|---|---|
| 快速上手 | Codex CLI 快速开始 | 能打开项目、说明目标、完成一次小改动 |
| 接入 OfApp.cn | Codex CLI 接入 OfApp.cn | Base URL、Key 和可用模型均以控制台或官方文档为准 |
| 写清任务 | Codex Goal 提示词模板 | 范围清楚、验证明确、完成证据充分 |
| 本地项目 | Codex 本地项目使用指南 | 工作目录、AGENTS.md、范围和验证可追踪 |
| 写代码 | 用 Codex 写代码 | diff 聚焦、lint 和测试通过 |
| 修 Bug | 用 Codex 修 Bug | 有复现、有根因、有回归验证 |
| 生成测试 | 用 Codex 生成测试 | 覆盖风险分支,不只追求覆盖率数字 |
| 改网站 | Codex 建站指南 | 本地预览、截图检查、构建通过 |
| Git 交付 | Codex 如何完成 Git 提交和推送 | diff 清晰、commit 信息准确、PR 描述可读 |
| 生成 README | 用 Codex 生成 README | 安装、运行、环境变量和脚本说明完整 |
| 配置 Docker | 用 Codex 写 Dockerfile | 镜像能构建,运行命令和健康检查明确 |
| 排查报错 | Codex 常见报错与解决 | 日志脱敏、最小复现、定位路径清楚 |
| 编程工作流 | AI 编程工作流 | 从需求到验证形成固定流程 |
AGENTS.md 和项目规范
Section titled “AGENTS.md 和项目规范”AGENTS.md 是给 Codex 的项目说明书,适合存放长期有效的约束:目录结构、常用命令、代码风格、测试要求、文案边界、提交规则和安全提醒。它不应该写成一次性任务清单,也不应该放真实密钥、内部账号、客户数据或临时口令。
如果仓库很大,可以在根目录写全局规则,在子目录写更细的规则。Codex 处理文件时应遵守离目标文件最近的说明,所以团队可以把前端、后端、文档和脚本的规则拆开维护。
安全边界和权限
Section titled “安全边界和权限”| 场景 | 建议边界 |
|---|---|
| 只想让 Codex 读项目 | 让它先扫描、解释结构和提出计划,不做文件修改 |
| 允许改当前仓库 | 明确可改目录、禁止目录和验证命令,结束后检查 git diff |
| 需要联网查资料 | 只查询公开文档,不把 Key、客户数据和私有日志发出去 |
| 涉及生产部署 | 让 Codex 准备脚本、说明风险和回滚步骤,由人执行关键操作 |
| 涉及 API Key | 使用 .env.example、部署平台 Secret 或本机环境变量,示例统一写成假值 |
什么时候接入 OfApp.cn
Section titled “什么时候接入 OfApp.cn”Codex 本身的价值在于把任务执行到可验证状态;OfApp.cn 更适合出现在“需要统一 API 入口”的环节。例如你希望同一个团队在 Codex、SDK 示例、网页工具、自动化脚本和内部演示里使用一致的 Base URL 与 Key 管理方式,就可以阅读 Codex CLI 接入 OfApp.cn 和 OpenAI 兼容 API 快速调用。
OfApp.cn 官方页面提供网页入口、API 文档和天才游乐场等使用入口。涉及模型、价格、套餐、额度、可用地区和具体能力时,请以 OfApp.cn 控制台或官方文档为准。
示例:让 Codex 修一个前端页面
Section titled “示例:让 Codex 修一个前端页面”| 阶段 | 可以这样要求 |
|---|---|
| 描述问题 | “移动端 /office/ 页面目录太长,正文被挤压,请检查布局并提出修复计划。” |
| 限定范围 | “只改当前页面和必要样式,不重构导航,不调整无关页面。” |
| 要求验证 | “运行构建,用浏览器检查 390px 宽度,没有横向滚动。” |
| 交付结果 | “列出修改文件、截图位置、验证命令和仍需人工确认的内容。” |
git diff是否只包含本次任务相关文件。- 文案、价格、模型和能力是否都能从可信来源确认。
- 构建、测试、lint 或页面检查是否真的运行过。
- 真实 Key、日志、截图、数据库内容是否已脱敏。
- 移动端、暗色模式、链接、可访问性和加载速度是否有明显问题。
- 交付说明是否包含修改范围、验证结果和风险提示。
Codex 和普通聊天有什么区别?
Section titled “Codex 和普通聊天有什么区别?”普通聊天主要给建议和代码片段;Codex 更接近代码代理,可以在本地项目里读文件、改文件、执行命令、根据报错继续修复,并把验证结果写回交付说明。
Codex 会不会改到无关文件?
Section titled “Codex 会不会改到无关文件?”会有这个风险,所以任务里要写清范围、禁区和验证方式。结束后必须看 git diff,尤其留意格式化、依赖锁文件、配置文件和自动生成文件。
什么时候应该用 Plan 或 Goal?
Section titled “什么时候应该用 Plan 或 Goal?”任务跨多个文件、需要多轮验证、需要长期推进时适合用 Goal;需要先讨论方向、比较方案或限制修改范围时适合让 Codex 先给计划,再进入执行。
AGENTS.md 应该写多长?
Section titled “AGENTS.md 应该写多长?”写到“新加入的人能少问几个基础问题”为止。常用命令、目录说明、代码风格和安全边界值得写;一次性需求、临时想法和真实凭据不适合写进去。
Codex 需要知道真实 API Key 吗?
Section titled “Codex 需要知道真实 API Key 吗?”通常不需要。让它知道环境变量名、示例值和加载方式就够了。真实 Key 应放在本机环境、.env、部署平台 Secret 或控制台里,代码和文档只保留假值。
可以让 Codex 直接提交和推送吗?
Section titled “可以让 Codex 直接提交和推送吗?”可以,但建议把权限放在任务末尾。先让它完成修改、运行验证、解释 diff,再由人确认是否 stage、commit 和 push。涉及生产分支时更要保留人工确认。
任务很大时怎么拆?
Section titled “任务很大时怎么拆?”按“能独立验证”的结果拆。比如网站迭代可以拆成内容重写、组件优化、内链更新、结构化数据、移动端 QA 和构建修复,每一步都要有明确完成证据。
- Codex CLI 接入 OfApp.cn:配置统一 API 入口。
- Codex Goal 提示词模板:把任务写清目标、范围、验证和完成审计。
- Codex 本地项目使用指南:控制工作目录、指令文件、任务范围和验证命令。
- 用 Codex 写代码:把需求落成可验证代码改动。
- 用 Codex 修 Bug:整理复现、定位根因和回归测试。
- 用 Codex 生成测试:补齐项目里的关键测试。
- Codex 建站指南:完成前端迭代和浏览器验证。
- Codex 如何完成 Git 提交和推送:交付变更。
- AI 编程工作流:把 AI 写代码变成团队流程。
Codex 的核心不是“让 AI 多写代码”,而是把目标、上下文、边界、验证和复核串成一个闭环。需要 API 能力时,再把 OfApp.cn 作为统一入口接入 Codex、SDK、脚本和网页工具;无法确认的模型、价格和能力,都回到 OfApp.cn 控制台或官方文档复核。