> ## Documentation Index
> Fetch the complete documentation index at: https://platform.minimaxi.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# M 系列模型使用技巧
> 通过 Prompt 模板、工具调用、agentic 工作流和长上下文能力，更稳定地使用 MiniMax Token Plan 模型。
这些方法适用于使用 MiniMax Token Plan 模型。每一节都会给出一个效果欠佳的 Prompt、一个效果更佳的 Prompt，以及为什么后者更容易被模型稳定执行。
Token Plan 模型目前为纯文本模型，因此图片、音频、视频请先用其他工具处理，再把结果传给 Prompt。
直接跳到你关心的章节——日常 Prompt 用「通用原则」，Agent 工作流用「工具调用」，大量素材用「长上下文」。
## 通用原则
### 指令明确具体
模型更适合处理目标、约束和输出要求都明确的任务。请直接说明要做什么、优先考虑什么，以及什么样的结果才算好。
**黄金法则：** 把你的 Prompt 给一个完全不了解任务背景的同事看。如果他会困惑，模型也会。
**效果欠佳：**
```text theme={null}
创建一个可视化网站
```
**效果更佳：**
```text theme={null}
创建一个企业级数据可视化网站。
要求：
- 包含图表、筛选器、下钻视图和导出操作。
- 优先满足业务分析师快速浏览数据的需求。
- 使用精致的仪表盘布局，不要做成营销落地页。
- 先返回实现计划，再开始写代码。
```
### 补充约束的意图
当你解释某个约束为什么重要时，模型更容易做出正确取舍。意图说明尤其适合格式、安全、可访问性和工作流约束。
**效果欠佳：**
```text theme={null}
禁止使用文档符号
```
**效果更佳：**
```text theme={null}
你的回复将由文本转语音模型朗读。请只使用纯文本，避免文档符号，并让句子短一些，保证朗读时自然流畅。
```
当模型可能只满足字面要求、忽略真实使用场景时，请补充说明意图。
### 用示例引导输出
精心准备的示例（few-shot 或 multishot prompting）通常比抽象的风格描述更稳定。示例应当：
* **相关：** 贴近你的真实使用场景。
* **多样：** 覆盖边界情况和模糊输入。
* **具体：** 展示真实的输出风格，而不仅是话题。
**效果欠佳：**
```text theme={null}
写一段吸引人的产品介绍智能保温杯。
```
**效果更佳：**
```text theme={null}
请为智能保温杯写一段产品介绍。
好的例子：
这款台灯采用全光谱 LED 技术，能模拟清晨的自然光，温柔唤醒您的一天。它具备 6 级亮度调节，满足您阅读、工作和休息的不同需求。
请避免这种空洞描述：
这个台灯很好用，灯光很舒服，设计也很棒。
现在，请用同样具体、突出利益点的风格，写智能保温杯的产品介绍。
```
对于分类、结构化抽取、边界情况判断这类任务，请给出 3 到 5 个差异化示例，而不是单个。
**效果欠佳：**
```text theme={null}
将每条工单分类为：bug、需求、咨询。
```
**效果更佳：**
```text theme={null}
将每条工单分类为：bug、需求、咨询。
示例：
- "打开设置时应用崩溃" → bug
- "为导出面板添加深色模式" → 需求
- "如何导出为 PDF？" → 咨询
- "申请新的导出选项后崩溃了" → bug（崩溃才是工单本身，需求只是背景）
- "这是预期行为吗？" 无其他细节 → 咨询（未确认前不要归为 bug）
```
复杂模式匹配任务请给 3-5 个差异化示例。重复同类示例只会浪费 token，无法教会模型新东西。
### 使用 Prompt 模板
对会反复执行的任务，把 Prompt 写成带命名变量的可复用模板。这样更方便用同一套 Prompt 测试多组输入、对比版本、长期保持行为稳定。
**效果欠佳：**
```text theme={null}
礼貌地回复这条客户投诉。
```
**效果更佳：**
```text theme={null}
你是 [产品名] 的客户支持专家。
客户消息：
[客户消息]
可使用的已知事实：
[已知事实]
请写一封回复，要求：
- 第一句先承认客户遇到的问题。
- 只能基于上述已知事实解释下一步处理方式。
- 除非已知事实中明确出现，否则不要承诺补偿、退款或具体时间。
- 结尾给客户一个清晰的下一步动作。
```
变量能让任务、输入和边界条件都保持清晰，方便后续排查生产环境中的回归。
### 匹配输出语言
当输入是多语言混合，或希望输出固定为某种语言时，请明确说明。例如："即使素材是英文，也请用中文回复。"否则模型通常会跟随主要输入语言。
## 输出与格式
### 用清晰的段落结构
当 Prompt 中包含指令、素材、示例、约束和输出要求等多类内容时，请为每段加上标签，让模型能区分它们。粗体标签或带冒号的小标题比连续段落更清晰。
**效果欠佳：**
```text theme={null}
看看这个发布计划，告诉我哪里需要改进。要实用一点。读者是销售团队。我们关注企业客户和合作伙伴打法。再做个表格。
【很长的发布计划】
```
**效果更佳：**
```text theme={null}
任务：审阅发布计划，并找出最值得优先改进的部分。
背景：读者是销售团队。优先关注企业客户和合作伙伴打法。
素材：
【很长的发布计划】
输出格式：
返回表格，列包括：领域、问题、建议、优先级。
每条建议都要可执行，并控制在 40 个汉字以内。
```
建议使用简短、语义明确的标签——任务、背景、素材、约束、输出格式。冒号或加粗即可标识每段，结构保持扁平，避免深层嵌套。
### 设定角色、格式与长度
角色设定最好同时说明专业背景、工作范围和判断标准。输出要求最好明确章节、字段和长度限制，方便人和程序一起校验。
**效果欠佳：**
```text theme={null}
你是资深工程师。帮我 review 这段代码，简洁一点。
```
**效果更佳：**
```text theme={null}
你是资深后端代码 reviewer，重点关注正确性、可靠性和可维护性。
待审阅的 diff：
[diff]
严格按以下结构返回：
1. 摘要 —— 最多 3 条
2. 阻塞问题 —— 表格，列为 文件、风险、修改建议
3. 非阻塞建议 —— 最多 5 条
不要重写整个文件。只提出与该 diff 直接相关的修改建议。
```
推荐使用明确的输出契约，例如章节名称、表格列名、条数限制和讨论范围。对于需要进入下游评审流程的输出，避免只写"详细一点"或"简短一点"。
## 长上下文
Token Plan 模型支持长上下文窗口，输入和输出容量都很大。长上下文效果更好时，通常具备清晰分隔的素材、索引信息，以及放在素材之后的具体任务。
### 任务放在素材之后
对于长输入，请把问题或任务写在**素材之后**，而不是之前。任务越靠近模型回答位置，越容易保持关注。
在所有长上下文技巧中，把任务放在 Prompt 末尾对回答质量的提升最大。
### 为素材建索引并分隔
**效果欠佳：**
```text theme={null}
阅读下面所有内容，总结重点。
【很长的会议记录、需求文档、访谈材料和代码片段】
```
**效果更佳：**
```text theme={null}
按时间顺序列出素材：
**launch-plan** —— 2026-04-12
【发布计划】
**pricing-notes** —— 2026-04-18
【定价笔记】
**meeting-transcript** —— 2026-04-21
【会议记录】
任务：为发布负责人产出一份管理层简报。如果来源互相冲突，优先采用日期最新的来源，并指出冲突。
输出格式：
- 决策摘要 —— 最多 5 条
- 风险 —— 用表格列出，并标注来源
- 待确认问题 —— 负责人、阻塞点、下一步动作
```
对于特别大的输入，可以先要求模型引用或概述每个文档中的关键内容，再开始回答。基于原文引用能降低噪音，也让最终结论更容易核查。
## 工具调用
Token Plan 模型支持工具调用。好的工具调用 Prompt 会定义何时使用工具、何时不要使用、以及如何把工具结果合并进最终回答。
### 工具定义
为每个工具写清楚名称、用途、输入、返回结构和失败处理方式。模型在决定是否调用工具前，应先理解工具契约。
**效果欠佳：**
```text theme={null}
需要时使用搜索工具。
```
**效果更佳：**
```text theme={null}
工具：search_docs
用途：搜索内部文档库，获取产品或政策相关事实。
适合使用：
- 用户询问当前产品行为、限制、价格或发布说明。
- 在做出可能随时间变化的事实判断前，需要来源支撑。
不适合使用：
- 用户只要求改写、排版或头脑风暴。
- 用户提供的上下文已经足以支持回答。
参数：
- query：简洁的关键词查询
- product_area：可选，产品或功能领域
返回：结果列表，每条包含标题、URL、日期和摘要。
失败处理：如果连续两次搜索失败，停止重试，并说明哪些信息无法验证。
```
### 并行工具调用
当多个工具调用彼此独立时，明确要求模型并行调用。只有当一个结果会决定下一次查询或动作时，才保持顺序调用。
**效果欠佳：**
```text theme={null}
查一下文档、Issue 和更新日志，告诉我这个 bug 有没有修复。
```
**效果更佳：**
```text theme={null}
请并行检查以下彼此独立的信息源：
- 文档搜索 —— 当前预期行为
- Issue 搜索 —— 相似 bug 反馈
- 更新日志搜索 —— 近期修复记录
所有结果返回后，再回答：
- 这个 bug 是否已经修复？
- 哪个来源支持该结论？
- 用户下一步应该做什么？
```
独立的只读查询适合并行。像「先找到客户，再更新该客户记录」这样的工作流应保持顺序执行。
### 避免过度调用
在 agentic 工作流中，请明确停止规则。模型应该在工具能实质提升回答质量时使用工具，而不是为了显得忙碌。
**效果欠佳：**
```text theme={null}
使用任何可用工具解决这个任务。
```
**效果更佳：**
```text theme={null}
仅在工具能实质提升回答质量时使用工具。
规则：
- 如果问题是概念解释或只依赖用户提供的上下文，请直接回答。
- 涉及当前价格、版本、事故或政策时，先搜索再下结论。
- 进行删除、购买、发送消息或外部写入前，必须先请求确认。
- 如果同一个工具连续失败两次，停止重试并说明阻塞点。
- 工具参数保持最小、明确、具体。
```
## 思考与推理
### 控制推理深度
当任务涉及规划、调试、权衡或长链路执行时，可以明确要求模型深入分析；当任务只是抽取、改写或排版时，建议要求模型直接回答。
**效果欠佳：**
```text theme={null}
每个请求都一步一步思考，然后回答。
```
**效果更佳：**
```text theme={null}
请对这个迁移方案进行更深入的分析。
先分析：
- 兼容性风险
- 数据迁移顺序
- 回滚策略
- 发布前必须通过的测试
然后只返回最终方案：
1. 推荐方案
2. 关键风险与缓解措施
3. 发布检查清单
4. 待确认问题
最终回答中的推理过程保持简洁，不要输出隐藏思维链或无关探索。
```
对于简单请求，可以明确说明不需要深度分析：
```text theme={null}
从下面文本中抽取公司名称。只返回 JSON 数组，不需要解释。
```
### 降低幻觉
对于模型可能编造事实的任务——引用、API 接口、版本相关行为、客户数据——请明确授权它可以拒绝回答，并提供它可以引用的参考资料。
**效果欠佳：**
```text theme={null}
回答用户的账单问题。
```
**效果更佳：**
```text theme={null}
仅根据下方政策回答用户的账单问题。
政策：
[账单政策]
如果政策无法支持答案，请回复：
"我无法根据现有政策确认这一点——请联系账单支持。"
请在回答末尾引用你所依据的具体政策原文。
```
降低幻觉有三种常用做法：
* **允许拒绝** —— 明确告诉模型在不知道时应该怎么回答。
* **来源引用** —— 要求模型引用或标注它所使用的素材。
* **先约束、再生成** —— 在任务之前说明允许使用的来源、时间范围或产品版本，而不是之后再补。
## 长任务与 Agentic 工作流
对长时间运行的任务，每次只给模型少量当前目标。这样更有利于模型维持状态、记录决策，并避免同时推进太多半相关任务。
### 单窗口状态跟踪
模型可以在一个长上下文窗口内保持较强的任务状态。建议把当前计划、进度和待确认问题保留在 Prompt 或项目记录中。
在支持上下文压缩的工具中使用时，例如 Claude Code，请保持 system prompt 简洁。模型在临近上下文容量阈值时，可能出现任务提前终止。
### 多窗口工作流
当任务天然可以分阶段推进时，使用多个窗口。
第一个窗口搭建框架、测试和脚本，后续窗口继续遍历剩余任务。
要求模型创建 `tests.py` 或 `tests.json` 跟踪测试，有助于长期迭代。
创建 `init.sh` 启动服务器、运行测试，避免新窗口重复操作。
单个连续任务适合压缩。新任务或方向大幅变化时，建议开启新窗口。
要求模型在进入下一部分前，把当前部分彻底完成。
长任务建议的 system prompt：
```text theme={null}
这是一项非常冗长的任务。请充分利用可用上下文窗口。进入下一部分前，请先彻底完成当前部分，避免任务完成前耗尽 tokens。
```
## 评估与迭代
对重要 Prompt，建议像管理产品配置一样管理。保留一小组评估样例，对比不同 Prompt 版本，并记录每次修改的原因。
**效果欠佳：**
```text theme={null}
随便试几个 Prompt，直到答案看起来更好。
```
**效果更佳：**
```text theme={null}
Prompt 迭代流程：
1. 定义成功标准 —— 正确性、格式遵循、工具调用准确性、语气。
2. 准备 10-30 个代表性测试样例，包含边界情况。
3. 用当前 Prompt 和候选 Prompt 跑同一批样例。
4. 并排比较输出，记录退化案例。
5. 只有当候选 Prompt 提升目标指标，且没有破坏必需行为时，才更新 Prompt。
6. 保存简短变更记录 —— 改了什么、为什么改、哪些样例变好了。
```
这个流程可以避免只为了某一个漂亮示例优化 Prompt，却无意中破坏其他常见场景。