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