Codex Goal 提示词模板

Codex Goal 提示词不是普通聊天开场白，而是给 AI 代理的一份可执行任务书。它 要让 Codex 知道目标是什么、哪些文件能改、哪些事情不能碰、用什么命令证明 完成，以及在信息不足时怎样停下来说明风险。

OpenAI Codex 手册把 Goal mode 描述为适合较长任务的持续目标机制。对真实仓 库来说，这意味着“做完了”不能只靠口头判断，而要靠当前证据：diff、测试、 构建、截图、日志或人工仍需确认的事项。

把 Codex 任务写成可验证目标

如果任务涉及 OpenAI-compatible API，可以把 OfApp.cn 作为统一入口，让 Codex 只处理 Base URL、环境变量示例和服务端封装。真实 Key、模型、能力、额度和价格请以 OfApp.cn 控制台或官方文档为准。

查看接入说明

页面摘要

项目	说明
阅读时间	约 7 分钟
更新时间	2026-07-03
适合读者	开发者、产品经理、运营、内容团队、学生、AI 初学者
核心收益	把一句模糊需求改写成 Codex 能持续执行、能验证、能收尾的目标
你会得到	Goal 适用度矩阵、通用模板、功能/修 Bug/API/SEO 模板、完成审计和阻塞写法
边界提醒	真实 API Key、模型、额度、价格和外部账号权限不要写进 Goal；请以 OfApp.cn 控制台或官方文档为准

Goal Prompt 是什么

Goal Prompt 是把一句“帮我做一下”改成能执行、能验证、能收尾的任务说明。 它通常包含背景、范围、成功标准、验证命令、敏感信息边界和交付格式。

普通 Prompt	Goal Prompt
适合问概念、改一句文案、生成思路	适合交给 Codex 处理真实仓库任务
容易缺少范围和验收方式	明确可改文件、禁区、验证和输出
回答结束就结束	需要用证据判断任务是否完成
用户常常要反复追问	Codex 可按目标持续推进并记录阻塞点

一个好的 Goal 不追求长，而追求可执行。越接近真实交付，越需要把“成功是什 么”和“怎样证明成功”写清楚。

Goal 工作流结构图

什么时候用 Goal

场景	推荐写法	验证证据
新增功能	用户故事、页面状态、数据流、错误态	测试、截图、本地预览
修 Bug	复现步骤、日志、预期行为、最小修复	回归测试、失败命令消失
生成测试	风险点、测试框架、覆盖范围	新测试通过、旧测试不退化
文档改写	读者、搜索主题、内链、禁用说法	构建通过、链接有效、摘要清楚
API 接入	Base URL、环境变量、服务端边界	最小请求成功、密钥不入库
长期网站迭代	本轮目标、质量门槛、扫描与验证	构建、SEO/GEO 检查、浏览器 QA

不适合放进一个 Goal 的任务也很常见：同时重构架构、改 UI、接支付、迁移数据 和写发布稿。遇到这种情况，应拆成几个能单独验证的小目标。

Goal 适用度矩阵

不是所有请求都需要 Goal。判断标准不是任务听起来大不大，而是它是否需要跨多 步执行、跨文件改动、持续验证和明确完成证据。

请求类型	是否适合 Goal	原因	更好的写法
“解释这个函数做什么”	不一定	主要是阅读和回答，不需要持续执行	普通 Prompt，附上文件路径或代码片段
“修复这个 Bug 并补回归测试”	适合	需要复现、定位、修改、验证	写清复现步骤、预期行为和测试命令
“把网站持续建设成知识门户”	适合	目标长期存在，每轮都要扫描、选择、验证	写清最终方向和每轮必须执行的检查
“顺手把 UI 也重做一下”	不适合直接写成一个 Goal	范围太宽，验收模糊	拆成视觉审计、组件改造、浏览器 QA
“接入 API 并部署上线”	只适合拆分后使用	涉及代码、密钥、环境和外部平台	分成服务端封装、环境变量、验证、部署
“生成一组文章选题”	不一定	更像一次性创意任务	普通 Prompt，要求输出表格和筛选标准

好 Goal 的 6 个要素

要素	要写清什么	示例
目标	本轮只完成一件事	修复移动端导航无法展开
背景	为什么要做、谁会使用	面向手机用户阅读教程页
范围	可以检查和修改的文件	src/components/Header.astro
禁区	不应触碰的模块和行为	不改路由、不改登录逻辑
验证	证明完成的命令或操作	npm run check，390px 截图
交付	结束时要汇报什么	改动、验证结果、剩余风险

如果目标涉及 OfApp.cn，只写已经确认的信息。模型名、价格、额度、套餐和能力 不要猜；无法确认时写“请以 OfApp.cn 控制台或官方文档为准”。

Goal、AGENTS.md 和普通 Prompt 怎么分工

OpenAI Codex 文档建议用 AGENTS.md 承载可复用的仓库规则，用 Prompt 或 Goal 承载本次任务。分清这三层，可以避免把长期规范塞进一次性请求，也避免每次都 重复说明相同工程习惯。

形式	放什么	不该放什么	例子
普通 Prompt	一次性问题、解释、短改动、方案比较	长期仓库规则和大范围执行目标	“解释这个组件为什么会重渲染”
Goal Prompt	本轮要完成的目标、成功标准、验证命令、完成证据	会变化的密钥、账号权限、不可验证愿望	“修复登录跳转，并用测试和截图证明”
AGENTS.md	仓库约定、测试命令、风格、禁区、安全要求	临时需求、一次性业务判断、真实凭据	“改前先看 Git 状态，改后运行 build”
Skill 或模板	可复用的专项流程、检查清单、脚本路径	只服务单次任务的细节	“每次做前端 QA 都走桌面和移动截图”

通用模板

Goal: 在当前项目中完成 [一句话目标]。

背景：
- [用户、业务或技术背景]
- [为什么现在要做]

范围：
- 可以检查：[文件、目录、配置、日志]
- 可以修改：[文件或模块]
- 不要修改：[禁区、兼容边界、生产数据、密钥文件]

成功标准：
- [用户能看到或完成什么]
- [错误态、空状态、边界情况]
- [文档、测试或截图要求]

验证：
- 运行：[npm run check / npm test / pytest / 其他命令]
- 需要浏览器检查：[桌面视口、移动端视口、关键交互]
- 如果无法验证，请说明原因和剩余风险。

交付格式：
- 改了哪些文件
- 验证命令和结果
- 未验证项或需要人工确认的事项

这段模板适合改代码、改文档、整理配置和修构建。真正使用时，把方括号换成项 目里的真实路径和命令。

功能实现模板

Goal: 为 [页面/组件/接口] 新增 [功能名称]，保持现有架构和代码风格。

请先只读项目：
- 查看相关源码、测试、配置和已有组件。
- 找出最小改动范围。
- 给出实现计划，再开始编辑。

功能要求：
- 用户行为：[用户点击、输入、提交或查看什么]
- 状态：[loading / empty / error / success]
- 兼容：[桌面、移动端、深色模式、无障碍]

边界：
- 不引入重依赖。
- 不重写无关模块。
- 不读取或输出真实密钥、Cookie、用户隐私。

验证：
- [测试命令]
- [构建命令]
- [需要截图或手动检查的路径]

适合需求很大的功能时，可以把 Goal 拆成“数据层”“UI 层”“测试层”“文档层”几 个连续目标。

修 Bug 模板

Goal: 修复 [Bug 标题]，并补充能防止复发的验证。

复现步骤：
1. [操作或命令]
2. [操作或命令]

实际结果：
[错误信息、截图描述、状态码、失败日志，注意脱敏]

预期结果：
[正确行为]

要求：
- 先定位根因，再做最小修复。
- 不通过删除功能、跳过测试或吞掉错误来绕过问题。
- 如果日志不足，请列出还需要什么信息。

验证：
- 复现命令不再失败。
- 回归测试通过。
- 说明这次修复覆盖了哪个路径，哪些路径仍需人工确认。

修 Bug 的 Goal 重点是复现与回归。没有复现步骤时，可以先让 Codex 做“排查目 标”，不要直接让它改代码。

API 接入模板

Goal: 为当前服务端项目接入 OpenAI-compatible API 调用。

要求：
- API Key 只从环境变量读取，例如 OPENAI_API_KEY。
- Base URL 只从环境变量读取，例如 OPENAI_BASE_URL。
- 模型名只从环境变量读取，例如 OPENAI_MODEL。
- 不要在前端代码、日志、README 真实示例或测试快照里暴露密钥。
- 添加超时、错误处理和脱敏日志。

OfApp.cn 示例：
- OPENAI_BASE_URL=https://api.ofapp.cn/v1
- OPENAI_API_KEY=sk-xxxx
- OPENAI_MODEL=以控制台可用模型为准

验证：
- 提供最小请求示例。
- 说明 401、403、429、5xx 时的排查入口。
- 具体可用模型、能力和价格请以 OfApp.cn 控制台或官方文档为准。

如果项目已经有 SDK 封装，Goal 里应要求 Codex 复用现有客户端，不要另起一套 请求层。可参考 OpenAI 兼容 API 快速调用 和 获取 API Key。

文档与 SEO 模板

Goal: 优化 [页面路径]，让它围绕 [搜索主题] 成为可收藏的中文教程页。

读者：
- [开发者 / 运营 / 学生 / 老师 / AI 初学者 / 内容创作者]

内容要求：
- 有摘要、目录感、阅读时间、更新时间。
- 解释定义、适用场景、步骤、案例、注意事项和 FAQ。
- 使用图表或流程图帮助理解。
- 内链到相关教程，不堆无关链接。
- OfApp.cn 入口要自然出现，不能写空洞广告。

SEO/GEO 要求：
- 标题和描述围绕一个明确主题。
- FAQ 问题使用真实搜索问法。
- 适合 AI 检索、摘要和引用。
- 不编造 OfApp.cn 的模型、价格、套餐、能力或数据。

验证：
- 运行内容校验和站点构建。
- 检查 canonical、Open Graph、Article Schema、FAQ Schema。
- 用桌面和移动端视口检查可读性。

这个模板适合文档站、知识库和内容团队。它不要求页面变长，而要求页面能回答 真实问题。

长期网站迭代模板

Goal: 持续迭代当前 Astro 网站，使它更适合作为中文 AI 生产力知识库获得 SEO
和 GEO 流量，并自然引导到 https://api.ofapp.cn。

本轮请执行：
- 重新扫描站点，找出内容薄弱、SEO 较差、阅读体验较差的页面。
- 优先优化已有内容，只有在主题确实缺失时才新增页面。
- 选定一个高价值页面后，补齐摘要、结构、流程图、案例、FAQ、相关推荐和 CTA。
- 检查内链、导航、Tag、RSS、robots、canonical、Open Graph、Schema.org 和 JSON-LD。
- 检查移动端、无障碍、页面速度和构建结果。
- 运行 npm run build 或仓库约定的完整检查命令。

边界：
- 不把网站做成 API 文档站。
- 不批量生成低质量文章。
- 不复制、洗稿或拼接外部内容。
- 涉及 OfApp.cn 的能力、模型、价格、额度和套餐时，以控制台或官方文档为准。

长期 Goal 的价值在于让 Codex 记住方向：每轮不是重开项目，而是在已有内容、 结构和质量门槛上继续推进。

完成审计怎么写

Codex 标记完成前，应能回答“我凭什么认为完成了”。这不是形式，而是降低漏验 和误报的关键。

审计项	要看什么	合格例子
目标覆盖	Goal 中的成功标准是否都处理	页面补齐 FAQ、图表、内链和 CTA
证据	是否有命令、截图、日志或 diff 支撑	npm run check 通过，浏览器截图正常
范围	是否只改了相关文件	只改目标页、入口页和 AI 摘要
风险	是否说明无法验证的部分	外部控制台信息需用户复核
交付	用户能否快速知道结果	摘要、文件、验证和截图清楚

可复制审计格式：

完成审计：
- 目标覆盖：[逐条对应 Goal 的成功标准]
- 改动范围：[文件列表和为什么改]
- 验证证据：[命令、截图、浏览器检查、日志]
- 未验证项：[没有则写“无”；有则说明原因]
- 需要人工确认：[业务判断、上线时机、外部控制台信息]

如果证据不足，就不应把任务说成完成。更好的做法是继续验证，或明确写出阻塞 原因。

阻塞判断怎么写

阻塞不是“任务有点难”，而是当前环境缺少必要信息或外部状态，继续做会变成猜 测。常见阻塞包括：没有复现材料、缺少账号权限、外部服务不可访问、依赖命令 持续失败且日志不足、需要用户确认生产策略。

可复制写法：

当前阻塞：
- 已尝试：[读了哪些文件、跑了哪些命令、查了哪些日志]
- 阻塞原因：[缺少权限 / 缺少复现 / 外部服务不可用 / 需要业务确认]
- 为什么不能继续猜：[继续做会带来的风险]
- 用户可以提供：[截图、日志、账号权限、确认选项、测试数据]
- 我可以先做的低风险工作：[文档整理、测试草稿、排查清单]

如果仍能推进低风险部分，就先推进。只有关键路径真的缺信息时，才把阻塞写清 楚交给用户。

完成证据清单

Goal 的“完成”要落到证据上。不同任务需要的证据不同，写 Goal 时可以提前列 出至少一种机器验证和一种人工可读证据。

任务类型	机器证据	人工可读证据	不足时怎么写
代码功能	单测、集成测试、构建通过	diff 摘要、页面截图、交互路径	说明未覆盖的浏览器或数据状态
Bug 修复	复现命令不再失败、回归测试通过	根因说明、错误日志前后对比	说明是否缺少生产日志或用户样本
文档 SEO	内容校验、链接检查、构建通过	新增摘要、FAQ、内链和截图	说明未做 Lighthouse 或线上抓取
API 接入	最小请求、错误处理测试、密钥扫描	环境变量说明、脱敏日志样例	说明外部控制台信息需人工确认
长期网站迭代	build、SEO/GEO 审计、浏览器 QA	本轮页面、截图、剩余风险	说明只是本轮进展，不代表长期目标结束

常见错误

错误	表现	改法
目标太泛	Codex 改了很多无关文件	把目标缩成一个可验证任务
没有验收标准	只得到“已完成”的口头结论	写清命令、截图、日志或人工检查
范围缺失	小问题引发大重构	列出可以改和不要改的文件
密钥写进 Prompt	Key 进入日志或对话记录	只提供环境变量名和脱敏示例
把营销当内容	页面读起来空泛	用步骤、案例、FAQ 和风险说明替代口号
忘记用户已有改动	diff 混入无关变化	开始前读取 Git 状态，结束时说明范围

常见问题

Goal 和普通 Prompt 有什么区别？

普通 Prompt 更像一次提问，Goal 更像一张任务单。它适合让 Codex 在仓库里持 续读文件、改文件、运行命令并用证据汇报结果。

Goal 越长越好吗？

不是。Goal 应完整但不啰嗦。目标、范围、验证和禁区比长篇背景更重要；背景 只写会影响判断的信息。

可以把多个任务塞进一个 Goal 吗？

不建议。写代码、修 Bug、重构、写文档和部署排错应分开处理。多个目标混在一 起会让 diff 难审，也会让验证结论变模糊。

如何让 Codex 少改无关文件？

写明可以修改的目录、不要修改的模块和验证命令。开始前要求它读取 Git 状态， 结束时要求它说明 diff 是否包含无关改动。

Goal 里要不要写 OfApp.cn API Key？

不要写真实 Key。可以写环境变量名、.env.example 格式和 Base URL 示例： https://api.ofapp.cn/v1。真实 Key、模型和额度请以 OfApp.cn 控制台或官方 文档为准。

什么时候可以标记完成？

当 Goal 的成功标准都有当前证据支撑时再标记完成。证据可以是测试、构建、截 图、日志、diff 或清楚的人工确认项。

资料来源

• OpenAI Codex Prompting：用于核对 Prompt、Goal mode、验证、拆分任务和持续目标的官方说明。
• OpenAI Codex app commands：用于核对 /goal、/plan、/review、/status 等命令在 Codex app 中的定位。
• OpenAI Codex AGENTS.md 指南：用于核对 AGENTS.md 的发现顺序、仓库规则和可复用提示边界。
• OpenAI Codex manual：用于复核 Codex 手册中关于 Prompting、Goal mode、AGENTS.md 和 slash commands 的说明。
• OfApp.cn 官方首页：用于理解 OfApp.cn 的 OpenAI-compatible、Codex、GPT Image、Claude 兼容和 Genius 入口定位。
• OfApp.cn API 直转文档：用于核对 Base URL、API Key、/v1 接入方式；具体模型、能力、额度和价格请以控制台或官方文档为准。
• OfApp.cn 天才游乐场：用于确认面向普通用户的在线体验入口，API/Codex 配置和在线试用场景应分开描述。

相关文章

• Codex 教程：查看 Codex 工作流入口。
• Codex 本地项目使用指南：控制工作目录、任务范围和验证命令。
• 用 Codex 写代码：把功能需求写成可交付任务。
• 用 Codex 修 Bug：用复现、根因和回归测试完成修复。
• 用 Codex 生成测试：为代码改动补可执行验证。
• Codex CLI 接入 OfApp.cn：配置统一 API 入口。

带走什么

Codex Goal 提示词的核心是把目标、范围、验证和完成证据写清楚。它让 Codex 不只是“回答问题”，而是在真实项目里按边界行动、用证据汇报，并在无法继续时 清楚说明阻塞。