MiniMax 官方：M 系列提示词最佳实践

摘要

这是本批资料中最完整、最适合直接转成 M3 使用规范的来源。官方文档覆盖一般提示词、输出格式、长上下文、工具调用、思考深度、Agent 长任务和提示词评测迭代。

可直接采用的提示词规则

1. 任务、约束、优先级和期望输出必须明确；官方黄金规则是：让一个不了解上下文的同事阅读提示词，如果他会困惑，模型也会困惑。

2. 解释约束背后的原因，帮助模型在格式、安全、可访问性和工作流之间做取舍。

3. 困难的分类、抽取和边界任务使用 3–5 个相关、差异化、具体的示例。

4. 重复任务使用带命名变量的模板，便于比较版本、定位回归和保持行为稳定。

5. 用 Task、Context、Source、Constraints、Output format 等短标签分隔内容，避免深层嵌套。

6. 长上下文中把任务放在 source 之后；对 source 编号、加日期和清晰边界；来源冲突时定义优先级。

7. 工具提示词要写清工具目的、何时使用、何时不要使用、参数、返回结构和失败行为。

8. 明确停止规则：工具失败两次就停止重试并解释阻塞；不要为了“显得忙”而调用工具。

9. 对复杂规划、调试和权衡要求深入推理；对抽取、改写、格式化要求直接输出，不要固定要求每次都深度思考。

10. 允许模型拒答并引用依据，以降低版本、价格、政策和 API 行为方面的幻觉。

11. 长任务保持少量活动目标，把计划、状态和未决问题放在可见上下文中；必要时分窗口处理。

12. 为重要提示词准备 10–30 个代表性测试用例，比较候选版本、记录回归并维护变更日志。

推荐的 M3 编程提示词骨架

Task: [要完成的具体任务]
Context: [项目背景、技术栈、为什么这样做]
Source: [文件、日志、需求或接口资料]
Constraints:
- [必须遵守的边界]
- [何时使用工具，何时不要使用]
- [失败时如何处理]
Process:
1. 先检查现有项目和测试。
2. 先给出计划，再实施。
3. 每次修改后运行相关验证。
Output format:
- Summary
- Changed files
- Tests and results
- Remaining risks

原文阅读

本站仅展示 Tabbit 编辑摘要和必要节选；完整内容、上下文与最新版本请查看原始来源。

限制

这是官方通用 M-series 文档，不是只针对 M3 的单任务实验；官方示例应作为骨架，仍需用自己的项目测试。