MiniMax M3 · workflow
围绕“MiniMax 官方：M 系列提示词最佳实践”整理任务边界、必需输入和运行环境；完整步骤、变量与限制见详情。
任务：
{{TASK}}
背景：
{{CONTEXT}}
来源：
{{SOURCE}}
约束：只使用给定证据，并在达到失败上限时停止。
输出格式：
{{OUTPUT_FORMAT}}
代表性用例：
{{TEST_CASES}}运行前仍需替换: {{TASK}}, {{CONTEXT}}, {{SOURCE}}, {{OUTPUT_FORMAT}}, {{TEST_CASES}}
准备 M3 任务、项目背景、编号并注明日期的来源、验收命令，以及工具参数和停止条件。
分开写 Task、Context、Source、Constraints、Output format。
抽取/分类任务准备 3–5 个差异化示例；重复任务固定变量和模板版本。
用 10–30 个固定用例记录格式错误、事实遗漏、工具误用和长上下文回归。
检查格式、引用、停止行为和工具参数；长上下文混淆时删除无关历史并把任务放到来源之后，简单任务变慢时改为直接输出。
这是 M-series 方法指南，不是 M3 成功率或 Tabbit 端到端测试；复制块为编辑改写。
这是本批资料中最完整、最适合直接转成 M3 使用规范的来源。官方文档覆盖一般提示词、输出格式、长上下文、工具调用、思考深度、Agent 长任务和提示词评测迭代。
任务、约束、优先级和期望输出必须明确；官方黄金规则是：让一个不了解上下文的同事阅读提示词，如果他会困惑，模型也会困惑。
解释约束背后的原因，帮助模型在格式、安全、可访问性和工作流之间做取舍。
困难的分类、抽取和边界任务使用 3–5 个相关、差异化、具体的示例。
重复任务使用带命名变量的模板，便于比较版本、定位回归和保持行为稳定。
用 Task、Context、Source、Constraints、Output format 等短标签分隔内容，避免深层嵌套。
长上下文中把任务放在 source 之后；对 source 编号、加日期和清晰边界；来源冲突时定义优先级。
工具提示词要写清工具目的、何时使用、何时不要使用、参数、返回结构和失败行为。
明确停止规则：工具失败两次就停止重试并解释阻塞；不要为了“显得忙”而调用工具。
对复杂规划、调试和权衡要求深入推理；对抽取、改写、格式化要求直接输出，不要固定要求每次都深度思考。
允许模型拒答并引用依据，以降低版本、价格、政策和 API 行为方面的幻觉。
长任务保持少量活动目标，把计划、状态和未决问题放在可见上下文中；必要时分窗口处理。
为重要提示词准备 10–30 个代表性测试用例，比较候选版本、记录回归并维护变更日志。
Task: [要完成的具体任务]
Context: [项目背景、技术栈、为什么这样做]
Source: [文件、日志、需求或接口资料]
Constraints:
- [必须遵守的边界]
- [何时使用工具，何时不要使用]
- [失败时如何处理]
Process:
1. 先检查现有项目和测试。
2. 先给出计划，再实施。
3. 每次修改后运行相关验证。
Output format:
- Summary
- Changed files
- Tests and results
- Remaining risks本站仅展示 Tabbit 编辑摘要和必要节选；完整内容、上下文与最新版本请查看原始来源。
这是官方通用 M-series 文档，不是只针对 M3 的单任务实验；官方示例应作为骨架，仍需用自己的项目测试。
MiniMax API Docs，Token Plan → M-series Usage Tips · 原文日期: 未公开 · 编辑日期: 2026-09-20
阅读原始来源MiniMax M3
请在上方所列环境中运行本指南。下载不会自动传入模板，也不代表账户已开放该模型。