夜雨聆风Codex 新手教程
最近一条 7.8 万浏览的 Codex 热帖和一个新 Skill 都在提醒同一件事：别只给一句模糊需求，先把 /goal 补成能验证、能停下、能交付的任务合同。
这两天如果你刷 Codex 相关内容，会看到一个很真实的抱怨：明明模型更强了，任务还是容易跑偏，甚至跑一晚上，第二天起来发现它卡在半路。
很多人第一反应是换模型、换提示词、换插件。
但我把一条 7.8 万浏览 的 X 热帖和一个刚冒头的 Goal Skill 看完后，反而更确定了一件事：新手最该补的，不是更花哨的工作流，而是把一句模糊需求，改成一份能执行的任务合同。
你别再只跟 Codex 说：
帮我做个 App 修一下这个 bug 搭个网页 优化一下这个项目
这些话，人能脑补。
Agent 不行。
它不知道怎么验证，哪里不能碰，失败后要不要重试，做到什么程度算完成，什么情况下必须停下来等你确认。
所以今天这篇，不聊版本号，也不聊谁家模型又超了谁。
我们只聊一件最值钱的基础动作：怎么把一句需求，补成 6 段能直接给 Codex 跑的 /goal。
PART 01
0130 秒看懂
最近一条 Codex 热帖拿到 7.8 万浏览，核心观点不是“模型不行”，而是 goal 写得太松。 一个新 Skill 已经把这件事产品化：把模糊需求自动补成带验证、约束、边界、完成条件和暂停条件的 /goal。 对普通人来说，最值得先学的不是“长提示词文学”，而是 6 段任务合同。 你今天就能试：拿一个想做的小任务，照着本文模板补一遍，再交给 Codex
PART 02
02最近为什么这个话题突然又热了
先说热度信号。
1. Codex /goal 跑一晚烂尾，不一定怪 Codex：2026-06-13，约 78,821 Views。重点在“goal 太模糊，agent 不知道怎么验证和何时停”。
2. 把模糊任务转成可复制 /goal 的 qiaomu-goal-meta-skill：2026-06-14，约 1,282 Views。热度不算大，但信息密度极高。
3. OpenAI 官方：Codex 可把 rate limit reset 留到以后再用：2026-06-12，约 4.31M Views。热度最大，但更像权益更新。
PART 03
03大多数人哪里说错了
很多人现在和 Codex 的沟通方式，本质上还是在“口头带新人”。
你心里觉得自己说得很清楚了。
但站在 Agent 视角，下面这些其实都不清楚：
你要它先改，还是先看； 它改完之后，要不要自己验证； 它能不能顺手装依赖、改配置、删文件； 如果跑不通，是先重试 1 次，还是先停下来； 你要的是“先出一个最小能跑版本”，还是“一步做到完整交付”。
这就是为什么同一句“帮我做个 landing page”，可能会出现完全不同的结果：
有人拿到的是一个能打开、能点击、能改字的最小版本；
有人拿到的是一堆没跑过的文件；
还有人第二天起来，发现它停在“Installing dependencies…”那里不动了。
这不是 Codex 专属问题。
Claude Code、Hermes 调起 CLI 工具、甚至多个 Agent 串起来时，都会遇到同一类问题：任务目标太像一句口头话，不像一个可执行工单。
所以我很认同那条热帖里的核心判断：
真正拉开差距的，不是你会不会说漂亮提示词，而是你有没有把目标写成 agent 能验证、能收尾、能止损的格式。
PART 04
046 段任务合同，到底该怎么写
如果你不想学一堆提示词理论，可以直接记住这 6 段。
1. 目标：先说你到底要什么
目标不是“做高级一点”。
目标要写成：交付物 + 场景 + 第一版范围。
比如不要写：
帮我做个 App。
可以改成：
做一个第一版落地页，用户打开后能看懂产品价值、提交邮箱，并在手机上正常浏览。
重点不是文采，而是让 Codex 一开始就知道：这次要交什么，不要顺手扩成别的东西。
2. 验证：告诉它怎么证明自己做完了
这是最容易被忽略的一段。
很多任务之所以烂尾，不是因为代码没写完，而是因为没人告诉它“怎么叫完成”。
你可以写：
验证：启动本地服务，在浏览器里检查首屏、按钮、表单提交和手机端布局；如果项目已有测试命令，先跑项目自带检查。
这一段的作用，是把“我觉得差不多了”变成“你跑给我看”。
3. 约束：先写不能做什么
很多返工都不是能力问题，而是边界没提前说。
例如：
不接付费 API； 不新装大型依赖； 不改数据库； 不动登录系统； 不使用受版权保护素材； 不做上线部署。
你把这些先写进去，能省掉后面很多“我不是这个意思”。
4. 边界：告诉它这次能改哪些地方
约束是“不做什么”，边界是“最多做到哪”。
例如：
边界：如果是新项目，只写入当前新建目录；如果在现有项目里，只修改和首页、样式、表单、直接相关测试有关的文件。
这段特别适合已经有仓库的人。
因为很多人真正怕的，不是它不会写，而是它手太长。
5. 完成条件：把“第一版够了”写清楚
这段是为了防止 Agent 无限加戏。
例如：
完成条件：页面可运行，桌面和移动端无明显布局错位，邮箱表单可提交或有占位反馈，关键文案可编辑，并输出本次修改文件清单。
你会发现，完成条件一写，任务会明显更聚焦。
它不会老想“再优化一下动画”“顺便补个后台”“再做个第二页”。
6. 暂停条件：哪些事必须停下来问你
这一段，是让你睡得着的关键。
比如：
暂停条件：需要购买服务、接第三方账号、删除现有文件、改生产配置、迁移数据、加入支付或上线部署时，先暂停并汇报。
对新手来说，这一段比很多 fancy 工作流都重要。
因为真正会让人害怕的，不是它慢一点，而是它替你做了你根本没授权的动作。
PART 05
05为什么这比“学会写长提示词”更重要
最近很多教程喜欢把提示词写得很玄。
看起来很厉害，但普通人照抄后，最常见的问题是：太长、太散、太像口号，真正交给工具时反而抓不住重点。
我更推荐把 /goal 理解成一个小工单。
它不需要文学性。
它只要解决 4 个现实问题：
1. 这次到底做什么；
2. 做完怎么验证；
3. 哪些东西不能碰；
4. 什么时候必须停下来。
你把这 4 个问题解决，已经比 80% 的“帮我做一下”强很多了。
这也是 qiaomu-goal-meta-skill 为什么值得看一眼。
它不是在教你“写得更像大师”。
它是在帮你把模糊需求，补成一份 copy-ready 的 `/goal`：默认带验证、边界、迭代策略、完成条件和暂停条件。
对中文用户尤其友好的一点是，它不是先逼你填一大堆表，而是先给一版可直接复制的推荐执行版。
这比很多理论更实用。
PART06
06给普通人的 30 分钟小实验
如果你今天就想试，不用找复杂项目。
拿一个很小的任务就行，比如：
做一个个人介绍页； 把已有 README 改得更清楚； 修一个表单样式问题； 给项目加一个“30 秒看懂”的首页模块。
然后按这 3 步来：
第一步：先写一句原始需求
比如：
帮我做一个能收集邮箱的产品介绍页。
第二步：把它补成 6 段
你不需要一次写很长。
照着下面补就够了：
目标：第一版产品介绍页，含价值说明、邮箱表单、手机可读。 验证：本地启动后，用浏览器检查首屏、输入框、提交按钮和手机布局。 约束：不接真实邮件服务，不引入大型 UI 框架，不加后台。 边界：只改首页和相关样式文件。 完成条件：页面可运行，表单有反馈，移动端不乱。 暂停条件：如果要接第三方服务或改构建配置，先停下来。
第三步：让 Codex 先交“结果 + 验证 + 修改清单”
最后再补一句：
完成后请汇报：做了什么、怎么验证的、改了哪些文件、还有什么没做。
这一步看起来很小，但特别重要。
因为很多人不是拿不到结果，而是拿到结果后不知道它到底有没有真的跑过。
PART 07
07适合谁，不适合谁
这套方法特别适合：
刚开始用 Codex / Claude Code / Hermes 调 CLI 的人； 想把任务交给 Agent 跑 10 分钟到 1 小时的人； 经常做网页、小脚本、内容自动化、数据整理这类可拆小任务的人； 想减少返工、但又不想一上来学重工程流程的人。
它不太适合：
你还没想清楚自己到底要什么； 任务本身跨度特别大，比如“做一个完整 SaaS”； 你想一次把产品、部署、增长、支付全打包； 你明知道涉及高风险动作，却又不愿意写暂停条件。
说白了，任务合同不是让大任务 magically 变简单。
它只是让你别一开始就把一个模糊大坑扔给 Agent。
PART 08
08最后只记住一句话
如果你最近觉得 Codex 不稳定，先别急着怪模型。
先回头看一下：你给它的，到底是一句口头话，还是一份能执行的任务合同。
真正好用的 Agent，不只是“会做”。
而是你能不能把目标写成：它知道做什么，知道怎么验证，知道哪里不能碰，也知道什么时候该停。
这一步补上之后，你再去谈 Skills、Hooks、Subagents、自动化协作，体验会完全不一样。
今天就能做的下一步
随便挑一个你本周想交给 Codex 的小任务，把一句需求补成上面的 6 段，再跑一次。
你大概率会第一次明显感受到：不是你多学了一个新命令，而是 Agent 终于听懂了你。