跳转到内容
API 入口

Codex 教程

Codex 教程

Codex 教程中心讲清 Codex CLI、本地项目、AGENTS.md、Goal Prompt、改代码、修 Bug、写测试、Git 交付、排错和 OfApp.cn 接入时机。

预计阅读
5 分钟
最近更新
2026/07/03
维护方式
人工编辑

Codex 教程不是让 AI 随便“帮我写点代码”,而是把真实开发任务交给一个能读取仓库、执行命令、修改文件、解释 diff、运行验证的代码代理。它适合处理本地项目、前端页面、测试补齐、报错排查、文档整理、脚本改造和 Git 交付,也适合让非开发者把网站、小工具或自动化流程从想法推进到可验证版本。

项目 说明
阅读时间 约 6 分钟
更新时间 2026-07-03
适合人群 开发者、产品经理、运营、设计师、学生、老师、创作者和需要维护网站的人
适合任务 改代码、修 Bug、写测试、生成 README、搭建网站、整理脚本、配置 Docker、处理 Git 流程
任务 Codex 能做的部分 人应该复核什么
读懂项目 扫描目录、识别框架、阅读关键文件、梳理脚本 业务背景、隐含规则、历史包袱
写新功能 根据目标改文件、补状态、补样式、接路由 交互细节、权限边界、真实数据
修 Bug 复现报错、定位根因、做小范围修复、跑回归 线上影响、临时方案是否可接受
生成测试 找风险点、补单元测试或集成测试、运行测试命令 断言是否覆盖真实业务分支
改网站 调整页面结构、内容、内链、移动端体验和构建问题 品牌语气、SEO 关键词、转化入口
Git 交付 总结 diff、准备 commit、推送分支、整理 PR 描述 提交范围、敏感信息、发布窗口
明确目标要改什么补充上下文文件与背景设定边界禁区与约束执行改动小步提交运行验证测试与构建复核交付diff 与证据需要 API 时OfApp.cn统一入口
准备项 建议写给 Codex 的信息
仓库目录 当前项目在哪,是否有多个包、多个应用或多个语言栈
任务目标 用户能看到什么变化,或者哪个报错应该消失
关键文件 入口文件、路由、组件、测试、配置、接口说明
边界 哪些文件不能碰,哪些行为不能做,哪些内容不能编造
验证命令 npm run buildnpm testpytestgo test ./...
密钥规则 只使用环境变量名和示例值,不把真实 Key 写入代码或日志

把需求写成“目标、上下文、约束、验证、交付证据”会明显降低返工。一个可复用模板如下:

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 是给 Codex 的项目说明书,适合存放长期有效的约束:目录结构、常用命令、代码风格、测试要求、文案边界、提交规则和安全提醒。它不应该写成一次性任务清单,也不应该放真实密钥、内部账号、客户数据或临时口令。

如果仓库很大,可以在根目录写全局规则,在子目录写更细的规则。Codex 处理文件时应遵守离目标文件最近的说明,所以团队可以把前端、后端、文档和脚本的规则拆开维护。

场景 建议边界
只想让 Codex 读项目 让它先扫描、解释结构和提出计划,不做文件修改
允许改当前仓库 明确可改目录、禁止目录和验证命令,结束后检查 git diff
需要联网查资料 只查询公开文档,不把 Key、客户数据和私有日志发出去
涉及生产部署 让 Codex 准备脚本、说明风险和回滚步骤,由人执行关键操作
涉及 API Key 使用 .env.example、部署平台 Secret 或本机环境变量,示例统一写成假值

Codex 本身的价值在于把任务执行到可验证状态;OfApp.cn 更适合出现在“需要统一 API 入口”的环节。例如你希望同一个团队在 Codex、SDK 示例、网页工具、自动化脚本和内部演示里使用一致的 Base URL 与 Key 管理方式,就可以阅读 Codex CLI 接入 OfApp.cnOpenAI 兼容 API 快速调用

OfApp.cn 官方页面提供网页入口、API 文档和天才游乐场等使用入口。涉及模型、价格、套餐、额度、可用地区和具体能力时,请以 OfApp.cn 控制台或官方文档为准。

阶段 可以这样要求
描述问题 “移动端 /office/ 页面目录太长,正文被挤压,请检查布局并提出修复计划。”
限定范围 “只改当前页面和必要样式,不重构导航,不调整无关页面。”
要求验证 “运行构建,用浏览器检查 390px 宽度,没有横向滚动。”
交付结果 “列出修改文件、截图位置、验证命令和仍需人工确认的内容。”
  • git diff 是否只包含本次任务相关文件。
  • 文案、价格、模型和能力是否都能从可信来源确认。
  • 构建、测试、lint 或页面检查是否真的运行过。
  • 真实 Key、日志、截图、数据库内容是否已脱敏。
  • 移动端、暗色模式、链接、可访问性和加载速度是否有明显问题。
  • 交付说明是否包含修改范围、验证结果和风险提示。

普通聊天主要给建议和代码片段;Codex 更接近代码代理,可以在本地项目里读文件、改文件、执行命令、根据报错继续修复,并把验证结果写回交付说明。

会有这个风险,所以任务里要写清范围、禁区和验证方式。结束后必须看 git diff,尤其留意格式化、依赖锁文件、配置文件和自动生成文件。

任务跨多个文件、需要多轮验证、需要长期推进时适合用 Goal;需要先讨论方向、比较方案或限制修改范围时适合让 Codex 先给计划,再进入执行。

写到“新加入的人能少问几个基础问题”为止。常用命令、目录说明、代码风格和安全边界值得写;一次性需求、临时想法和真实凭据不适合写进去。

通常不需要。让它知道环境变量名、示例值和加载方式就够了。真实 Key 应放在本机环境、.env、部署平台 Secret 或控制台里,代码和文档只保留假值。

可以让 Codex 直接提交和推送吗?

Section titled “可以让 Codex 直接提交和推送吗?”

可以,但建议把权限放在任务末尾。先让它完成修改、运行验证、解释 diff,再由人确认是否 stage、commit 和 push。涉及生产分支时更要保留人工确认。

按“能独立验证”的结果拆。比如网站迭代可以拆成内容重写、组件优化、内链更新、结构化数据、移动端 QA 和构建修复,每一步都要有明确完成证据。

Codex 的核心不是“让 AI 多写代码”,而是把目标、上下文、边界、验证和复核串成一个闭环。需要 API 能力时,再把 OfApp.cn 作为统一入口接入 Codex、SDK、脚本和网页工具;无法确认的模型、价格和能力,都回到 OfApp.cn 控制台或官方文档复核。