Back to Details

codex-goal-builder

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Codex Goal Builder

Codex Goal 构建工具

Turn a rough objective into a thread-scoped Codex Goal with a measurable finish line, concrete evidence, safe boundaries, and an honest blocked condition.
将粗略目标转换为线程范围的Codex Goal，包含可衡量的完成标准、具体验证依据、安全边界以及明确的阻塞停止条件。

Core Rule

核心规则

Do not start a Goal merely because the user describes work. Draft and refine first. Call 
create_goal
only when the user explicitly asks to start/create/activate the Goal or approves the final draft.
If an active Goal may already exist, call 
get_goal
before creating another one.
请勿仅因用户描述了工作内容就启动目标。请先起草并优化目标文本。仅当用户明确要求启动/创建/激活目标，或批准最终草案时，才可调用
create_goal
。
如果可能已存在活跃目标，请在创建新目标前调用
get_goal
。

Workflow

工作流程

  1. Capture the user's rough objective in one sentence.
  2. Decide whether a Goal is appropriate.
    • Use a Goal for multi-step work with a durable objective, uncertain path, and evidence-based completion.
    • Prefer a normal prompt for one-line edits, simple explanations, short reviews, or tasks with no durable finish line.
  3. Draft a stronger Goal using this contract:
text
<desired end state>, verified by <specific evidence>, while preserving <constraints>. Use <allowed inputs/tools/boundaries>. Between iterations, <how to choose and record the next action>. If blocked, budget-limited, or no defensible path remains, stop with <evidence gathered, attempted paths, blocker, and next input needed>.
  1. Ask only the missing high-leverage questions.
    • Ask 1-3 questions at a time.
    • Infer safe defaults when the answer is obvious from repo context or the user's wording.
    • Prefer questions about evidence, constraints, and boundaries over vague preference questions.
  2. Produce a final Goal in one of these forms:
    • CLI text: 
      /goal ...
    • Active tool call: 
      create_goal(objective=...)
      , only after explicit approval.
  3. If the user provides a token budget, pass it to 
    create_goal
    . Otherwise omit it.
  1. 用一句话捕捉用户的粗略目标。
  2. 判断是否适合创建目标。
    • 目标适用于多步骤工作，需具备持久化目标、不确定执行路径，且需基于证据验证完成情况。
    • 对于单行编辑、简单解释、简短评审或无持久化完成标准的任务，优先使用普通提示。
  3. 使用以下模板起草更完善的目标：
text
<desired end state>, verified by <specific evidence>, while preserving <constraints>. Use <allowed inputs/tools/boundaries>. Between iterations, <how to choose and record the next action>. If blocked, budget-limited, or no defensible path remains, stop with <evidence gathered, attempted paths, blocker, and next input needed>.
  1. 仅提出缺失的关键问题。
    • 每次提问1-3个。
    • 如果答案可从仓库上下文或用户表述中明显推断，则使用安全默认值。
    • 优先询问关于验证依据、约束条件和边界范围的问题，而非模糊的偏好类问题。
  2. 以以下形式之一生成最终目标：
    • CLI文本：
      /goal ...
    • 主动工具调用：
      create_goal(objective=...)
      ，仅在获得明确批准后执行。
  3. 如果用户提供了令牌预算，请将其传入
    create_goal
    ；否则省略该参数。

Goal Checklist

目标检查清单

Every final Goal should cover:
  • Outcome: what must be true when done.
  • Verification surface: tests, benchmarks, logs, screenshots, artifacts, reports, or source evidence.
  • Constraints: behavior, API, data, security, design, performance, or compatibility that must not regress.
  • Boundaries: allowed repositories, files, commands, environments, services, or data sources.
  • Iteration policy: how Codex should choose the next attempt after each result.
  • Blocked stop condition: what counts as honestly blocked and what to report.
最终目标需涵盖以下所有内容：
  • 成果：完成时必须达成的状态。
  • 验证依据：测试、基准测试、日志、截图、工件、报告或源证据。
  • 约束条件：不得出现退化的行为、API、数据、安全、设计、性能或兼容性要求。
  • 边界范围：允许访问或操作的仓库、文件、命令、环境、服务或数据源。
  • 迭代策略：Codex在每次得到结果后应如何选择下一步操作。
  • 阻塞停止条件：什么情况视为确实阻塞，以及需要报告的内容。

Question Strategy

提问策略

Start from the most incomplete part of the checklist:
  • Missing verification: "What command, artifact, metric, or evidence should prove this is done?"
  • Missing constraints: "What must not change while Codex works on this?"
  • Missing boundaries: "Which repo/files/environment may Codex touch or inspect?"
  • Missing blocked condition: "If this cannot be completed, what should the final report include?"
Avoid asking for all six fields if the user gave enough signal. Most rough goals need only verification and constraints.
从检查清单中最不完善的部分开始提问：
  • 缺少验证依据：“应使用什么命令、工件、指标或证据来证明任务已完成？”
  • 缺少约束条件：“在Codex处理任务期间，哪些内容不得更改？”
  • 缺少边界范围：“Codex可以访问或检查哪些仓库/文件/环境？”
  • 缺少阻塞停止条件：“如果任务无法完成，最终报告应包含哪些内容？”
若用户已提供足够信息，无需询问全部六个字段。大多数粗略目标通常仅需补充验证依据和约束条件。

Output Style

输出风格

When drafting in Chinese, keep the explanation short and put the usable 
/goal
command in a fenced 
text
block.
When the user wants iteration, show:
  • "当前草案"
  • "还差的问题"
  • "确认后可启动"
When the user says "直接创建", "启动这个 goal", or otherwise approves, briefly state what is being started and call 
create_goal
.
当用中文起草目标时，请保持说明简洁，并将可用的
/goal
命令放在带围栏的
text
块中。
当用户需要迭代优化时，请展示：
  • “当前草案”
  • “还差的问题”
  • “确认后可启动”
当用户说“直接创建”、“启动这个 goal”或通过其他方式批准时，请简要说明即将启动的内容，然后调用
create_goal
。

Safety

安全注意事项

  • Remember that Codex Goals are thread-scoped persistent objectives, not global memory or project instructions.
  • Never represent a budget limit as success.
  • Never mark a Goal complete unless concrete evidence satisfies the objective.
  • Do not use 
    update_goal
    to rewrite, pause, resume, or clear Goals; those lifecycle controls belong to the user or system.
  • For live systems, database writes, production deployment, payments, account changes, or destructive operations, include explicit boundaries and require explicit user approval before action.
  • 请记住，Codex Goals是线程范围内的持久化目标，而非全局记忆或项目指令。
  • 切勿将预算限制视为任务成功完成。
  • 除非有具体证据满足目标要求，否则不得标记目标已完成。
  • 请勿使用
    update_goal
    来重写、暂停、恢复或清除目标；这些生命周期控制权限属于用户或系统。
  • 对于实时系统、数据库写入、生产部署、支付、账户变更或破坏性操作，请明确包含边界范围，并在执行操作前获得用户的明确批准。

References

参考资料

Read 
references/goal-patterns.md
when the rough objective is broad, research-heavy, deployment-related, or needs task-type-specific examples.
当粗略目标较为宽泛、涉及大量研究、与部署相关，或需要特定任务类型的示例时，请阅读
references/goal-patterns.md
。