技能介绍

要解决什么问题

把一个「我大概想做个什么」的想法直接丢给 Codex 的 /goal，最常见的结果是跑了几个小时才发现验收标准没对齐、进度评分全靠模型自觉、上下文窗口被反复实验撑爆。问题通常不在模型，而在目标没被写成合约：谁给进度评分、多久跑一次检查、长跑时记忆放在哪、用户中途能调什么，这四件事在裸奔。

Goal Forge 把这件事拆成可审计的规格流程，让 /goal 拿到的是一份带度量和停止条件的合同，而不是一段散文。

核心能力与工作方式

四种模式，按需求选最小的那个：

Interview：拿到粗糙想法先深挖，覆盖实现方式、数据模型、边界情况、技术取舍、回滚方案、评分口径与验证方式，直到 done_when 里出现用户确认过的成功标准才落笔 SPEC.md。
Tighten：对已有 SPEC.md 做质疑式收紧。每个歧义都给出两种解释、说明它影响什么、推荐更易维护的那种，并且不加范围，无法验证的条目直接删除或标记。
Compile：把 SPEC.md 编译成 GOAL.md，映射到规格摘要、相关文件与模块、架构规则与非目标、评分指标与阈值、验收标准、快速反馈循环、工作记忆文件、人工控制面、验证命令等区块。
Check config：用 scripts/inspect_codex_config.py 做只读检查，输出 Codex 版本、选中的配置项、项目信任状态，以及与自治 /goal 要求的差距。

长跑合约必须显式写清四块：Scorecard（Codex 如何反复给进度评分）、Feedback loop（迭代时能跑的最快代表性检查）、Working memory（PLAN.md、ATTEMPTS.md、NOTES.md 这类 markdown 记忆文件，避免只依赖对话上下文）、Human control surface（用户可观察与微调的旋钮，通常落在精简的 CONTROL.md）。

编译阶段有硬闸门：done_when 每一项都必须指向具体命令、文件产物或可观察行为；评分卡必须给出主指标、通过阈值、回归检查与停止条件；反馈循环必须说明预计耗时、运行节奏与代理有效性。规格不达标就退回 Interview 或 Tighten，不产出 GOAL.md。

适用边界与注意点

优先用于编码与仓库相关工作。纯探索、只做调研、涉及安全关键路径、或缺少可验证完成标准的任务，应保留人在回路，不要强行编译 /goal。

配置检查是只读的；在用户明确要求之前不要修改 ~/.codex/config.toml。若确实需要开启 approval_policy = "never" 和 sandbox_mode = "danger-full-access"，应限定在明确信任的项目路径，而不是全局生效。CONTROL.md 只保留与该目标相关的旋钮，不要把它写成第二份 GOAL.md。

截图预览

使用场景

负责将多个内部服务整合为统一API网关，手头只有一段粗略的功能构想且缺乏明确的验收标准，需要在让 Codex 自动跑通功能前，通过访谈梳理需求并生成完整的 `SPEC.md`。
在重构遗留的电商结算模块时，已经编写了一份 `SPEC.md`，但不确定部分业务边界和技术取舍是否合理，需要质疑并收紧这份规格文档，消除其中的歧义以供后续执行。
在构建跨多仓库的自动化测试框架时，需求已经很清晰，下一步需要把规格文档编译成 `GOAL.md`，让 Codex 拿到一份包含工作记忆和停止条件的合约去自主执行。
准备发起长时自动重构任务前，想确认 Codex 是否已具备全访问权限，需要运行只读的配置检查脚本，验证当前环境的版本和沙箱模式是否满足自治 `/goal` 的运行要求。

适合人员

负责内部服务整合的后端工程师，在让代码改动自动跑起来之前，需要把自己的粗糙需求梳理成有明确验收标准的规格文档。
正在重构遗留系统的架构师或初级工程师，想要一份被质疑和收紧过的规格文档，以提前排除模棱两可的业务边界，防止在后续多小时运行中偏离方向。
准备在团队内引入长时间自动化任务的技术负责人，希望在真正开启长时自动重构前，通过只读检查确认环境配置已满足全访问的自治要求。
需要管理数小时自动实验运行的工程师，在任务进行期间想要一份精简的 `CONTROL.md` 来监控进度，并在运行中调整范围限制或资源预算。

目标锻造器