> ## Documentation Index
> Fetch the complete documentation index at: https://agent.minimaxi.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 目标功能

> 使用 Goal 为 MiniMax Code 设定可验证的最终目标，让任务持续推进直到达标或遇到阻塞。

<div className="code-docs">
  Goal 可以理解为给 MiniMax Code 设定一个有验收标准的终点。MiniMax Code 会围绕这个结果反复检查、修改和验证；只要还没有达标，它就会继续寻找下一步，你不需要每轮都重新说“继续”。

  <img src="https://mintcdn.com/agent-cn/5TPJB6G0XbsVtdR0/images/code/goal-overview.png?fit=max&auto=format&n=5TPJB6G0XbsVtdR0&q=85&s=1ff4c52df5ed79841e4c87943df14046" alt="Goal 功能界面" className="code-screenshot" width="750" height="736" data-path="images/code/goal-overview.png" />

  ## Goal 是什么？

  只有达到目标、遇到无法解决的阻塞，或者你主动暂停时，Goal 才会停下来。

  普通 Prompt 更像是告诉 MiniMax Code“下一步做什么”：完成当前指令、返回结果，然后等待新的要求。

  Goal 则是告诉 MiniMax Code“最终要做到什么”：只要目标仍然有效、任务具备继续推进的条件，MiniMax Code 就会根据上一轮得到的结果选择下一步。

  <CardGroup cols={2}>
    <Card title="普通 Prompt" icon="message-square">
      提出要求 → 执行 → 返回结果 → 等待下一次要求
    </Card>

    <Card title="Goal" icon="target">
      设定最终目标 → 执行 → 检查结果；未达标时选择下一步继续推进，达标后完成，遇到阻塞时汇报并等待。
    </Card>
  </CardGroup>

  > 普通 Prompt 关注下一步行动；Goal 关注最终状态是否成立。

  因此，一个可执行的 Goal 至少要说清楚最终结果、判断完成的证据，以及工作过程中必须保持的条件。Goal 并不等于无限制的后台自动执行，它仍然受到当前任务范围、用户控制、可用预算和实际证据的约束。

  ## 如何开始使用 Goal？

  Goal 会显示在输入框的命令菜单和 `+` 菜单中。如果菜单里没有“目标”，请先将 MiniMax Code 更新到支持 Goal 的版本，并确认当前环境已开放该功能。

  <Steps>
    <Step title="进入 Goal 模式">
      在输入框输入 `/` 并从命令菜单选择“目标”，或者点击输入框旁的 `+`，再选择“目标”。
    </Step>

    <Step title="填写并发送目标">
      写清最终结果、验收依据、工作边界和停止条件，然后发送。
    </Step>

    <Step title="检查运行状态">
      发送后，输入区域上方会出现 Goal 状态。MiniMax Code 会持续推进并检查结果；你可以随时编辑、暂停、继续或清除 Goal。
    </Step>
  </Steps>

  <Note>
    直接在输入框中键入 `/goal` 不会自动进入 Goal 模式。请先从 `/` 命令菜单或 `+` 菜单选择“目标”。
  </Note>

  ## 什么时候适合使用 Goal？

  **Goal 最适合“终点清晰，但实现路径需要边做边判断”的任务。** 它的价值在于保留目标，让 MiniMax Code 可以根据测试、日志、Benchmark 或研究证据持续调整下一步。

  常见场景主要有四类：

  * **问题定位：** 排查偶发失败的测试，或先复现再修复 Bug。
  * **工程演进：** 依赖迁移、多阶段重构等需要跨多轮推进的改造。
  * **指标优化：** 性能优化，以及由 Benchmark 驱动的反复调优。
  * **研究交付：** 需要形成报告、复现结果或证据审计的研究任务。

  这些任务通常无法在开始前写出完整步骤，但可以预先定义清晰的完成标准。

  如果任务只是修改一句文案、解释一个报错、完成一次短代码审查或改动一个明确文件，普通 Prompt 会更直接。

  ## 如何用好 Goal？

  写 Goal 时，最重要的是把“做到什么才算完成”说清楚。目标、验证方式、工作范围和停止条件越明确，MiniMax Code 就越容易持续推进。

  <Steps>
    <Step title="先写清目标和验收标准">
      Goal 需要让 MiniMax Code 清楚知道“做到什么才算完成”，以及用什么结果来验收。例如：“将支付模块升级到新版 SDK，确保下单和退款流程保持正常，并让相关集成测试全部通过。”升级 SDK 是目标，业务流程保持正常是约束，集成测试通过是验收依据。
    </Step>

    <Step title="再写清约束和工作边界">
      约束说明主目标实现后仍然必须保持什么，例如正确性测试继续通过、公开 API 行为不变；工作边界说明 MiniMax Code 可以使用或修改哪些文件、工具和数据。
    </Step>

    <Step title="最后约定迭代方式和停止条件">
      每轮尝试后，根据最新证据选择下一项最有希望的行动并记录结果。遇到缺少必要数据、验证工具无法运行、需要额外权限，或当前边界内已没有合理路径时，应停止实质工作并汇报阻塞。
    </Step>
  </Steps>

  可以直接使用下面的结构：

  ```text theme={null}
  实现【最终状态】，并通过【具体测试、报告或产物】验证。
  工作过程中保持【不能退步的条件】。
  只使用或修改【允许的文件、工具和数据范围】。
  每轮尝试后记录【改动、结果和下一项实验】。
  如果出现【阻塞条件】，停止继续尝试，并汇报已经尝试的路径、现有证据、阻塞原因以及继续工作所需的输入。
  ```

  如果暂时不会写，可以先用自然语言描述任务，让 MiniMax Code 生成一份 Goal 草稿，再检查草稿是否明确了完成标准、验证方法、约束、工作边界和阻塞条件。最终“什么才叫完成”仍然应由用户确认。

  ## 哪些情况不适合使用 Goal？

  * **终点模糊、无法验收：** “优化一下”“重构这段代码”“让它更好”都缺少可靠的完成条件。开始前，应先把目标收敛到可以通过测试、指标、产物或证据判断是否完成的状态。
  * **一次即可完成的短任务：** 对于一行修改、简单解释、短代码审查或只需要一个答案的问题，普通 Prompt 已经足够。
  * **主要依赖主观判断：** UI 视觉效果、文案定调或业务取舍很难仅凭测试结果判断是否达标，应在关键阶段保留人工验收。
  * **涉及高风险操作：** 生产环境、删除或覆盖数据、付费操作、对外发布或发送消息等行为应保留人工确认。

  ## 使用 Goal 时需要注意什么？

  <Warning>
    **注意额度消耗：** Goal 会连续执行多轮，用量可能明显高于一次性 Prompt。开始前应设置运行时间、尝试次数或用量上限；达到上限、连续两轮无进展或方向不正确时，应及时暂停或编辑目标。
  </Warning>

  * **用实际证据复核完成结果。** MiniMax Code 显示目标已经完成后，仍应检查对应的测试结果、构建输出、Benchmark、日志或最终产物。
  * **提前限定操作范围。** 在 Goal 中说明允许修改的文件、可以使用的工具和环境，并约定不能触碰的目录、数据或现有行为。
  * **为阻塞和长任务设置退出机制。** 缺少权限、外部服务不可用或多次尝试仍重复遇到同一问题时，应暂停执行并汇报现有证据、阻塞原因和继续推进所需的信息。
</div>