4 Prompt、Plan 与 Goal：让 Codex 先想清楚再动手

查看大图

Codex 能执行很多事，所以你更需要把任务说清楚。

官方 best practices 给了一个非常好的提示：一个好任务最好包含四部分，Goal、Context、Constraints、Done when。中文说就是：目标、上下文、约束、完成标准。

我写 Codex 任务时，会先把一句模糊需求拆成四块：要达成什么，不能碰什么，准备怎么做，怎样算完成。这个习惯能减少很多来回解释。

查看大图

如果任务超过三个文件，我一般先让它列计划；如果任务会持续多轮，再用 Goal 追踪。不要把 Plan 当口号，也不要把 Goal 当普通待办，它们的价值在于让上下文和验收标准保持稳定。

一个差 prompt 和一个好 prompt

差 prompt：

查看大图

使用 Codex 前，先把目标、上下文、修改范围和验证命令说清楚。计划不是形式，它决定后面改动能不能被检查。

帮我优化首页。

问题是，优化什么？速度、SEO、样式、转化、移动端、结构化数据？如果没有边界，Codex 只能猜。

更好的写法：

目标：优化首页第一屏，让用户能更快进入今日 AI 和实测文章。
上下文：请先阅读 app/page.tsx、导航组件和首页样式。
约束：不要改登录、注册、API、数据库；不要新增依赖。
完成标准：移动端和桌面端按钮不溢出，npm run build 通过，并总结 diff。

这不是“提示词工程玄学”，这是工程任务描述。

复杂任务先 /plan

当任务复杂、模糊、跨多个文件时，先用计划模式。Codex manual 里说明，Plan mode 可以让 Codex 先收集上下文、提出问题、构建计划，再进入实现。

查看大图

看完《Prompt、Plan 与 Goal：让 Codex 先想清楚再动手》后，建议用一分钟复盘：关键概念是否分清、练习步骤是否可复现、结论能不能换成自己的话。

在 CLI、IDE、App 中可以用：

/plan

也可以直接说：

先不要改文件。请先阅读相关代码，列出分步骤计划、风险和验证方式，等我确认后再执行。

我通常会要求计划里必须有：

• 要读哪些文件。
• 每一步准备改什么。
• 哪些文件不能碰。
• 如何验证。
• 回滚风险在哪里。

目标明确时用 /goal

Goal mode 适合更长的任务。官方 prompting 文档里解释，goal 是一个持续目标，Codex 会围绕它判断下一步和完成条件。

例如：

/goal
把这个项目的登录页面移动端布局修好。完成标准：320px 宽度不横向滚动，表单按钮不遮挡，构建通过。

如果目标还不清楚，先 /plan，让 Codex 帮你把模糊想法整理成可执行目标，再设 /goal。

别让多个线程改同一批文件

Codex 支持多线程和并行任务，但官方 manual 也提醒，最好避免两个线程同时修改同一批文件。否则你会遇到冲突，甚至看不清是哪条线程引入的问题。

适合并行的是：一个线程写文档，一个线程补测试，一个线程查资料。
不适合并行的是：三个线程同时改同一个首页。

每个任务都要有“完成标准”

完成标准可以很简单：

查看大图

读完《Prompt、Plan 与 Goal：让 Codex 先想清楚再动手》后，可以先挑一个小样例走完整流程，再判断哪些步骤已经能独立完成。

查看大图

读到这里，可以把《Prompt、Plan 与 Goal：让 Codex 先想清楚再动手》整理成一张复盘表：先说清主线，再拿一个小任务检查结果。

• 构建通过。
• 指定测试通过。
• 页面在移动端不溢出。
• Git diff 没有无关文件。
• 只改了约定范围内的文件。

没有完成标准，Codex 就容易给你一个“我已经优化好了”的回答。你要的不是一句完成，而是能验收的结果。

参考资料：

• Codex best practices
• Codex prompting
• Codex app commands