夜雨聆风一条 30 秒视频，把 /goal 的写法改了
6 月 14 日晚，Pietro Schirano（@skirano）发了一条帖，文案很短，信息密度极高：
"I basically don't write /goal myself anymore."
「我基本上不再自己写 /goal 了。」
帖子里附了一段 30 秒的录屏。画面中，Codex 接收了一个高阶指令后，自动完成了一连串动作：合成强目标 → 拆分子任务 → 给每个子 agent 注入专属 /goal → 并行 dispatch → 等待返回并合成结果。
▲ Pietro Schirano 的主帖视频卡：Codex 自写 goal 并分发给子 agent 的演示，拿到 2673 赞、453K+ 浏览、3774 书签
跟实验室白皮书是两回事。这是一个每天都在用 Codex 做产品的工程师，把自己已经跑通的工作流摊在台面上。互动数据指向一个事实：大量开发者对此有强烈共鸣，甚至有人回复"Same!"、"Been doing the same"、"this is the way!"
Pietro 是谁？他的履历横跨 Facebook、Uber、Brex、Anthropic，做过 Claude Engineer 和 DesignerGPT 这两个在 agent 圈里使用率极高的工具。现在他是 MagicPath 的 CEO，一个把"人类和 agent 在同一块画布上协作"当作产品核心的人。这个背景下来公开工作流，分量不一样。
"Like this"：Pablo Stanley 甩出一套可直接套用的模板
帖子里 Pietro 说"Like this 👇"，指的是设计师 Pablo Stanley 的回复。Pablo 没有只说"好主意"——他直接给了一套可执行模板。
先是一个通用 brief 框架（占位符风格，设计师看了会心一笑）：
"Build [THING] in [TECH/FRAMEWORK]. It should include [MAIN FEATURES], with [INTERACTION/ANIMATION/BEHAVIOR DETAILS]. Make it feel [MOOD/QUALITY], using [VISUAL DETAILS], [ENVIRONMENT DETAILS], and [EXTRA EFFECTS]. Output as [FORMAT/FILE TYPE]."
「用 [技术/框架] 构建 [某物]。应包含 [主要功能]，附带 [交互/动画/行为细节]。让它的感觉是 [氛围/品质]，使用 [视觉细节]、[环境细节] 和 [额外效果]。输出为 [格式/文件类型]。」
然后追加了一段关键指令：
"For this task, write yourself a new goal and spawn agents in parallel — as many as needed to do it better and faster. Split the work into independent pieces, dispatch them concurrently, and synthesize the results as they return. Give each agent its own dedicated /goal."
「为这个任务，给你自己写一个新的 goal，并并行 spawn agent——需要多少就用多少，做得更好更快。把工作拆成独立模块，并发派发，在结果返回时实时合成。给每个 agent 一份专属的 /goal。」
▲ Pablo Stanley 的回复：上半部分是通用 brief 模板，下半部分是让 Codex 自己写 goal 并并行 spawn 的完整指令
这个模板把 Pietro 的做法从"个人习惯"变成了"别人也能复制的工作流"。人类只需要填几个占位符、讲明白想要什么，目标制定、任务拆分、子 agent 的 goal 撰写全部交给 Codex。
注意这里面的分工：人类负责"想要什么"（高阶意图），AI 负责"怎么组织执行"（目标工程 + 分发 + 合成）。中间那一大块最耗心力的事——写出精确、可验证、没有遗漏的 goal——被外包给了最清楚当前上下文和自身能力的那个实体。
为什么"让 AI 自己写目标"比人类写更靠谱
手动为一个复杂任务写 /goal，有多折磨人？做过的人都懂。
你要同时考虑产物是什么、怎么验证、哪些不能动、边界在哪里、迭代策略是什么、卡住了怎么办。每一项漏了或写模糊了，agent 就有可能在错误方向上猛跑几个小时。
当任务需要 spawn 3 到 10 个并行子 agent 时，难度指数级上升。你要让所有子 goal 对齐主目标、互相不冲突、各管一摊不重叠。人类的大脑不是为此设计的。
反过来，一个长期跑在同一个 repo 里的 Codex 实例，比人类更清楚当前代码状态、依赖关系、历史上的坑、自己的 token 和 context 余量。让它自己写 goal，它会把"我上次在这里翻过车""这个文件别碰""这条路径目前是坏的"这些隐性知识自然编码进去。
Pietro 的做法还有一个更深的好处：自对齐。AI 在撰写目标时，同时在做自我评估——它能干什么、什么有风险、什么需要额外验证。这个过程本身就降低了后续执行跑偏的概率。
Vox（@Voxyz_ai）在转发中把逻辑讲得很透。他直接给了一条 prompt：
"Write a /goal that creates multiple sub-goals for parallel task execution, where each sub-goal is self-contained with its own verification criteria and context for the agent that will run it."
「写一个 /goal，为并行任务执行创建多个子目标，每个子目标自包含，带有自己的验证标准和上下文，给将要执行它的 agent。」
▲ Vox 给出可一键执行的 /parallel-goal 命令，同时警告：不锁 spec 就是五个 agent 同时在错误的路上狂奔
但他立刻加了一句警告——这句话可能是整个讨论里最值钱的一句：模糊的 goal 会让五个 agent 同时在错误的路上狂奔。所以在并行之前，spec 必须先 lock。这里没有商量的余地：必须 lock。
社区已经把它做成了可安装的 skill
Pietro 的聪明倒在其次。这条帖真正让人兴奋的是社区反应有多快。
RTK（@RiverKhan）留言说他已经这么干了好几个星期，并且 OpenAI 官方其实写过一篇关于如何有效使用 /goal 的文章。他把它做成了一个可安装的 skill，放在了 GitHub 上：infinite-skills。
▲ RTK 直接把 Pietro 的"个人黑魔法"连接到了 OpenAI 官方文档和社区可复用 skill
打开这个 skill 的 SKILL.md，能看到一套完整的 preflight 流程：先做 ambiguity gate 检查（产物是什么？怎么证明完成？范围边界？），把人类的 rough request 通过结构化 interview 澄清，再产出 goal contract，最后才进入并行执行。
▲ infinite-skills 中 goal skill 的 SKILL.md：ambiguity gate 表格、preflight 流程、contract template，把"自写 goal"从灵感变成了工程资产
这说明了一个重要的转变：Pietro 的技巧已经从个人灵感变成了可工程化、可命令化、可 skill 化的模式。从一条帖到一个 GitHub 仓库，中间只隔了几个星期。
日文科技博主 @airiaiai8 也用结构化方式复述了这个工作流——传统做法（人类为每个 agent 手动写 goal，认知负荷巨大且容易出错）vs 新做法（Codex 自写 + 子 agent 各有专属 goal，AI 自知能力、一致性强、可扩展）。他的判断是：「AI に AI 用の目標を作らせる——これ、マルチエージェント設計の新常識になりそう。」（让 AI 为 AI 制定目标——这可能会成为多 agent 设计的新常识。）
OpenAI 官方的伏笔：/goal 不只是"更长的 prompt"
Pietro 的技巧之所以有效，底层有一个硬基础：OpenAI 对 /goal 的设计从一开始就不是让你写"更长的 prompt"。
根据 OpenAI 2026 年 5 月发布的 cookbook，一个强 goal 必须同时定义六件事：Outcome（具体产物/行为/指标）、Verification surface（测试命令、benchmark、截图等可观测证据）、Constraints（不可回归项）、Boundaries（允许/禁止的文件和动作）、Iteration policy（每次迭代后如何选下一步）、Blocked stop condition（无路可走时如何报告并停止）。
▲ OpenAI 官方 cookbook 对强 goal 六要素的详解，以及 Goals vs Prompts 的对比——goal 是"持久合同 + 可验证停止条件"
弱例是 `/goal Improve performance`。强例是 `/goal Reduce p95 latency below 120 ms on the checkout benchmark while keeping the correctness suite green. If blocked or no valid paths remain, stop with the attempted paths and evidence gathered.`
▲ OpenAI Codex 官方用例页：/goal 模式被定位为"持久目标 + 可验证停止条件 + 证据驱动决策"，最佳场景包括代码迁移、大型重构、实验原型
换句话说，/goal 本质上是一份"可验证合同"。而 Pietro 的洞见是：写合同这件事，最合适的起草方未必是人类。AI 更懂自己的执行边界、更清楚当前代码库的状态、更不容易遗漏边界条件——让它来起草这份合同，人类只需要审批和 lock。
这跟 OpenAI 官方的设计意图正好咬合。官方推荐的最佳实践（强 goal 六要素、evidence-driven、verifiable end state）恰好是 AI 自己能写得更好的东西。人类写这些容易遗漏，AI 写这些是对自身能力边界的诚实表达。
从"打字员"到"spec 制定者"：这件事到底意味着什么
Pietro 的这条帖之所以炸，重点不在于他发现了什么秘密——他把很多人已经在暗暗做的事公开摊开了，而且给出了可复用的模板和证据。
回看 Pietro 的轨迹：2024 年 3 月，他发过一段广为流传的视频——"Claude Opus's ability to orchestrate subagents is absolutely insane... Watch Claude direct subagents to build an entire drawing app."从让强模型编排子代理，到让 agent 自己定义并分发目标，这条线画了两年。
而 MagicPath——他的创业产品——恰好是这条线的 UI 层：一块多玩家画布，人类和 Codex/Claude Code/Cursor agent 同时在上面协作，agent"在你睡觉的时候"持续交付，输出不再是黑箱 diff 或聊天记录——agent 的每一步都变成了实时可见、可编辑的共享现实。
如果把 Pietro 的技巧放到更大的图景里看，agentic 编程的角色分工正在被重写：
- 人类
：定义高阶 spec + lock 验证标准 + 最终合成评审 - 主 agent
：填充 brief → 自写强 goal → 拆分子任务 → 给每个子 agent 写专属 /goal - 子 agent 集群
：各拿一份专属合同，并行执行，返回证据 - 验证表面
：test/benchmark/playwright/deploy 检查，防止 agent "自欺欺人"
人类从"为每一步写指令"变成了"为团队写 spec + 验证规则 + 合成策略"。AI 从"被指挥的执行者"部分进化成了"能定义自己工作合同的参与者"。
Vox 的警告仍然是最重要的刹车：五个 agent 同时在错误方向上狂奔。技巧有效的前提是 spec 先被 lock、验证表面真实存在、人类对最终合成有否决权。关键不在"让 AI 随便干"。本质是：把目标制定这一高价值认知工作，适度外包给最了解执行上下文的实体，同时保留人类对 high-level spec 的把控。
一个细节值得注意：Pietro 没说自己发明了什么。他原话是"我不再自己写 /goal 了"——一个行为转变，不是一个技术声明。这里的"不再"说明他对比过两种做法，选了更好的那个。而社区的反应——"Same!" "Been doing the same"——说明这不只是一个人的偏好，一个共识正在形成。
当 agent 能可靠地写出强 goal 之后，人类在编程循环里的终极角色会变成什么？这个问题，2026 年 6 月的这条帖没有给出答案。但它引发的模板、skill、警告和 45 万人的围观，至少说明了一件事：目标工程（Goal Engineering）正在取代 prompt engineering，成为 agentic 时代真正需要被掌握的手艺。
— END —
