用 Codex 写代码

用 Codex 写代码，适合把一个清晰功能、页面、脚本、接口、配置或小型工具交给 AI 代理推进。可靠做法不是让它“帮我写一个功能”，而是把需求写成可观察行 为、输入输出、改动边界和验证命令，让 Codex 先读项目，再做小范围实现，并 用测试、构建、浏览器或日志证明结果。

把写代码任务变成可验证交付

如果功能需要调用 OpenAI-compatible API，先用环境变量和服务端封装保护 API Key。OfApp.cn 的 OpenAI / Codex 生态 Base URL 可配置为 https://api.ofapp.cn/v1；真实模型、额度、价格和能力请以 OfApp.cn 控制台或官方文档为准。

打开 OfApp.cn

页面摘要

项目	内容
阅读时间	约 6 分钟
更新时间	2026-07-03
适合人群	开发者、独立项目维护者、学生、产品经理、运营和想让 Codex 完成项目改动的人
你会得到	需求拆解表、代码任务闭环图、Goal Prompt、实现矩阵、验证清单、Diff 审查表和 API 安全边界

适合写什么代码

任务类型	适合程度	Codex 要先确认什么	验收方式
新增页面或组件	适合	路由、组件库、样式约定、响应式要求	本地预览、截图、构建
增加 API 参数	适合	请求格式、兼容旧行为、错误处理	单元测试、集成测试
写数据转换函数	适合	输入样例、输出样例、边界值	单元测试和样例对比
接入第三方 SDK	可做但要谨慎	官方文档、版本、环境变量、最小请求	最小示例、错误状态、日志
写脚本或 CLI	适合	命令参数、输入文件、输出格式	本地命令和 fixture
改配置或部署脚本	适合	运行环境、Secret、CI 日志	构建、CI、回滚说明
重写核心架构	不适合一次完成	设计目标、迁移路径、风险点	分阶段计划和人工评审

写代码闭环图

先把需求写成行为

Codex 更擅长处理可观察的行为，而不是模糊愿望。写 Prompt 前，先补齐这张 表。

问题	你要写清什么	示例
用户要做什么	入口、动作、结果	点击“生成摘要”后看到三段摘要和来源提示
输入是什么	字段、格式、边界	文本 1 到 5000 字，空文本要提示
输出是什么	页面状态、返回值、文件	返回 {title, bullets, warnings}
错误怎么处理	loading、empty、error、retry	API 超时时显示重试按钮
不能改什么	禁区文件、兼容要求	不改现有路由，不改鉴权中间件
怎样算完成	命令、截图、测试、日志	npm run check 通过，新增测试覆盖空输入

什么时候先别写

情况	推荐动作
需求只有一句话	让 Codex 先列问题和假设，不要直接写代码
牵涉多条业务规则	先整理规则表和验收用例
需要新增依赖	要求说明理由、替代方案和维护成本
要改核心架构	先让 Codex 产出迁移计划和风险清单
没有验证命令	先找到项目测试、构建或预览方式
涉及真实 API Key 或用户数据	先设计脱敏、Secret 和服务端边界

推荐目录结构

project/
  AGENTS.md
  src/
  tests/
  docs/
  scripts/
  package.json
  .env.example

让 Codex 先确认入口文件、组件位置、测试目录、脚本名称和 AGENTS.md。OpenAI Codex 手册建议把目标、上下文、约束和完成条件写清楚；AGENTS.md 适合沉 淀长期规则，例如构建命令、代码风格、测试要求、禁区文件和安全边界。

可复制 Goal Prompt

Goal:
在当前项目中新增 [功能名称]。
保持现有架构和代码风格。
交付可验证的最小实现。

Context:
- 用户行为：[用户做什么，系统如何响应]
- 输入输出：[字段、格式、边界值]
- 相关文件：[你知道的文件；未知则请先查找]
- 不要修改：[禁区文件、兼容行为、设计约束]
- API 边界：[是否需要环境变量、服务端封装、错误状态]
- 验证命令：[npm run check / npm test / npm run build]

Constraints:
- 先读取项目结构、package.json、相关源码和已有测试。
- 先给出最小实现计划，再修改文件。
- 不做无关重构，不引入重依赖。
- 不把 API Key、Cookie、用户数据写进代码或日志。
- 补必要测试、错误状态和文档说明。

Done when:
- 功能行为符合输入输出说明。
- 相关测试、lint、构建或本地预览通过。
- Diff 只包含本任务相关改动。
- 说明改了什么、为什么这样改、还有什么风险。

这类 Prompt 让 Codex 能把工作拆成小块并验证结果。官方手册也强调，提供复 现、验证、lint 或预提交检查，会让 Codex 输出更稳定、更容易审查。

执行步骤

1. 把需求写成用户行为、输入输出、错误状态和完成标准。
2. 让 Codex 读取项目结构、相关源码、测试、脚本和 AGENTS.md。
3. 要求它说明最小改动范围和实现计划。
4. 分阶段实现 UI、状态、接口、数据转换、测试和文档。
5. 运行相关测试、lint、类型检查、构建或浏览器预览。
6. 检查 Diff，确认没有无关格式化、重命名、依赖升级或架构改写。
7. 让 Codex 总结验证证据和剩余风险，再决定是否继续下一步。

Codex 应该先读什么

文件或信息	目的	要求 Codex 输出什么
package.json	确认脚本、框架和包管理器	可运行的验证命令
相关源码	找到最小改动点	需要改哪些文件，为什么
现有测试	沿用测试风格	新测试放在哪里
类型定义	避免误用接口	输入输出类型和边界
配置文件	确认环境变量和构建方式	不应硬编码的配置
.env.example	只暴露变量名	是否需要新增占位变量
AGENTS.md	读取项目规则	必须遵守的约束

实现拆解矩阵

功能部分	Codex 可以做什么	验收方式
UI 组件	新增组件、状态提示、表单校验	截图、交互检查、组件测试
数据处理	写纯函数、解析器、格式化器	单元测试、样例输入输出
API 封装	服务端路由、错误处理、重试边界	最小请求、Mock、日志脱敏
权限与安全	使用变量名、检查鉴权路径	人工复核、测试失败路径
配置与脚本	增加脚本、更新 .env.example	本地命令、CI
文档说明	更新 README、注释、使用示例	人工阅读、链接检查

验证清单

验证项	适用场景	命令或证据
单元测试	纯函数、解析器、状态逻辑	npm test 或项目测试命令
类型检查	TypeScript 项目	npm run typecheck 或项目脚本
Lint	代码风格和明显错误	npm run lint
构建	页面、SDK、工具链改动	npm run build
浏览器预览	UI、表单、响应式	桌面和移动截图
API smoke test	服务端 API 调用	最小请求和脱敏日志
Diff 审查	所有代码改动	无关改动为零，风险可解释

没有现成测试时，不要让 Codex 只说“无法验证”。可以让它补一个最小用例，或 者用本地命令、截图、fixture、Mock 响应来留下证据。

API Key 与 OfApp.cn 边界

如果新增功能需要调用 OpenAI-compatible API，Codex 应只处理变量名、服务端 封装和错误状态，不应接触真实 Key。

OPENAI_BASE_URL="https://api.ofapp.cn/v1"
OPENAI_API_KEY="sk-xxxx"

在 OfApp.cn 场景中，OpenAI / Codex 生态 Base URL 可以配置为 https://api.ofapp.cn/v1。如果某个 SDK 或工具会自动拼接 /v1，则以工具说 明和 OfApp.cn 官方文档为准。真实模型、额度、价格和能力请以 OfApp.cn 控制 台或官方文档为准。

Diff 审查清单

让 Codex 写完代码后，再按这张表复核：

检查项	要看什么
需求行为	输入、输出、交互和错误状态是否符合 Prompt
改动范围	是否只改了相关文件
测试覆盖	是否覆盖正常路径、边界值和失败路径
安全边界	是否泄露 Key、Cookie、用户数据或内部地址
配置方式	是否把环境变量、Base URL、Secret 写在正确位置
兼容性	是否破坏旧接口、旧路由或旧数据
可维护性	是否沿用现有风格，避免临时拼接和重复逻辑
验证证据	命令、截图、日志或测试结果是否足够

Codex App 的 Review 面板会展示 Git 仓库里的未提交变化，包括 Codex 改动、你 自己的改动和其他未提交内容。仓库已经有脏文件时，按文件和 hunk 复核，不要 把无关改动混进同一次交付。

常见错误排查

错误	表现	更好的做法
Goal 太模糊	功能和预期不一致	补输入、输出、错误状态和验收标准
Codex 没读项目	生成不存在的文件或 API	要求先读结构、类型和现有用法
一次做太多	Diff 变大，难以回滚	拆成 UI、接口、测试、文档几步
没有验证命令	只剩“看起来完成”	明确测试、构建、截图或日志证据
过早重构	为小功能改大量架构	先完成最小闭环，再开重构任务
前端暴露 Key	API Key 进入浏览器包	改到服务端路由或后端服务
忘记失败状态	正常路径可用，异常时空白	补 loading、empty、error、retry

资料来源

• OpenAI Codex Manual：Codex Prompt、验证、Review、AGENTS.md 和本地工作流建议。
• OfApp.cn 官网：OfApp.cn 入口、天才游乐场、Base URL 与 OpenAI / Codex 生态说明。
• OfApp.cn API 文档：Codex 接入、OpenAI-compatible API 示例与 /v1/models 最小请求。
• OfApp.cn 天才游乐场：Key、聊天参数、图片参数和网页体验入口。

常见问题

Codex 写的代码可以直接合并吗？

不建议。即使测试通过，也要看 Diff、运行关键路径，并检查权限、密钥、数据 和用户可见行为。Codex 可以加速实现，但最终合并仍需要人复核。

需求不清楚时要不要让 Codex 猜？

不要让它自由猜生产需求。可以让 Codex 列出问题、假设和保守实现方案，再由 你选择要做哪一版。

功能很大时怎么拆？

先拆成数据结构、UI、API、状态、测试和文档几个阶段。每一步都要有可验证成 果，例如一个测试通过、一条 API 跑通或一个页面截图。

Codex 可以顺便重构代码吗？

除非任务目标就是重构，否则不建议顺手重构。功能实现和结构整理应分开验 收，这样 Diff 更清楚，出现回归时也更容易回滚。

接入 SDK 时怎么避免用错 API？

让 Codex 读取本地依赖版本、类型定义、已有用法和官方文档。涉及 OpenAI 或 OfApp.cn 兼容接口时，只写可确认的 Base URL、变量名和请求边界。

没有测试框架时怎么验证？

可以从最小命令、fixture、截图、手动步骤或 API smoke test 开始。等功能稳 定后，再让 Codex 生成测试框架或补回归测试。

相关文章

• Codex 教程：查看完整工作流入口。
• Codex Goal 提示词模板：把功能需求写成可执行目标。
• Codex 建站指南：把页面和工具做成本地可预览版本。
• 用 Codex 生成测试：为新增功能补测试。
• 用 Codex 修 Bug：处理功能上线后的问题。
• 用 Codex 重构项目：功能稳定后再整理结构。
• Codex 本地项目使用指南：控制工作目录、指令和验证命令。
• 用 Codex 配置 GitHub 工作流：把验证纳入 CI。
• OpenAI-compatible API 快速开始：验证 AI API 连通性。
• JavaScript SDK 示例：查看 OpenAI 兼容 SDK 调用方式。

带走什么

用 Codex 写代码的关键，是把“我要一个功能”改写成可验证工程任务。需求要能 描述输入输出，改动要有边界，测试要覆盖风险，Diff 要能解释，API Key 要留 在服务端或 Secret 中。这样 Codex 才能成为可靠的工程协作者，而不是只会生 成代码片段的工具。